BUSINESS PROCESS MANAGEMENT

CO5270

CHAPTER 3 – PROCESS MODELING (cont.)

Dr. Thai-Minh Truong

thaiminh@[Link]

Adapted from [Link]

Process Modeling in the BPM Lifecycle
Management Processes

Process Define Vision Develop Strategy Implement

Strategy
Manage Risk

identification Core Processes

Procure Procure Market Deliver

Manage
Customer
Materials Products Products Products
Service

Support Processes

Examples for BPM lifecycle and process mining Process architecture Manage Personnel
Manage
Information Manage Assets

35h B 30h
15h

A
D
E
Conformance and Process As-is process
5m 3m 5m 10m 30m 2h 10m
performance discovery
C model
15m 1.5h 10min insights

A B C D E

Process Process
monitoring analysis

Executable Insights on
process weaknesses and
model their impact

Process Process
implementation To-be process redesign
model
BPMN Main Elements - Recap
Flow Objects Connections

Activity
Message Association
Gateway

Event
Flow

Pools & lanes Artifacts

Pool

Data Data
Object Store
Lane
BPMN Gateways
Exclusive (XOR) Parallel (AND) Inclusive (OR)

• Exclusive • Parallel split • Inclusive decision

decision take all branches take one or
take one branch • Parallel join several branches
• Exclusive merge proceed when all depending on
Proceed when incoming conditions
one branch has branches have • Inclusive merge
completed completed proceed when all
active incoming
branches have
completed
Anything wrong with this model?
Is this better?
 Identifying sub-processes
Acquire raw materials

7 Ship and invoice

Expanded…
Sub-processes

▪ An activity in a process can invoke a separate sub-process

▪ Use this feature to:
1. Decompose large models into smaller ones, making them easier
to understand and maintain
Guideline: Multi-level modeling
▪ Level 1: value chain
▪ Simple linear description of the phases of the process
▪ No gateways
▪ Each activity chain is a sub-process

▪ Level 2+: expand each activity in the value chain, add incrementally
the following:
▪ Decisions, handoffs (lanes, pools)
▪ Parallel gateways, different types of events
▪ Data objects & data stores
▪ And as much detail as you need, and no more
Guideline: Multi-level modeling (cont.)
▪ At each level, decompose according to:
▪ Logical milestones towards achieving the outcome of the process
▪ Major objects used in the process

▪ Decompose until processes are of “reasonable” size

▪ e.g. up to 20 nodes (tasks + events + gateways) per model
Value chain with sub-processes
Purchase Purchase Goods Invoice
Approval
Request Order Receipt Verification

Consider re-
submission

Purchase Request process

rejected

Check purchase
request for 1st
approval

approved rejected
Purchase Request

Check purchase
request for 2nd
approval

approved

Send approved
request to requestor

Purchase Order process

Make copy of Forward to purchase

purchase request department

Approved Purchase Request

Sub-processes
▪ An activity in a process can invoke a separate sub-process
▪ Use this feature to:
1. Decompose large models into smaller ones, making them easier
to understand and maintain
2. Share common fragments across multiple processes
Shared sub-process
Sub-processes
▪ An activity in a process can invoke a separate sub-process
▪ Use this feature to:
1. Decompose large models into smaller ones, making them easier
to understand and maintain
2. Share common fragments across multiple processes
3. Delimit parts of a process that can be:
▪ Repeated
▪ Interrupted
Structured repetition
Block-structured repetition: Activity loop
Activity loop markers allow us to state that a task or a sub-process
may be repeated multiple times

Task Sub-process
Loop Loop

17
More on rework and repetition

XOR-join: entry point XOR-split: exit point

Structured
cycle (SESE
component)

18
 Example: block-structured repetition
Completion
condition

Until Response is approved

Finalise
Assign Investigate
Ministerial
Ministerial Ministerial
Response
Enquiry Enquiry
Ministerial Ministerial
Enquiry Enquiry
received finilized

Prepare Review
Ministerial Ministerial
Response Response
Enquiry Response
investigated reviewed

Must have a
decision activity
19
Parallel repetition: multi-instance activity
The multi-instance activity provides a mechanism to indicate that an
activity is executed multiple times concurrently

Multi-Instance Multi-Instance
Task Sub-process

Useful when the same activity needs to be executed for

multiple entities or data items, such as:
▪ Request quotes from multiple suppliers
▪ Check the availability for each line item in an order separately
▪ Send and gather questionnaires from multiple witnesses in the context of
an insurance claim
20
 Example: multi-instance activity
Procurement
In procurement, typically a quote is to be obtained from all
preferred suppliers (assumption: five preferred suppliers exist).
After all quotes are received, they are evaluated and the best
quote is selected. A corresponding purchase order is then
placed.

21
Solution: without multi-instance activity
Procurement
Obtain Quote
from Supplier A

Obtain Quote
from Supplier B

Obtain Quote Select best ...

... Place PO
from Supplier C quote

Obtain Quote
from Supplier D

Obtain Quote
from Supplier E
22
Solution: with multi-instance activity
Procurement

cardinality
For each supplier

... Select best ...

Obtain Quote Place PO
quote

23
Events
 Events
In BPMN, events model something instantaneous happening during
the execution of a process

Types of event:
▪ Start
▪ Intermediate
▪ End

25
 BPMN event types
Start Intermediate End

Untyped Event – Indicates that an instance of the

process is created (start) or completed (end),
without specifying the cause for creation/completion Catching

Start Message Event – Indicates that an instance

of the process is created when a message is
received

End Message Event – Indicates that an instance of

the process is completed when a message is sent

Intermediate Message Event – Indicates that an

event is expected to occur during the process. The
event is triggered when a message is received or
sent

26
Comparison with sending/receiving tasks

= Receive
invoice
Invoice
received

Invoice
= Send invoice

sent

Invoice
= Send invoice

sent

≠
Receive
invoice
Invoice
received
27
 So, when to use what?
Use message events only when the corresponding activity would
simply send or receive a message and do nothing else

28
 Temporal events
Start Intermediate End

Start Timer Event – Indicates that an instance of the

process is created at certain date(s)/time(s), e.g. start
process at 6pm every Friday

Intermediate Timer Event – Triggered at certain date(s)/

time(s), or after a time interval has elapsed since the
moment the event is enabled (delay)

29
 Example
PO handling
A Purchase Order (PO) handling process starts when a PO is received.
The PO is first registered. If the current date is not a working day,
the process waits until the following working day before proceeding.
Otherwise, an availability check is performed and a PO response is
sent back to the customer.

Next working day

weekend/
holiday

weekday Check Send PO

Register PO
Availability Response
PO PO
Received fulfilled

30
Recap: Message and Timer events
Start Intermediate End
Catching Catching Throwing Throwing

process message message process

starts upon received sent during ends upon
message during the the process message
received process sent

process time event

starts when occurred
time event (to model delay)
occurs

31
 Data-based vs. event-based choices
▪ In a XOR-split gateway, one branch is chosen based on expressions
evaluated over available data
→Choice is made immediately when the gateway is reached

▪ Sometimes, the choice must be delayed until something happens

→Choice is based on a “race between events”

▪ BPMN distinguishes between:

▪ Exclusive decision gateway (XOR-split)
▪ Event-based decision gateway
 Event-based decision
With the XOR-split gateway, a branch is chosen based on
conditions that evaluate over available data
→ The choice can be made immediately after the token
arrives from the incoming flow

Sometimes, the choice must be delayed until an event

happens
→ The choice is based on a “race” among events

Two types of XOR split:

data-driven event-driven
XOR-split XOR split

33
Choices outside our control…
Stock replenishment
A restaurant chain submits a purchase order (PO) to replenish its
warehouses every Thursday. The restaurant chain’s procurement
system expects to receive either a “PO Response” or an error
message. However, it may also happen that no response is received
at all due to system errors or due to delays in handling the PO on the
supplier’s side. If no response is received by Friday afternoon or if an
error message is received, a purchasing officer at the restaurant
chain’s headquarters should be notified. Otherwise, the PO Response
is processed normally.

1
 Solution: event-driven XOR split
Stock replenishment

35
Exception handling
Let’s extend our PO handling process
PO handling
A PO handling process starts when a PO is received. The PO is first
registered. If the current date is not a working day, the process
waits until the following working day before proceeding. Otherwise,
an availability check is performed and a PO response is sent back to
the customer.

A PO change request may be received anytime after the PO is

registered. This request includes a change in quantity or line
Next working day
items. When such weekend/
a request is received, any processing
holiday
related to the PO must be stopped. The Check
PO change request is
Send PO
weekday
then registered.
Register PO
Thereafter, the process proceedsResponse
Availability as it would
do
PO
Received
after a normal PO is registered. Further, if the customer PO
fulfilled
sends a PO cancelation request after the PO registration, the
PO processing must be stopped and the cancelation request
must be handled.
37
 Abortion (terminate event)
Exceptions are events that deviate a process from its “normal” course

The simplest form of exception is to notify that there is an exception

(negative outcome)

This can be done via the Terminate end event: it forces the whole
process to abort (“wipes off” all tokens left behind, if any)

38
 Example 1: terminate event
Signal the negative outcome…

39
 Example 2: terminate event
Abort the process by removing all tokens…

40
 Exception handling
Handling exceptions often involves stopping a sub-process and performing a special
activity

Types of exceptions for an activity (task/sub-process) in BPMN:

External: something goes wrong outside the process, and the execution
of the current activity must be interrupted. Handled with the Message
event

Internal: something goes wrong inside an activity, whose execution

must thus be interrupted. Handled with the Error event

Timeout: an activity takes too long and must be interrupted. Handled

with the Timer event

All these events are catching intermediate events. They stop the enclosing activity and
start an exception handling routine.
41
Let’s extend our PO handling process
Next working day
weekend/
holiday

weekday Check Send PO

Register PO
Availability Response
PO PO
Received fulfilled

A PO change request may be received anytime after the PO is

registered. This request includes a change in quantity or line
items. When such a request is received, any processing
related to the PO must be stopped. The PO change request is
then registered. Thereafter, the process proceeds as it would
do after a normal PO is registered. Further, if the customer
sends a PO cancelation request after the PO registration, the
PO processing must be stopped and the cancelation request
must be handled.
42
Solution: exception handling
PO handling

Handle PO
Next workingNext
day working day
weekend/ weekend/
holiday holiday

weekday weekday Check Check Send PO Send PO

Register PO Availability Response Response
Availability
PO PO PO PO
Response
Received Registered fulfilled fulfilled
sent

PO Change PO Cancel
received received
Handle PO
Cancelation
Register PO
PO
Change
canceled

8
 Internal exception: error event
Start Intermediate End
Error Event – Indicates an error: the end version generates an
error event while the catching intermediate version consumes it
when attached to the boundary of an activity

Must be attached to the

activity’s boundary

44
 Example: internal exception
PO handling
Consider again our “PO Handling process” example with the following
extension: if an item is not available, any processing related to the PO
must be stopped. Thereafter, the client needs to be notified that the
PO cannot be further processed.

Handle PO
Next workingNext
day working day
weekend/ weekend/
holiday holiday

weekday weekday Check Check Send PO Send PO

Register PO
Availability Availability Response Response
PO PO PO PO
Response
Received Registered fulfilled fulfilled
sent

PO Change PO Cancel
received received
Handle PO
Cancelation
Register PO
PO
Change
canceled

45
 Solution: internal exception
Throwing and catching
error events must have
the same label
PO handling
Handle PO
Handle PO
Nextworking
Next working day
day Items not
weekend/
weekend/ available
holiday
holiday

weekday
weekday Check
Check Send POSend PO
Register PO
Register PO Availability
Availability ResponseResponse
Items
PO
PO
PO available Response PO PO
Response
Received
Received Registered
Registered fulfilled
fulfilled
sentsent

PO Change PO Cancel Items not

received received available
Handle PO
Cancelation
Register PO
PO Notification
Change
canceled sent

Must catch an error

event thrown from
within the same activity

46
Example: activity timeout
Order-to-transportation quote
Once a wholesale order has been confirmed, the
supplier transmits this order to the carrier for the
preparation of the transportation quote. In order to
prepare the quote, the carrier needs to compute the
route plan (including all track points that need to be
traversed during the travel) and estimate the trailer
usage.
By contract, wholesale orders have to be dispatched
within four days from the receipt of the order. This
implies that transportation quotes have to be prepared
within 48 hours from the receipt of the order to remain
within the terms of the contract.
Solution: activity timeout
Order-to-transportation quote
 More on the PO handling example…
PO handling
Handle PO

Next working day Items not

weekend/ available
holiday

weekday Check Send PO

Register PO Availability Response
Items
PO PO available PO
Response
Received Registered fulfilled
sent

PO Change PO Cancel Items not

received received available
Handle PO
Cancelation
Register PO PO Notification
Change canceled sent

The customer may send a request for address change after the PO
registration. When such a request is received, it is just registered,
without further action.

49
 Non-interrupting boundary events
Sometimes we may need to trigger an activity in parallel to the normal
flow, i.e. without interrupting the normal flow.

This can be achieved by using non-interrupting boundary events

Must be attached to
the activity’s
boundary
50
Solution: non-interrupting boundary events
PO handling

Handle PO

Next working day Items not

weekend/ available
holiday

weekday Check Send PO

Register PO Availability Response
Items
PO PO available PO
Response
Received Registered fulfilled
sent

PO Change PO Cancel Items not Address

received received available change
Handle PO received
Cancelation
Register PO Update
PO Notification
Change customer
canceled sent address

Customer
address
updated

51
Summary
▪ In this lecture we have learned about:
▪ BPMN sub-processes
▪ Repetition markers: loop marker and parallel multi-instance marker
▪ Events: timer, message and error events
▪ Event-based choice gateway
▪ Boundary events: interrupting and non-interrupting
▪ Error events (throw and catch)
Q&A