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

Workflow Nets

Event-driven process chains provide an informal notation for representing
business processes and their environment. To precisely specify and reason
about business processes, more formal approaches need to be investigated,
such as, Petri nets.
While Petri nets are very useful for representing simple types of processes,
complex processes such as business processes require advanced modelling
mechanisms. In particular, tokens need to carry information at least about
the process instance they belong to.
Workflow nets are an approach to enhance traditional Petri nets with
concepts and notations that ease the representation of business processes.
At the same time, workflow nets introduce structural restrictions that prove
useful for business processes.
The reasons for using Petri nets in general and workflow nets in particular
for business process modelling are as follows.
• Formal Semantics: Business processes can be defined in a formal manner.
This observation holds in particular for the control flow aspect of Petri
nets.
• Graphical Representation: Activities in a business process and their execution
constraints are expressed graphically in a Petri net, which eases
communication about business processes with the different stakeholders
involved (although some stakeholders prefer semiformal techniques like
event-driven process chains).
• Analysis of Process Properties: The formal semantics of business processes
expressed in Petri nets allows for the analysis of process properties.
• Tool Independence: Although several business process management tools
are based on Petri nets, the formalism itself is vendor independent.

Definitions

Like Petri nets, workflow nets focus on the control flow behaviour of a process. Places represent conditions and tokens represent process instances. Activities of a
business process are represented by transitions in the workflow net.
Because tokens represent business process instances, tokens hold application
data including process instance identifiers, i.e., the tokens are coloured.
However, in workflow nets, the colouring of tokens is not represented explicitly,
as will be discussed in more detail below.Workflow nets can be hierarchically structured.The internal structure of a complex
activity is realized by another dedicated workflow net. Hierarchical structuring
of workflow nets is not investigated in detail; in the context of the YAWL
process language, hierarchical structuring based on extended workflow nets is
studied.
Based on these considerations, workflow nets can be defined as Petri nets
with specific structural restrictions.
Definition 4.8 A Petri net PN = (P, T, F) is called workflow net if and only
if the following conditions hold.
• There is a distinguished place i 2 P (called initial place) that has no
incoming edge, i.e., •i = ;.
• There is a distinguished place o 2 P (called final place) that has no outgoing
edge, i.e., o• = ;.
• Every place and every transition is located on a path from the initial place
to the final place.
The rationale of this definition is as follows: a token in the initial place i
represents a process instance that has not yet started; a token in place o
represents a finished process instance. Each place and each transition in a
workflow net can participate in a process instance; therefore, each place and
each transition needs to be located on a path from i to o.
As a consequence of these structural properties of workflow nets, the initial
place i is the only place without incoming edges, and the final place is the
only place without any outgoing edges.
If there were another place i0 6= i 2 P without incoming edges, then i0
could not be located on a path from i to o, contradicting the definition of
workflow net. And if there were a place o0 6= o 2 P without outgoing edges,
then o0 could not be on a path from i to o. Therefore, places with the properties
of i0 and o0 cannot exist in workflow nets.
It represents a simple
claim management process in which, initially, the claim is recorded and, concurrently,
a witness report is created and the client status is checked. After
the results have been gathered, an assessment of the claim is performed. In
the case of a positive assessment, the damage is compensated. In the case of
a negative assessment, the claim is rejected. Finally the claim is filed and the
process completes.