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

Event-driven Process Chains

Event-driven process chains are an important notation to model the domain
aspects of business processes. The main focus of this rather informal notation
is on representing domain concepts and processes rather than their formal
aspects or their technical realization. Event-driven process chains are part
of a holistic modelling approach, called the ARIS framework; ARIS stands for Architecture of Integrated Information Systems, and it was developed by
August-Wilhelm Scheer.
The pillars reflect data, control and function,
while the roof reflects the overall organization. In each area, three levels of
abstraction are identified: a concept level, an architecture level, and an implementation
level, characterized by the terms Requirements Definition, Design
Specification, and Implementation Description, respectively.
The concept level is the highest level of abstraction in which data, control
and function are modelled. This level looks at nontechnical requirements of
business processes and their execution environment. Business goals and functions
are typical artefacts in the function view at this level. The data view is
expressed by data modelling techniques using Entity Relationship diagrams.
In the control view, business processes are described by event-driven
process chains, which are also used to integrate the different views. The organizational
view at the concept level deals with the organizational structures
of a company, described by organizational diagrams. The architecture level is
the intermediate level, and it aims at bridging the gap between the concept
level and the implementation level. At the implementation level, steps towards
concrete realization of the business process are addressed.
This framework is specified by a set of metamodels that describe various
views, similar to the business process perspectives introduced in Chapter 3.
The main views are as follows.
• Functional View: The functional view represents the goals and subgoals of
the enterprise and their relationships. In general, one subgoal might contribute
to a number of goals at the higher level. For instance, the subgoal
“reduce business process execution time” contributes to the goals “increase
customer satisfaction” and “reduce overall cost.”
At a lower level of abstraction, each subgoal is associated with a set of
functions that contribute to goals and subgoals. Functions are then hierarchically
decomposed until the desired granularity of functions is achieved,
similarly to functional decomposition in value chains.
• Organizational View: The organizational view describes the organizational
structure of an enterprise at a type level and at an instance level. There
are detailed specifications of organizational entities, including their relationships
and positions, roles, skills, and individuals associated with them.
Administration information such as the address of an organizational entity
can be represented. The organizational view also includes organizational
aspects of information technology of the enterprise, including its main
operational information systems, its storage facilities, and its network infrastructure.
• Data View: The data view characterizes business relevant data objects that
are manipulated by functions during business process execution. Entity
Relationship diagrams are used for data modelling.
• Business Value View or Output View: The business value view describes
the outcome of business processes, i.e., the products and services the enterprise
generates. These can be physical goods like automobiles or electronic
devices, as well as intangible goods, such as a processed order or a flight
booking.
These views are integrated in a control view. This control view provides linkage
between the artefacts in the different views. Functions, for instance, are
associated with the organizations that are responsible for conducting these
functions. Analogously, data and business value artefacts are associated with
functions, data, and organization, providing an integrated view of the business
processes of an enterprise.
Process modelling uses event-driven process chains. The main building
blocks of event-driven process chains are events, functions, connectors, and
control flow edges, as shown in Figure 4.33.
The entering of a business-relevant state is represented by an event in an
event-driven process chain. Examples of events are the receipt of an order, the
completion of processing an order, and the completion of shipping a product.
In event-driven process chains, events are represented by hexagons. Events
are marked by a string, often of the type order is received, indicating a business
relevant object (order) and the state change that has occurred to this object (is received). Events trigger functions, and functions are triggered by events.
Events are passive elements in the sense that they do not provide decisions.
Functions represent units of work. The granularity of these functions depends
on the modelling purpose. In general, functions in event-driven process
chains are at a rather low level of granularity; their contribution to functions
at higher levels of granularity or to business goals is specified in the functional
view.
Unlike events, functions are active elements that take input and transform
it to output. Input and output can be information products or physical products.
Functions can also make decisions that influence the behaviour of the
process through connector nodes associated with the function. Functions are
triggered by events, and on the completion of a function, an event occurs. In
event-driven process chains, functions are represented by rounded rectangles.
Connectors are used to model causal ordering relations, i.e., to represent
the process logic. There are three types of connectors, for logical and, or, and
exclusive or (xor). These connectors serve both as split nodes and as join
nodes. Depending on the number of incoming edges, it can be determined if
a connector is a split connector or a join connector.
It is also possible that connectors serve at the same time as split connector
and join connector. In case split and join realize the same semantics (for
instance, both have and semantics), a connector with an and symbol suffices.
In case the split and join have different semantics, the connector can be divided
into an upper and a lower part, each of which holds a notational symbol. Other combinations
are also possible. Edges are used to provide the glue between events, functions,
and connectors. Event-driven process chains are defined as follows.