Chapter 2 – Process Identification

1. Process Identification - Focusing on Key Processes

A. Designation Phase
B. Evaluation Phase

2. Designing a Process Architecture

A. Identify Case Types
B. Identify Functions for Case Types
C. Construct Case/Function Matrices
D. Identify Processes
E. Complete the Process Architecture

2
 Process Identification

Process Identification

Dumas, et al. (2013)

3
 Process Identification

Process Identification

What is Process Identification?

➢ The definition of an organization’s business processes;
➢ The establishment of criteria to prioritize the management of these processes.

Why conduct Process Identification?

➢ To better understand the organization;
➢ To maximize value of BPM initiatives.

Result of Process Identification: Process Architecture

➢ Capture business processes and their scope;
➢ Serve as a framework for defining priorities and scope of subsequent BPM phases (e.g.
modelling, redesign and automation).

4
 Process Identification

Process Identification
Process identification is intended to identify the firms’ business processes and establish
clear criteria and rules for prioritizing them.
Process architecture: should represent the organization’s business
processes how they relate with each other.

The process identification is separated in two different stages:

1. Designation
• Enumerate main processes Process
• Determine process scope Architecture

2. Evaluation
Prioritize processes based on: Prioritized
• Importance Process
• Health
Portfolio
• Feasibility
5
 Process Identification

Focusing on the key processes within an organization

• Few organizations have the capability to
model every process they have in detail Prioritize processes
• BPM is not free
BPM initiatives need to focus on key processes (subset of process in an organization).

When one is initiating a BPM initiative, two answers must be addressed:

1. what processes are executed in the organization (designation)?
2. which ones should the organization focus on (evaluation)?

For this to be possible an organization needs to have a clear map of all its processes.

Hence, process identification is concerned with two successive phases: designation and
evaluation.

6
 The Designation Phase

The Designation Phase

The designation phase aims to enumerate every existing process within an organization.
This enumeration is of specially difficulty for organizations in early, or non-existing, stages
of BPM.

Perhaps one of the main constraints in this phase is related with the fact that business
processes have a hierarchical nature, i.e., different criteria can be considered for
determining which chains of operations can be seen as forming an independent business
process and which ones are seen as being part of another process.

As there are various perspectives on how to categorize business processes within an

organization, one may look at its value chain for achieving this purpose.

7
 The Designation Phase

Porter’s Value Chain Model

In enumerating business processes, some authors posit that there is only two types of
processes (managing the product line, and managing the order cycle); whereas others
argue that there are three (developing new products, delivering products to customers,
and managing customer relationships), among others.

One of the most common

definition is the Michael Porter’s
Value Chain Model.

8
 The Designation Phase

After Porter’s Value Chain Model

The Organization Source: Marcello La Rosa

Management
Processes

Customers / Owners
Suppliers / Partners

Core Processes

Support Processes
9
 The Designation Phase

Porter’s Value Chain Model Example: Wholesaler

Core processes
➢ Sales (lead-to-quote, quote-to-order, order-to-cash)
➢ Direct procurement (supplies replenishment)
➢ …
Support processes
➢ Indirect procurement (parts replenishment, operational resources replenishment…)
➢ HR (policies update, recruitment, induction, probation…)
➢ …
Management processes
➢ Suppliers management (suppliers planning, suppliers acquisition…)
➢ Logistics management (logistics planning, logistics controlling…)
➢ …

10
 The Designation Phase

Process Architecture Example: Wholesaler

Strategic
Mng.
Corporate Investor
Development Relations
Warehouse Demand
Mng Mng.
Core Processes

Direct
Sales Distribution
Procurement
Process
Marketing Service
Group
Processes
Support

Indirect
Finance IT HR
Procurement
11
 The Designation Phase

Process Architecture Example: Insurance Company

Strategic
Mng.

Logistics Market Investors

Mng. Development Relations

Risk Assessment
and Management

Sales and Marketing

Core Processes

Underwriting Policy Claims

Management Servicing Management

Process
Payment Collections and Disbursement
Group
Asset Management

Source:
Processes

Marcello La Rosa
Support

Finance/ Legal/
Reinsurance IT HR
Treasury Audit
12
 The Designation Phase

After Porter’s Value Chain Model

Management processes Sign Source:

provide direction, rules and Contracts Marcello La Rosa
practices
Establish
Sourcing Plan
Evaluate
Vendors
Procedure Vendors
Process

Core processes
Fill Order Process
generate value as they
are directly linked to Receive Approve Deliver
Fill Order
external customers Order Order Order

Reorder
Supplies
Support processes provide
Stock Process Order
resources to be used by other Supplies Supplies
processes
Receive
Supplies
13
 The Designation Phase

Process Architecture Exercise: University Sport Services

HR

Indirect Procurement

Strategic Mng.

Teaching Awards

IP Mng.

Marketing

Course Mng.

Additional Services Mng.

Language Training

Admissions

IT

Market Mng.

Teaching Courses 14
 The Designation Phase

Process Architecture Exercise: University (Possible Solution)

Market Mng.

Additional Services Mng.

Strategic Mng. IP Mng. Course Mng.

Marketing Teaching Courses

Core Processes

Language Training Sport Services

Admissions Teaching Awards

Processes
Support

IT HR Indirect Procurement
15
 The Designation Phase

The Designation Phase – How many (identified) processes are advisable?

Any list of business processes ought to attempt for a realistically complete result, which
needs to be associated with the organization’s specific objectives of BPM. For most
organizations, as a rule of thumb, this corresponds from a dozen to a couple of dozens of
processes.

Besides a quite exhaustive sight on what processes occur, an understanding needs to be

developed regarding the relationships across the multiple processes. Every time
organizations define both narrow and broad processes it is imperative to map how narrow
processes relate to broader processes in order to avoid confusions.

It is very likely that the description of between the processes’ relations between is
subjective. The most important objective of apprehending dependent relations is to
achieve an understanding of how the performance of a process is related with another’s

16
 The Designation Phase

The Designation Phase - Impact vs. Manageability (critical point in this stage)
A very important issue in the designation phase is the number of processes defined!!
Advantages Disadvantages
Small / many useful for an organization initiating BPM low level of
Processes activities manageability
Large / few have higher impact in the organization as much more difficult to
Processes it is easier to spot opportunities for model and redesign
efficiency gains by identifying redundant
work

To balance the advantages and disadvantages of a large process scope, Davenport

suggests a combination of both, i.e., define broad and narrow processes:
➢ Broad processes are identified in areas where an organization feels it is important
to completely renovate the existing operations at some point.
➢ Narrow processes are not targeted for major renovations; they do need to be
actively monitored and are subjected to continuous fine-tuning and updating.
17
 The Designation Phase

The Designation Phase - Approaches

Processes may be designated by consider their interrelations in:
1. Specialization: general – special product/service (business case / function matrix);
2. Horizontal: upstream – downstream processes (value chain analysis);
3. Vertical: main processes – sub-processes (process decomposition).

18
 The Designation Phase

Value Chain Modeling Approach to Identify Processes (Horizontal example)

➢ Chain of processes an organization performs to deliver value to customers and
stakeholders

➢ More generally, a mechanism to group high-level business processes according to an

order relation (can be applied to core, support and management processes)
business
process
Procure-to-service
Supplies Lead-to- Quote-to- Order-to- After-sale
Purchases quote order cash service

order
relation
19
 The Designation Phase

The Designation Phase - Question

1. Explain how the trade-off between impact and manageability works out for broad and
narrow processes, respectively.

20
 The Designation Phase

The Designation Phase - Question

1. Explain how the trade-off between impact and manageability works out for broad and
narrow processes, respectively.
Answer: The smaller the number of the processes one wishes to identify, the larger their
individual scope is (yields larger impact). The smaller the number of the processes one
wishes to identify, the bigger their individual scope is.
The main advantage of a large process scope is that it potentially increases the impact
one can have with actively managing such a process.

21
 The Evaluation Phase

The Evaluation Phase

Main objective: evaluate which processes should be focused on BPM initiatives.

Note that not all processes are equally relevant nor can them receive the same level of
attention from BPM team.

It is therefore critical to develop some criteria to evaluate which processes should be

addressed first. Although there are multiple methods, the most popular ones are
grounded on processes’ importance, dysfunction (health) or feasibility.

22
 The Evaluation Phase

Criteria for evaluating processes’ importance

➢ Importance: Considers the importance that each process has on the organization’s
strategic goals (e.g., profitability, business continuity, etc.).
➢ Dysfunction: Takes into consideration a (to some extent still subjective) evaluation of
the each process’ health. Hence, the most important question is which processes need
to be managed first, due to its constant problems.
➢ Feasibility: Developed based on how prone is each process of being successfully
managed (processes where it is realistic to anticipate higher benefits).

Keep in mind that all these criteria demands that there is some level of information
regarding the processes available. At this point, process models (for process analysis) are
usually not yet available. So, some subjectivity is always present.

23
 The Evaluation Phase

How many processes should then be subjected to BPM?

There is no straight answer to this question.

Some organizations prefer to start by modelling every important business process,

postponing the initiation of more advanced BPM activities. The reason behind this
decision is the fact that process models are the foundation of every subsequent BPM
activity. Hence, their existence is a requirement to understand where improvements’
opportunities may be hidden.

On the other hand, this tactic has its own drawbacks, such as, e.g., major (and more
complex) improvements may be missed as the focus is on the simplest ones, or that top-
management starts to feel that BPM does not lead to efficiency improvements.

24
 Process Architecture

Designing a Process Architecture

As mentioned earlier, the output of the process architecture stage, within the BPM
lifecycle presented on the previous chapter of this course, is to design a process
architecture. A process architecture is a map that comprises the processes within an
organization and its relationships with each others.

25
 Process Architecture

Designing a Process Architecture

Usually a process architecture provides multiple levels of detail (see the previous slide).

• The first level is denominated process landscape or process architecture for level one
and should include the main processes an organization conducts in a very simple way;

• Each process within this first layer subsequently points to a more developed business
process on the 2nd level, called abstract process models;

• Finally, each business process on the 2nd level points to a process model in the 3rd level,
with an increased level of detail. The 3rd level is known as detailed process models, and
comprises the actual processes mapped (e.g., using BPMN 2.0), with every element
specified

26
 Process Architecture

Designing a Process Architecture

In the BPM field, there are several approaches to process architectures. In the context of
this course, we will use the one provided by Dijkman et al. (2011). This approach
developed the 1st level of the process architecture in two distinct dimensions: case types
and business functions:
• The case type dimension classifies the types of cases that are handled by an
organization;
• The business function dimension classifies the functions of an organization, i.e., what
the organization does.
Process
Case Types
Landscape
X
Business X
Functions
X X
X 27
 Process Architecture

Case Types
A case is something that an organization/unit/department does. Normally, a case is a P/S
that is delivered by the firm to its clients, such as a bank account (service) or a electronic
device (product). Note that, cases can characterize P/S that are “delivered” to the
organization’s internal or external customers. Hence, case types can be purposely
categorized using many types of different properties.

Business Functions
A business function categorizes the functions of an organization. A function is something
that an organization does. Usually, a hierarchical decomposition of functions can be made:
A function consists of sub-functions, which, in turn, consist of sub-sub-functions, etc.

28
 Process Architecture

Designing a Process Architecture

To arrive at a business process architecture as the one provided in the previous slide, an
approach consisting of four steps is proposed:
1. Identify the organization’s case types;
2. identify the organization’s functions for each case type stated earlier;
3. construct one or more case/function matrices; and
4. identify the processes crossing each case types with business functions.

29
 Process Architecture

Case Types
Case types categorization can be stated using many number of properties. Nevertheless,
some of the most popular ones are based on the following:

Products Identifies the kinds of products that exists in the organization, which can
be split into sub-types of products
Services This property characterizes the types of services that the organization
handles in a similar the way to that of the products
Channels This criteria grounds on the channel through which the organization
contacts its customers
Customers Represent the types of customer that the organization deals with

Although these are the most commonly used properties to distinguish different case
types, there are certainly other properties that can be used.

30
 Process Architecture

Business Functions for Case Types

The second step of building the process architecture is consisted of classifying the
business functions which the organization conducts for each previously defined case
types. Hence, it is required that each defined case type is toughly analyzed so that each
business function conducted for it is not forgotten.

In many cases, one can use a pre-existent reference model for coming up with the
business functions (e.g., the APQC’s Process Classification Framework – see next slide).
This reference models can only serve as a starting point to develop an initial classification
of business functions, and then subsequently adapted to each organization in particular.

31
 Process Architecture

First 2 levels of the APQC’s

32
Process Classification Framework
 Process Architecture

Business Functions for Case Types

Finally, the decision to what extent should the functional decomposition go needs to be
made. Although one can go until the task-level each employee performs, a shallower
decomposition is advised at this stage. Two rules of thumb may be used:
1. Decomposition should at least be performed down to a level at which functions
correspond to different organizational units (with corresponding managers).
2. Decomposition should include different functions for the different roles in each
department.

33
 Process Architecture

Case/Function Matrices
The previous two steps of the described approach led to a matrix that has the different
case types as columns and the different functions as rows. A cell in the matrix contains an
‘X’, if the corresponding function can be performed for the corresponding case type.

Example

34
Dumas, et al. (2013)
 Process Architecture

Identify Processes
After the case types, its respective business functions, and the development of the
case/function matrix or matrices, the final step of building the process architecture is the
identification of the processes per se. These identification will be made upon the
combinations of case types and business functions that form different processes.

The two edges of the spectrum in terms of how many processes are identified here range
from considering the whole matrix form one (big) process, or define one in which each
single cross in the matrix forms an individual process.

As it is expected, the “optimal” solution lie between these two edges. The next slides will
propose eight guidelines (that are just that) to help in this decision. Nevertheless, as a
starting point, we will consider the whole matrix to form a process, and we leave from
there, splitting processes according to each of the eight guidelines.

35
 Example - Mortgage Brokering Process

Identify Processes

Mortgage
Brokering
Process

Adapted from Dumas, et al. (2013) 36

 Example - Mortgage Brokering Process

Identify Processes – Guideline 1

➢ If a process has different flow objects, it can be split up vertically.

A flow object is an object in the organization that flows through a business process. It is
the object on which business process activities are being carried out. Typically, each
business process has a single flow object, such that flow objects can be used to identify
business processes. Consequently, if multiple flow objects can be identified in a business
process, this is a strong indication that the process should be split up.

37
 Example - Mortgage Brokering Process

Setting the Process Architecture (Guideline 1)

Product Development and Assessment

Adapted from Dumas, et al. (2013)

Mortgage Application

Product Development and Assessment

38
 Example - Mortgage Brokering Process

Identify Processes – Guideline 2

➢ If the flow object of a process changes multiplicity, the process can be split up
vertically.

This is due to the fact that in a business process a single flow object is sometimes used,
while at other times multiple flow objects of the same type are used. This is typical for
batch processing, in which certain activities are performed for multiple customer cases in
batch at the same time. If, in the same process, the number of flow objects that is
processed per activity differs this may be a reason for splitting up the process.

39
 Example - Mortgage Brokering Process

Identify Processes – Guideline 2

Product Development and Assessment

Adapted from Dumas, et al. (2013)

Mortgage Brokering Process

Mortgage Collection

Product Development and Assessment

40
 Example - Mortgage Brokering Process

Identify Processes – Guideline 3

➢ If a process changes transactional state, it can be split up vertically.

According to the action-workflow theory, a business process goes through a number of

transactional states (initiation, negotiation, execution and acceptance).
• In the initiation state, contact between a customer and a provider is initiated.
• In the negotiation state, the customer and the provider negotiate about the terms of
service or delivery of a product.
• During the execution state, the provider delivers the product or service to the
customer and;
• During the acceptance state, the customer and the provider negotiate about the
acceptance and payment of the delivery.
A transition in a process from one state to another is an indication that the process can be
split up.

41
 Example - Mortgage Brokering Process

Identify Processes – Guideline 3

Product Development and Assessment

Adapted from Dumas, et al. (2013)

Mortgage Application

Mortgage Payment

Mortgage Collection

Product Development and Assessment

42
 Example - Mortgage Brokering Process

Identify Processes – Guideline 4

➢ If a process contains a logical separation in time, it can be split up vertically.

A process contains a logical separation in time, if its parts are performed at different time
intervals. Intervals that can typically be distinguished include: once per customer request,
once per day, once per month and once per year.

43
 Example - Mortgage Brokering Process

Identify Processes – Guideline 4

Product Development and Assessment

Adapted from Dumas, et al. (2013)

Mortgage Application

Mortgage Payment

Mortgage Collection

Product Development and Assessment

44
 Example - Mortgage Brokering Process

Identify Processes – Guideline 5

➢ If a process contains a logical separation in space, it can be split up horizontally.

A process contains a logical separation in space, if it is performed at multiple locations and

is performed differently at those locations. In other words, besides the spatial distance,
the separation must be such that there is no choice but to perform the processes
differently for the different logical units.

45
 Example - Mortgage Brokering Process

Identify Processes – Guideline 5

PD&A
PD&A Netherlands
Belgium

Adapted from Dumas, et al. (2013)

Mortgage
Mortgage Application
Application
Netherlands
Belgium

Mortgage Payment

Mortgage Collection

PD NL PD NL

46
 Example - Mortgage Brokering Process

Identify Processes – Guidelines 6 and 7

Guideline 6:
➢ If a process contains a logical separation in another relevant dimension, it can be split
up horizontally.

Like with the separation in space, it is not sufficient for processes to just be separated. The
separation must be such that there is no choice but to perform the processes differently
for the different logical units.

Guideline 7:
➢ If a process is split up in a reference model, it can be split up.

A reference process architecture is an existing process architecture that is pre-defined as a

best-practice solution. It structures a collection of processes. For example, if a reference
financial services process architecture exists, its structure can be used as an example or
starting point to structure your own process architecture.
47
 Example - Mortgage Brokering Process

Identify Processes – Guidelines 6 and 7

PD&A
PD&A Netherlands
Belgium

Adapted from Dumas, et al. (2013)

Mortgage
Mortgage Application
Application
Netherlands
Belgium

Mortgage Payment

Mortgage Collection

PD NL PD NL

48
 Example - Mortgage Brokering Process

Identify Processes – Guideline 8

➢ If a process covers (many) more functions in one case type than in another, it can be
split up horizontally.

The application of this last rule depends upon the current decomposition of processes. If
applied, it is necessary to look at the current decomposition of processes and check if,
within a process, (many) more functions are performed for one case type than for
another, i.e.: whether a process has many more crosses in one column than in another. If
so, this is a strong indication that the process should be split up for these two case types.

49
 Example - Mortgage Brokering Process

Setting the Process Architecture (Guideline 8)

PD&A
PD&A Netherlands
Belgium

Adapted from Dumas, et al. (2013)

Composite Simplex Composite
Mortgage Mortgage Mortgage
Application Application Application
NL NL BE

Mortgage Payment

Mortgage Collection

PD NL PD NL

50
 Process Architecture

Identify Processes – Summary Guidelines 1 to 8

1. Change of flow object in the process

2. Change of multiplicity of flow object in the process

3. Change of transactional state

4. Process contains logical separation in time

5. Process contains logical separation in space

6. Process contains logical separation in other dimension

7. Follow scope in reference model (see later)

8. Based on functions in case types covered

51
 Limitations of Process Identification

Limitations of Process Identification

➢ The project’s purpose is not clear;

➢ The scope of the process is too narrow causing that the identified root-causes are
located outside the scope;

➢ The scope of the process is too wide making to a process improvement project that
must be compromised in its lack of detail

➢ The process is identified in isolation to other projects leading to redundancies and

inconsistencies between these projects;

➢ Involved project members and stakeholders are not sufficiently informed;

➢ The involved project members and stakeholders have not been correctly selected;

52
 References

References:
1. Dumas, M., Rosa, M. L., Mendling, J., & Reijers, H. A. (2017). Fundamentals of
Business Process Management 2nd Edition pp 35-74. Springer Berlin Heidelberg
2. Dumas, M., Rosa, M. L., Mendling, J., & Reijers, H. A. (2013). Fundamentals of
Business Process Management pp 33-60. Springer Berlin Heidelberg.
3. Michael Glykas (Ed.) (2013). Business Process Management: Theory and
Applications. Springer Berlin Heidelberg.
4. vom Brocke, J., & Mending, J. (Ed.) (2018). Business Process Management Cases:
Digital Innovation and Business Transformation in Practice. Springer Berlin
Heidelberg.
5. T.H. Davenport, “Process Innovation: Reengineering Work Through Information
Technology”, Harvard Business School Press, 1993
6. R. Dijkman, I. Vanderfeesten, H. A. Reijers (2011). The road to a business process
architecture: an overview of approaches and their use. BETA Working Paper series.
7. Marcello La Rosa, Queensland University of Technology, Brisbane, Australia.

53