Business Processes and Enterprise Systems

1
Introduction to Business Processes, BPM,and BPM Systems

Module 001 | Introduction to Business

Processes

It is very common, in industrial settings, that the performed activities are

repetitive and have several persons involved. In these cases, it is very useful
to define a standard procedure that everyone can follow. A business process,
essentially, is the definition of such “standard procedure”.
Since the process aims at standardizing and optimizing the activities of the
company, it is important to keep the process up to date and as flexible as
possible, in order to meet the market requirements and the business
objectives.

Objectives:

1. Understand the actual definition and characterization of

business processes and on the different languages that can be
used to describe them.
2. Know the main components of Business Process Management
systems

Business Processes

There are several definitions of “business process”. The first, presented in by

Hammer and Champy, states that a business process is a collection of activities
that takes one or more kinds of input and creates an output that is of value to
the customer. A business process has a goal and is affected by events
occurring in the external world or in other processes.
In another work, by Davenport, a business process is defined as a structured,
measured set of activities designed to produce a specified output for a
particular customer or market. A process is thus a specific ordering of work
activities across time and place, with a beginning, an end, and clearly
identified inputs and outputs: a structure for action.
In both cases, the main focus is on the “output” of the actions that must take
place. The problem is that there is no mention to the originators (i.e., the
executors) of such activities and how they are interoperating.
A business process is viewed as something that: (a) contains purposeful
activities; (b) is carried out, collaboratively, by a group of humans and/or
machines;(c) often crosses functional boundaries; (d) is invariably driven by
the outside world.

Course Module
van der Aalst, Weijters and Medeiros gave attention to the originators of the
activities: by process we mean the way an organization arranges their work
and resources, for instance the order in which tasks are performed and which
group of people are allowed to perform specific tasks.
Ko, in his “A Computer Scientist’s Introductory Guide to Business Process
Management”gave his own definition of business process: a series or network
of value-added activities, performed by their relevant roles or collaborators, to
purposefully achieve the common business goal.
A formal definition of business process is presented by Agrawal, Gunopulos
and Leymann:
A business process P is defined as a set of activities VP = {V1,...,Vn}, a directed
graph
GP = (VP , EP ), an output function oP : VP → Nk and ∀(u, v) ∈ EP a boolean
function f(u,v) = Nk → {0, 1}.
In this case, the process is constructed in the following way: for every
completed activity, the value oP (u) is calculated and then, for every other
activity v, if f(u,v)(oP(u))is “true”, v can be executed. Of course, such
definition of business process is hard to be handled by business people, but is
useful for formal modeling purposes.
More general definitions are given by standards and manuals. For example,
the glossary of the BPMN manual describes a process as “any activity
performed within a company or organization”. The ISO 9000 [125] presents a
process as:a set of activities that are interrelated or that interact with one
another. Processes use resources to transform inputs into outputs. Processes
are interconnected because the output from one process becomes the input for
another process. In effect, processes are “glued” together by means of such
input output relationships.
Right now, no general consensus has been reached on a specific definition.
This lack is due to the size of the field and to the different aspects that every
definition aims to point out.
In the context of this work, it is not important to fix one definition: each
definition highlights some aspects of the global idea of business process. The
most important issues that should be covered by a definition of business
process are:
1. There is a finite set of activities (or tasks) and their executions are
partially ordered (it’s important to note that not all the activities are
mandatory in all the process executions);
2. Each activity is executed by one or more originators (can be humans
or machines or both);
3. The execution of every activity produces some output (as a general
notion, with no specific requirement: it can be a document, a service
or just a “flag of state” set to “executed”) that can be used by the
following activity.
This is not intended to be another new definition of business process, but it’s
just a list of the most important issues that emerge from the definitions
reported above.
 Business Processes and Enterprise Systems
3
Introduction to Business Processes, BPM,and BPM Systems

Representation of Business Processes

Closely related to Business Processes is Business Process Management

(BPM). Van der Aalst, ter Hofstede and Weske, in , define BPM as: supporting
business processes using methods, techniques, and software to design, enact,
control, and analyze operational processes involving humans, organizations,
applications, documents and other sources of information.
From this definition, it clearly emerges that two of the most important
aspects of BPM are design and documentation. The importance of these two
tasks is clear if one thinks about the need to communicate some specific
information on the process that has been modeled. The main benefits of
adopting a clear business model can have summarized in the following list:
 it is possible to increase the visibility of the activities, that allows the
identification of problems (e.g. bottlenecks) but also areas of potential
optimization and improvement;
 grouping the activities in “department” and grouping the persons in
“roles”, in order to better define duties, auditing and assessment
activities.
For the reasons just explained, some characteristics of a process model can
be identified. The most important one is that a model should be
unambiguous, in the sense that the process is precisely described without
leaving uncertainties to the potential reader.
There are many languages that allow the modeling of systems and business
processes. The most used formalisms for the specification of business
processes have in common to be graph-based representations, so that nodes,
typically, represent the process tasks (or, in some notations, also the states
and the possible events of the process); arcs represent ordering relations
between tasks (for example, an arc from node n1 to n2 represents a
dependency in the execution so that n2 is executed only after n1). Two of the
most important graph based languages are: Petri nets and BPMN.

Petri Nets
Petri nets, proposed in 1962 in the Ph.D. thesis of Carl Adam Petri [119],
constitute a graphical language for the representation of a process. In
particular, a Petri net is a bipartite graph, where two types of nodes can be
defined: transitions and places. Typically, transitions represent activities that
can be executed, and places represent states (intermediate or final) that the
process can reach. Edges, always directed, must connect a place and a
transition, so an edge is not allowed to connect two places or two transitions.
Each place can contain a certain number of tokens and the distribution of the
tokens on the network is called “marking”. In Fig. 2.1 a small Petri net is
shown; circles represent places, squares represent transitions.

Course Module
Petri nets have been studied in depth from many points of view, such as from
their clear semantic to a certain number of possible extensions (such as time,
color, etc.). A formal definition of Petri net is the following:
Petri net
A Petri net is a tuple (P, T, F) where: P is a finite set of places; T is a finite set
of transitions, such that P∩T = ∅, and F ⊂ (P×T) ∪ (T ×P) is a set of directed
arcs, called flow relation.
The “dynamic semantic” of a Petri net is based on the “firing rule”: a
transition can fire (i.e., be executed) if all its “input places” (places with edges
entering into the transition) contain at least one token. The firing of a
transition generates one token for all its “output places” (places with edges
exiting from the transition). The distribution of tokens among the places of a
net, at a certain time, is called “marking”. With this semantic, it is possible to
model many different behaviors, for example, in Fig. 2.2, three basic
templates are proposed. The sequence template describes the causal
dependency between two activities (in the figure example, activity B requires
the execution of A); the AND template represents the concurrent branching
of two or more flows (in the figure example, once A is terminated, B and C
can start, in no specific order and concurrently); the XOR template defines
the mutual exclusion of two or more flows (in the figure example, once A is
terminated, only B or C can start). Figure 2.3 proposes the same process of
Fig. 2.2 with a different marking (after the execution of activities A, B and C).
An important subclass of Petri nets is the Workflow nets (WF-net), whose
most important characteristic is to have a dedicated “start” and “end”:
 Business Processes and Enterprise Systems
5
Introduction to Business Processes, BPM,and BPM Systems

WF-net
A WF-net is a Petri net N = (P, T, F) such that:
a. P contains a place i with no incoming arcs (the starting point of the
process);
b. P contains a place o with no outgoing arcs (the end point of the
process);
c. If we consider t ∈/ P ∪ T, and we use it to connect o and i (so to obtain
the so called “short-circuited” net: N = (P, T ∪ {t}), F ∪ {(o, t), (t,i)}),
the new net is strongly connected (i.e. there is a direct path between
any pair of nodes).

Business Process Modeling and Notation (BPMN)

Business Process Modeling and Notation is the result of an agreement among

multiple tool vendors that agreed on the standardization of a single notation.
For this reason, now it is used in many real cases and many tools adopt it
daily. BPMN provides a graphical notation to describe business processes,
which is, at the same time, intuitive and powerful (it is able to represent
complex process structure). It is possible to map a BPMN diagram to an
execution language, BPEL (Business Process Execution Language).
The main components of a BPMN diagram presented in Fig. 2.4areEvents,
Activities, Gateway, Sequence and Message Flows and Associations.

Course Module
Events: defined as “something that “happens” during the course of a
process”; typically, they have a cause (trigger) and an impact (result). Each
event is represented with a circle (containing an icon, to specify some
details), as in Fig. 2.4(d). There are three types of events: start (single narrow
border), intermediate (single thick border) and end (double narrow border).
Activities: This generic term identifies the work done by a company. In the
graphical representation they are identified as rounded rectangles. There are
few types of activity like tasks (a single unit of work, Fig. 2.4(a)) and sub-
processes (used to hide different levels of abstraction of the work, Fig.
2.4(e)).

Gateway: structure used to control the divergences and convergences of the

flow of the process (fork, merge and join). An internal marker identifies the
type of gateway, like “exclusive” (Fig. 2.4(b), on the left), “event based”,
“inclusive”, “complex” and “parallel” (Fig. 2.4(b), on the right).
Sequence and Message Flows and Associations: connectors between
components of the graph. A sequence flow (Fig. 2.4(c), top) is used to indicate
the order of the activities. Message flow (Fig. 2.4(c), bottom) shows the flow
of the messages (as they are prepared, sent and received) between
participants. Associations (Fig. 2.4(c), middle) are used to connect artifacts
with other elements of the graph.
Beyond the components just described, also other entities can appear in a
BPMN diagram, such as artifacts (e.g. annotations, data objects) and swim
lanes.
Figure 2.5 proposes a simple process fragment. It starts on Friday, executes
two activities (in the figure, “Receive Issue List” and then “Review Issue List”)
 Business Processes and Enterprise Systems
7
Introduction to Business Processes, BPM,and BPM Systems

and then checks if a condition is satisfied (“Any issues ready”); if this is the
case, a discussion can take place a certain number of times (“Discussion
Cycle” sub process), otherwise the process is terminated (and the “End
event” is reached, marked as a circle with the bold border). There are,
moreover, intermediate events (marked with the double border): the one
named A is a “throw event” (if it is fired, the flow continues to the
intermediate catch event, named A, somewhere in the process but not
represented in this figure); the B is a “catch event” (it waits until a throw
events fires its execution).

Yet another Workflow Language (YAWL)

YAWL (Yet Another Workflow Language) is a workflow language born from a

rigorous analysis of the existing workflow patterns.
The starting point for the design of this language is the identification of the
differences between many languages: out of this, authors collected a
complete set of workflow patterns. This set of possible behaviors inspired
authors to develop YAWL, which starts from Petri net and adds some
mechanisms to allow a “more direct and intuitive support of the workflow
patterns identified”. However, as authors stated, YAWL is not a “macro”
package on top of high-level Petri nets: it is possible to map a YAWL model to
any other Turing complete language. Figure 2.6 presents the main
components of a YAWL process. The main components of a YAWL model are
Task, Conditions, Splits and Joins and Cancellation Areas.
Task: represents an activity, as in Fig. 2.6(a). It is possible to execute
multiple instances of the same task at the same time (so to have many
instances of the process running in parallel). Composite tasks are used to
define hierarchical structure: a composite task is a container of another
YAWL model.

Course Module
 Conditions: a condition Fig. 2.6(b) in YAWL has the same meaning of “place”
for Petri nets (i.e. the current state of the process). There are two special
conditions, i.e., “start” (with a triangle inscribed) and “end” (with a square
inscribed), like for WF-nets.
Splits and Joins: a task can have a particular split/join semantic. In
particular, it is possible to have tasks with an AND (whose behavior is the
same of the Petri net case, presented in Fig. 2.2(b)), XOR (same as Petri net,
Fig. 2.2(c)) or semantic. In the last case, one or more outgoing arcs are
executed2.
Cancellation Areas: all the tokens in elements within a cancellation area
(the dotted area in Fig. 2.6(d)), are removed after the activation of the
corresponding task (whose enabling does not depend on the tokens on the
cancellation area).

Declare
Imperative process modeling languages such as BPMN, Petri nets, etc., are
very useful in environments that are stable and where the decision
procedures can be predefined. Participants can be guided according to such
process models. However, they are less appropriate for environments that
are more variable and that require more flexibility. Consider, for instance, a
doctor in a hospital dealing with a variety of patients that need to be handled
in a flexible manner. Nevertheless, some general regulations and guidelines
can be followed. In such cases, declarative process models are more effective
than the imperative ones. Instead of explicitly specifying all possible
sequences of activities in a process, declarative models implicitly define the
allowed behavior of the process with constraints, i.e., rules that must be
followed during execution. In comparison to imperative approaches, which
produce “closed” models (what is not explicitly specified is forbidden),
declarative languages are “open” (everything that is not forbidden is
allowed). In this way, models offer flexibility and at the same time remain
compact.
While in imperative languages designers tend to forget incorporating some
possible scenarios (e.g., related to exception handling), in declarative
languages, designers tend to forget certain constraints. This leads to under
specification rather than over specification, i.e., people are expected to act
 Business Processes and Enterprise Systems
9
Introduction to Business Processes, BPM,and BPM Systems

responsibly and are free to select scenarios that may seem out-of-the-
ordinary at first sight.

Figure 2.7 shows a simple Declare model with some illustrative constraints
for an insurance claim process. The model includes eight activities (depicted
as rectangles, e.g., Create Questionnaire) and six constraints (shown as
connectors between the activities, e.g., not co-existence). The not co-
existence constraint indicates that Low Insurance Check and High Insurance
Check can never coexist in the same trace. On the other hand, the co-
existence constraint indicates that if Low Insurance Check and Low Medical
History occur in a trace, they always co-exist. If High Medical History is
executed, High Insurance Check is eventually executed without other
occurrences of High Medical History in between. This is specified by the
alternate response constraint. Moreover, the not succession constraint
means that Contact Hospital cannot be followed by High Insurance Check.
The precedence constraint indicates that, if Receive Questionnaire Response
is executed, Send Questionnaire must be executed before (but if Send
Questionnaire is executed this is not necessarily followed by Receive
Questionnaire Response). Finally, if Create Questionnaire is executed, it is
eventually followed by Send Questionnaire as indicated by the response
constraint.

Other Formalisms

The language for the definition of business processes, briefly presented in the
previous sections, are only a very small fragment of all the available ones. In
Table 2.1 some standards are proposed, with their background (either
academic or industrial), the type of notation they adopt, if they are
standardized somehow, and their status.
When all these aspects are provided, the system is called “BPMS”. These
aspects are provided if the system contains:
 an orchestration engine, that coordinates the sequencing of activities
according to the designed flow and rules;

Course Module
  A business intelligence and analysis tools, that analyze data produced
during the executions. An example of this kind of tools is the Business
Activity Monitoring (BAM) that provides real-time alerts for a
proactive approach;
 a rule engine, that simplifies the changes to the process rules and
provides more abstraction from the policies and from the decision
tables, allowing more flexibility;
 a repository that stores process models, components, documents,
business rules and all the information required for the correct
execution of the process;
 tools for simulation and optimization of the process, that allow the
designer to compare possible new process models with the current
one in order to get an idea of the possible impact into the current
production environment;
 An integration tool that links the process model to other components
in order to execute the process activities.

From a more pragmatic perspective, the infrastructure that seems to be the

best candidate in achieving all the objectives indicated by BPM is the Service-
Oriented Architecture (SOA).
With the term SOA, we refer to a model in which automation logic is
decomposed into smaller, distinct units of logic. Collectively, these units
constitute a larger piece of business logic; individually these can be
distributed among different nodes. An example of such composition is
presented in Fig. 2.8.
 Business Processes and Enterprise Systems
11
Introduction to Business Processes, BPM,and BPM Systems

Business Service - A discrete unit of business activity, with significance to the

business, initiated in response to a business event, that can’t be broken down
into smaller units and still be meaningful (atomic, indivisible, or elementary).
This term indicates the so-called “internal requirements” of an Information
System, in opposition to the “external” ones, identified as Use Cases: a single
case in which a specific actor will use a system to obtain a particular business
service from one system. In authors’ opinion, this separation simplifies the
identification of the requirements and can be considered a methodological
approach to the identification of the components of the system.
In the context of SOA, one of the most promising technologies is represented
by Web services. In this case, a Web service is going to represent a complex
process that can span even more organizations. With the Web services
composition, complex systems can be built according to the given process
design; however, this is still a young discipline and industries should be more
involved in the standardization process.

Glossary
Business Process Management: supporting business processes using
methods, techniques, and software to design, enact, control, and analyze
operational processes involving humans, organizations, applications,
documents and other sources of information.

Course Module
 Business Process Modeling and Notation: The result of an agreement
among multiple tool vendors that agreed on the standardization of a single
notation.
Business Service: A discrete unit of business activity, with significance to
the business, initiated in response to a business event, that can’t be broken
down into smaller units and still be meaningful (atomic, indivisible, or
elementary).

References
Books and Journals:
1. Motiwalla, L., Thompson, J. (2012).Enterprise Systems for
Management 2nd Edition. New Jersey: Pearson Education, Inc.
2. Magal, S., Word, J. (2011). Integrated Business Processes with ERP
Systems 1st Edition. New Jersey: Wiley
Online Supplementary Reading Materials:
1. Introduction to Business Processes, BPM and BPM Systems;
http://www.springer.com/cda/content/document/cda_downloaddoc
ument/9783319174815-c2.pdf?SGWID=0-0-45-1506178-p177331342
May 10, 2017
2. Introduction to Business Process Management;
https://www.slideshare.net/alanmcsweeney/introduction-to-
business-process-management; May 10, 2017
3. Introduction To Business Process Management;
https://static1.squarespace.com/static/50c9c50fe4b0a97682fac903/t
/558ad9c6e4b0bab95f42a464/1435163078065/BPMIntroduction.pdf
; September 7, 2017
Online Instructional Videos:
1. An Introduction to Business Process Management;
https://www.youtube.com/watch?v=_YXqnEXnnBk&t=105s; August
31, 2017
2. What is BPM (Business Process Management) in 3 Minutes;
https://www.youtube.com/watch?v=XtvIU0ZCwjE; August 31, 2017
3. BPM Basics: An Introduction to Business Process Management;
https://www.youtube.com/watch?v=hAsRTy7UlN4; September 7,
2017