Module 2: Process Identification

TIME STUDENT LEARNING OUTCOMES LEARNING

(SLOs) CONTENT

Week 3  Understand and discuss the process Process Identification

identification  Focusing on
 Discuss on how to design a process Key
architecture Processes
 Designing a Process
Architecture

Week 4  Understand the essential process Essential Process

modeling Modeling
 Discuss the steps on BPMN  First Steps
with BPMN
 Branching and
Merging
 Information
Artifacts
 Resources

CHAPTER 2: Process Identification

Process identification is a set of activities aiming to systematically define the set of
business processes of a company and establish clear criteria for prioritizing them. The
output of process identification is a process architecture, which represents the business
processes and their interrelations. A process architecture serves as a frame-work for
defining the priorities and the scope of process modeling and redesign projects.
In this chapter, we present a method for process identification that is based on two
phases: designation and evaluation. The designation phase is concerned with the
definition of an initial list of processes. The evaluation phase considers suitable criteria
for defining priorities of these processes. After that, we discuss and illustrate a method
for turning the output of this method into a process architecture.
 Systematically define the business processes of a company and establishing clear
criteria for prioritizing them.
 OUTPUT = PROCESS ARCHITECTURE
o Framework for defining priorities and scope for process modeling and
redesign projects.
2.1 Focusing on Key Processes
What to focus on?
o It is not cost-effective to model/analyze/redesign/deploy/support/monitor (via
BPM) all the processes organization. It has to pay off.
o Focus on a subset of processes.

 What processes are executed? AND Which ones should the organization
focus on?
 A map describing all the processes and keeping it up to date.
 Clear criteria for determining process importance.

 Processes need to receive priority based on:

 Processes with strategic importance (to a organizations
survival)
 Processes were it is possible to create great value
 Processes with striking problems
 Processes were a significant problem is present
 Processes may change priority if necessary
 Problems may solve itself
 New problems arise
 Processes that are strategic important, become
less/more important

The Designation Phase

 When a organization is turning into a process-centered organization, there are
things to consider:
o Which chain of operations is a single business process.
o Which chains are part of another process?
o The idea of process management is to actively manage business
processes in the pursuit of satisfying its specific customers.
 Categorize business processes:
o Existence of only 2 processes: Managing product line & Managing the
order cycle
o Categories of processes according to Porter:
 Core processes (primary activities)
 Essential value creation, production of goods/services for
which customers pay.
 Inbound logistics, operations, outbound logistics, marketing &
sales and services
  Support processes (support activities)
 Enable execution of core processes
 Infrastructure, human resources, technology development and
procurement.
 Management processes (some authors)
 Periodic process to assess the strength of competitors.
o Distinction of core, support and management processes is of strategic
importance to a company.
 Conclusion: The number of processes that are identified in the designation phase
must represent a trade-off between impact and manageability.
o Small number of processes == numerous operations per process.
 Impact when changing a process is higher.
 More difficult to manage.
 Realistic models would take a long time to develop and would be
extremely complex.
 The involvement of a large number of staff will make effective
communication among them problematic.
 Keeping models up to date would be very difficult.
 Improvement projects that are related to large project are more
complex.
o Identify broad and narrow processes
 Broad processes = Where an organisation field it is important to
completely overhaul the existing operations. (ex. competitive forces)
 Narrow processes = Not targeted for major overhauls. Actively
monitored, continuously updated and fine-tuned. (ex. improvement
suggestions of employees)
 In addition to a detailed view on what business processes exist, there also needs
to be understanding of the relations between processes.
o In organisations with both broad and narrow processes, it is important to
map how these narrow processes relate to broad processes.
o Hierarchical relations between processes = Relationships about broad-
narrow relationships of processes.
 ex. management (broad) consists of: order booking, billing, shipment
and delivery (all narrow).
o Illustrates how processes can be sequentially related.
 Upstream process = If a process occurs before another one but are
from the same broad process.
 ex. Billing and Shipping are in the same broad process. But
Billing occurs before Shipping.)
 Downstream process = If a process occurs after another one, but are
from the same broad process.
 ex. Billing and Shipping are in the same broad process. But
Shipping occurs after Billing.)
 o Gain understanding about how important the outcome of a process is as
impute for another process.
 Reference models:
o While processes are subject to different design choices and preferences
from a organization, some general guidance is available in the form of
reference models.
o Developed by a range of different organizations ranged from non-profits to
government research programs.
o Best known examples:
 ITIL, Information Technology Infrastructure Libary.
 SCOR, Supply Chain Operatios Reference Model.
 PCF, Process Classification Framework.
 APQC, American Productivity and Quality Center.
 VRM, Value Reference Model.
 Performance Framework.
o These models standardize:
 What can be seen ales different processes with unique
characteristics and delivering distinguishable products.
 How the performance of a process can be measured.
 Process Architecture
o Organizes overview over the processes that exist within a organizational
context.

Exercise 2.1 Explain how the trade-off between impact and manageability works out for
broad and narrow processes, respectively.
o Any enumeration of business processes should strive for a reasonably
detailed outcome, which needs to be aligned with the organization’s
specific goals of process management. For most organizations, as a rule
of thumb, this will boil down to a dozen to a couple of dozens of business
processes. Very large and diversified organizations might be better off
with identifying a couple of hundred processes. To illustrate this: Within a
multi-national investment firm, which employs close to 3,000 staff and
holds assets in the range of € 300 billion, 120 different business
processes have been identified. To each of these business processes a
process owner is assigned, who oversees the performance of the process
and monitors the achievement of its objectives in terms of customer
satisfaction, profitability, and accountability. Detailed process models are
kept up-to-date, both as a means for documenting planned changes to
any process and for satisfying the requirements of financial authorities. By
contrast, for a small medical clinic in the Netherlands, which employs
medical specialists, nurses, and administrative staff, 10 different treatment
 processes have been identified. A few of these have been mapped in the
form of process models and are now in the process of being automated
with a business process management system. For all other processes, it is
sufficient to be aware of the distinctive treatment options they can provide
to different patient categories.
Exercise 2.2 What are the potential drivers for the described investment firm to identify
a large number of processes?
o In addition to a rather detailed view on what business processes exist, an
understanding must be developed about the relations between the various
processes. In a situation where organizations define both narrow and
broad processes, to avoid confusion, it is important to map how narrow
processes relate to broader processes. A broad process like order
management, for example, can be related to the more narrowly defined
processes of order booking, billing, shipment, and delivery. All of these
can be considered sub-processes of order management. We can call this
an example of hierarchical relations between processes. Processes may
also be related to one another differently. Billing, in the example we just
used, is an upstream process compared to shipment: for the same order
the bill is sent out usually before the ordered goods are shipped. Another
way of expressing this relation is, of course, that shipment can be
considered a downstream process in comparison to billing. This illustrates
how processes can be sequentially related.
Exercise 2.3 Discuss in how far order management might be sequentially related to
booking, billing, shipment, and delivery.
o Most of the time, the insight into the relations between processes may be
less than strictly exact. The most important goal of capturing dependent
relations is to gain an understanding of how the performance of a process
is related to that of another. If one would, for example, redesign an
existing process it is useful to understand which processes depend on the
outcomes of such a process. Such downstream processes may need to
be prepared for receiving information or goods in another frequency or
form than before and measures should be taken to prevent any
disruptions.
Exercise 2.4 At this point, we discussed hierarchical and sequential relations between
business processes. Can you think of other types of relation that are useful to
distinguish between processes? As a hint, you might want to think about the purpose of
identifying the relations between business processes.
o While the designation of business processes and their inter-relationships
is subject to different design choices and preferences, some general
guidance is available. First of all, several so-called reference models for
 business process identification exist. These are developed by a range of
industry consortia, non-profit associations, government research programs
and academia. The best-known examples are the Information Technology
Infrastructure Library (ITIL), the Supply Chain Operations Reference
Model (SCOR) by the Supply Chain Council, the Process Classification
Framework (PCF) by the American Productivity and Quality Center
(APQC), the Value Reference Model (VRM) by the Value Chain Group,
and the Performance Framework of Rummler–Brache. Reference models
standardize what can be seen as different processes, with unique
characteristics and delivering distinguishable products, and how their
performance can be measured. Their largest value is in the identification
of regulatory or highly industry-specific processes, or when performance
benchmarking against peers and competitors is the issue that a process-
centered organization is after. In other cases, these reference models may
still be useful in identification exercises in the form of a checklist. For
example, an organization can use the APQC’s PCF to inventory the
processes in the framework they use, flag those they do not use, and add
its own unique processes. We will take a closer look at the PCF to
inventory A second stream of support is available in the form of specific
design approaches to develop a so-called process architecture. A process
architecture is an organized overview of the processes that exist within an
organizational context, which is often accompanied with guidelines on how
they should be organized. Design approaches for business process
architectures use a certain logic to arrive at an identification of business
processes. We will go into more detail with respect to a specific design
approach.
Finally, what is worth noting with respect to the designation phase is that
processes change over time, deliberately or not. This naturally implies that
process identification is of a continuous nature. To avoid the situation that
one becomes bogged down in the stage of process identification, the
activity should be considered as an exploratory and iterative endeavor.
When a certain stable overview is created it may very well be usable for a
period of two to three years.

The Evaluation Phase

 Not all processes are equally important and do not receive the same amount of
attention.
 Process management involves: Commitment, ownership, investment in
performance enhancement, optimization.
 Processes that create loss or risk demand for: consolidation, decommissioning or
elimination.
 Criteria to evaluate a process evaluation:
o Importance: Assessing strategic relevance of each process.
 Greatest impact on a company`s strategic goals considering
profitability, continuity or contribution
 The criteria assume that there is certain information available.
 Such as: the strategic course of the company.
o Dysfunction: Render a high-level judgment of the "health" of each
process.
 Which processes are in the deepest trouble. These profit most.
 Bad health: Organizations that do not work in process-centered
ways do not have insight in process performance.
o Feasibility: Is the process susceptible to process management
initiatives?
 Obstacles are most likely to be Culture and Politics.
 Focus on processes where it is reasonable to expect benefits.
 Political sensitivities within a organization may have effect on the
success rate of process management efforts.
 BPM Maturity Assessment
o Body of techniques that define the level of systematic process
thinking.
o Aspects to asses:
 To what extend does the organization cover the range of
processes that are ideally expected from it.
 To what degree are these processes documented and
supported.
o CMMI (Capability Maturity Model Integrated) Framework levels:
 Level 1 (Initial)
 Run processes in ad-hoc fashion. No clear definition of
processes. No control.
 Level 2 (Managed)
 Project planning, monitoring and control, measurement,
analysis and product quality assurance are
implemented.
 Level 3 (Defined)
 Focus on processes. Organizational training for
stakeholders to be engaged in process documentation
and analysis.
 Level 4 (Quantitatively Managed)
 Organizational processes performance is tracked.
Project management uses quantitative techniques.
 Level 5 (Optimizing)
 Established organizational performance management
with casual analysis and resolution.
  Important to have credibility in process management initiatives to ensure
organization-wide change.
o Can be achieved by focusing on processes with less strategic
importance, but with need/desire to change.
The different levels of detail in a process architecture:

In this section, we have described the process designation and evaluation phases on
a high level of discourse. Now, we will turn to a specific technique to come up with a
process design architecture.

2.2 Designing a Process Architecture

General
 Processes can be in a consumer-producer relationship .
o One process provides an output that the other process takes as an input.
 Process Architecture levels
o Level 1: Process landscape model, very abstract.
 Level 1 element points to concrete level 2 business process
 Should be understandable. Not more than 20 categories of business
processes of a company.
 All employees should be able to relate to it with their daily work, and
accept it as a consensual description of the company.
 Dijkman approach (see further).
o Level 2: Shows more granularity than level 1, still quite abstract.
  Level 2 element points further to a business process model on level
3.
o Level 3: Shows detail of the processes.
 Including: control flow, data inputs/outputs, assignment of
participants.

Dijkman Model

 Architecture along two dimensions:

o Case Type: Type of cases handled by an organization. (product or service
delivered to external customers or other internal departments)
 Horizontal displayed.
 Classified according to properties (see a paragraph down)
o Business Function: Something an organization does.
 Vertical displayed.
 Hierarchical decomposition of functions:
 Function consists of Sub-Functions which can consist of Sub-
Sub-Functions etc.
 Ex: Purchasing function -> Vendor selection + Operational
Procurement
 Steps to create this model:
1. Identify Case types
2. Identify Functions for case types
3. Construct One or more case/functions matrix`s
4. Identify Processes
Step 1. Identify Case Types
 Selecting case properties that will be used for the classification.
o Purpose: Determine different ways in which (similar) processes are handled.
 Properties that make processes behave differently (different steps)
should be included in the classification.
 Properties used to classify:
 Product/Service type: Home insurance, car insurance, life insurance.
 Channel:
 Contact medium: Telephone, face-to-face, internet.
 Or location: Europe, North-America.
 Customer type (customers dealt with): Frequent flyers, regular travelers.
o Cases would be then classified by combining the previous:
 Home insurance via telephone, home insurance via face-to-face, car
insurance via telephone.
 RESULT: List with Case Types
Exercise 2.5 Consider the case of a bank and the classification criteria product type,
service type, channel, and customer type. In how far are these criteria related to
each other?

Step 2. Identify Functions For Case Types & Construct a

case/function matrix.
 Classification of the business functions that are performed on the different case
types.
 Each case type need to be identified in detail.
o Use a reference model.
o Interview different people within the organization.
 Purpose: Check if reference model applies to the organization or to
identify functions.
 With: Employees involved, product and service managers.
 Different people may use different terms for similar business functions.
 Avoiding terminological issues from the start.
 When a functional separation of the departments needs to be harmonized along
for ex. different locations, management structures also need to change with it.
 RESULT: Matrix of which business function(s) associate with which case type(s).
Observe that these are rules of thumb, which leave room for handling them flexibly.
They merely provide an aid for determining the lowest level of decomposition that
should be used.
Exercise 2.6 Consider the case of a university and the level one processes listed in the
APQC’s PCF. What kind of more specific functions does a university typically cover in
categories 2.0 Develop and Manage Products and Services and in 5.0 Manage
Customer Service?

Step 3. Construct Process Landscape Model

 A cell in the matrix contains a 'X' if the corresponding functions can be performed
for the corresponding case types.
o Group different processes.
o Make the matrix`s so that all X’s are covered. You can use multiple matrices
to increase readability.
 RESULT: One or more Basic Process Landscape Models
 Fig. 2.5 A case/function matrix evolving into a process landscape model (applying
Guideline 1)

preserved. For example, the matrix from Fig. 2.4 can be partitioned into, on the one
hand, a matrix that contains the management and support functions and the internal
customers and, on the other, a matrix that contains the operational functions and the
private and corporate customers.

Step 4. Identify Processes

 Which combinations of business functions and case types form a business
process.
 Trade-off between:
o All X`s are different processes.
o The entire matrix is one process.
 General rule: Entire matrix is one big process which will only be split up in case
certain rules/guidelines apply.
 Guidelines to finish the identifying the process:
1. If a process has different flow objects, it can be split up vertically.
 Flow object = A product/service/object that the process activities are
carried out on.
2. If the flow object of a process changes multiplicity, the process can be split
up vertically.
 When some one task has a single flow object at a time, and another
task has a batch you are better of splitting up the process.
3. If a process changes state, it can be split up vertically.
 In particular, we distinguish:
  Initiation state: Contact between customer and provider.
 Negotiation state: Customer and provider negotiate about the terms
of service/delivery etc.
 Execution state: The provider delivers the product or service
 Acceptance state: Customer and provider negotiate about
acceptance and payment of the delivery
4. If a process contains a logical separation in time, it can be split up
vertically.
 Parts are performed at different time intervals
 ex. Once per customer request, once per day, once per month, once
per year
5. If a process contains a logical separation in space, it can be split up
horizontally.
 If the process is performed differently at multiple locations.
 There must be a difference in the way processes are handled at
multiple locations. Just separation in space is not enough to make
separation in space a must.
6. If a process contains a logical separation in another relevant dimension, it
can be split up horizontally.
 There has to be no choice why a processes needs to be performed
differently across logical units.
 Another relevant dimension other than time and space.
7. If a process is split up in a reference model, it can be split up.
 A reference model is usually a best practice solution. So why not
use that?
8. If a process covers (many) more functions in one case type than in
another, it can be split up horizontally.
 If with different case types, in the same process, there is a
difference in the number of functions the process can be split up.
 See Composite Mortgage Application NL and Simplex Mortgage
Application NL in the figure below.
 RESULT: One or more finished Process Landscape Models
Fig. 2.6 A case/function matrix evolving into a process landscape model (applying
Guide-lines 2–7)
Solutions to Exercises
Solution 2.1 Explain how the trade-off between impact and manageability works out for
broad and narrow processes, respectively. A broad process has by definition a large
scope. Managing it actively potentially can have a large impact on an organization’s
performance. The flip side is that it is more difficult to actively manage such a broad
process or the improvement projects that are related to it. For a narrow process, this is
exactly the other way around: given its smaller scope, it is more easily managed but it
will probably have a lesser impact on an organization’s performance as a whole.
Solution 2.2 The description of the investment firm points at large financial holdings,
which may be related to the employment of many different products (investment
instruments) for many different customers, both private and institutional. Both of these
dimensions, products and customers, may drive the firm to identify different processes
that cater for these. In addition, the description of the firm also mentions ‘accountability’:
for many financial organizations, there are strict requirements on how they must
manage and disclose their operation, as imposed on them by regulatory agencies. This,
too, may be a driver for the identification of many different processes.
Solution 2.3 Order management is not sequentially related to any of these. As
discussed in the text, booking, billing, shipment, and delivery are all sub-processes of
order management. So, it is impossible to indicate that any of these sub-processes
precedes or follows up on order management; rather, they are subsumed by this
process.
Solution 2.4 Organizations wish to accomplish certain goals. Processes are a means to
achieve these goals. A relation that, therefore, may be important is how processes are
related to one another in the sense that they contribute to the same or related goals.
Other, context-specific relations may be important for organizations as well. Consider
how it may be important for an organization to know on which technologies their
processes are based; if a particular technology becomes obsolete, such an organization
knows which processes are affected. A similar line of reasoning can be taken for
geographic areas, regulations, etc.
Solution 2.5 Many banks distinguish different types of customers, and use this
distinction for defining product and service types for them as much as channels. For
instance, a retail bank customer is typically characterized by a low to average income
who requires transaction services and products for building up wealth. Often, banks try
to serve these customers via standardized channels like telephone and internet in order
to limit transaction costs. On the contrary, private bank customers are typically have
high income or possess a considerable fortune. Banks invest much more into personal
advise and consulting of these customers and in offering individual packages of
products and services. Often, such strategic considerations as of those a bank in this
example have the consequence that different classification criteria are often correlated.
Solution 2.6 The products and services of a university relate to teaching and
certification, and essentially support the lifecycle of a student towards obtaining a
degree. Therefore, the category 2.0 mainly relates to the development and
management of curricula and degree programs. The academic entities of a university
are concerned with these tasks. The category 5.0 would refer to the management of
student services. Usually, tasks belonging to this category are organized in an
examinations office of the university assisting in all study-related matters.
Chapter 3: Essential Process Modeling

Business process models are important at various stages of the BPM lifecycle. Before
starting to model a process, it is crucial to understand why we are modeling it. The
models we produce will look quite differently depending on the reason for modeling
them in the first place. There are many reasons for modeling a process. The first one is
simply to understand the process and to share our understanding of the process with
the people who are involved with the process on a daily basis. Indeed, process
participants typically perform quite specialized activities in a process such that they are
hardly confronted with the complexity of the whole process. Therefore, process
modeling helps to better understand the process and to identify and prevent issues.
This step towards a thorough understanding is the prerequisite to conduct process
analysis, redesign or automation.
In this chapter we will become familiar with the basic ingredients of process modeling
using the BPMN language. With these concepts, we will be able to produce business
process models that capture simple temporal and logical relations between activities,
data objects and resources. First, we will describe some essential concepts of process
models, namely how process models relate to process instances. Then, we will explain
the four main structural blocks of branching and merging in process models. These
define exclusive decisions, parallel execution, inclusive decisions and repetition. Finally,
we will cover information artifacts and resources involved in a process.
 Reasons for modeling a process:
o Understand the process.
o Identify and prevent issues.
o Share our understanding of the process to others.

3.1 First Steps with BPMN

Fig. 3.2 Progress of three instances of the order fulfillment process

 Events = Things that happen instantaneously.

o Start event = When an instance of the process start
 Represented by: circle with a thin border.
 ex. Purchase order received.
o End Event = When an instance of the process is complete.
 Represented by: circle with thick border.
  ex. Order fulfilled.
 Activities = Units of work that have a duration.
o Represented by: Rectangles with rounded of corners.
o ex. Confirm order / Emit invoice etc.
 Relation = Sequence: Activity A is followed by activity B.
o Represented by: Arrow with a full arrow head.
o ex. The arrow between Confirm Order and Get Shipment Address.
 Token = Identify the progress/state of a process instance.
o Represented by: Colored dot on top of a process model.
o ex. Red dot above the Ship Product activity
o ex. Black dot inside the start event.
o ex. Green dot between (is starting with the next activity) Receive
Payment and Archive Order.
 Label = A name for an event or activity
o Use for:
 Start event: communicate what triggers/starts an instance of the
process.
 End event: communicate the outcome of the process.
 Activity: Name what the activity does
 Syntax: {VERB}+{ADJECTIVE}+{NOUN}+{COMPLEMENT}
 (Werkwoord, Bijvoeglijk Naamwoord, Zelfstandig
Naamwoord, Toevoeging)
 Adjective and the complement can be used, but is not
needed.
 Long labels will decrease readability of the model.
 Thumb rule: max 5 words (excluding the "glue" words (the,
a, and, via etc.))
 Use words consistently (so no synonyms)
 Use meaningful and not ambiguous (dubbelzinnig) verbs
( to process > order fulfillment)
 ex. {Approve}+{}+{Order}+{} = Approve Order
 ex. {Issue}+{Driver}+{License}+{} = Issue Driver License
 ex. {Renew}+{Driver}+{License}+{via offline agencies} =
Renew Driver License via offline agencies
Modeling Theory
 Model characteristics:
o Mapping: Create a model of the subject.
o Abstraction: Only use relevant aspects of the subject.
o Fit For Purpose: Creation of a blueprint to display the purpose of the
subject.
 Target audience (for who are you making the model).
 o ex. A buyer may want to see a wooden model, but an electrical engineer
can’t use it to design an electrical system.
 Purpose for modeling:
o Organizational design:
 Business oriented, used mainly for understanding and
communication.
 Also benchmarking and improvement.
 For: Managers, Process owners and business analysts.
o Application system design:
 IT-oriented
 For: System Engineers and developers used for automation.
 Blueprints for software development.

3.2 Branching and Merging

 Activities may not be performed sequentially.
 Mutually Exclusive = When two or more activities are alternative to each other.
 Concurrent = When two or more activities can be executed simultaneously.
 Gateway = Gating mechanism that either allows or disallows passage of tokens
trough the gateway.
o Split = The process flow splits in 2 or more different process flows. (1 in,
2-* out)
o Join = Different process flows come together to exit the gateway as one
process flow. (2-* in, 1 out)
 Synchonization = Waiting for a number of tokens to arrive and then merging them
together.
 Deadlock = When a token cannot continue because the wrong gateways are
used.
Exclusive Decisions (XOR)
 Fig. 3.4 An example of the use of XOR gateways

 X marker in the gateway symbol (diamond shape).

 When only one of the branches needs to be executed.
 An XOR-split (decision) routs the token:
o From: The only incoming branch (ex. Check invoice for mismatches)
o To: One of the multiple outgoing branches.
o The line towards "Block invoice" has a line diagonal near the gateway .
 This indicates the default flow.
 Default only counts when the conditions of all the other outgoing
flows evaluate to false.
o Make sure all the outgoing branches have labels describing when to take
this flow.
 An XOR-join (merge) routs the token:
o From: One of the multiple incoming branches (ex. Post invoice, Block
invoice or resend invoice to customer)
o To: The only outgoing branch.
o Waits for the only token to arrive from one of the branches, before
continuing.
Exercise 3.1 Model the following fragment of a business process for assessing loan
applications. Once a loan application has been approved by the loan provider, an
acceptance pack is prepared and sent to the customer. The acceptance pack includes a
repayment schedule which the customer needs to agree upon by sending the signed
documents back to the loan provider. The latter then verifies the repayment agreement:
if the applicant disagreed with the repayment schedule, the loan provider cancels the
application; if the applicant agreed, the loan provider approves the application. In either
case, the process completes with the loan provider notifying the applicant of the
application status.
Parallel Execution (AND)

Fig. 3.5 An example of the use of AND gateways

o marker in the gateway symbol (diamond shape)
 When 2 or more activities do not depend on each other they can be executed in
parallel.
 An AND-split routs the token:
o From: The only incoming branch.
o To: All the outgoing branches.
 An AND-join routs the token
o From: All the incoming branches.
o To: The only outgoing branches.
o Waits for all the tokens to finish their branches, before continuing.
Exercise 3.2 Model the following fragment of a business process for assessing loan
applications.
A loan application is approved if it passes two checks: (i) the applicant’s loan risk
assessment, done automatically by a system, and (ii) the appraisal of the property for
which the loan has been asked, carried out by a property appraiser. The risk
assessment requires a
Inclusinve Decisions (OR)

 marker in the gateway symbol (diamond shape)

 When one or more branches needs to be executed.
 Use only when strictly required. The OR-gateway causes confusion.
 An OR-split (decision) routs the token:
o From: The only incoming branch.
o To: One or more outgoing branches.
 An OR-join routs the token:
o From: One or more incoming branches.
o To: The only outgoing branch.
o Waits for all the active tokens to finish their branches, before continuing

Exercise 3.3 Model the following fragment of a business process for assessing loan
applications.
A loan application may be coupled with a home insurance which is offered at discounted
prices. The applicant may express their interest in a home insurance plan at the time of
submitting their loan application to the loan provider. Based on this information, if the
loan application is approved, the loan provider may either only send an acceptance
pack to the applicant, or also send a home insurance quote. The process then
continues with the verification of the repayment agreement.

Rework and Repetition

  Repetition block = A sequence of activities that can be repeated based on the
result.
 Begins with a join and ends with a split.
 The spit will redirect to the previous join.
Components of a modeling language
 Syntax = Set of modeling elements and a set of rules of how these elements can
be used.
 Semantics = Binding of the elements with precise meaning.
 Notation = Set of graphical symbols for visualization of the elements.
Exercise 3.4 Model the following fragment of a business process for assessing loan
applications.
Once a loan application is received by the loan provider, and before proceeding with its
assessment, the application itself needs to be checked for completeness. If the
application is incomplete, it is returned to the applicant, so that they can fill out the
missing information and send it back to the loan provider. This process is repeated until
the application is found complete.
3.3 Information Artifacts

 Functional perspective = What activities should happen in the process.

o Control-flow perspective = When activities and events should occur.
o Data perspective = Which information artifacts (documents/files) are
required to perform an activity or are produced as result of performing an
activity.

 Data objects = Represents information flowing in and out of activities.

o Can be: Physical and digital artifacts such as: invoice, paper letter,
email, file.
o Displayed as: A document with the upper-right corner folded over.
 ex. Invoice under Emit invoice.
o Allows to model the information flow between process activities.
 o To avoid cluttering the model, a data object may be repeated multiple
times.
o When a data object (1 or more) is an input the activity will proceed when
all the data objects becomes available.
o Short notation for a data object being passed on to another activity, is by
connecting it to the sequence flow line.
 ex. Shipment address between Get shipment address and Ship
product.
o State of a data object
 Note the state behind the name of the data object between [].
 ex. Purchase order [confirmed] under Receive payment.
 Data association = Displays the association between a activity and a data object.
o Can be: An input (arrowhead to activity) or an output (arrowhead to data
object).
o Displayed as: Dotted line with an open arrowhead.
o ex. output from activity: Invoice under emit Invoice.
o ex. input to activity: Purchase order under Confirm Order.
 Data store = Contains data objects that need to be kept beyond the duration of a
process instance.
o Can be: A electronic database, filing cabinet.
o Displayed as: Empty cylinder with triple upper border.
o Connected via data association.
o ex. Warehouse DB under Check stock availability.
 Text annotations = Adds additional information to the object/acivity they are
connected to.
o Displayed as: [ in which the text is written connected with an dotted line
to the object/activity.
o Provides extra information to make the model more clear.
o Do not affect the flow of tokens through the process model.
o ex. Also includes packaging above Ship product.

Exercise 3.5 Put together the four fragments of the loan assessment process that you
created in Exercises 3.1–3.4.
Hint Look at the labels of the start/end events to understand the order dependencies
among the various fragments. Then extend the resulting model by adding all the
required artifacts. Moreover, attach annotations to specify the business rules behind (i)
checking an application completeness, (ii) assessing an application eligibility, and (iii)
verifying a repayment agreement.
3.4 Resources

 Resource = Anyone or anything involved in the performance of a process activity.

o Can be:

 Process participant : Individual person such as an employee.

 Software system: Server or software application.
 Equipment: Printer or manufacturing plant.

o Distinguishing between:

 Active resources (participant): Resources that can autonomously perform

an activity.
 Passive resources (equipment): Resources that are merely involved in the
performance of an activity.

 Resource Classes = A group of resources (people) that are interchangeable in

the sense that any member of the group can perform a given activity.
 Pools = Used to model resource classes.
o Used to model an whole organization.
o Each different business can be represented by a pool.
o Sequence flows cannot cross the boundary of a pool.
 Lane = An partition of an pool, which stands for an sub-class or single resource.
 o Used to model an department, unit, team, software system or
equipment within that organization.
o Lanes can be nested inside each other in multiple levels.
o Important to place an activity/event within the right lane and pool.
o Placing of a data object is not important, they depend on the activities
they are linked to.
o Gateways need to be placed in the same lane as the preceding
decision activity.
 Message flow = Represents the flow between two separate pools (resource
classes)
o Displayed as: Dotted line starting with an empty circle and ending with
an empty arrowhead. Also has the label indicating the content of the
message.
 Collaboration diagram = A diagram with two or more pools.
 White box pool = It shows all the activities, events, gateways and data objects.
 Black box pool = It hides how the process is performed.
o An organization may decide to not expose internal behavior because of
competition.
 Send Activity = An activity that is the source of a message
 Receive Activity = An activity that receives a message. And starts when this
message is available.
Exercise 3.6 Extend the business process for assessing loan applications that you
created in Exercise 3.5 by considering the following resource aspects.
The process for assessing loan applications is executed by four roles within the loan
provider: a financial officer takes care of checking the applicant’s credit history; a
property appraiser is responsible for appraising the property; an insurance sales
representative sends the home insurance quote to the applicant if this is required. All
other activities are performed by the loan officer who is the main point of contact with
the applicant.
DEFINITION OF TERMS
Process Identification
 Process identification refers to those management activities that aim to
systematically define the set of business processes of an organization and
establish clear criteria for selecting specific processes for improvement. The
output is a process architecture, which represents the processes and their
interrelations.
The Designation Phase
 Is to gain an understanding of the processes an organization is involved in as
well as their inter-relationships.
The Evaluation Phase
 Is the phase in the sales funnel where customers make final decisions about
whether they plan to make a purchasing decision. In ABM marketing, this the
time where the sales team works closely with key decision makers to guide the
purchasing process and close the sale.
Designing a Process Architecture
 A process architecture is a conceptual model that shows the processes of a
company and makes their relationships explicit. Typically, these relationships are
defined in two directions. On the one hand, processes can be in a consumer–
producer relationship. This means that one process provides an output that the
other process takes as an input.
Identify Case Types
 Classification of case types is developed for the organization. This is done by
selecting the case properties that will be used for the classification.
Product type: this property identifies the types of products that are handled by an
organization. These can be hierarchically decomposed. For example, an insurance
company handles damages and life insurance products. In the class of damage
insurances, a further decomposition is possible into car insurance and home insurance;
similarly, within the class of life insurance a further decomposition is possible into
healthcare insurance and accident insurance.
Service type: if (a part of) an organization handles services rather than products,this
property identifies the types of services that the organization handles, similar to the way
in which product type identifies the types of tangible deliverables.
Channel: this property represents the channel through which the organization contacts
its customers. We can, for example, distinguish: face-to-face contact (over the counter),
telephone or internet contact.
Customer type: this property represents the types of customer that the organization
deals with. An airline, for example, may distinguish frequent flyers from regular
travelers.
Identify Functions for Case Types
 A classification is developed of the business functions that are performed on the
different case types.
Construct Case/Function Matrices
 A case/function matrix can be split up into multiple matrices for the purpose of
improving readability.
Identify Processes
 Determine which combinations of business functions and case types form a
business process. To determine this, we need to find a trade-off between two
extremes, one in which the entire matrix forms one big process and one in which
each single cross in the matrix forms a process.
Essential Process Modeling
 Process models help us to better understand a business process and to identify
and prevent issues. This step towards a thorough understanding of business
processes is the prerequisite to conduct process analysis, redesign, or
automation.
Events
 Represent things that happen instantaneously (e.g. an invoice has been
received)
 Events are represented by circles
Activities
 Represent units of work that have a duration (e.g. an activity to pay an invoice).
 activities by rounded rectangles
Relation
 Is that of sequence, which implies that one event or activity A is followed by
another event or activity B.
Exclusive Decisions
  Normal/Exclusive gateway – When splitting, routes the flow to one outgoing
branch. When merging, waits for one incoming branch to complete before
triggering the outgoing flow.
Parallel Execution
 The diamond must have an addition (a ‘plus’ sign) symbol inside it.
 When used to split the flow, all output branches are activated simultaneously.
When converging parallel branches, it waits for all input branches to complete
before starting the output stream. There is only one situation where this timing is
not necessary.
 When splitting, activates all outgoing branches simultaneously.
Inclusive Decisions
 When dividing, one or more branches are activated depending on a formula
configured in each flow. All active input branches must be completed before
converging on another gateway.
Information Artifacts
 Artifacts allow you to visually represent objects outside of the actual process.
Artifacts can represent data or notes that describe the process, or they can be
used to organize tasks or processes. There are three main types of artifacts: data
objects, annotations, and groups.
Resources
 Resource is a generic term to refer to anyone or anything involved in the
performance of a process activity.