‫ر‬

‫الجامعة السعودية االلكتونية‬

‫ر‬
‫االلكتونية‬ ‫الجامعة السعودية‬

‫‪26/12/2021‬‬
College of Computing and Informatics

IT342
Enterprise Systems
 IT342 - Enterprise Systems
Week 11 - Business Process Modeling and Notation
Part 2
Contents
1. Sample Purchasing Scenario Represented in Business Process
Modeling and Notation

2. Characteristics of Business Process Modeling and Notation for

Modeling Software Engineering Processes

3. Spreadsheet-Based Process Modeling

Weekly Learning Outcomes

1. Understand Sample Purchasing Scenario Represented in

Business Process Modeling and Notation
2. Understand the Characteristics of Business Process Modeling
and Notation for Modeling Software Engineering Processes
3. Understand Spreadsheet-Based Process Modeling
 Required Reading
1. Chapter 11: Business Process Modeling and Notation
Recommended Reading
1. Dunn, C., Cherrington, J., & Hollander, A. (2005). Enterprise information
systems: A pattern based approach (3rd ed.). New York: McGraw Hill
Higher Education. ISBN: 007240429 (print), 9781308469676 (e-text).
2. Business Process Model and Notation (BPMN) Tutorial
https://www.youtube.com/watch?v=dxd19GDrnVY

This Presentation is mainly dependent on the textbook: Enterprise Information Systems: Contemporary Trends and Issues
Business Process Modeling and Notation
Part 2
Sample Purchasing Scenario Represented in Business Process
Modeling and Notation
• The basic structure and elements in a BPMN process model can be
illustrated by using a purchasing scenario as an example. The example
purchasing scenario can be described as follows:

• In a company, an employee needs a certain commodity (e.g., a printer

cartridge). In order to get that product, a requisition form must be filled out
and submitted to the warehouse.

• The warehouse will check whether the product is available in stock. If it is

available, then the warehouse dispatches the product to the employee.
Sample Purchasing Scenario Represented in Business Process
Modeling and Notation
• Otherwise, the product must be purchased from an external supplier. In this
case, the item is not available in-house, so the purchasing department
prepares a purchase order and sends it to a supplier.

• The supplier confirms the order and delivers the product directly to the
warehouse.

• The warehouse receives the product, which includes updating the stock, and
dispatches the product to the employee who originally submitted the request.
Sample Purchasing Scenario Represented in Business Process
Modeling and Notation
• The corresponding process model using BPMN is shown in below figure.
• It consist of two entities:
• the company and
• the supplier
• Represented by:
• A “purchase process” pool, which is subdivided into three organizational units represented by
• An employee swim lane corresponding to the employee who requests the product
• A warehouse swim lane corresponding to the warehouse that stores the product
• A purchase department swim lane corresponding to the department that processes the purchase of the
product

• A “supplier” pool, which is left blank because nothing is known about the internal behavior of
the supplier other than the fact that it receives the purchase order and returns an order
confirmation
Sample Purchasing Scenario Represented in Business Process
Modeling and Notation
Sample Purchasing Scenario Represented in Business Process
Modeling and Notation
• In the figure, there is a splitting exclusive gateway, but there is no matching
merge. This is possible because both paths eventually lead to an end event,
so there is no need to merge them back to a common flow.

• The swim lane is a placeholder for BPMN flow constructs, such as the
activities, gateways, and events described earlier.

• The swim lane is a means to assign responsibility for certain tasks to a

given organizational unit; whatever is placed inside a swim lane is assumed
to happen within the context of that organizational unit.
Sample Purchasing Scenario Represented in Business Process
Modeling and Notation
• The process begins in the “employee” swim lane with a start event.
The first activity that appears after the start event is “fill in
requisition.”

• This activity is then followed by “check product availability,” which is

performed by the warehouse, on a different swim lane. The
warehouse checks the inventory and determines the quantity
available for the requested product.
Sample Purchasing Scenario Represented in Business Process
Modeling and Notation

• If the dispatch activity is seen as being exactly the same in both paths,
then the process can be redesigned as shown in the figure. Here, if
the product is available in the warehouse, then the process proceeds
immediately to “dispatch product”; otherwise, the product must be
ordered first and only then dispatched to the employee.
Characteristics of Business Process Modeling and Notation for
Modeling Software Engineering Processes
• With the increasing demands regarding flexibility and adaptability of
development processes, the constant evolution of development
methods and tools, and the trend toward continuous product
deployment, better support for process engineers in terms of
universally applicable modeling notations as well as simulation and
enactment mechanisms has become more desirable than ever.
Characteristics of Business Process Modeling and Notation for
Modeling Software Engineering Processes
• The discipline of business process modeling has attained a greater
level of consensus and standardization, leading most notably to the
BPMN idea. The success of BPMN as a standard business process
modeling notation concept has prompted the question of whether
BPMN could also be used for modeling software engineering
processes.
Characteristics of Business Process Modeling and Notation for
Modeling Software Engineering Processes
• BPMN relies on the following three fundamental assumptions that
affect its scope of applicability:
• A process consists of a set of isolated process instances (also called cases) that
interact with each other in very limited ways.

• An instance is a sequence of activities that transform objects associated with

the instance along the way from a start state to an end state (possibly among
multiple possible end states).

• Each atomic activity task is an atomic unit of work performed by a single

actor.
Characteristics of Business Process Modeling and Notation for
Modeling Software Engineering Processes
• Business Process Modeling and Notation Strengths
• Modeling control flows: BPMN is armed with special types of gateways that
allow one to capture complex synchronization conditions

• Modeling events and messages: another distinguishing feature of BPMN is its

richness of event types, which range from the timer and message events to
conditional events, escalation events, compensation events, and error events.

• Modeling executable process: BPMN is designed to also support the

enactment of business processes via so-called executable BPMN models.
Characteristics of Business Process Modeling and Notation for
Modeling Software Engineering Processes
• Business Process Modeling and Notation Weaknesses
• The following are some of the inherent limitations of BPMN that hinder
capturing software processes:
• Modeling resources: BPMN is rather limited in the resource perspective.

• Modeling data: BPMN is also somewhat limited along the data perspective. In the data
perspective, BPMN primarily relies on the concept of a data object, meaning a logical
unit of data that can be read by or created or modified by a task or an event.

• Modeling “in totality”: A more fundamental limitation of BPMN that hampers its use for
software process modeling is its inherent focus on business processes consisting of
isolated instances.
Characteristics of Business Process Modeling and Notation for
Modeling Software Engineering Processes
• Business Process Modeling and Notation Drawbacks
• BPMN does not provide a mechanism that would allow one to link the
completion of one task to a condition on the data objects manipulated by the
process.

• It is not possible to express in BPMN that the normal completion of a task is

determined by a given condition becoming true.

• In other words, the completion of a task in a BPMN process has to be

explicitly signaled by the resource performing the task and cannot be
automatically determined based on the current state of the data objects in
the process.
Spreadsheet-Based Process Modeling

• Graphical process model notations such as the BPMN provide

established and successful ways for the specification or
documentation of intended or existing processes.

• In order to close the gap between BPM method experts and domain
experts, other representations of a process model that are simpler,
such as spreadsheets, can be helpful.

• Spreadsheets offer a simple and (especially in business) well-known

way to organize data in rows and columns.
Spreadsheet-Based Process Modeling

• Transformations between graphical notation and spreadsheets have

to be defined.

• In order to really close the gap between process and domain experts,
the transformation algorithms will have to be used in a
synchronization mechanism that enables a model to roundtrip
between both of the worlds.
Spreadsheet-Based Process Modeling

• Process Model Transformations into Spreadsheets

• There are different approaches to modeling processes using spreadsheets
that depend on the envisaged degree of fidelity.

• The simple sequence approach. As the existing tools are mostly for business
process method experts as users, this first approach tries to be as simple as
possible: only the modeling of sequences of activities is supported. Activities
have a number of property types that can be assigned once or several times
per activity. These multiple assignments of properties are necessary, e.g., for
activities that have two input data objects.
Spreadsheet-Based Process Modeling

• The branching approach. This approach adds some new elements and, more
importantly, a successor property to each element to address process models
that contain not only sequences but also complex control flow structures. In
order to support branching and joining within one model, gateways and
events are necessary.

• The additional properties approach. The earlier approach still has no support
to specify properties, for example of an input document or an assigned role.
As mentioned before, this is due to the fact that all of those elements are just
represented by simple strings. This can be mended by enabling elements like
data objects to be represented by rows that are linked to activities in a
manner similar to the control flow, which links two control flow elements.
Spreadsheet-Based Process Modeling

• Process Model Transformations

• In order to benefit from the established techniques for graphical models as
well as from the easiness of spreadsheets, both worlds have to be
transformable into each other.

• Therefore, this section will show how a spreadsheet-based model can be

transformed from and into BPMN.

• For a natural ordering of elements within the produced spreadsheet, first, the
nodes have to be sequentialized.
Spreadsheet-Based Process Modeling

• In order to transform a graphical model into a spreadsheet, we need a

transformation T. The following algorithm shows how T can be
implemented:
nodeArray = getNodesInSequentialOrder(model) for each node in
nodeArray:
if isSupportedElement(node):
createRow(node)
for each node in nodeArray:
if isSupportedElement(node):
for each connectedNode of node:
if isSupportedRelation(node, connectedNode):
addRelation(node, connectedNode)
Spreadsheet-Based Process Modeling

• Business Process Modeling and Notation Transformations

• In the transformation of BPMN to spreadsheet, there exists a lot of BPMN
elements that cannot be transformed into either one of the approaches, for
example subprocesses and collapsed (black-box) pools but also descriptive
element groups and annotations.

• Message flows are used to model the interaction of different processes, they
are a pretty complicated construct and can therefore not be pressed into a
spreadsheet-based model that aims for simplicity.
Spreadsheet-Based Process Modeling

• Business Process Modeling and Notation Transformations

• In the transformation of spreadsheet to BPMN, all elements of the three
approaches can be transformed into BPMN elements. Thereby, every row of a
spreadsheet is interpreted as an activity, except if one of the following criteria
is met:
• In II and III: If the name starts with AND, XOR, or OR, the element is a gateway.
• In II and III: If the element has no predecessor/successor, it is a start event/end event.
• In II and III: If the ref property is set, then the element is a collapsed subprocess.
• In III: If the element is connected through a typed relation (e.g., input), then the
element’s type can be deducted from the relation.
Spreadsheet-Based Process Modeling (Transformability of BPMN
Elements and Relations)
Summary

• Using BPMN, business analysts can describe organizational processes

in a way that can be understood by developers and system integrators
and that can serve as a blueprint for implementing the services and
orchestrations required to support those processes.
 Main Reference
1. Chapter 11 (Enterprise Modeling by Vivek Kale)

This Presentation is mainly dependent on the textbook: Enterprise Process Management Systems by Vivek Kale
Thank You