Fundamentals of
Business Process Management
A Quick Introduction to Value-Driven
Process Thinking
Marlon Dumas
University of Tartu
marlon.dumas@ut.ee
Estonian BPM Roundtable – 10 Oct. 2013

2
Objectives
1. To inspire you to think about your processes as
a way of improving your work and that of your
colleagues
1. To show you how you can improve your
business one process at a time
1. To reflect on which processes you should
improve first, why and how?

3
Structure of the course
• Part 1 – A quick tour of the BPM Lifecycle
– Why BPM?
– Overview of the BPM lifecycle
– Introducing BPM in a company: What to do first?
• Part 2 – Identifying, Prioritizing and Modeling Processes
– Building a process architecture
– Prioritization of business processes
– Bare-bones introduction to process modeling
• Part 3 – Analyzing and re-designing processes
– Simple analysis techniques to look at first
– Tips for process re-design

4
Companion Material
• Fundamentals of Business Process Management
(chapters 1, 2, 6, 8)
– Introduction to BPM (freely available)
– Identification
– Analysis
– Design
http://fundamentals-of-bpm.org
http://slideshare.net/MarlonDumas
Youtube – Marlon Dumas

5
Business Process Management (BPM)
What is it?
Body of principles, methods and tools to design,
analyze, execute and monitor and continuously
manage business processes

6
What is a Business Process?

7
fault-report-to-resolution process
“My washing machine won’t work!”
VALUE
Customer
Warranty?
Parts
StoreService
Dispatch
Technician
Customer
Call Centre
Customer
© Michael Rosemann

8
Processes and Outcomes
• Every process leads to one or several outcomes,
positive or negative
– Positive outcomes deliver value
– Negative outcomes reduce value
• Fault-to-resolution process
– Fault repaired without technician intervention
– Fault repaired with minor technician intervention
– Fault repaired and fully covered by warranty
– Fault repaired and partly covered by warranty
– Fault repaired but not covered by warranty
– Fault not repaired (customer withdrew request)

9
Rule of thumb
“If it does not make at least three
people mad, it’s not a process.”
Hammer and Stanton (1995)

10
Your turn
• Think of a process in your organization:
– Is it order-to-cash, procure-to-pay, fault-to-resolution…
– Who is/are the customer(s)?
– What value does this process deliver to its customer?
– Who are the key actors of the process?
– List at least 3 outcomes of the process.

11
Why BPM?
The Technology Perspective
Information
Technology
Process
Change
Yields
Yields
Business
Value
Index Group (1982)
Enables

12
Why BPM?
The Technology Perspective
“The first rule of any technology used in a business
is that automation applied to an efficient operation
will magnify the efficiency.
The second is that automation applied to an
inefficient operation will magnify the inefficiency.”

13
Why BPM? The Management Perspective
Roger Tregear: Practice Processes, BPTrends, July 2012

14
Why BPM?
Roger Tregear: Practice Processes, BPTrends, July 2012

15
Why BPM?

16
BPM and Related Disciplines
BPM is about managing and improving processes.
Whatever tools it takes to do so are most welcome.

17
How to engage in BPM?
After Tregear (2012)

18
Business Process
Lifecycle

19
Process Identification – Steps
• Enumerate major processes
• Determine process boundaries (scoping)
• Assess strategic relevance of each process
• Assess of the “health” of each process
• Qualify the culture and politics of each process
• Back judgments with performance measures
See Davenport (1993)
Prioritized Processes & Performance Measures

20
Process Enumeration
“Most businesses have just three core processes:
1. Sell stuff
2. Deliver stuff
3. Making sure you have stuff to sell and deliver”
Geary Rummler

21
Core vs Support Processes (Porter)

22
Process enumeration
• Typical number of processes is unclear
• Trade-off:
– ensuring process scope is manageable
– process scope determines potential impact
• Rule of thumb: 10-20 main processes

23
Exercise
• Let us enumerate processes at your company

24
Process scoping
• Processes are interdependent
1. Hierarchical relations: Main processes – subprocesses
2. Upstream–downstream relations
• Key scoping questions:
1. When starts a given process instance?
2. When do we consider a process completed/closed?
3. What key objects does the process manipulates?
4. Who participates in the process?
5. Who owns the process?

25
Process Scoping
Rules of Thumb
• A well-scoped process:
– Has a clear start, clear end (input, output)
– Has a clear, coherent set of “main objects” and
“participants”
– Has a clear owner

26
Process Architecture
Core processes
Support processes
Management processes
Quote handling
Product delivery
Invoice handling
Detailed quote
handling process

27
Exercise
• Let us scope 1-2 processes up to level 2

28
Process selection
Three criteria:
1. Assess strategic relevance of each process
 Strategic importance
1. Render high-level judgments of the “health” of
each process
 Potential dysfunction
1. Qualify the culture and politics of each process
 Feasibility

29
Business Process PICK Chart

30
Back Health Judgments with
Performance Measures

31
Business Process
Lifecycle

32
Purposes of Process Modeling
Communication,
simulation, activity-
based costing…
Detailed Models
including
Data types, conditions, data
mappings, fault handling…
Integration, testing,
deployment…

33
Business Process Modeling Notation
(BPMN)
• OMG Standard, supported by many tools:
– Bizagi Process Modeller (free)
– Signavio (http://www.signavio.com/) - subscription
– Oracle BPA – “kind of free”
– ARIS – very sophisticated but the opposite of free
– IBM Websphere Business Modeler
– Logizian – reasonable tradeoff
– Visio – Your company might already have this
– Paper and pen! - No excuse not to start

34
BPMN from 10 000 miles…
• A BPMN process model is a graph consisting of
four types of elements (among others):

35
Revised Order Management Process

36
When a claim is received, we first check if the claimant has a valid
insurance policy. If not, the claimant the claim is rejected and the
claimant is informed.
Otherwise, the severity of the claim is evaluated. Based on the
outcome (simple or complex claims), relevant forms are sent to the
claimant. Once the forms are returned, we check them for
completeness.
If the forms are complete, we register the claim in the Claims
Management system and the evaluation of the claim may start.
Otherwise, the claimant is asked to update the forms. Upon reception
of the updated forms, we check them again and continue.
BPMN Exercise:
Simplified Insurance Claim Registration

37
Guideline: Naming Conventions
• Give a name to every event and task
• For tasks: verb followed by business object
name and possibly complement
– Issue Driver Licence, Renew Licence via Agency
• Avoid generic verbs such as Handle, Record…
• Every XOR-split should be labelled with
conditions
– Policy is invalid, Claim is inadmissible
• For events: object + past participle
– Invoice received, Claim settled

38
When?
Process
Which?
Data / Service / Product
What?
Function
Who?
Organization
Process Modelling Viewpoints

39
Resource Modelling in BPMN
• In BPMN, resource classes are captured using:
– Pools – independent organizational entities, e.g.
• Customer, Supplier, East-Tallinn Hospital, Tartu Clinic
– Lanes – resource classes in the same organizational
space and sharing common systems
• Sales Department, Marketing Department
• Clerk, Manager, Engineer

40
Example with Pools and Lanes

41
BPMN Exercise: Lanes, Pools
• Claims Handling process at a car insurer
A customer submits a claim by sending in relevant
documentation. The Customer Service department
checks the documents for completeness and registers
the claim. The Claims Handling department picks up
the claim and first checks the insurance policy. Then,
an assessment is performed. If the assessment is
positive, a garage is phoned to authorise the repairs
and the payment is scheduled (in this order). In any
case (whether the outcome is positive or negative),
an e-mail is sent to the customer to notify the
outcome.

42
BPMN Information Artifacts
• Data Objects are a mechanism to show how
data is required or produced by activities.
– Are depicted by a rectangle that has its upper-right
corner folded over.
– Represent input and output of a process activity.
• Data stores are containers of data
objects that need be persisted beyond
the duration of a process instance
• Associations are used to link artifacts
such as data objects and data stores
with flow objects (e.g. activities).
Data
Store

43
Example: Data Object

44
When a claim related to a major car accident is evaluated, a clerk
first retrieves the corresponding car accident report in the Police
Reports database. If the report is retrieved, it is attached to the
claim file. The claim file and the police report serve as input to a
claims handler who calculates an initial claim estimate. Then, an
“action plan” is created based on a “checklist”. Based on the action
plan and the initial claims estimate, a claims manager negotiates a
settlement with the customer. After this negotiation, the claims
manager makes a final decision, updates the claim file to record this
decision, and sends a letter to the claimant to inform him/her of the
decision.
Depict all relevant documents in the model.
BPMN Exercise 3: Data Objects

45
Anything wrong with this model?

46
Is this better?

47
Modeling Guideline
Start with a value chain
• Good practice is that the top-level process should
be simple (no gateways, no lanes) and should
show the main phases of the process
– Each phase then becomes a sub-process
– Top-level process is basically a value chain
• Introduce gateways and lanes at the next levels…

48
Guidelines: Modeling Levels
• First level: start with value chain
• Next level add:
– Main decisions
– Handoffs (lanes, see later)
• Only at the more detailed level add procedural
aspects:
– Parallel gateways
– Input and output data objects, data stores
– Different types of events
– And as much detail as you need

49
Showing the value chain with sub-
processes

50
Question?
• What is the biggest pitfall of process modeling?
1. Using the wrong type of gateways, e.g. decision
gateway instead of parallel gateways
2. Writing process models from top-to-bottom instead
of left-to-right
3. Not following strictly the rules of the BPMN notation
4. Spending lots of time to produce detailed models
that nobody uses

51
Business Process
Lifecycle

52
Process Analysis Techniques

53
Purposes of Qualitative Analysis

54
Eliminating Waste
"All we are doing is looking at the time line, from
the moment the customer gives us an order to
the point when we collect the cash.
And we are reducing the time line by reducing
the non-value-adding wastes ”
Taiichi Ohno

55
7+1 Sources of Waste
1. Unnecessary Transportation (send, receive)
2. Inventory (large work-in-process)
3. Motion (drop-off, pick-up, go to)
4. Waiting (waiting time between tasks)
5. Over-Processing (performing what is not yet
needed or might not be needed)
6. Over-Production (unnecessary cases)
7. Defects (rework to fix defects)
8. Resource underutilization (idle resources)
Source: Seven Wastes defined by Taiichi Ohno
8th
waste coined by Ben Chavis, Jr.

56
Value-Added Analysis
1. Decorticate the process into steps
2. Classify each step into:
– Value-adding (VA): Produces value or satisfaction to
the customer.
• Is the customer willing to pay for this step?
– Business value-adding (BVA): Necessary or useful for
the business to run smoothly, or required due to the
regulatory environment, e.g. checks, controls
• Would the business potentially suffer in the long-term if this
step was removed?
– Non-value-adding (NVA) – everything else including
handovers, delays and rework

57
Example (Equipment Rental Process)

58
Example – Equipment Rental Process

59
Issue Register
• Purpose: to categorise identified issues as part of as-is
process modelling
• A table with the following columns (possibly others):
– issue number
– name
– Description/explanation
– Impact: Qualitative vs. Quantitative
– Possible resolution

60
Issue Register (Equipment Rental)
Name Explanation Assumptions Qualitative
Impact
Quantitative
Impact
Equipment
kept longer
than
needed
Site engineers keep the
equipment longer than
needed by means of
deadline extensions
BuildIT rents 3000 pieces of equipment p.a.
In 10% of cases, site engineers keep the
equipment two days longer than needed.
On average, rented equipment costs 100
per day
0.1 × 3000 ×
2 × 100 =
60,000 p.a.
Rejected
equipment
Site engineers reject
delivered equipment due
to non-conformance to
their specifications
BuildIT rents 3000 pieces of equipment p.a.
Each time an equipment is rejected due to
an internal mistake, BuildIT is billed the cost
of one day of rental, that is 100.
5% of them are rejected due to an internal
mistake
Disruption to
schedules.
Employee
stress and
frustration
3000 × 0.05 ×
100 = 15,000
p.a.
Late
payment
fees
BuildIT pays late
payment fees because
invoices are not paid by
the due date
BuildIT rents 3000 pieces of equipment p.a.
Each equipment is rented on average for 4
days at a rate of 100 per day.
Each rental leads to one invoice.
About 10% of invoices are paid late.
Penalty for late payment is 2%.
0.1 × 3000 ×
4 × 100 ×
0.02 = 2400
p.a.

61
Techniques for issue analysis
• Cause-effect diagrams
• Why-why diagrams
• Pareto charts

62
Cause-effect diagram (rejected equipment)

63
Why-why analysis (equipment rental)
Site engineers keep equipment longer, why?
• Site engineer fears that equipment will not be available
later when needed, why?
– time between request and delivery too long, why?
• excessive time spent in finding a suitable equipment and approving
the request, why?
– time spent by clerk contacting possibly multiple suppliers sequentially;
– time spent waiting for works engineer to check the requests;

64
Pareto chart
• Useful to prioritize a collection of issues or
factors behind an issue
• Bar chart where the height of the bar denotes
the impact of each issue

65
Pareto chart (excessive rental expenses)
http://pareto-chart.qtcharts.com/index.php?g=prtt

66
Business Process
Lifecycle

67
Process Redesign
• Purpose: Identify possibilities for improving the
design of a process: “as is”  “to be”
• No silver-bullet: requires creativity
• Redesign heuristics can be used to generate ideas
Descriprive modelling
of the real world (as-is)
Prescriptive modelling
of the real world (to-be)

68
Process Redesign Approaches

69
The Ford Case Study (Hammer 1990)
Ford needed to review its procurement process to:
• Do it cheaper (cut costs)
• Do it faster (reduce turnaround times)
• Do it better (reduce error rates)
Accounts payable in North America alone employed
> 500 people and turnaround times for processing
POs and invoices was in the order of weeks

70
The Ford Case Study
• Automation would bring some improvement
(20% improvement)
• But Ford decided not to do it… Why?
a) Because at the time, the technology needed to
automate the process was not yet available.
b) Because nobody at Ford knew how to develop the
technology needed to automate the process.
c) Because there were not enough computers and
computer-literate employees at Ford.
d) None of the above

71
The correct answer is …
Mazda’s Accounts Payable Department

72
How the process worked? (“as is”)

73
How the process worked? (“as is”)

74
How the process worked? (“as is”)

75
How the process worked? (“as is”)

76
How the process worked? (“as is”)

77
How the process worked? (“as is”)

78
Reengineering Process (“to be”)

79
Reengineering Process (“to be”)

80
Reengineering Process (“to be”)

81
Reengineering Process (“to be”)

82
Reengineering Process (“to be”)

83
Reengineering Process (“to be”)

84
The result…
• 75% reduction in head count
• Material control is simpler and financial
information is more accurate
• Purchase requisition is faster
• Less overdue payments
 Why automate something we don’t need to do?
Automate things that need to be done.

85
Principles of BPR
1. Capture information once and at the source
2. Subsume information-processing work into the
real work that produces the information
3. Have those who use the output of the process
drive the process
4. Treat geographically dispersed resources as if
they were centralized

86
Exercise – Claims Handling in a
Large Insurance Company
• Claims handling for replacement of
automobile glass
• Under the existing process the client may
have to wait 1-2 weeks before being able
to replace the damaged auto glass
⇒ Goal – A radical overhaul and of the
process to shorten the client waiting time
© Laguna & Marklund

87
Overview of the existing claims
process
Client
Local
independent
agent
Approved
glass
vendor
Claims
processing
center
Request additional information
Pay
Notify agent
File claim
Give instructions
Forward
claim
Request quote
Provide quote
Pay
© Laguna & Marklund

88
Existing claims process
1. Client notifies local agent that she wishes to file a claim. She is
given a claims form and told to obtain a cost estimate from a local
glass vendor.
2. When the claims form is completed the local agent verifies the
information and forwards the claim to a regional processing center.
3. The processing center logs the date and time of the claim’s arrival.
The data is entered into a computer-based system (for record
keeping only) by a clerk. The claim is then placed in a hard copy file
and passed on to a claims representative.
4. a) If the claims representative is satisfied with the claim it is passed
along to several others in the processing chain and eventually a
check is issued and sent to the client.
b) If there are problems with the claim the representative mails it
back to the client for necessary corrections.
5. When the client receives the check she can go to the local glass
vendor and replace the glass.
© Laguna & Marklund

89
Process Redesign Approaches

90
Incremental Process Re-design
1. Select issues to address, improvement goals
2. Map goals to process performance measures
and set objectives/targets
3. Apply re-design heuristics on the “as is”
process model and analyze the tradeoffs
4. Select promising “change options”, justify and
prioritize their implementation

91
Costs
Quality
Time
Flexibility
Process Redesign Tradeoffs

92
Redesign Heuristics
1. Task elimination
2. Task composition
3. Triage
4. Resequencing
5. Parallelism
6. Process specialization and
standardization
7. Resource optimization
8. Communication optimization
9. Automation
Each heuristics improves one side of the devil’s
quadrangle, generally to the detriment of others

93
Sample Heuristics
(8) Communication optimization
• Reduce the number of messages to be exchanged with
customers and business partners
– But avoid front-loading the process too much
– Not necessarily suitable if customer contact is desirable
• Monitor customer interactions, record exceptions,
determine what to front-load/back-load
• Try to automate handling, recording and organization of
messages (send/receive).
(T+,Q+,C+/-,F-)

94
Specific Guidelines
The Complete Kit Concept
• Many processes follow the “complete kit” concept:
– Work should not begin until all pieces necessary to
complete the job are available
• In such cases, consider three principles:
– Provide complete and easy-to- follow instructions for
those who will initiate the process.
– If a process cannot start, the client should be notified of
all defects that could be reasonably identified at the
onset of the process.
– Consider the tradeoff between “incomplete-kit” process
initiation and roundtrip to revise and resubmit a request.
Michael zur Muehlen:
“Service Processes: The Customer at the Center?” http://tinyurl.com/5tunkxy

95
Final Words
• Any process is better than no process
• A good process is better than a bad process
• Even a good process can be improved
Michael Hammer
(1948 – 2008)