Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Analysis and optimization of business processes. Course of lectures
.pdf
{(ii,ei), (ei,bi)} In this case, Ei {ii,ei,bi,ti} and <I {(ii,ei), (ei,bi),
(bi,,ti)} satisfying the definition
Note that an activity instance can be skipped if it is in the init or
ready state. As a result, the enable event might or might not be in
the event set of a skipped activity instance.
The causal ordering of events indicated by this definition can be
graphically represented by event diagrams. In event diagrams, time
proceeds from left to right, and events are shown as bullets. The
causal relationships of events are represented by directed arcs.
Due to the nature of event diagrams, they form directed acyclic
graphs, where the nodes are events and the edges reflect causal
ordering between events. An event diagram for a particular activity
instance is shown in Figure 3.4.
In the event diagram shown in part (a) of that figure, an activity
instance that is properly executed is shown, while (b) shows the
events of a skipped activity instance. To illustrate the relationship
between state transition diagrams and event diagrams, each state
transition in the state transition diagram is associated with an event
in the respective event diagram.
The activity instance starts with a state transition to the unit
state. This state transition is represented by an initialize event in the
event diagram. An enable state transition brings the activity instance
in the ready state; this state transition is represented by an enable
event. An activity instance in the ready state can be started,
represented by the begin state transition.
Finally, the terminate state transition completes the activity
instance. Events are points in time, that is, events do not take time.
The time interval in which an activity instance is in one state is
delimited by two events, the event representing the state transition
to enter the state and the event representing the state transition to
leave the state. For example, the time interval in which the activity
instance is in the running state is delimited by the begin and
terminate events.
41
Figure 3.4. Event diagram for (a) executed activity instance
and (b) skipped activity instance
3.1. Process Models and Process Instances
Business processes consist of a set of related activities whose
coordinated execution contributes to the realization of a business
function in a technical and organizational environment. Business
processes are represented by business process models. Since this
section concentrates on the execution ordering of activities,
disregarding the technical and organizational environment of
business processes, the term process model is used. Figure 3.5
shows the layers of the Meta Object Facility for the process
subdomain. In the M0 layer there are process instances that reflect
the actual occurrences of a business process. Each process instance
is an instance of a process model in the model layer M1. Process
models are described by process metamodels, building the M2
layer.
42
In order to express process models, there needs to be a
notation in place that provides notational elements for the
conceptual elements of process metamodels.
For instance, if the process metamodel has a concept called
activity model, then there needs to be a notational element for
expressing activity models.
Therefore, in Figure 3.5, a process notation is associated with
the process metamodel level and with the process model level; each
process model is expressed in a process notation associated with
the process metamodel that describes the process model.
Figure 3.5. MOF levels of process aspect process model
in the model layer M1
Process models are described by process metamodels, building
the M2 layer.
In order to express process models, there needs to be a
notation in place that provides notational elements for the
conceptual elements of process metamodels. For instance, if the
process metamodel has a concept called activity model, then there
needs to be a notational element for expressing activity models.
43
Therefore, in Figure 3.5, a process notation is associated with
the process metamodel level and with the process model level; each
process model is expressed in a process notation associated with
the process metamodel that describes the process model.
3.2. Modelling Process Data
Business processes operate on data. Explicitly representing
data, data types, and data dependencies between activities of a
business process puts a business process management system in a
position to control the transfer of relevant data as generated and
processed during processes enactment.
3.2.1. Modelling Data
Figure 3.6. MOF levels of modelling data
Data modelling is at the core of database design. The Entity
Relationship approach is used to classify and organize data in a
given application domain. Entity Relationship modelling belongs to
the metamodel level, as depicted in Figure 3.6, because it provides
the required concepts to express data models. Data modelling will
be illustrated by a sample application domain, namely by order
44
management. In a modelling effort, the most important entities are
identified and classified.
Entities are identifiable things or concepts in the real world that
are important to the modelling goal. In the sample scenario, orders,
customers, and products are among the entities of the real world
that need to be represented in the data model.
Entities are classified as entity types if they have the same or
similar properties. Therefore, orders are classified by an entity type
called Orders. Since each order has an order number,
a date, a quantity, and an amount, all order entities can be
represented by this entity type. Properties of entities are
represented by attributes of the respective entity types. The entities
classified in an entity type need to have similar, but not identical
structure, because attributes can be optional. If the application
domain allows, for instance, for an order to have or not to have a
discount, then the amount attribute is optional. This means that two
orders are classified in entity type order even if one has a discount
attribute while another does not. Entity types in the Entity
Relationship metamodel need to be represented in a notation by a
particular symbol. While there are variants of Entity Relationship
notations, entity types are often represented by rectangles, marked
with the name of the entity type. Figure 3.7 shows an entity type
Orders at the center of the diagram. Other entity types in the
sample application domain are customers and products. The
attributes are represented as ellipsoids attached to entity types.
Entities are associated with each other by relationships. For
instance, a customer “Miller” requests an order with the order
number 42. These types of links between entities are called
relationships. Just as there are many customer entities and many
order entities, there are many customer-order relationships.
45
Figure 3.7. Entity relationship diagram involving customers, orders,
and products, O’Neil and O’Neil (2000)
To represent these relationships, a relationship type requests
classifies them all. In Entity Relationship diagrams, relationship types
are typically represented by diamond symbols, connected to the
respective entity types by edges. The complex nature of data in a
given application domain can be well represented by Entity
Relationship Diagrams. These diagrams can be used to create
relational database tables, using transformation rules. Once the
respective database tables have been created in a relational
database, application data can be stored persistently. The data can
be retrieved efficiently using declarative query languages, for
instance Structured Query Language. While this discussion focuses
on data modelling in the context of database applications, the same
data modelling method can be used to represent data structures in
business process management. Based on these data structures, data
dependencies between activities in business processes can be
captured precisely.
Data modelling is also the basis for the integration of
heterogeneous data. In the enterprise application integration
scenarios discussed above, one of the main issues was the
integration of data from heterogeneous data sources. Once data
models are available for these data sources, the data integration
problem can be addressed. There are advanced data integration
techniques that also take into account data at the instance level, but
46
explicit data models in general are essential to addressing data
integration.
Data integration can then be realized by a mapping between
the data types. For instance, there might be applications on top of
database systems A and B, such that these systems have tables
CustomerA and CustomerB, respectively, that differ. For instance,
while CName is the attribute of the CustomerA table, referring to
the name of the customer, CustN might be the respective attribute
in the CustomerB table. In order to integrate both tables, the
attributes need to be mapped. In this case, CustomerA.CName is
mapped to CustomerB.CustN.
In data integration projects, complex integration problems are
likely to emerge. There might be attributes that cannot be mapped,
but there might also be attributes that need to be mapped to
different tables, often by our using transformation rules. The hardest
set of problems, however, stem from semantic heterogeneity. There
are assumptions on the data that are not explicit in the data model
or in the actual data stored in the database. These semantic
differences can only be taken into account when investigating the
meaning of the attributes in detail, often during interviews with the
persons involved in the data modelling and database design of the
systems to integrate.
Semantic specification of data can be used to solve these data
integration problems. However, complete semantic specification of
data requires considerable resources, and the completeness of the
semantic specification cannot be proven automatically. Therefore,
further research is required to evaluate the possibilities of
semantics-based data integration.
In graph-based approaches to business process modelling, data
dependencies are represented by data flow between activities. Each
process activity is assigned a set of input and a set of output
parameters. Upon its start, an activity reads its input parameters,
and upon its termination it writes data it generated to its output
parameters. These parameters can be used by follow up activities in
the business process.
47
The transfer of data between activities is known as data flow. By
providing graphical constructs to represent data flow between
activities, the data perspective can be visualized and used to validate
and optimize business processes.
3.2.2. Workflow Data Patterns
To organize data-related issues in business process
management, workflow data patterns have been introduced.
Workflow data patterns formulate characteristics on how to handle
data in business processes. They are organized according to the
dimensions data visibility, data interaction, data transfer, and databased routing.
Data visibility is very similar to the concept of scope in
programming languages because it characterizes the area in which a
certain data object is available for access. The most important
workflow data patterns regarding data visibility are as follows.
– Task data: The data object is local to a particular activity; it is
not visible to other activities of the same process or to other
processes.
– Block data: The data object is visible to all activities of a given
subprocess.
– Workflow data: The data object is visible to all activities of a
given business process, but access is restricted by the business
process management system, as defined in the business process
model.
– Environment data: The data object is part of the business
process execution environment; it can be accessed by process
activities during process enactment.
Data interaction patterns describe how data objects can be
passed between activities and processes. Data objects can be
communicated between activities of the same business process,
between activities and subprocesses of the same business process,
and also between activities of different business processes.
Data can also be communicated between the business process
and the business process management system. Data transfer is the
48
next dimension to consider. Data transfer can be performed by
passing values of data objects and by passing references to data
objects. These data transfer patterns are very similar to call-by-value
and callby-reference, concepts used in programming languages to
invoke procedures and functions.
In data-based routing, data can have different implications on
process enactment. In the simplest case, the presence of a data
object can enable a process activity. Data objects can also be used
to evaluate conditions in business process models, for instance, to
decide on the particular branch to take in a split node.
Workflow data patterns are an appropriate means to organize
aspects of business processes related to the handling of data.
3.3. Modelling Organization
An important task of a business process management system is
the coordination of work among the personnel of an enterprise. To
fulfill this, the system has to be provided with information on the
organizational structures in which the business process will execute.
Figure 3.8. MOF levels of organization aspect
The levels of abstraction in organization modelling are shown in
Figure 3.8. As in process modelling and data modelling, the
49
metamodel level provides the means to express models, in this case
organizational models.
Concepts at this level are positions, roles, teams, and
relationships between positions like supervisor. In organization
modelling, there are a few formal rules on how to express
organizational structures, as well as notations to express them.
The general principle behind organization modelling is the
resource, an entity that can perform work for the enterprise. The
general concept of resource subsumes humans and other resources,
such as trucks, warehouses, and other equipment a company
requires to fulfill its goals.
Persons are part of an organization, typically a business
organization. The persons in these organizations work to fulfill the
business goals of the enterprise. Each person typically occupies
some position, and the duties and privileges of that person come
with the position, not with the person. This allows filling positions
according to an overall organizational plan. In addition, the
company can cope better with changes in personnel. Organizational
units are permanent groupings of persons based on their positions.
Organizational teams or project teams are specific organizational
units without a permanent nature. They are conceptualized in the
object model shown in Figure 3.9.
Figure 3.10 shows an organizational chart of a fictive enterprise.
In order for us to not overload that figure, it contains positions only
at the top levels, the chief executive level and the department level.
Departments are organizational units with a set of member
positions.
The link between the organizational structure of an enterprise
and the business processes is accomplished by work items. Work
items represent activity instances to be performed, and work items
are associated with knowledge workers to facilitate their selection
by knowledge workers. In particular, when the business process
management system determines that a certain activity instance
enters the ready state, a work item is offered to a set of knowledge
workers.
50
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]