Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Analysis and optimization of business processes. Course of lectures
.pdf
the functions an enterprise performs and neglecting their interplay
falls short of properly representing how enterprises work. Therefore,
functional decomposition is used as first step in the representation
of enterprises based on business processes.
Operational business processes relate activities to each other by
introducing execution constraints between them. In principle,
relating functions to business processes can be applied for different
granularities of business functions.
In case high-level business functions are considered,
a textual specification of the process is used, since concrete
execution constraints between their constituents are not relevant in
coarse-grained business functions. Consider, for instance, the
business functions incoming logistics and operations.
At this very coarse level of functionality, no ordering of these
business functions is feasible: both business functions are performed
concurrently, and only at a lower level of granularity does a concrete
ordering make sense. For instance, when the operations business
function orders additional material, then there are concrete activities
that have a concrete ordering. Within operations, an internal order is
created and sent to incoming logistics. On arrival of this order, raw
material is provided to operations. In case no raw material is
available at the manufacturing company, an external order is created
and sent to a supplier of the raw material. Therefore, business
processes relate fine-grained business functions, typically the leaves
of the business function decomposition tree.
In the example shown in Figure 2.5, the activities AnalyzeOrder,
SimpleCheck, and advanced check (AdvCheck) are related to each
other by execution constraints. The sample business process starts
with analyzing the order, and then conducting either a simple check
or an advanced check depending on the decision made during
process execution. This process has a dedicated start event and a
dedicated end event. The business process is started once the start
event occurs; when it completes, an end event occurs. Events play a
crucial role when interrelationships between business processes are
expressed.
31
Figure 2.5. Business functions of small granularity
are organized as a business process
A particular business function of higher granularity
(CheckOrder) consists of fine-grained activities, which are related by
execution constraints. However, the check order business function
(and the business process that realizes it) is related to other business
functions and their respective business processes. An example
showing this situation is displayed in Figure 3.6, where a part of the
value chain is shown, in particular, the business functions Receive
Request, Request Analysis, and Quota Management are shown.
Since there is a strict ordering between these business functions, an
execution ordering relation is represented.
32
Figure 2.6. Related business processes, high-level view
After the business process related to receiving the request is
processed, it generates its end event. This end event is the signal for
starting the second business process, related to request analysis.
Finally, the quota is prepared and the business process completes.
This discussion shows that business processes at a lower level can
be identified, as well as business processes at a higher level, that is,
those relating business functions.
The overall organization of these levels is depicted in Figure 2.7.
At the left hand side of this figure a UML structure diagram provides
a conceptual model of the entities involved. To recapitulate, each
enterprise is represented by a value chain, which consists of coarsegrained business functions that are decomposed into smallergrained business functions, realizing a functional decomposition.
Activities are functions of the finest granularity; they are the building
blocks of operational business processes.
When a business process is started, the business functions that
it contains need to be executed. Therefore, each activity in a
business process requires an implementation. The implementation
of an activity can be based on functionality provided by information
systems, such as registering a new customer or implementations
reserving a flight.
33
Figure 2.7. Levels of business process management.
From value systems to activity
34
However, an activity implementation can also be provided by a
knowledge worker without using information systems.
Definition 2.1. A functional decomposition of coarse-grained
business functions to fine-granular activities defines the functional
perspective of a business process.
The conclusions on the topic
1. Describes conceptual model and terminology
2. Describes the horizontal and vertical abstraction
3. Describes the business functions to business processes
Questions
1. Tell us about conceptual model and terminology.
2. Give the definition of the horizontal and vertical abstraction.
3. What do you know about business functions to business
processes?
35
TOPIC 3. ACTIVITY MODELS AND ACTIVITY INSTANCES
Plan of the lectures
3.1. Process Models and Process Instances
3.2. Modelling Process Data
3.2.1. Modelling Data
3.2.2. Workflow Data Patterns
3.3. Modelling Organization
3.3.1. Direct Allocation
3.3.2. Role-Based Allocation
3.3.3. Deferred Allocation
3.3.4. Authorization
3.3.5. Separation of Duties
3.3.6. Case Handling
3.3.7. History-Based Allocation
3.3.8. Organizational Allocation
3.4. Modelling Operation
Business functions provide a high-level, coarse-grained
representation of the work conducted by enterprises. Activities can
be found in the leaves of the functional decomposition. This section
investigates how activities can be described.
In addition, the actual work conducted during business
processes has to be characterized, that is, activity instances have to
be characterized. Note that activity models represent the M1 layer
of the Meta Object Facility, while the activity instance layer
corresponds to M0. Figure 3.1 shows the relationships between
business functions, activity models, and activity instances.
Notice that there are activity instances for case (Smith, 123212)
for all three activity models, even though either a simple check or an
advanced check is required. This aspect will be discussed shortly.
36
Figure 3.1. Activity models and activity instances
An activity model describes a set of similar activity instances,
analogously to a process model describing a set of process
instances with the same structure. While process models are
typically expressed in graph-like notations (to be investigated in
detail in the next chapter), activity models can be expressed in
different forms, for instance, by plain text or by some formal
specification or references to software components that implement
them.
Activity instances represent the actual work conducted during
business processes, the actual units of work. To make this discussion
more concrete, assume a process instance that represents the
processing of an insurance claim by Clara Smith on the damage
amount of US $2000, submitted November 11, 2006. Let EnterClaim
(Clara Smith, 2000, 11-11-2006) represent the activity instance
responsible for entering the claim in the respective software system
of the insurance company. When the company receives the claim, a
process instance is started. Within this process instance, the activity
instance Enter- Claim(Clara Smith, 2000, 11-11-2006) is started.
When the claim is entered in the system, this activity instance
terminates.
37
Each activity instance during its lifetime is in different states.
These states and the respective state transitions can be represented
by a state transition diagram. A simple state transition diagram for
activity instances is shown in Figure 3.2. The states that an activity
instance adopts during its lifetime are described as follows. When it
is created it enters the unit state; by the enable state transition the
activity instance can enter the ready state.
If a particular activity instance is not required, then the activity
instance can be skipped, represented by a skip state transition from
the not started state to the skipped state. From the ready state, the
activity instance can use the begin state transition to enter the
running state. When the activity instance has completed its work,
the terminate state transition transfers it to the terminated state.
When an activity instance is in the terminated or the skipped state,
then it is closed.
Figure 3.2. State transition diagram for activity instances
While the state transition diagram shown in Figure 3.2 properly
represents the states of most activity instances in business
processes, in real-world settings, activity instances are likely to
expose a more complex behavior.
Reasons for this complex behavior include disabling and
enabling activities, suspending running activities, and skipping or
undoing activities. The respective state transition diagram is shown
38
in Figure 3.3. It provides a more detailed view on the states of
activity instances.
The state transition diagram representing the complex behavior
of activity instances is a refinement of the state transition diagram
representing their simple behavior. All state transitions possible in
the simple diagram are also possible in the complex state transition
diagram. The activity instance is initiated, and it enters the ready
state before entering the running state. If it turns out that an activity
instance that is not started is not required then it enters the skipped
state.
Figure 3.3. State transition diagram for activity instances, detailed version
But the detailed state transition diagram shown in Figure 3.3
allows more complex behavior of activity instances. When an activity
instance can be activated, it enters the ready state. If during the
execution of a process instance certain activity instances are
currently not available for execution, they can be disabled. Activity
instances that are in the unit, disabled, or ready state are also in the
not started state. Once an activity instance is ready, it can be started,
entering the running state. Running activities can be temporarily
suspended, to be resumed later. An activity instance can terminate
39
either successfully or in failure. Terminated activity instances can be
undone, using compensation or transactional recovery techniques.
Based on the description of the behavior of an activity instance,
the question now arises on how to capture the actual behavior of a
concrete activity instance, that is, on how to specify the trace of
states and state transitions that the activity instance went through.
In this section, events and event orderings are introduced to
properly represent the essence of activity instances.
The basic idea of using events for representing activity
instances is quite simple: each state transition of an activity instance
is represented by an event. These events have a temporal ordering.
Based on the state transition diagram for activity instances, each
activity instance can be represented by a totally ordered set of
events. For the representation of activity instances by events, the
simple state transition diagram shown in Figure 3.2 suffices.
Definition 2.2. Let AM be a set of activity models and AI be a
set of activity instances. An activity instance i=(Ei,<i)AI based on an
activity model I AM is defined by a totally ordered set of events Ei
such that either.
activity instance i is executed, in which case Ei {ii,ei,bi,ti},
referencing the occurrence of state transitions initialize, enable,
begin, and terminate, respectively, and an event ordering <I {(ii,ei),
(ei,bi), (bi,,ti)}, or
activity instance i is skipped, in which case Ei {ii,ei,si}
referencing the occurrence of state transitions initialize, enable, and
skip, and an event ordering <I {(ii,si), (ii,ei), (ei,,si)}.
The function model : AI AM maps each activity instance to its
activity model, that is, model(i) = I.
We define the event set of an activity instance as a subset of
the complete event set, Ei {ii,ei,bi,ti} since during the execution of
an activity instance the events occur one after the other. Therefore,
any prefix of the totally ordered event set characterizes a valid state
of an activity instance.
If, for instance, an activity instance i has entered the running
state, it is characterized by i=(Ei,<i) such that Ei {ii,ei,bi} and <
I
40
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]