Monday, September 7, 2009

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec N -- By Mathias Weske

Event-driven Process Chains Definition

A tuple A = (E, F, V, m,C) is an event-driven process chain,
if
• E is a nonempty set of events
• F is a nonempty set of functions
• V is a set of connectors
• m : V 7! {and, or, xor} is a mapping that assigns to each connector a
connector type, representing and, or, and exclusive or semantics.
• Let K = E [ F [ V . C  K × K is a set of edges connecting events,
functions, and connectors such that the following conditions hold:
– (K,C) is a connected graph
– Each function has exactly one incoming edge and exactly one outgoing
edge.
– There is at least one start event and at least one end event. Each start
event has exactly one outgoing edge and no incoming edge. Each end
event has exactly one incoming edge and no outgoing edge. There is at
least one start event and one end event. All other events have exactly
one incoming edge and one outgoing edge.
– Each event can only be followed (possibly via connectors) by functions,
and each function can only be followed (possibly via connectors) by
events.
– There is no cycle in an event-driven process chain that consists of
connectors only.
– No event is followed by a decision node, i.e., an or split node or an
exclusive or split node.

Depending on the connector used, the occurrence of one event (exclusive
or join connector), the occurrence of two events (and join connector), or the
occurrence of any nonempty subset of events (or join connector) triggers a
function F. There is no surprise with respect to the semantics of the connectors:
an exclusive or connector triggers F after either E1 or E2 has occurred;
for the and connector to trigger the function, both events must occur, and
the or connector triggers F after any nonempty subset of events E1 and E2
has occurred.
The execution semantics of the split connectors follows the traditional way: an exclusive or split connector represents the business logic that after F,
either event E1 or event E2 occurs. The decision about which event actually
occurs during a particular process instance is made by function F. Analogous
considerations hold for the or split connector, where any nonempty subset of
events {E1,E2} can occur after F. The and split connector determines that
after function F, both events E1 and E2 occur.
Event-driven
process chains start with events (never with functions), since a function is always a consequence of an event and cannot therefore be performed without
the state change represented by the event.
When an order is received, it is analyzed and either accepted or rejected.
When it is accepted, the stock is checked for availability of the ordered products.
If all products are in stock, then the products are shipped and the bill
is sent. In case there are additional bills open, the payment will need to include
these open bills. The other parts of the event-driven process chains deal
with the manufacturing of products if the ordered products are not in stock.
While most constructs of event-driven process chains can be explained in this
example, the process is a severe simplification of real-world ordering processes.
While the process aspect in terms of the functions and events that occur in
business processes is well captured by event-driven process chains, there are
other types of diagrams that abstract from the relatively fine-granular level
of event-driven process chains.
Interaction flow diagrams provide a high-level view on the organizational
entities that participate in a business process, as well as their interactions.
An interaction flow diagram is a directed graph, whose nodes correspond to
organizational entities and whose edges represent interactions between the
organizations.
The interaction flow diagram shown describes at a high level of abstraction
a business process in which a customer sends an order to the marketing and
sales department, which triggers the purchase of raw material, before operations manufactures the products and finally ships them to the customer, who
pays for ordered products.
While the overall interactions are properly represented in interaction flow
diagrams, the ordering in which these interactions actually occur is not in the
scope of interaction flow diagrams. For instance, the two interactions between
customer and sales are not ordered in the diagram.
However, the reader of an interaction diagram might be able to deduce
the ordering of interactions by common sense. For instance, placing an order
is done before paying for the ordered item. The diagram itself abstracts from
these ordering relationships and, therefore, provides an abstract, high-level
representation of the organizational entities involved in a business process
and their relationships through interactions.
Function flow diagrams are a refinement of interaction flow diagrams in
the sense that they (i) represent the ordering of interactions and (ii) provide
coarse-grained functions for representing these interactions.The latter includes functions and
an ordering relationship between these functions, indicating that the entering
of the order precedes the processing of the order by the marketing and sales
department.
In addition to the functions and their ordering, split and branch ing nodes are introduced. Function flow diagrams provide information on the
coarse grained functions involved in a business process, as well as the organizational
entities that perform them. In addition, the ordering of these functions
is also represented in function flow diagrams.
In the sample function flow diagram it is clarified that planning the manufacturing
and purchasing of material are performed concurrently, but the item
is only manufactured after the supplier has processed the order and manufacturing
has received the material. The function flow diagram also models
the fact that payment of the received material is performed concurrently to
manufacturing the item.
To summarize, function flow diagrams provide high-level information on
the functions in a business process and on the organizational entities that perform
them and their ordering. Events of the business process are not covered
by function flow diagrams.
Additional views are represented by enhancing event-driven process chains
with notational symbols for data involved as well as for process paths and
process groups. Data and material are represented by rectangles, associated
with functions by solid arrows. The direction of the arrows indicates whether
the data is used for input or output (or both). Process groups hold a collection
of processes, and process paths indicate where the process continues.This part consists of a single function to analzye an order and its environment.
When the order arrives, the function is triggered, represented by the respective
event. In order to check the order, the order document and the stock status
are used as input data.
We assume the function is performed by the operations department. When
the function completes, the result is recorded in the check result data object.
The function is also responsible for creating the respective event: either the
products are in stock or the products are not in stock and need to be manufactured.
Event-driven process chains allow us to model business processes from a
business perspective. The explicit representation of the occurrence of relevant
situations by events and the bipartite structure, in which events and functions
alternate, lead to verbose and often actually quite complex process representations.
Due to their semiformal nature, business engineers and process designers
enjoy a fair degree of freedom when expressing business processes. When
it comes to implemented business processes, process designers and systems
engineers need to make explicit what was intended by the EPC.
The or join is an important control flow construct in EPCs, which is used
quite often, because it allows us to represent any type of join behaviour.
Due to the nonlocal semantics, the decision on when the join needs to be
performed cannot be taken without nonlocal knowledge.
Since event-driven process chains are primarily used to model business
processes at a business level, typically humans interpret event-driven process
chains. Since humans, when assessing an EPC, have nonlocal knowledge, the
semantics of the or join is clear to them.
The problems start when an EPC needs to be translated into an executabe
format, for instance, to serve as input for a workflow management system to
control the enactment of business processes. There are approaches in handling
the or join semantics, based on global state transition systems; for details,
the reader is referred to the bibliographical notes.