Samenvatting BPM H123456

lOMoARcPSD|33530078
Samenvatting Fundamentals of Business Process

Management - Hoofdstukken 1-3,5-6,8
Business Process Mangement (Hanzehogeschool Groningen)
Scannen om te openen op Studeersnel
Studeersnel wordt niet gesponsord of ondersteund door een hogeschool of universiteit

Gedownload door Jasmine (jasmine.agebar@gmail.com)
lOMoARcPSD|33530078

lOMoARcPSD|33530078
Fundementals Of Business Process Management Summary
Table of Contents
1. Introcuction to the summary
2. CHAPTER 1. Introduction to Business Process Management
i. Processes Everywhere
ii. Ingredients of a Business Process
iii. Origins and History of BPM
iv. The BPM Life-cycle
3. CHAPTER 2. Process Identification
i. Focusing on Key Processes
ii. Designing a Process Architecture
4. CHAPTER 3. Essential Process Modeling
i. First Steps with BPMN
ii. Branching and Merging
iii. Information Artifacts
iv. Resources
5. CHAPTER 4. NVT
6. CHAPTER 5. Process Discovery
i. The Setting Of Process Discovery
ii. Discovery Methods
iii. Process Modeling Method
iv. Process Model Quality Assurance
7. CHAPTER 6. Qualitative Process Analysis
i. Value-Added Analysis
ii. Root Cause Analysis
iii. Issue Documentation and Impact Assessment
8. CHAPTER 7. NVT
9. CHAPTER 8. Process Redesign
i. The essence of Process Redesign
ii. Heuristic Process Redesign

lOMoARcPSD|33530078
Introduction
A summary of the book Fundementals Of Business Process Management chapters
1,2,3,5,6 and 8: written originaly by Marlon Dumas, Marcello La Rosa, Jan Mendling
and Hajo A. Reijers.
This was made by me during my first year at the Hanze University of Groningen, The
Netherlands.
English grammar and spelling are not my strong points and so there are errors and
mistakes in this summary. Please contact me if you find any.
All rights are reserved for the original writers of the book.
Failing your exam by only reading my summary, which might not be complete, is your
own responsibility.
Original site from the book: Inculding all sorts of extra materials: http://fundamentals-of-
bpm.org/
Writer: Joris Oosterhuis (genie137 on gitbook.com)
Introcuction to the summary 3

lOMoARcPSD|33530078
1.0 - Chapter Introduction

BPM = Business Process Management
" Art and science of overseeing how work is performed in an organization to ensure
consistent outcomes and take advantage of improvement opportunities."
Processes = Chains of events, activities and decisions.
CHAPTER 1. Introduction to Business Process Management 4

lOMoARcPSD|33530078
1.1 - Processes Everywhere

Typical examples of processes in organizations:
Order-To-Cash:
Starts when a customer submits an order.
Ends when the product/service in question has been delivered to the customer.
Includes: Order verification, shipment, delivery, invoicing, payment receipt and
acknowledgment.
Quote-To-Order:
Starts when a supplier receives a request for quote (RFQ)
Ends when the customer in question places a purchase order.
Usually precedes a Order-To-Cash process.
When combined it is called a Quote-To-Cash.
Procure-To-Pay:
Starts when someone in the organization determines that a given product or
service needs to be purchased.
Ends when the product or service is delivered and paid for.
Includes: obtaining quotes, approving purchase, selecting supplier, issuing
purchase order, receiving/consuming the goods/service, checking and paying
the invoice.
Issue-To-Resolution:
Starts when a consumer raises a problem or issue. (such as a defect product
or an issue while consuming a service)
Ends when (preferably both) a party has concluded that the issue/problem has
been resolved.
Variant for insurance companies: Claim-To-Resolution.
Application-To-Approval:
Starts when someone applies for a benefit/privilege.
Ends when the benefit/privilege has been either approved or denied.
For example building permits (government), admission processes (universities)
or applying for a vacation/special leave (companies)
Balance between quality of service and efficiency.
Processes Everywhere 5

lOMoARcPSD|33530078
1.2 - Ingredients of a Business Process

Business processes encompass a number of events and activities.
Events = Things that happen atomically (have no duration), may trigger other
events or activities. (ex. arrival of equipment)
Activity = Thing that takes time. (ex. inspection of equipment)
Task = Simple activity that can be seen as a single unit of work. (ex. checking the
equipment)
A typical process involves decision points
When a event or activity can have multiple outcomes. For example when an
inspection has been done, it can be cleared for use or send back when faulty.
A typical process involves actors
For example: Human actors, organizations and software systems.
A typical process involves physical objects
For example: Equipment, materials, products and paper documents.
A typical process involves immaterial objects
For example: Electronic documents and records.
The result of a process leads to one of several outcomes:
A positive outcome = Delivers value to the actors involved (ex. Product is
purchased > money for the supplier + happy customer)
A negative outcome = All actors gain no value. (ex. Product is returned > no money
+ no product)
Consumer = The actor who consumes the output of a process
Multiple consumers = For example selling a house. The buyer, seller, real estate
agent, mortage providers and a notary all gain something when a house is sold.
Related BPM Disciplines :

TQM (Total Quality Management)
Historically preceded and inspired BPM.
Focus on: continuous improving and sustaining quality of products.
TQM is found more in the industry, because BPM is more oriented towards
service organizations.
Operations Management
Focus on: managing the physical and technical functions of a firm or
organization, particular relating to production and manufacturing.
Math plays a big part. (probability and queuing theory, decision analysis,
mathematical modeling and simulation)
Operations management controls a process without necessarily changing it.
BPM makes changes to improve.
Ingredients of a Business Process 6

lOMoARcPSD|33530078
Lean
Focus on: Elimination of waste (activities that do not add value to the
customer).
Originates from manufacturing industry (Toyota)
Lean is similar to BPM, but BPM encompasses more and uses IT as a tool to
improve business processes to make them more consistent en repeatable.
Six Sigma
Focus on: Minimization of defects (errors) by measuring quality of the process
output.
Originates from manufacturing (Motorola)
Often combined with Lean. Many techniques are commonly applied in BPM as
well.
Ingredients of a Business Process 7

lOMoARcPSD|33530078
1.3 - Origins and history of BPM

Prehistoric times
Humans support themselves or he small groups they lived in by producing their
own food, tools and items.
Consumers and producers were mostly the same person.
They were generalists. (Knowledge of producing many different things)
Ancient times
Humans were evolving towards an intermediate level of specialism.
People started specializing in one type of goods such as pottery, or providing a
particular service such as lodging for travelers.
Middle Ages
More specialism, often combined in a guild of the craftsmen.
Guild = Group of merchants and artisans concerned with the same economic
activity.
Second Industrial Revolution
Between 1850 and WW1
Scientific Management (Fredrick W. Taylor)
Extreme form of labor division.
Laborers would only be involved in one of the many steps in the production
process.
Most dominant form of organizing work. (also in the government)
Laborers/workers became super specialized in there step in the production
process.
Side effect > managers. Someone has to oversee the productivity of a section of
the production process.
Managers were responsible for pinning down the productivity goals for
individual workers
Main interest > optimize how a job is done with the resources under their
supervision.
How to differentiate between responsibilities of the managers?
Create a functional units in which people with a similar focus on part of the
production process were grouped together.
These units were supervised by managers with different responsibilities. So
were different departments created.
1900 - 2000
As a result of the Second Industrial Revolution: functional organization was
created.
Origins and History of BPM 8

lOMoARcPSD|33530078
Major American companies came to realize that their emphasis on functional

optimization was creating inefficiencies, and thus affecting heir competitiveness.
So instead new IT projects went to Japanese competitors.
1980s Ford acquisition of a big financial stake in Mazda
Mazda was accomplishing the same result with less people than Ford did in the
Purchasing Department.
Ford had a complicated process which purpose was to keep all documents
consistent.
Consistency between 3 files (Purchase order copy, shipping notice, invoice),
each file consisted o f 14 data items.
Various discrepancies were discovered every day, and occupied several 100
people within Ford.
Mazda had only 5 people working in this department, but was not 100x smaller.
As a result of the comparison, Ford carried out several changes in its own
purchasing process.
A central database was created (replaced one of the original paper streams).
New terminals were installed in the warehouse department so personnel could
check incoming goods immediately.
Acceptance of the goods were registered in the purchasing database.
Ford managed to reduce there workforce in accounts payable by 76% (from
500 to 120 people).
1990s BPR (Business Process Redesign/Re-engineering)
Enthusiasm faded down around late 1990s. What went wrong?
1. Concept misuse: It was not clear if BPR was driving downsizing. Companies
used the name BPR for other things than process redesign.
2. Over-radicalism: According to some specialists redesign had to be radical.
"Don`t automate, Obliterate". While a radical approach may be justified in
some situations, most situations require a more gradual approach.
3. Support immaturity: Supported tools and technologies needed for improving a
business process were not available or powerful enough at that time.
Supporting IT applications were also to hard coded to change in order to
achieve process improvement.
What made BPR evolve into BPM

Study shows process oriented manufacturing organizations showed better overall
performance. The mood in departments were better and there were less inter-
functional conflicts.
Different types of new IT systems emerged. (such as ERP and WfMSs)
ERP stores company data in a consistent manner so all stakeholders who
needed access to the data can gain access.

lOMoARcPSD|33530078
WfMSs supported work-distribution to actors, based on predefined business

processes.
WfMSs made it easier to implement changes to business processes.
WfMSs became known as BPMSs (Business Process Management Systems)

lOMoARcPSD|33530078
1.4 - The BPM Lifecycle
Step 1, PROCESS IDENTIFICATION: Which processes are we dealing with and

how can we measure the outcome?
Defining the start and end of a process to eliminate confusion. (as-is process)
If the company has engaged in BPM initiatives in the past (parts) of the
process will already be defined and documented.
If the company has not engaged in BPM initiatives, it needs to identify the
processes that are relevant to the problem/issue and define which
relationships they have.
Measuring value is a crucial step in BPM, because otherwise you cannot
see the improvement the process has made.
A process can be measured via:
Cost related, Decreasing costs while keeping the same/better quality.
The BPM Life-cycle 11

lOMoARcPSD|33530078
Time related, Improving the cycle time (time to do a process), while

keeping the same/better quality.
Quality related, Reducing error rates (times processes end up in a
negative outcome)/
Step 2, PROCESS DISCOVERY: What is the process in detail?
A outcome of this phase is to create a as-is process model. Which reflects the
understanding that people in the organization have about how the work is done.
Textual descriptions are difficult to read and easy to misinterpret. Diagrams make it
much easier for everyone involved to understand. They also limit
misunderstanding.
In a diagram you can find the following:
Swim-lanes: A flowchart is divided into several horizontal lanes. These each
represent a organizational unit/person.
Activity nodes: Units of work that represent a human or software application
doing a specific task.
Control nodes (gateways): Capture the flow of execution between activities.
(decision/choice/check)
Event nodes: Requires a action from an actor in order to proceed with the
process.
Step 3, PROCESS ANALYSIS: What are the issues, and how can we resolve
them?
Identify and analyze potential remedies.

Multiple remedies need to be looked at because a change in the process can cause
other issues down the road.
Changing a process is not as easy as it sounds, because people are used to work
in a certain way.
Sometimes to change a process in your own organization it requires a change in
another organization. (for example with the providing more data to make a better
choice)
Step 4, PROCESS REDESIGN: What is the improved process?
A new process diagram is drawn to shown the organization. (to-be process)

In the new diagram the issues are resolved.
There could be multiple new process concepts. Each varies in the amount of work
required to change, time it takes to implement the changes or what it costs to make
the changes.
Step 5, PROCESS IMPLEMENTATION: What needs to be changed?
For example, IT systems need to change and people need to be trained to use the

lOMoARcPSD|33530078
new system at best.

Complementary facets of change:
Organizational change management
Explain the changes in the process to the participants.
Explain what changes are being made to the participants.
Explain why the changes are beneficial to the company, to the
participants.
Put a change management plan in place in which you:
Describe when the changes wil be put into effect
Describe what transitional arrangements will be employed to address
problems during the transition to the to-be process.
Process automation
Configuration of a existing IT system OR implementation of a new system.
System should support process participants in their performance of tasks
in the process.
Which includes:
Assigning tasks to process participants.
Helping process participants prioritize their work.
Providing process participants with the information they need to
perform a task.
Performing automated cross-checks and other automated tasks
where possible.
Step 6, PROCESS MONITORING AND CONTROLLING: Do some adjustments to
the process need to happen?
Processes need to be monitored and analyzed to identify further

adjustments/improvements to the process to better control the execution of the
process.
BPM should be seen as a circle because the outputs of the process monitoring
make demands for more changes. Also because the ever-changing landscapes of
customer needs, technology and competition.
Stakeholders in a BPM life cycle:
Management team:
CEO (Chief Executive Officer), responsible for overall business performance.
COO (Chief Operations Officer), responsible for the way operations are setup.
CPO (Chief Process Officer), responsible for process performance. (otherwise
COO`s responsibility)
CIO (Chief Information Officer), responsible for efficient and effective operation
of information system infrastructure.
CFO (Chief Financial Officer), responsible for the overall financial performance

lOMoARcPSD|33530078
of the company.
HRD (Human Resources Director), responsible when big numbers of process
participants are involved.
Process Owners:
Responsible for efficient and effective operations of a given process.
Planning, organizing, controlling, monitoring, securing resources, guidance (in
resolving errors)
One person could be responsible for multiple processes.
Process Participants:
Human actors who perform the activities of a business process on a day-to-
day basis.
Conducting of routine work according to standards and guidelines.
Support redesign activities and implementation efforts.
Process Analysts:
Conduct process identification, discovery, analysis and redesign activities.
Coordinate process implementation, process monitoring and process
controlling.
Report to management.
Closely interact with process participants.
Have an business or IT background depending on which change facet they
focus.
System Engineers:
Involved in process redesign and implementation
Interact with process analysts to capture system requirements.
Can be a external contractor.
BPM Group:
Not all organizations have a dedicated BPM group.
Preserving of process documentation.
Knowledge of how to plan and execute an BPM project.
Responsible for maintaining process architecture, prioritizing of redesign
projects and giving support to other stakeholders of a BPM project.

lOMoARcPSD|33530078
2.0 Chapter Introduction

Systematically define the business processes of a company and establishing clear
criteria for prioritizing them.
OUTPUT = PROCESS ARCHITECTURE
Framework for defining priorities and scope for process modeling and redesign
projects.
CHAPTER 2. Process Identification 15

lOMoARcPSD|33530078
2.1 Focusing on Key Processes
What to focus on?

It is not cost-effective to model/analyze/redesign/deploy/support/monitor (via BPM) all
the processes organization. It has to pay off.
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:
Which chain of operations is a single business process.

Which chains are part of another process?
The idea of process management is to actively manage business processes in the
pursuit of satisfying its specific customers.
Categorize business processes:
Existence of only 2 processes: Managing product line & Managing the order cycle
Categories of processes according to Porter:
Core processes (primary activities)
Essential value creation, production of goods/services for which
customers pay.
Focusing on Key Processes 16

lOMoARcPSD|33530078
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 autors)
Periodic process to assess the strength of competiors.
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.
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 dat would be very difficult.
Improvement projects that are related to large project are more complex.
Identify broad and narrow processes
Broad processes = Where an organisation feeld 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 vieuw on what business processes exist, there also needs to be
understanding of the relations between processes.
In organisations with both broad and narrow processes, it is important to map how
these narrow proesses relate to broad processes.
Hierarchical relations between processes = Relationships about broad-narrow
relationships of processes.
ex. management (broad) consists of: order booking, billing, shipment and
delivery (all narrow).
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

lOMoARcPSD|33530078
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.)
Gain understanding about how importand the outcome of a process is as imput for
another process.
Reference models:
While processes are subject to different design choises and preferences from a
organization, some general guidance is available in the form of reference models.
Developed by a range of different organizations ranged from non-profits to
goverment resachearch programs.
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.
These models standardize:
What can be seen als different processes with unique charasteristics and
delivering distinguishable products.
How the performance of a process can be measured.
Process Architecture
Organizes overview over the processes that exist within a organizational context.
The Evaluation Phase

Not al 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:
Importance: Assessing strategic relevance of each process.

Greatest impact on a company`s strategic goals considering profitability,
continuity or contribution

lOMoARcPSD|33530078
The criteria assume that there is certain information available.

Such as: the strategic course of the company..
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.
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
Body of techniques that define the level of systematic process thinking.

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.
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.
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:

lOMoARcPSD|33530078

lOMoARcPSD|33530078
2.2 Designing a Process Architecture
General
Processes can be in a consumer-producer relationship.
One process provides an output that the other process takes as an input.
Process Architecture levels
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).
Level 2: Shows more granularity than level 1, still quite abstract.
Level 2 element points further to a business process model on level 3.
Level 3: Shows detail of the processes.
Including: control flow, data inputs/outputs, assignment of participants.
Dijkman Model
Architecture along two dimensions:
Case Type: Type of cases handled by an organization. (product or service delivered
Designing a Process Architecture 21

lOMoARcPSD|33530078
to external customers or other internal departments)
Horizontal displayed.
Classified according to properties (see a paragraph down)
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.
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.
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
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.
Use a reference model.
Interview different people within the organization.

lOMoARcPSD|33530078
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).
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.
Group different processes.
Make the matrix`s so that all Xes are covered. You can use multiple matrices to
increase readability.
RESULT: One or more Basic Process Landscape Models

lOMoARcPSD|33530078
Step 4. Identify Processes

Which combinations of business functions and case types form a business process.
Trade-off between:
All X`s are different processes.
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

lOMoARcPSD|33530078
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

lOMoARcPSD|33530078
Essential Process Modeling

Reasons for modeling a process:
Understand the process.
Identify and prevent issues.
Share our understanding of the process to others.
CHAPTER 3. Essential Process Modeling 26

lOMoARcPSD|33530078
3.1 First Steps with BPMN
Events = Things that happen instantaneously.

Start event = When an instance of the process start
Represented by: circle with a thin border.
ex. Purchase order received.
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.

Represented by: Rectangles with rounded of corners.
ex. Confirm order / Emit invoice etc.
Relation = Sequence: Activity A is followed by activity B.

Represented by: Arrow with a full arrow head.
ex. The arrow between Confirm Order and Get Shipment Address.
Token = Identify the progress/state of a process instance.

Represented by: Colored dot on top of a process model.
ex. Red dot above the Ship Product activity
ex. Black dot inside the start event.
ex. Green dot between (is starting with the next activity) Receive Payment and
Archive Order.
Label = A name for an event or activity

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)
First Steps with BPMN 27

lOMoARcPSD|33530078
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:
Mapping: Create a model of the subject.
Abstraction: Only use relevant aspects of the subject.
Fit For Purpose: Creation of a blueprint to display the purpose of the subject.
Target audience (for who are you making the model).
ex. A buyer may want to see a wooden model, but an electrical engineer cant use it
to design an electrical system.
Purpose for modeling:
Organizational design:
Business oriented, used mainly for understanding and communication.
Also benchmarking and improvement.
For: Managers, Process owners and business analysts.
Application system design:
IT-oriented
For: System Engineers and developers used for automation.
Blueprints for software development.
First Steps with BPMN 28

lOMoARcPSD|33530078
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.
Split = The process flow splits in 2 or more different process flows. (1 in, 2-* out)
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)
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:
From: The only incoming branch (ex. Check invoice for mismatches)
To: One of the multiple outgoing branches.
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.
Make sure all the outgoing branches have labels describing when to take this flow.
Branching and Merging 29

lOMoARcPSD|33530078
An XOR-join (merge) routs the token:

From: One of the multiple incoming branches (ex. Post invoice, Block invoice or
resend invoice to customer)
To: The only outgoing branch.
Waits for the only token to arrive from one of the branches, before continuing.
Parallel Execution (AND)
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:
From: The only incoming branch.
To: All the outgoing branches.
An AND-join routs the token
From: All the incoming branches.
To: The only outgoing branches.
Waits for all the tokens to finish their branches, before continuing.
Inclusinve Decisions (OR)

lOMoARcPSD|33530078
O 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:
From: The only incoming branch.
To: One or more outgoing branches.
An OR-join routs the token:
From: One or more incoming branches.
To: The only outgoing branch.
Waits for all the active tokens to finish their branches, before continuing
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.

lOMoARcPSD|33530078
3.3 Information Artifacts
Functional perspective = What activities should happen in the process.

Control-flow perspective = When activities and events should occur.
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.

Can be: Physical and digital artifacts such as: invoice, paper letter, email, file.
Displayed as: A document with the upper-right corner folded over.
ex. Invoice under Emit invoice.
Allows to model the information flow between process activities.
To avoid cluttering the model, a data object may be repeated multiple times.
When a data object (1 or more) is an input the activity will proceed when all the
data objects becomes available.
Information Artifacts 32

lOMoARcPSD|33530078
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.
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.
Can be: An input (arrowhead to activity) or an output (arrowhead to data object).
Displayed as: Dotted line with an open arrowhead.
ex. output from activity: Invoice under emit Invoice.
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.
Can be: A electronic database, filing cabinet.
Displayed as: Empty cylinder with triple upper border.
Connected via data association.
ex. Warehouse DB under Check stock availability.
Text annotations = Adds additional information to the object/acivity they are connected
to.
Displayed as: [ in which the text is written connected with an dotted line to the
object/activity.
Provides extra information to make the model more clear.
Do not affect the flow of tokens trough the process model.
ex. Also includes packaging above Ship product.
Information Artifacts 33

lOMoARcPSD|33530078
3.4 Resources
Resource = Anyone or anything involved in the performance of a process activity.

Can be:
Process participant : Individual person such as an employee.
Software system: Server or software application.
Equipment: Printer or manufacturing plant.
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.

Used to model an whole organization.
Each different business can be represented by a pool.
Sequence flows cannot cross the boundary of a pool.
Lane = An partition of an pool, which stands for an sub-class or single resource.

Used to model an department, unit, team, software system or equipment within that
Resources 34

lOMoARcPSD|33530078
organization.
Lanes can be nested inside each other in multiple levels.
Important to place an activity/event within the right lane and pool.
Placing of a data object is not important, they depend on the activities they are
linked to.
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)
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.
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.
Resources 35

lOMoARcPSD|33530078
CHAPTER 4. NVT
CHAPTER 4. NVT 36

lOMoARcPSD|33530078
Process Discovery
CHAPTER 5. Process Discovery 37

lOMoARcPSD|33530078
5.1 The Setting Of Process Discovery

Process Discovery = The act of gathering information about an existing process and
organizing it in terms of an as-is process model.
Modeling can only start when enough information is gathered.
Phases of process discovery:

1. Defining the setting = Assembling a team in a company responsible for working on
the process.
2. Gathering information = Building an understanding of the process using different
discovery methods.
3. Conducting the modeling task = Organizing the creation of the process model in a
systematic way.
4. Assuring process model quality = Guarantee that the resulting process models
meet different quality criteria to ensure trust in the model.
Aspect Process Analyst Domain Expert

Modeling Skills strong limited
Process Knowledge limited strong
Process Analyst
Responsible for driving the modeling an analysis of a business process.
Not familiar with all the details of the business process.
Secure commitment of various domain experts for providing information on the
process.
Domain Expert
Any individual who has intimate knowledge about how a process or activity is
performed.
Multiple domain experts can be involved, each has a different perspective on the
process.
All the domain experts should jointly have insight into the whole process.
Ex. Process participants, process owner/manager, suppliers, customers.
Process Discovery Challenges

1. Fragmented process knowledge
Business process consist of a set of logically related activities.
The Setting Of Process Discovery 38

lOMoARcPSD|33530078
These activities are assigned to specialized participants.

Domain experts know little about the whole process and a lot about their own
task.
Different ideas of the expected output.
Rules of the process are not explicitly defined in detail.
Difficult to puzzle the different views together.
A process analyst needs to talk with several domain experts.
Multiple iterations:
i. Receive input from domain experts.
ii. Proposal for resolving inconsistencies.
iii. Receive approval/feedback/input from domain experts.
iv. etc.
2. Thinking in cases
Domain experts can easily describe activities performed for a specific case, but
have problems responding to general questions about how the process works
in a general way.
" You cannot really generalize, every case is different. "
Process analysts need to keep asking questions to reverse engineer the
conditions that govern the routing decisions in the business process
3. Lack of familiarity with process modeling languages
Domain experts are often not trained to create and READ process models
themselves.
The process analyst often needs to explain the model in a natural-language to
get feedback from the domain experts.
Profile of a process analyst

Five Factor Model (certain personal dispositions that help becoming an expert in
process analysis)
1. Openness (appreciating art, emotion, and adventure)
2. Conscientiousness (tendency to self-discipline, achievement and planning)
3. Extraversion (being positive, energetic, and seeking company)
4. Agree-ableness (being compassionate and cooperative)
5. Neuroticism (being anxious, depressed and vulnerable).
Process analists apprear to be strong in Conscientiousness and Extraversion.

Creation of positive atmosphere despite enterprise-internal politics.
How process analists navigate trough a project is mainly influenced by former
experiences.
Expert process analists pay specific attention to the following aspects:
1. Getting the right people on board.

lOMoARcPSD|33530078
Make sure the hierarchy backs the process participant involvement in the
process discovery
2. Having a set of working hypotheses on how the process is structured at
different levels of details.
Prepare a extensive set of questions and assumptions to be discussed in
workshops or interviews.
3. Identifying patterns in the information provided by domain experts.
Pieces of information typically refer to specific control structure. (gateways
etc.)
4. Paying attention to model aesthetics.
Models have to look nice to be engaging to a wide audience.
Us the right level of abstraction
You should not show a super-detailed model to an executive-level
manager.

lOMoARcPSD|33530078
5.2 Discovery Methods

Discovery methods are techniques for gathering information.
Evidence based discovery
Consists of:
1. Document analysis
There is documentation material available that can be related to an
existing process
Good for getting familiar with the process, the environment and for
creating hypotheses.
Issues:
Documentation is not available in a process oriented way.
The level of granularity of the material might not be appropriate.
Many documents are only partially trustworthy.
Outdated, do not show how it is in reality
2. Observation
Directly follow the processing of individual cases.
The process analyst can either play:
Active role such as a customer.
Process analyst triggers the execution of a process.
Records the steps that are executed and the set of choices that
are offered.
Provides a good understanding of the boundaries of the process
and its essential milestones.
Process analyst will only see parts of the process that require
customer interaction.
Back office processing remains a black box.
Passive role such as an observer.
Appropriate for understanding the entire process.
Requires access to the people and sights where the process is
being worked on.
Requires approval from the managers and supervisors of the
corresponding teams.
People can change their behavior under observation.
Work faster and more precise.
Displays how a process is conducted today in contrast to
Discovery Methods 41

lOMoARcPSD|33530078
document analysis that usually captures the past.

3. Automatic process discovery
Use of event logs stored by information systems
Individual case of the process
Specific activity of the process
Precise point in time
Log information can be misleading (ex. after a system crash)
Creates rather complex models.
Interview based discovery
Labor intensive.
Interviews have to be conducted with various domain experts involved in the
process. (due to everyone not having the same amount of knowledge)
Domain experts feel more comfortable with using a free-form interview than a
structured one.
Information can be hold back when not specifically asked.
The interview usually describes an sunny-day scenario.
Expertise of the process analyst is required for understanding how individual cases
are executed in order to create an meaningful process model.
Multiple interviews to check if the independent process model is correct.
Important to ask what happens when something goes wrong or unexpected
cases are handled.
Strategies for scheduling interviews:
Upstream = Starting backwards from the result of the process.
Understanding what input needs to be available before a activity can start.
Downstream = Starting forwards from the beginning of the process.
Understanding which decisions are taken at a given stage.
Workshop based discovery
Offers the opportunity to get a rich set of information on the business process.
Contributors get immediately used to the modeled process.
Involves more participants.
Uses 5x 0.5 day sessions.
Restricting speech time .
Everybody should express their perspective.
Lighter method: using sticky notes to represent task/event.
Purpose: Build a map of activities and their temporal ordering.
Tasks/events need to be the same level of detail.

lOMoARcPSD|33530078
Involves additional roles for facilitating the discussion and operating the modeling
tool.
Facilitator = Takes care of organizing the verbal contributions of the
participants.
Tool Operator = Directly entering the discussion results into the modeling tool.
Domain Experts = Participate in the discussion.
Process Analyst = Participate in the discussion.
Process owner = Participate in the discussion.
Strengths and Limitations
Aspect Evidence Interview Workshop

Objectivity High Medium-High Medium-High
Richness Medium High High
Time Consumption Low-Medium Medium Medium
Immediacy of Feedback Low High High
Objectivity
BEST: Evidence based
Existing documents, logs and observation provide unbiased account of how
the process works.
Interview en workshop based
Rely on descriptions and interpretations of domain experts who are involved.
Risk that those persons may have perceptions and ideas of how the process
operates, may not be correct.
Domain experts might opportunistically hide relevant information about the
process because of fear for loss of power, influence or position in a political
environment.
Richness
BEST: Interview and workshop based
Domain experts are a good source to clarify reasons and objectives for why a
process is setup as it is.
Provides history of the process and the surrounding organization.
Provides information about the personal agenda of the different stakeholders.
Evidence based
Might show issues or raise questions, but do not provide an answer.
Provides insight into strategic considerations when documented in white
papers.
Does not tell anything about the personal agenda of the different stakeholders.

lOMoARcPSD|33530078
Time consumption
BEST: Evidence based
Can be easily made available to a process analyst.
Automatic Process Discovery costs a lot of time extracting, reformatting, and
filtering of event logs.
Passive observation requires coordination and approval time.
Interview and workshop based
Conducting interviews and workshops is time consuming.
Interviews can take many iterations
Difficult to schedule workshops with various domain experts on short notice.
Immediacy of feedback
BEST: Workshop based

Inconsistent perceptions can be resolved directly
Interview based
Offer opportunity to ask questions
Interviews take many iterations to come to the right model.
Evidence based
Questions can only be answered by talking to a domain expert.
Best to use an mixture of the discovery methods.

lOMoARcPSD|33530078
5.3 Process Modeling Method

Modeling a process in the discovery phase via an predefined procedure.
STEP 1: Identify the process boundaries

GOAL: Essential for understanding the scope.
Has been partially done with the definition of a process architecture.

TODO: Identify events that trigger the processes.
TODO: Identify events that identify possible process outcomes.
STEP 2: Identify activities and events
GOAL: Identify the main activities of the process.
Advantage: Domain experts will be able to state what they are doing, even if they
do not "know" they are part of a bigger process.
Documents might explicitly mention activities (ex. A set of work instructions).
When the model is getting too complex, focus only on the main activities and
events.
TODO: Identify activities that take place within the process.
TODO: Identify intermediate events that take place within the process.
STEP 3: Identify resources and their handovers
Process Modeling Method 45

lOMoARcPSD|33530078
GOAL: Identify resources and their handovers.
Who handles the activities and events.

Definition of pools and lanes.
Assignment of activities and events to a pool or lane.
Handover points are important so that the next worker knows what has been done.
Make assumptions explicit.
Identify parts of the process which can be studied in isolation from the rest.
TODO: Create pools and lanes.
TODO: Place events and activities in the correct pool/lane.

TODO: Define handover points (where is the work handed over to another resource).
STEP 4: Identify the control flow
GOAL: Create the control flow using gateways.

lOMoARcPSD|33530078
TODO: Create decision points ((X)OR-splits/joins) with their relevant conditions, where
possible.
TODO: Create AND gateways where possible.

TODO: Create rework and repetitions using loop structures where possible.
TODO: Create message flows where information is exchanged between multiple
pools/businesses.
STEP 5: Identify additional elements

GOAL: Capture the involved artifacts and exception handlers.
Additions of data elements and exceptions depends on the modeling purpose.

TODO: Add data objects, data stores and their relations to activities and events via data
associations.

lOMoARcPSD|33530078
5.4 Process Model Quality Assurance

Gathering information and organizing it in a process model is often done in a sequential
way, and not simultaneously, there is a need for various steps of quality assurance.
Syntactic Quality and Verification
Process Model Quality Assurance 48

lOMoARcPSD|33530078
Syntactic quality = Producing a process model that complies with the rules and
guidelines.
Following the modeling language rules (ex. BPMN, no sequence flows across
pools)
Verification = Structural and behavioral correctness.
Structural correctness = Types of elements used and how they are connected.
ex. An activity should always have an incoming and outgoing arc.
Behavioral correctness = Relates to potential sequences of execution defined by
the model.
ex. A case should never be able to reach a deadlock or a livelock.
Soundness = Common sound an unsound process fragments: See the picture
above.
Semantic Quality and Validation

lOMoARcPSD|33530078
Semantic quality = Goal of producing models that make true statements. about the
considered domain, either for existing as-is processes or future to-be processes.
The model has to be compared with the real-world domain of a particular business
process.
There are no formal rules to check semantic quality, it has to pass by the people
involved in the process.
Validation = Checking the semantic quality of a model by comparing it with the real-
world business process.
Validity = All statements included in the model are correct and relevant to the
problem.
A domain expert should point out any difference between what the model
states and what is possible in reality.
Can be checked by simulations and interviews.
Completeness = The model contains all relevant statements on a process that
would be correct.
Check if all the possible alternative processing options have been accounted
for.
Pragmatic Quality and Certification

Pragmatic Quality = Building a process model of good usability.
Predict how the model is going to be used.
Can be checked by how well a user understands the model.
Certification = Checking the pragmatic quality of a process model by investigating its
usage.
Aspects of usability:
1. Understandability = How easy it is to read a specific process model.
Size of the model, structural complexity, graphical layout.
2. Maintainability = The ease of applying changes to a process model.
3. Learning = Relates to the degree of how good a process model reveals how a
business process works in reality.
Certification can be conducted using user interviews or user experiments.

Improve usability by providing usability by applying design rules on the structure of
the model.
Checks for Understandability, Maintainability and Learning:
1. Consistency between the visual structure and logical structure.
2. Using meaningful labels.

lOMoARcPSD|33530078
Modeling Guidelines and Conventions

Modeling Guidelines and Conventions are an important tool to make sure the models
are consistent and keep their integrity when multiple people are involved.
Increase readability and compatibility.
Using naming conventions, recommends the use of verb-object style for labeling of
activities etc.
Restrictions, for simplifying the set of elements used in BPMN.
THE SEVEN MODELING GUIDELINES:

1. Use as few elements in the model as possible. (Less elements == easier to
understand)
2. Minimize the routing paths per element. (Less paths == less chance to get errors)
3. Use one start and one end event. (Less events == easier to understand)
4. Model as structured as possible. (Better structured == easier to understand, less
errors)
5. Avoid OR-gateways. (No OR-gateways = easier to understand)
6. Use verb-object activity labels. ( Less ambiguous == easier to understand)
7. Decompose a model with more than 30 elements. (Less elements == easier to
understand)

lOMoARcPSD|33530078
CHAPTER 6. Qualitative Process Analysis

There is not a single way of producing a good process analysis.
Identification of unnecessary parts of the process and there elimination.
Analyze weak parts of the process, that create issues/impact negatively.
CHAPTER 6. Qualitative Process Analysis 52

lOMoARcPSD|33530078
6.1 Value-Added Analysis

Value added analysis consists of two stages:
1. Value classification
2. Waste elimination
Value Classification
Value added analysis = Technique for identifying unnecessary steps in a process, and
eliminating them.
Step = Part of task, or handover between tasks.
Value Classification:
1. Decompose tasks into steps
When no checklists are available, the process analyst needs to conduct
interviews to decompose those steps from the task.
2. Identify customer of the process, and what positive outcomes the customer seeks.
3. Analyze each step in terms of the value it adds.
(VA) Value-adding steps = Directly contribute to positive outcomes of the
process.
ex. Repairing a dryer.
(BVA) Business value-adding steps = Steps that are necessary or useful for
the company that performs the process.
ex. Recording defect in a information system.
(NVA) Non-value adding = The step is none of the above.
Result:
Classification of steps in the equipment rental process (pg. 189)
Not everything is displayed.
Step Performer Classification

Fill request Site Engineer VA
Send request to clerk Site engineer NVA
<> <> <>
Open and examine request Works engineer BVA
Value-Added Analysis 53

lOMoARcPSD|33530078
Waste Elimination
Strive to minimize/eliminate the NVA steps.
Some steps can be eliminated via automation.
Some steps can be eliminated by reducing the control steps.
Weighted against possible consequences.
Before eliminating BVA steps, these steps should be mapped to business goals and
requirements .
ex. Regulations.
"What is the minimum amount of work required in order to perform the process to the
satisfaction of the customer, while fulfilling the goals and requirements associated to the
BVA steps in the process?"
Value-Added Analysis 54

lOMoARcPSD|33530078
6.2 Root Cause Analysis

Even a good process can be made better.
Always errors, misunderstandings, incidents, unnecessary steps and other forms of
waste.
Process analyst`s job: identify and document the issues that plague a process.
Different stakeholders have different issues created from their perspective.
Same issue can be raised by different stakeholders.
Root cause analysis = Family of techniques to identify and understand root cause(s) of
problems or undesirable events.
Cause-Effect Diagrams (Fishbone diagram)
Relationship between a given negative effect and its causes.

Negative effect = Recurrent issue or undesirable level of process performance.
Causes can be divided in:
Casual factors = When corrected, eliminated or avoided would prevent the
Root Cause Analysis 55

lOMoARcPSD|33530078
issue from occurring in the future.

Contributing factors = Set the stage for/increase chances of a given issue
occurring.
In this chapter there will be no distinction between those two.
Factors are grouped into categories
Useful in order to guide the search for causes.
Well known categorization for cause-effect analysis, 6M:
1. Machine
Factors: Technology used.
ex. Software failures, network failures, system crashes
Possible sub-categories:
Lack of functionality
Redundant storage across systems
Low performance of IT/network systems
Poor user interface design
Lack of integration between multiple systems (internal or external)
2. Method
Factors: The way a process is defined, understood or performed.
ex. Employee A thinks employee B will send an email to the customer but
employee B is not aware of this.
Unclear, unsuitable or inconsistent assignment of responsibilities to
process participants.
Lack of empowerment of process participants.
Process participants cannot make decisions without asking
permission from the people above them.
Lack of timely communication.
Between process participants, or them and the customer.
3. Material
Factors: Raw materials, consumables or data required as input.
ex. Incorrect data leading to incorrect decisions.
Raw materials
Consumables
Data
4. Man
Factors: Wrong assessment, incorrect performed step.
ex. Accepting the claim even though the data and rules suggest it needs
to be denied.

lOMoARcPSD|33530078
Lack of training and clear instructions.

Lack of an incentive (aansporing) system to motivate.
Expecting to much from process participants.
Inadequate recruitment.
5. Measurement
Factors: Measurements or calculations made during the process.
ex. Amount to be paid to the customer is miscalculated.
6. Milieu
Factors: Environment in which the process is executed.
Factors which are outside the control of the company.
ex. Faulty data from a police report which is used to handle car insurance
claims.
Originating Actor
Alternative, 4P (Policies, Procedures, People, Plant/equipment).

6M/4P meant as guidelines for brainstorming during root cause analysis.
Cause-effect diagram (Fishbone diagram)
Consists of:
Trunk = Main horizontal line (ex. Big blue arrow)
Effect that is being analyzed in a box connected to the trunk. (ex. Issue)
Main branch = Arrows from the box with one of the 6M`s to the trunk.
Primary Factors = Have a direct impact on the issue at hand.
Secundary Factors = Have an impact on the primary factors.
Ex. Underneath here.

lOMoARcPSD|33530078
Why-Why Diagrams (Tree diagams)
Capture series of cause-to-effect relations that lead to a given effect.

Recursively ask the question: "Why has something happened??"

lOMoARcPSD|33530078
Asking it 5 times allows to pin down the root cause of a given negative effect.
Structuring brainstorm sessions.
Examples see page 197

lOMoARcPSD|33530078
Issue Documentation and Impact

Assessment
Understand impact of the issues.
Techniques for impact assessment.
Issue Register
Provides a more detailed analysis of individual issues and their impact.
Determine how and to what extend each issue is impacting on the performance of
the process.
Quantitatively = Time/money lost.
Qualitatively = Perceived nuisance (hinder) to the customer or risks that the issue
entails.
Fields:
1. Name of the issue
Short, 2-5 words, understandable by all.
2. Description
Short, 1-3 sentences, focused on the issue itself.
3. Priority
A number, stating the relevance relative to other issues.
4. Assumptions (input data)
Any data used or assumptions mad in the estimation of the impact of the issue.
ex. Number of times a given negative outcome occurs.
ex. Estimated loss per occurrence of a negative outcome.
Over time these assumptions/estimates will be replaced with more reliable
numbers.
5. Qualitative impact
Description of the impact in qualitative terms.
ex. Impact of the issue on customer/employee satisfaction, long term supplier
relationships, company reputation.
6. Quantitative impact
Estimate of the impact of the issue in quantitative terms.
ex. Time loss, revenue loss, avoidable costs.
Evt. extra possible resolution field in the view of process redesign.

Examples, see page 200.
Issue Documentation and Impact Assessment 60

lOMoARcPSD|33530078
Pareto Analysis
Impact assessment input for Pareto analysis.

Pareto Analysis = identify which issues or which causal factors of an issue should be
given priority.
PRINCIPLE: Small number of factors are responsible for the largest share of a
given effect.
80-20 principle ( 20% of the issues is responsible for 80% of the effect )
APPROACH:
1. Define the effect to be analyzed and the measure via which this effect will be
quantified.
ex. Financial loss for customer/business.
ex. Time loss by the customer/process participants.
ex. Number of occurrences of a negative outcome, such as number of
unsatisfied customers due to errors made when handling their case.
2. Identify all relevant issues that contribute to the effect to be analyzed.
3. Quantify each issue according to the chosen measure.
Quantitative impact column in the issue register can be used.
4. Sort the issues according to the chosen measure (from highest to lowest
impact) and draw a so-called Pareto chart. a. A bar chart where each bar
corresponds to an issue and the height of the bar is proportional to the impact
of the issue or factor. b. A curve that plots the cumulative percentage impact of
the issues.
Pareto analysis focuses on a single dimension.

lOMoARcPSD|33530078
PICK chart
Complement Pareto analysis.

Each issue appears as a point.
Horizontal axis = difficulty of addressing/fixing the issue
Vertical axis = payoff when the issue is fixed
Split into 4 quadrants:
Possible (bottom left, low payoff, easy to do)
Implement (top left, high payoff, easy to do)
Challenge (top right, high payoff, hard to do)
Kill (bottom right, low payoff, hard to do)

lOMoARcPSD|33530078
CHAPTER 7. NVT
CHAPTER 7. NVT 63

lOMoARcPSD|33530078
CHAPTER 8. Process Redesign

Redesign often not approached in a systematic way but rather considered as a purely
creative activity.
Parts of the spectrum of potential redesign options could be missed.
CHAPTER 8. Process Redesign 64

lOMoARcPSD|33530078
8.1 The essence of Process Redesign

Motivations and trade-offs of redesign.
Why Redesign?
Business process redesign is about improving the quality of products/services by
rethinking and re-organizing business processes.
If someone wants to improve the quality of a product/service from the perspective

of a customer, the best way to go is to improve the related business process.
A customer-oriented organization becomes a process-centered organization.
Why would anyone like to redesign business processes?
1. All business processes evolve over time. (organic nature)

People who do the day-to-day operations are usually not inclined or equipped
to start rethinking the overall processes.
People who do the day-to-day operations usually only know the activity they
do, and before and after them.
Even managers are more concerned with the day-to-day execution than
structural improvement.
2. The world evolves.
New competitors
Different preferences of customers.
So when there is still a strategic incentive to keep offering a product or service,
the best way to keep competitive is to do a process redesign.
What is redesign?
Redesign = Any change to an existing progress.
Framework of items to think about with process redesign
1. The Customers of the business process (internal or external)
2. The Business Process Operation view:
How a business process is implemented.
The number of activities that are identified in the process.
The nature of the activities.
3. The business process behavior view:
How a business process is executed.
The essence of Process Redesign 65

lOMoARcPSD|33530078
In which order activities are executed .

How the activities are scheduled and assigned for execution.
4. The organization and the participants in the business process:
Organization structure (elements: roles, users, groups, departments, etc.)
Organization population (individuals who can execute activities)
5. The information that the business process uses or creates.
6. The technology the business process uses.
7. The external environment the process is situated in.
Process redesign extends to:

Processes
Organizations
External environment
Information
Technology
Products delivered to the customers
Process redesign excludes activities such as training people for their new/edited
activities.
Not each business domain is equally suitable for (application/business) process
redesign
Manufacturing domain: transforming raw materials to products using robots an
sophisticated machinery.
Services domain: Mostly knowledge is involved in the processing of information to
deliver a particular service.
Properties of service organizations:
Making a copy is easy and cheap (on paper or electronically).
No limitations on the in-process inventory (stored in a database, require not
much space).
Less requirement with respect to the order in which activities are executed
Quality is difficult to measure.
Quality of end products may vary.
Transportation of electronic data is timeless.
More freedom in redesigning a business process in the services domain than the
manufacturing domain.
The Devil`s Quadrangle

lOMoARcPSD|33530078
Available directions for improvement

Time (lower is better)
Cost (lower is better)
Quality (higher is better)
Flexibility (higher is better) (How a process can deal with variation)
Improving one property can decrease another.
Ex. Doing something what increases quality, adds more time to the production.
Redesign Heuristics = Common approaches to improve business processes.
How to redesign?
Levels of abstraction for methods for process redesign
Methodologies
collection of problem-solving methods with principles and a common
philosophy.
Field of consulting firms which developed these.

lOMoARcPSD|33530078
Techniques
Precisely described procedures for achieving a standard task.
Ex. Fishbone diagram, pareto analysis etc.
Redisigning/ creativity techniques
Ex. Brainstorming, flowcharting, data modeling, role-playing, simulation etc.
Tools
A computer software package to support one or more techniques.
Intensity of a methodology = Pace that one aims with changing the process.
Starting point of the redesign effort:
OPTION A: Start from scratch
Easyer to get rid off the inefficiencies in the current process.
Better chance to create a new truly innovative process alternative.
OPTION B: From traits of the existing process that is to be redesigned
Most popular approach
No need to cover all exceptions, or to forget steps.
Level of detail is already inplemented.
OPTION C: Use a good general design (Reference Model)
Use of a blueprint or reference model.
Developed by consultancy and IT companies
Gives an up to date and standardized view on how to carry out a business
process.

lOMoARcPSD|33530078
8.2 Heuristic Process Redesign

Stages of heuristic process redesign:
1. Initiate
GOAL: Create understanding of current situation (as-is model)
Usage of BPMN to create a model
GOAL: Set performance goals for the redesign project
Get a clear picture with the Devil`s quadrangle.
2. Design
GOAL: Identify and execute potential improvement actions using redesign
heuristics.
For each heuristic it needs to be determined if it is applicable.
For some heuristics it makes sense to go together, for some it does not.
GOAL: Generate a set of scenarios which each describe which heuristics are
applied in a scenario, and how this is done.
3. Evaluate
GOAL: Evaluate the different redesign scenarios created in the previous step.
Use a combination of qualitative and quantitative techniques.
GOAL: Decide to:
i. Implement the scenario OR
ii. Adjust the performance goals OR
iii. Step back to the design stage OR
iv. Drop the redesign project altogether.
Customer Heuristics
Time Cost Quality Flexibility
Control relocation . -- + .
Contact reduction + -- + .
Integration + + . --
This are effects on the characteristics.
Control relocation (“Move controls towards the customer”.)

Let the customer do more.
Less work for the employees.
Heuristic Process Redesign 69

lOMoARcPSD|33530078
DISADVANTAGE: Higher probability of fraud, less yield.

Contact reduction (“Reduce the number of contacts with customers and third parties”)
Reducing time spend on waiting for contact.
DISADVANTAGE: Increased possible error injection.
DISADVANTAGE: Possible loss of essential information.
Integration (“Consider the integration with a business process of the customer or a
supplier”)
More efficent execution.
DISADVANTAGE: Growth of mutual dependence, decrease of flexibility.
Business Process Operation Heuristics

Case types + + -- --
Activity elimination + + -- .
Case-based work + - . .
Triage . -- + --
Activity composition + + . --
Case types (“Determine whether activities are related to the same type of case and, if
necessary, distinguish new business processes”)
Activity elimination (“Eliminate unnecessary activities from a business process”)
Case-based work (“Consider removing batch-processing and periodic activities from a
business process”)
Triage (“Consider the division of a general activity into two or more alternative
activities”)
Activity composition (“Combine small activities into composite activities and divide
large activities into workable smaller activities”)
Business Process Behavior Heuristics

Re-sequencing + + . .
Parallelism + -- . --

lOMoARcPSD|33530078
Knock-out -- + . .
Exception + -- + --
Re-sequencing (“Move activities to more appropriate places”)

Parallelism (“Consider whether activities may be executed in parallel”)
Knock-out (“Order knock-outs in an increasing order of effort and in a decreasing order
of termination probability”)
Exception (“Design business processes for typical cases and isolate exceptional cases
from the normal flow”)
Organization Heuristics
Case assignment . . + --
Flexible assignment + -- . +
Centralization + -- . +
Split responsibilities . . + --
Customer teams . . + --
Numerical involvement + -- . --
Case manager . -- + .
Extra resources + -- . +
Specialist-generalist + . + --
Empower + . -- +
Case assignment (“Let workers perform as many steps as possible for single cases”)
Flexible assignment (“Assign work in such a way that maximal flexibility is preserved
for the near future”)
Centralization (“Treat geographically dispersed resources as if they are centralized”)
Split responsibilities (“Avoid shared responsibilities for tasks by people from different
functional units”)
Customer teams (“Consider to compose work teams of people from different
departments that will take care of the complete handling of specific sorts of cases”)
Numerical involvement ( “Minimize the number of departments, groups and persons
involved in a business process”)

lOMoARcPSD|33530078
Case manager (“Appoint one person to be responsible for the handling of each type of
case, the case manager”)
Extra resources (“If capacity is insufficient, consider increasing the available number of
resources”)
Specialist-generalist (“Consider to deepen or broaden the skills of resources”)
Empower (“Give workers most of the decision-making authority instead of relying on
middle management”)
Information Heuristics
Control addition -- -- + .
Buffering + -- . .
Control addition (“Check the completeness and correctness of incoming materials and
check the output before it is sent to customers”)
Buffering (“Instead of requesting information from an external source, buffer it and
subscribe to updates”)
Technology Heuristics
Activity automation + -- + --
Integral technology + -- . .
Activity automation (“Consider automating activities”)

Integral technology (“Try to elevate physical constraints in a business process by
applying new technology”)

Samenvatting BPM H123456

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Samenvatting BPM H123456

Uploaded by

Copyright:

Available Formats

lOMoARcPSD|33530078

Samenvatting Fundamentals of Business Process

Scannen om te openen op Studeersnel

Studeersnel wordt niet gesponsord of ondersteund door een hogeschool of universiteit

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

Writer: Joris Oosterhuis (genie137 on gitbook.com)

Introcuction to the summary 3

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

1.0 - Chapter Introduction

CHAPTER 1. Introduction to Business Process Management 4

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

1.1 - Processes Everywhere

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

1.2 - Ingredients of a Business Process

Related BPM Disciplines :

Ingredients of a Business Process 6

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

Ingredients of a Business Process 7

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

1.3 - Origins and history of BPM

Origins and History of BPM 8

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

Major American companies came to realize that their emphasis on functional

What made BPR evolve into BPM

Origins and History of BPM 9

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

WfMSs supported work-distribution to actors, based on predefined business

Origins and History of BPM 10

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

1.4 - The BPM Lifecycle

Step 1, PROCESS IDENTIFICATION: Which processes are we dealing with and

The BPM Life-cycle 11

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

Time related, Improving the cycle time (time to do a process), while

Step 2, PROCESS DISCOVERY: What is the process in detail?

Identify and analyze potential remedies.

A new process diagram is drawn to shown the organization. (to-be process)

The BPM Life-cycle 12

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

new system at best.

Processes need to be monitored and analyzed to identify further

The BPM Life-cycle 13

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

The BPM Life-cycle 14

Gedownload door Jasmine (jasmine.agebar@gmail.com)

Fundementals Of Business Process Management Summary

2.0 Chapter Introduction

CHAPTER 2. Process Identification 15