UNIT 3

ADVANCED PROCESS MODELLING

Process Decomposition
1. Challenge of Model Complexity:

o Larger models with many elements reduce understandability.

o Example: The "order-to-cash" process initially has 14 activities, six gateways,

and two events. Adding data objects, resources, and message flows further
complicates it.

2. Simplifying Through Sub-Processes:

o Definition:

▪ A sub-process is a self-contained composite activity that can be broken

into smaller units of work.

▪ Tasks, or atomic activities, represent the smallest unit of work.

o Grouping Activities:

▪ Related activities achieving a specific goal can form a sub-process.

▪ Example: Activities for acquiring raw materials or handling shipping and

invoicing.
3. Collapsed vs. Expanded Sub-Processes:

o Expanded Sub-Process: Shows internal steps (e.g., Figure 3.17).

o Collapsed Sub-Process:

▪ Replaces detailed content with a simplified activity marked by a "+" sign.

▪ Improves readability by reducing visible activities (e.g., Figure 3.18).

o Content of a collapsed sub-process is accessible at a lower abstraction level.

4. Hierarchical Decomposition:

o Models can be nested at multiple levels, adding detail as needed:

▪ Top Level: Models core business activities.

▪ Lower Levels: Add decision points, exceptions, and automation-specific

details.

o Example: Loan disbursement process with sub-processes for liability checks

and signing loans.

5. When to Decompose:

o A process model should be decomposed if it becomes difficult to understand.

o Guideline: Use sub-processes if the model exceeds ~30 flow objects (activities,
events, gateways).

o Other readability factors:

▪ Density of connections.

▪ Number of parallel branches.

▪ Longest path from start to end events.

▪ Layout, labels (verb-noun style), and visual aesthetics.

 6. Intentionally Under-Specified Sub-Processes:

o Some sub-processes may be left under-specified if their internal details are

irrelevant to the model.

o Example: "Ship product" activity could omit packaging and shipping details if
unnecessary.

7. Benefits of Process Decomposition:

o Enhances readability and understandability.

o Reduces errors and behavioral issues in process models.

o Provides a structured, hierarchical view of processes.

Process Model Reuse

1. Embedded vs. Global Sub-Processes:

o Embedded Sub-Process: A sub-process defined within its parent process

model. It is invoked only within that process.

o Global Sub-Process: Defined outside any parent process and can be invoked by
other processes in the same process model collection. This enhances
reusability.

2. Global Process Model (Call Activity):

o A global process model is reused across multiple process models. In BPMN, it is

represented by a call activity—a collapsed sub-process with a thicker border.

o Example: The sub-process for signing loans in a loan disbursement process can
be reused for student and motor loans by defining it as a global process model.

3. When to Use Global Sub-Processes:

o Default Choice: It is recommended to define sub-processes as global process

models to maximize reusability across the organization.

o Suitable Candidates for Global Models:

▪ Shared processes like payment, invoicing, HR, and printing are typically
reused across various business processes.

o Benefits of Global Sub-Processes:

▪ Reusability: Can be invoked by multiple processes.

▪ Maintenance: Any changes to the global model automatically propagate

to all processes that invoke it.
 4. When to Keep Embedded Sub-Processes:

o Internal Changes: Sometimes, a sub-process needs to be unique to a specific

process. For instance, the invoicing process for corporate orders may differ from
that for private orders. In this case, both variants should be modeled as
embedded sub-processes within their respective parent processes.

5. Example of Process Reuse:

o A pharmaceutical company uses both direct and indirect procurement

processes.

▪ The direct procurement process is specific to each business unit (e.g.,

inhaled medications vs. vaccines), so it is modeled as an embedded
sub-process within each business unit's manufacturing process.

▪ The indirect procurement process (ordering spare parts for equipment) is

shared across all units, so it is modeled as a global process model,
enabling reuse across units.

6. Syntactical Rules for Sub-Processes:

o A sub-process must start with at least one start event and end with at least one
end event.

o If there are multiple start events, the sub-process is triggered by the first one to
occur.

o If there are multiple end events, the sub-process will complete when all tokens
have reached an end event.

o Boundary Restrictions: The boundary of a sub-process cannot be crossed by a

sequence flow. To pass control in or out of a sub-process, use start and end
events.

o Message Flows: Can cross the boundaries of a sub-process to indicate

messages that go to or come from internal activities or events.

Rework and Repetition

1. Using Rework and Repetition in Process Models:

• In business process modeling, sometimes tasks need to be repeated or adjusted.

• For example, when you send a document for approval, it may need to go back for edits if
it’s not approved. We call this rework.

• To model this, we can use XOR gateways (which look like diamond shapes with an "X"
inside). They direct the process based on conditions: if approved, move forward; if not,
go back and redo steps.
2. Using Loop Activities for Repetition:

• Instead of always using XOR gateways, we can use a loop activity to show repeated
steps simply.

• For example, let’s say there’s a process for approving government letters. You could
bundle the repeated steps (like edits and reviews) into one “sub-process” that has a
loop symbol.

• This loop symbol means the steps inside this sub-process repeat until a specific
condition is met (like “until response is approved”).

• Important Note: If you create a loop sub-process, make sure the last step inside is a
decision point (like “approved or not?”). This way, it’s clear when to stop repeating.

3. Loop Activity vs. Structured Cycle:

• A loop activity is a specific kind of repetition that has a clear start and end.

• However, not all processes fit neatly into a loop. Some have multiple entry or exit points,
which can make the process flow complex.

• For example, imagine a process where you assess an application, send rejection
notices, and get customer feedback. If there are multiple ways to enter or exit these
steps, we call this an unstructured cycle.

• In these cases, using a simple loop activity doesn’t work well. We’d need extra
conditions to show where each part starts or stops, making the model harder to follow.

Parallel Repetition
Sometimes, we need to perform the same task for different people or items at the same
time.

• For example, in a procurement process, if you want quotes from multiple suppliers,
you’d contact all suppliers at once.

• Multi-instance activity is used for these cases, letting us run several copies of an
activity simultaneously without making the model large.

• Instead of drawing a task for each supplier, we draw one task and mark it as multi-
instance (with three small vertical lines). It will then run for as many suppliers as
needed.

Example of Use:

• Suppose there are 20 suppliers in the database, but you only need quotes from five. You
can add an annotation to say, “Complete when five quotes are obtained.” This way, once
five quotes arrive, the remaining requests are canceled, and the process moves forward.
Uncontrolled Repetition with Ad-hoc Sub-processes:
• Some activities can happen multiple times in no set order. We call this uncontrolled
repetition.

• For example, after placing an order, a customer may email the seller to check on it
multiple times. Or they might want to update their personal details. These actions don’t
follow a specific order and may or may not happen.

• An ad-hoc sub-process is useful here. It’s a group of tasks marked by a tilde (~) symbol
to show that they can happen in any order.

• You can still use sequence arrows to show preferred order, but there are no start or end
events for these activities.
Handling Events
Events in a process represent things that happen instantly and trigger specific actions in a
workflow. Events can start or end a process (like creating or destroying tokens in a workflow) or
be "intermediate" events, which occur somewhere in the middle of a process. Tokens flow
through the process steps and pause at intermediate events until the event occurs. Once it
happens, the token continues on its path.

4.4.1 Message Events

• Message events handle communications between processes. For instance:

o A start event triggered by a message (like an order request).

o An end event that signals the process has ended by sending a message (like a
confirmation sent after processing).

o Intermediate events where a process pauses, waiting for a message before

continuing (like waiting for an order confirmation before shipping).

• Types of Message Events:

o Catching event: Symbolized by an unfilled icon, it waits to "catch" a trigger from

outside (e.g., waiting for an approval message).

o Throwing event: With a filled icon, it "throws" or sends a trigger within the
process (e.g., sending a shipment notification).
4.4.2 Temporal Events
• Temporal events start based on time, like setting a process to start daily at a certain
time or to trigger at specific intervals. They are common for processes that need regular
updates or checks.

• Intermediate temporal events specify time gaps within the process. For example, if a
callover list needs to be prepared three weeks before a scheduled callover day, we can
set a timer event to prepare the list exactly at that time.

Example of Temporal Events:

In a small claims tribunal:

1. Preparation of a callover list starts three weeks before the callover day.
2. Parties are contacted one week prior to confirm readiness.
3. On the callover day, materials are prepared, and the callover is held.
4.4.3 Racing Events
In some processes, two external events compete or "race" to occur first. The first event that
happens determines the next steps, known as a race condition.

• Event-based XOR split: This represents a choice determined by external events. Unlike
an internal choice made by the process itself, the outcome here depends on which
external event occurs first. It is shown by a double-lined circle with a pentagon inside.

o For example, after sending an insurance quote to a client, the client may reply
with acceptance or rejection. The process then continues based on whichever
response comes first.

Avoiding Deadlocks in Collaborations

• When processes (or pools) interact, a deadlock can occur if they wait for actions that
never happen.

• Event-based gateways help ensure smooth interactions by checking the order and
conditions of message exchanges.

For instance, in an auctioning service and seller collaboration, if a seller is already registered,
they shouldn’t have to wait for an unnecessary confirmation. An event-based gateway allows for
flexible handling to prevent waiting endlessly, or deadlocking, if the expected message doesn’t
arrive.
Handling Exceptions
• Exceptions are unexpected events that disrupt a process flow, such as business faults
(e.g., out-of-stock items) and technology faults (e.g., database crash). Handling them
helps in managing process interruptions or recovery procedures.

4.5.1 Process Abortion

1. Terminate Event:

o The simplest way to handle an exception or an abnormal situation in a process is

to abort the running process and signal its termination.

o This is done using an End Terminate Event, depicted as an end event with a full
circle inside. The End Terminate Event immediately stops the process instance
at its current level and any sub-processes.

2. Example - Home Loan Process:

o Scenario: In a variant of the home loan process (Figure 4.14), the loan is
rejected and the process is aborted if the applicant has high debts or high
liability.

o Terminate Event Behavior:

▪ If the applicant is rejected due to these conditions, the terminate event

is triggered, causing the immediate cessation of the process.

▪ All tokens within the process model and sub-processes are destroyed,
preventing further execution.

3. Avoiding Deadlocks:

o The terminate event helps avoid deadlocks in the process. For example, a token
may get trapped before an AND-join if there are conflicting conditions (e.g., high
debts and low liability, or low debts and high liability). By triggering the terminate
event, the process is halted to avoid this situation.

4. Scope of the Terminate Event:

o If the terminate event is triggered within a sub-process, it will only abort the
sub-process, not the parent process.

o This means that the termination is propagated downwards in a process

hierarchy, affecting the sub-process level but not the parent process level.
4.5.2 Internal Exceptions
In BPMN, instead of aborting the entire process when an exception occurs, we can interrupt
the specific activity causing the exception, then trigger a recovery procedure to return the
process to a consistent state. Only if recovery is not possible, should we abort the entire
process. This scenario is managed through error events.

Key Concepts

1. Error Event:

o An Error Event in BPMN helps capture scenarios where an exception occurs

during process execution. The event is represented by a lightning marker.

▪ End Error Event (throwing event): This event triggers the exception and
is represented by a filled lightning marker.

▪ Intermediate Error Event (catching event): This event is attached to the

boundary of an activity or sub-process and catches the exception,
represented by an empty lightning marker.

2. Error Event Workflow:

o When an exception occurs (such as out-of-stock in an order process), the End

Error Event is triggered to interrupt the activity, which then throws the exception.

o The exception is captured by an Intermediate Catching Error Event attached to

the boundary of the sub-process or activity.

o This boundary event triggers the exception flow, leading to a recovery

procedure that can be a task, sub-process, or any other BPMN element for
handling the exception (e.g., notifying the customer about the out-of-stock
situation).
3. Exception Flow:

o The exception flow is used to model the recovery procedure. It is a separate

flow that allows the process to either:

▪ Continue execution through normal paths (if the exception is handled

properly).

▪ Be terminated using an End Terminate Event if recovery isn't possible.

o The exception flow may include any elements to handle the error, such as
tasks, messages, or even other sub-processes.

4. Token Semantics:

o When the End Error Event is thrown, all tokens within the enclosing sub-process
are removed, causing an interruption.

o One token is sent through the exception flow, representing the start of the
recovery procedure.

Example: Out-of-Stock Scenario (Order-to-Cash Process)

• In the Order-to-Cash process, if there is an out-of-stock exception while acquiring raw

materials, the following steps occur:

1. The End Error Event is triggered, causing the interruption of the raw material
acquisition task.

2. The Intermediate Catching Error Event on the boundary of the activity catches
the exception.

3. The exception flow leads to a task such as notifying the customer about the
out-of-stock situation.

4. If recovery is not possible, the exception flow can lead to an End Terminate
Event, causing the entire process to be aborted.
4.5.3 External Exceptions
external exceptions occur due to events outside the process, like customer requests or system
errors.

Key Concepts

1. Catching Intermediate Message Event:

o This event is attached to the boundary of an activity to capture external events

(e.g., order cancellation).

o When triggered, it interrupts the ongoing activity and follows the exception flow
to handle the event.

2. Interrupting the Activity:

o The event removes the token from the activity, causing it to stop.

o The process then follows the exception flow to initiate a recovery procedure.

3. Scope for External Events:

o The event scope is limited to a specific activity (e.g., canceling an order only
during stock checking).

o For broader coverage, use a sub-process with the event on its boundary.

4. Recovery Procedure:

o The event triggers actions like notifying the customer or updating order status.

o If necessary, the process can be aborted.

Example:

In an Order-to-Cash process, an order cancellation request interrupts the "Check stock

availability" activity. The catching message event handles this by triggering a recovery task
(e.g., canceling the order).

4.5.4 Activity Timeouts

• Timer Event: Used to set a timeframe for activity completion. If the activity exceeds this
time, the timer event fires, interrupting the activity.

• Example: A transportation quote preparation process must complete within a specific

time to meet contractual deadlines.

4.5.5 Non-Interrupting Events and Complex Exceptions

Non-interrupting events allow external events to trigger a procedure without stopping the
ongoing activity. These are particularly useful in scenarios where activities need to continue
while still responding to external requests.
Key Concepts

1. Non-Interrupting Boundary Events:

o Represented with a dashed double border.

o These events allow the process to continue executing while handling external
events (e.g., updating customer details without interrupting stock checks).

2. Modeling Complex Exceptions:

o Non-interrupting events are ideal for complex scenarios, such as handling a

customer order cancellation request during the acquisition of raw materials.

o In such cases, a boundary message event catches the cancellation request,

but does not stop the ongoing activity (raw material acquisition).

o After determining penalties, the customer is given a decision to either cancel the
order or continue. If the cancellation proceeds, an end signal event is thrown.

3. Signal Events:

o A signal event is different from a message event: it does not have a specific
target but is broadcast to all processes with a matching signal.

o The Order canceled signal can be caught by a catching signal event in another
part of the process, such as in the sub-process for acquiring raw materials. This
signal causes the sub-process to interrupt and initiate a recovery procedure,
which may involve charging the customer.

4. Message vs. Signal Events:

o Message events are specific in terms of source and target, while signal events
are broadcasted without a specific recipient, allowing broader process
interactions.

Example:

In the Order-to-Cash process, if a customer requests order cancellation during raw material
acquisition, the system:

• Uses a non-interrupting boundary message event to capture the cancellation request.

• A signal event is thrown based on the customer’s decision, interrupting the raw material
acquisition and triggering a recovery procedure.

4.5.6 Event Sub-processes

Event sub-processes and boundary events are both used to handle exceptional or external
events in a process, but they differ in scope, usage, and structure.

Key Differences

1. Scope of the Event:

 o Boundary Events: These are tied to specific activities in a process. They are
attached to the boundary of an activity and interrupt or trigger a procedure
based on the occurrence of the event during that activity's execution.

o Event Sub-Processes: These are more flexible and can be triggered by an event
at any point during the entire process. They are not tied to a specific activity but
instead capture events that may occur throughout the whole process.

2. Representation:

o Boundary Events: Represented by an event attached to the boundary of an

activity. If interrupting, it halts the activity, otherwise it continues without
interruption.

o Event Sub-Processes: Represented as a sub-process within a dotted rectangle

with rounded corners, where the event that triggers the sub-process is shown at
the start. If the event is non-interrupting, the border is dashed.

3. Interrupting vs Non-Interrupting:

o Both boundary events and event sub-processes can be interrupting or non-

interrupting:

▪ Interrupting Event Sub-Processes: Stop the main process flow, and the
procedure inside the sub-process handles the event.

▪ Non-Interrupting Event Sub-Processes: Allow the main process flow to

continue while the sub-process is executed in parallel.

4. Reusability:

o Boundary Events: Cannot be reused across different processes, as they are

specific to a single activity in the process.

o Event Sub-Processes: Can be defined as reusable global processes. They can

be used across multiple process models, making them more versatile.

Advantages of Event Sub-Processes:

• Global Scope: Can be triggered at any point in the process, not tied to a specific
activity.

• Reusability: Can be defined as a separate process model that can be reused in other
workflows.

• Non-Interrupting Flexibility: Non-interrupting event sub-processes allow parallel

execution, which is not possible with boundary events.

Advantages of Boundary Events:

• Specificity: Directly attached to a particular activity in the process, making them

straightforward to model for events specific to a task.

• Flow Integration: Can be wired back into the main process flow, maintaining the
process continuity without needing a separate sub-process.
When to Use Each:

• Event Sub-Processes:

o Use when the event can occur at any time during the process and is not tied to a
specific activity.

o Use when you need to capture a reusable procedure (e.g., handling customer
inquiries in an order-to-cash process).

• Boundary Events:

o Use when the event is specific to a particular activity and must be handled in the
context of that activity (e.g., handling order cancellations during stock
availability check).

4.6 Processes and Business Rules

• Business Rules: Organizational policies or practices, e.g., online shop rule - platinum
customers receive a 20% discount for purchases over €250.

• Implementation in Process Models:

o Decision Activity: Business rules can appear here.

o Condition on a Flow: Rules can be added to the flow conditions after an (X)OR-
split.

o Conditional Event: A BPMN event triggered when a business rule is satisfied.

▪ Symbol: Lined page marker.

▪ Usage: Start or intermediate catching event (after an event-based

gateway or activity boundary).

• Difference Between Conditional Event and Flow Condition:

o Flow Condition: Checked only once; if unsatisfied, a default or alternate flow is

followed.

o Conditional Event: Continuously checked until the condition is met; token

waits until rule satisfaction.

• Error Event in Multi-instance Activities:

o Only interrupts the specific instance with the error.

o Other Interrupting Boundary Events: Message, timer, signal, and conditional

events interrupt all instances of a multi-instance activity.