Master Thesis
Heuristic Customization of Configurable
Business Processes
University of Amsterdam
Faculty of Science
Supervisor:
Author:
Prof. dr. ir. H. A. Reijers
David Mischke
Submitted in fulfilment of the requirements
for the degree of MSc. Information Studies - Business Information Systems
September 2015
Abstract.
Configurable business processes are a unitary representation of a set of variants of a business
process. Earlier research has focused on the quantitative evaluation (simulation) of these di↵erent variants. Unfortunately, simulation based approaches are not always feasible, for example
if data on activity duration is unavailable.
This thesis develops a qualitative framework, heuristic customization, to identify best variants
in terms of cycle time. Therein, business process redesign heuristics are used to infer an ordinal
ordering of process variants. Opposed to earlier research, no quantitative information about
activity duration is needed to deduce best performing variants. The framework is evaluated
with a set of 15 randomly generated models. Heuristic customization is able to identify the best
variant(s) in 11 out of 15 cases and performs best in business processes without rework.
Keywords: BPM, configurable business processes, business process redesign heuristics, simulation
Acknowledgements
I would like to thank Prof. Reijers for his valuable comments and guidance throughout this
master project. In addition I would like to especially thank D. Schunselaar for his generous
support in the use of ProM and Petra. Without his input this project would have been a lot
harder.
ii
Contents
Abstract
i
Acknowledgements
ii
List of Figures
v
List of Tables
vi
1 Introduction
1
2 Literature Review
2.1 Literature Review Methodology . . . . . . . .
2.2 Overview of BPM . . . . . . . . . . . . . . . .
2.3 Business Process Modelling Languages . . . .
2.4 Process Performance . . . . . . . . . . . . . .
2.5 Business Process Redesign . . . . . . . . . . .
2.6 Introduction Configurable Business Processes
2.7 Configurable Business Process Models . . . .
2.8 Analyzing Configurable Process Variants . . .
.
.
.
.
.
.
.
.
3
3
4
4
5
5
6
8
8
3 Research Methodology
3.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Research objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
9
10
4 Analysis
4.1 Requirements . . . . . . . . . . .
4.1.1 QR1 Generality . . . . . .
4.1.2 QR2 Comparability . . .
4.2 Scope . . . . . . . . . . . . . . .
4.3 Assumptions . . . . . . . . . . .
4.4 Addressing QR1: Generality . . .
4.5 Addressing QR2: Comparability
4.5.1 Discovering best variants
4.5.2 Customization choices . .
4.5.2.1 Blocking . . . .
4.5.2.2 Hiding . . . . .
4.5.2.3 Substitution . .
4.5.3 Resources . . . . . . . . .
12
12
12
12
13
14
15
17
17
18
19
20
20
23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.5.4
4.5.5
Heuristic customization process . . . . . . . . . . . . . . . . . . . . . . . .
Example case heuristic customization . . . . . . . . . . . . . . . . . . . .
5 Evaluation
5.1 Implementation
5.2 Evaluation . . .
5.2.1 Business
5.2.1.1
5.2.1.2
5.2.1.3
5.2.1.4
5.2.1.5
. . . . . . . . . . . .
. . . . . . . . . . . .
Process Simulation .
Problem Definition .
Conceptual Model .
Executable Model .
Validated Model . .
Simulation Results .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Conclusion
6.1 Discussion . . . . . . . . . . . . . . . . .
6.1.1 Heuristic customization strengths
6.1.2 Validity of assumptions . . . . .
6.2 Conclusion and future work . . . . . . .
6.2.1 Conclusion . . . . . . . . . . . .
6.2.2 Future work . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
and weaknesses .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
25
.
.
.
.
.
.
.
.
27
27
28
28
28
29
29
30
31
.
.
.
.
.
.
33
33
33
34
35
35
36
A Definitions
37
A.1 Process Tree Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.2 Redesign Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.3 Customization options and redesign heuristics . . . . . . . . . . . . . . . . . . . . 39
B Simulation Models
40
B.1 Analysed models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
B.1.1 Model 8 variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C Preliminaries
44
C.1 Configurable Process Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
C.2 At-least-as-good relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
iv
List of Figures
2.1
Stages of creating configurable models . . . . . . . . . . . . . . . . . . . . . . . .
3.1
Regulative cycle
4.1
4.2
4.3
4.4
4.5
Example Configurable Process
Example customization options
Heuristic customization process
Example process . . . . . . . .
Example process customized . .
.
.
.
.
.
16
17
24
25
26
5.1
Phases of a simulation study . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
B.1 Model 8: Best variant identified by simulation . . . . . . . . . . . . . . . . . . . .
B.2 Model 8: Best variant identified by heuristic customization . . . . . . . . . . . .
43
43
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
11
List of Tables
4.1
Summary substitution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.1
Simulated models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
A.1 Process Tree elements and corresponding BPMN elements . . . . . . . . . . . . .
A.2 Definition of used redesign heuristics . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Customization options and considered redesign heuristics . . . . . . . . . . . . .
37
38
39
B.1 Analysed models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Analysed models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.3 Analysed models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
41
42
vi
Chapter 1
Introduction
Processes are ubiquitous in organizations. They define the flow of materials and information
through the organization to produce a predefined outcome. Often, organizations maintain virtually the same process across multiple locations, customers segments or products. For example,
a downstream logistics process to customers in di↵erent countries might have many commonalities but due to local di↵erences in capabilities or legislation, the process di↵ers in some steps.
On the one hand, businesses might tackle these issues by defining more generic or high-level
processes, which cover all local variations. However, more generic process models might not
permit an e↵ective management of those processes, because they fail to depict the process in
sufficient detail. On the other hand businesses might define a di↵erent process for each local
variant. Yet, defining, maintaining and managing all of those processes can be a significant
burden for an organization.
Configurable business processes can address the issue of variations within a given business processes. They are a unitary representation of a set of variants of the same business process such
that they conceptually capture many di↵erent variants of the process. Di↵erent variants are
derived by configuring customization options. They entail the choice to alter parts of the process
such that all possible combinations of customization options constitute the space of variants.
A particularly interesting problem for process analysts is the question how di↵erent variants of
the configurable business process compare to each other with respect to a given KPI. For example, one might be interested in which variant of a business process is least costly or which one
is most time e↵ective. The identification of best performing variants is, however, not straightforward: The number of possible variants can grow unmanagable quickly, because the space
of possible models grows exponentially in the configuration options. Moreover, assessing the
performance of a business process a priori has its inherent challenges. The topic of configurable
business processes is well established in the academic literature. It has also found promising
applications in real life, for example, deriving from the CoSeLog project1 , simulation has been
used to assess the performance of di↵erent variants of a process [1]. Nevertheless, quantitative approaches such as simulation are not always feasible due to lack of performance data or
inability to quantify performance criteria. In this thesis, the assessment of competing model
variants is approached from a qualitative angle. The research goal is, to develop a framework to
identify the best performing process variant from the space of all variants. By consulting business process redesign heuristics, a methodology of heuristic customization for identifying best
1
See: http://www.win.tue.nl/coselog/wiki/start
1
performing variants in terms of cycle time (i.e. total (average) time for a case to run through
the process) is developed.
Heuristic customization works by first breaking down a configurable business process model into
its (configurable) structural elements of its control flow. Structural elements refer to sequences,
choices, concurrency and loops. Then, the postulated e↵ect of applying a particular redesign
heuristic is projected onto the various structural elements of a configurable business process.
By doing so, a (partial) ordinal ordering of variants w.r.t. average cycle time can be derived.
On the one hand, being a qualitative technique, heuristic customization does not su↵er from the
aforementioned constraints of quantitative techniques. One the other hand, it cannot provide
an answer to “how much better” a particular variant is than another.
The remainder of this thesis is structured as follows: Section 2 summarizes existing literature
on BPM and configurable business processes. Section 3.1 defines the problem statement and
research goal. Thereafter, section 4 builds the framework of heuristic customization. Section
5.2 evaluates heuristic customization against a quantitative technique. Hereafter section 6.1
discusses the method and findings of this thesis. Finally, section 6.2 concludes the thesis and
suggest future research directions.
2
Chapter 2
Literature Review
2.1
Literature Review Methodology
The literature review serves two purposes. Firstly, it aims to provide an adequate background
to the topic at hand such that a reader with limited knowledge of the area of BPM could comprehend the context of this research. Secondly, it provides a justification of the posed problem
statement, such that the reader can understand the relevance of this research. Consequently, it
will present a summary of the body of relevant literature addressing both purposes.
The narrative in this literature review follows a general to specific approach. First, a general
introduction to BPM is given. Therein, the most pertinent topics in the area of BPM are
delineated. The following topics are addressed:
1. Definition and overview of BPM: Section 2.2
2. Historical development of process thinking: Section 2.2
3. Explanation and use of business process modelling languages: Section 2.3.
4. Business process performance: Section 2.4
5. Business process redesign: Section 2.5
After these general concepts have been explained, more specialized literature concerning the
area of interest, configurable business processes, is reviewed. Essential concepts covered in this
strand of BPM research are:
1. Introduction of configurable business processes: Section 2.6
2. Configurable business process models: Section 2.7
3. Analysis of process variants: Section 2.8
3
2.2
Overview of BPM
In every productive organization there are business processes: Selling a product, ordering supplies or hiring a new employee are all examples of business processes. A business process is a
sequence of activities, events and decisions, which lead to an outcome. It typically spans several
functional units of one or multiple organizations and has a customer (internal or external),
who consumes the result of the process [2]. For example, in a process of ordering supplies, the
purchaser may be seen as the customer, while delivered supply is the outcome of the process.
The management of businesses processes is termed business process management (BPM) and
may be defined as ”the art and science of overseeing how work is performed in an organization
to ensure consistent outcomes and to take advantage of improvement opportunities” [3]. Alternatively, in [4], BPM is defined as ”Supporting business processes using methods, techniques,
and software to design, enact, control, and analyse operational processes involving humans,
organizations, applications, documents and other sources of information”. The most distinctive
feature of BPM, relative to other management disciplines, is that is not concerned with optimizing the productivity of a single activity or business function but rather the process of producing
an outcome as a whole, which typically spans multiple functional units. In this respect, it is very
di↵erent from other management disciplines, which typically concerned with the improvement
of a single functional unit.
This way of thinking about the production of a good or service is a relatively new school of
thought about the business activities: During the 1980’s it was recognized that individual tasks
can change quickly or become obsolete due to advances in (ICT) technology [2, 5]. Therefore,
successful organizations must optimize the workings of its processes rather than trying to perfect
some individual tasks or business function. This was a rather harsh shift in thought, since traditionally businesses focused on the operational efficiency of individual activities or functional
units by the principle of division of labour [3]. Moreover, BPM goes beyond the ”workflow
management” of the 1990, which was primarily concerned with the software-supported enactment of work processes [4]. In contrast, BPM is a management technique which tries to take a
much more holistic view on processes within an organization by incorporating process discovery,
(re-)design and analysis into its scope.
2.3
Business Process Modelling Languages
In order to understand, visualize and enact our understanding of a process, business process
modelling languages are used to create business process models [3]. Business process models are
formal representations of business processes. They use a semantically defined set of elements,
capturing the workings of a business process. Typical elements in a business process model
are activities, decisions and events. Most business process modelling languages also feature a
graphical representation. Graphical representations are useful to illustrate, facilitate and communicate our understanding of a process.
The use of business process models allows to capture a process in a formalized way, such that the
potential for ambiguity is minimized and the process can be understood by various stakeholders [3, 4]. Di↵erent business process modelling languages have been developed to suit various
needs of BPM practitioners. Some languages (such as BPMN, EPC or UML activity diagrams)
focus on a the graphical representation of processes for mainly analytical and documentation
purposes, while other languages are machine executable languages (e.g. BPEL), which can be
4
interpreted by a workflow management system (WfMs) of a process aware enterprise applications [6]. Non-executable languages can be translated into executable languages. The choice of
appropriate modelling language depends on its intended use and the purpose pursued be the
business process analyst.
Business Processes languages come in two flavours: declarative and imperative modelling languages. The traditional imperative modelling paradigm depicts the procedure (”how” things
are done) which has to be followed in order to execute the process [7]. Therefore, imperative
modelling languages are said to over-specify the process executing as they explicitly indicate the
rules (e.g. wrt. branching) which have to be followed [8]. Commonly used imperative modelling
languages are BPMN, EPC, Petri nets etc.. In contrast, declarative modelling languages (e.g.
Declare [8]) do not specify the procedure of a process explicitly but indicate the constraints
of the model execution [7]. They specify allowed behaviour (”what” things should be done)
and leave the more freedom concerning process execution. Even though declarative languages
permit more freedom to process execution, they are found to be less understandable [9, 10]. For
an overview of business process modelling languages, see [11].
2.4
Process Performance
Insights into the behaviour of a business process can be of very valuable for a company.
Analysing issues of an as-is process and measuring process performance is one of the key steps
to successfully redesign the process. Process performance can broadly be divided into four categories: time, cost, quality and flexibility [3]. Each of those can be translated into measurable key
performance indicators (KPI) of the process. For example time could be measured in average
cycle time (sometimes called sojourn time or throughput time), variance of the throughput time
or average waiting time. Conducting process performance analysis can be divided into to broad
categories: qualitative analysis and quantitative analysis.
Qualitative process analysis is mostly based on the observation of the structure of business processes models [12, 13]. It covers techniques such as value added analysis and root cause analysis
[3]. In contrast, quantitative techniques use formalized techniques such as queuing analysis or
simulation to evaluate process performance. Quantitative process analysis can be very powerful, since not only the behaviour of enacted processes can be evaluated but through the use of
simulation, hypothetical situations can be looked at (what-if analysis) [12, 14]. However, quantitative evaluation relies on the presence of data about process behaviour such as processing
time and branching probabilities. Process Mining o↵ers the techniques to extract models from
event logs of an information system [15, 16].
2.5
Business Process Redesign
Process thinking was sparked by the business process re-engineering e↵orts of the 1990, whose
goal was to radically improve process performance [5, 17]. Since then, a large body of literature
has pondered upon how business processes can be organized more e↵ectively (see for example:
[18, 19]). In this spirit, a plethora of di↵erent approaches and management techniques have
evolved, which lay di↵erent emphasis on various aspects of the redesign of processes. Moreover,
there is no clear consent about where the boundaries of BPR are, since it is not always clear
what is being redesigned [20]. In this paper, Business Process Redesign (BPR) will be defined
5
according to Hammer [5] as “The fundamental rethinking and redesign of business processes
to achieve dramatic improvements in critical, contemporary measures of performance, such as
cost, quality, service and speed.” For the purpose of this paper, this definition is appealing,
because it narrowly defines the scope of BPR to be on the operational level and emphasizes the
ultimate goal of BPR, which is to improve process performance.
The reasons why a process needs to be redesigned fall into two major categories: Firstly, processes grow organically over time. Processes evolve and adapt as people and systems involved
in the process change and as a result often retain inefficiencies [3]. Secondly, the context of the
process changes. New technologies emerge, customer preferences change and new competitors
enter the market, all of which might necessitate a thorough redesign of a process to retain a
competitive edge [3, 21].
One of the most critical aspects of BPR is the question of how one can redesign a process. A
mere discussion of before-after process performance is often not very useful for process analysts,
as it omits the critical phase how redesign ideas are generated. Reijers and Mansar o↵er an answer to this important question by introducing Business Process Redesign Heuristics (“redesign
heuristics” hereafter) [22–24]. Redesign heuristics are a set of best practices, derived from the
academic literature and BPR expertise of large companies. They are ideas about how a process
could be redesigned and can be a concrete starting point of a BPR initiative. Therefore they
give valuable insights in the actual redesign. In [23] and [24] the authors test the applicability
and e↵ectiveness of the proposed redesign heuristics. By conducting a survey among BPR professionals and a case study, it is concluded that indeed the redesign heuristics are widely used
and an e↵ective tool for improving process performance.
2.6
Introduction Configurable Business Processes
Organizations often maintain di↵erent versions of essentially the same business process. For
example, the sales process of a product di↵ers, depending on where the product is sold [25].
Other reasons for variations in business processes might arise due to di↵ering laws and regulations or local decision making [26]. For an organization, maintaining multiple versions of
e↵ectively the same process is burdensome, since it unnecessarily duplicates the e↵orts for managing the same process. The concept of a configurable (customizable) business process addresses
this issue. A configurable business process is a set of process variants. It is a representation
of multiple possible process configurations in a consolidated manner. The individual process
variants are derived from the original configurable business process by selecting customization
options. The all possible combinations of customization options constitute the space of all variants. Hence, from one configurable process model, multiple customized models (variants) can be
derived. Configurable business processes are particularly well suited to support organizations,
which operate in a volatile and uncertain environment [27, 28]. Such firms need processes and
information systems which can adapt to the changing needs of the organization. Set against
this background, customizable business processes address this issue particularly well, since they
can be customized in order to adapt to a changing environment and thereby maintain agility.
Creating a configurable business process model involves three distinct phases: Design, customization and execution [25]:
• Design time. This phase is concerned with the design of the customizable model. It
needs to be decided, which process parts are configurable.
6
Figure 2.1: Stages of creating configurable models, reprinted from [25].
• Customization time. During this phase, a particular variant based on the configurable
model, is created. The customization options are chosen to create a customized model.
• Run time. In this phase, the customized model is executed. Now, only run time decisions
can be taken.
Relative to ordinary business processes, an additional stage of model creation, customization
time, is added to the model creation process. This stage makes configurable business process
models distinct from ordinary process design. Figure 2.1 shows the process of creating a configurable business process diagrammatically.
Note, that a customizable business process model is not the same as a “reference model”. Those
are process model descriptions usually designed to reflect best practices, but lack the options
to customize a particular process setup according to the organization’s needs [29].
The advantages for an organization to maintain a customizable process instead of several business processes are manifold:
• Avoiding redundancy. The maintenance of a single customizable business can avoid
the redundancy of maintaining a multiple business process variants in a database. If
each process variant is modelled separately, then the number of to be maintained process
models can quickly grow unmanageable.
• Achieving economies of scale. When multiple business process models are captured
in a consolidated manner, it is easier to design information systems, supporting those
variants, thereby creating economies of scale [25].
7
• Maintaining agility. The use of customizable business processes can reduce the design
and implementation time of new business processes, since only a new variant of the process
needs to be created, instead of a entirely new process.
• Cross-variant benefits. One particular process configuration can benefit from improvement e↵orts of another. For example, if a a particular process variation has been redesigned, these changes can be applied to other variants as well.
• Comparing performance. A configurable business process allows the the analysis of
its variants. Thus, various process instances can be compared along key performance
indicators (KPI) [1, 30] such that optimal configurations can be discovered.
2.7
Configurable Business Process Models
Configurable business processes models capture configurable business processes graphically and
conceptually by entailing configuration options. Hence the user can deduce a process variant
from a given configurable process model by customizing the model along those configuration
options. A number of business process modelling languages have been proposed: for example, CSAP, C-EPC [31], C-YAWL [32] or Configurable Declare [33] are configurable model notations.
Developing a configurable model is often done by merging two or more process variants into a
single configurable model such that the resulting model is a unified configurable model of the
process [26]. Two prominent issues with creating configurable process models by merging, are
soundness and reversibility. On the one hand, soundness refers to the correctness of the model,
such that no deadlocks or livelocks occur in a configuration. On the other hand, reversibility
is the property to infer the configurable model from an instantiation. Unfortunately, soundness
and reversibility is not always guaranteed in the aforementioned approaches [26, 34]. In the
remainder of this research, the configurable Process Tree notation is used to depict configurable
business processes. A description of the configurable Process Tree notation can be found in
appendix C, section C.1.
2.8
Analyzing Configurable Process Variants
The CoSeLog project is an initiative of consolidating processes of Dutch municipalities. Therein,
the concept of configurable business processes has already found very promising applications.
Most notably, the simulation analysis of configurable process variants through the use of Petra,
a tool within the open source process mining tool Prom 1 , has been able to find optimal configurations through the use of simulation [1]. Finding ”best” variants of a configurable business
process is no trivial undertaking, since it is a priori non-obvious which variant will perform
best wrt. to some KPI. The space of to-be analysed models grows with an exponential rate
in the configuration options. Therefore a large space of models has to be analysed to find the
best model wrt. to a KPI (e.g. cycle time). In order to find optimal configurations faster, the
concept of monotonicity as been introduced to prune the space of models, which have to be
analysed (i.e. simulated) [30]. This technique has the advantage that models can be compared
on the basis of their structure such that actual values for KPI’s do not need to be computed.
1
See www.processmining.org/start
8
Chapter 3
Research Methodology
3.1
Problem Statement
Previous research on optimizing configurable business processes has concentrated on finding optimal configurations in a quantitative manner through the use of simulation. It can deliver very
insightful results if circumstances permit. However, this type of analysis has inherent shortcomings which are acknowledged but largely unaddressed in the academic literature:
Firstly, simulation requires detailed data on process behaviour, such as activity duration, resolution on control flow choices (branching probabilities) and resource availability/allocation.
Obtaining such information is especially problematic if the process is not supported by an information system, recording such data. Under such circumstances, data collection can be very
lengthy, costly and potentially imprecise. Secondly, data of the external environment such as
the arrival process of new cases must be gathered. From these data, a statistical distribution
must be derived in order to model the arrival behaviour of cases. Thirdly, there are KPI’s which
are hard to grasp in a quantitative manner, such as quality-measures. Fourthly, simulation can
be very computationally expensive. A configurable model grows exponentially in the number
of configuration options. Therefore, a single simulation can take several hours to days to complete on a ordinary computer. This can make a simulation based approach to find an optimal
variant a lengthy and cumbersome undertaking. Given these limitations, in this thesis a more
qualitative approach towards finding optimal configurations will be taken.
In sum, the aforementioned limitations of quantitative techniques and the lack of alternative
techniques to analyse configurable business processes prompt the development of a new technique, which overcomes those limitations.
3.1.1
Research objective
From the problem statement it is evident that a another technique for finding optimal variants
will add value to the existing knowledge on configurable business processes. This technique
should serve as a substitute when a quantitative method is not feasible. Therefore, in order to
overcome the above stated limitations of quantitative techniques, the technique developed in
this thesis must be of qualitative nature.
9
A particular well-established concept in process redesign is the use of redesign heuristics (see
section 2.5). Redesign heuristics will be used as basis for developing a qualitative approach for
customizing configurable business processes. Heuristic redesign is a qualitative approach and
hence it does not su↵er from the aforementioned constraints of quantitative analysis. Certainly,
a qualitative technique has its own shortcomings. These are reflected upon in section 6.1.
A business process can be evaluated along many performance dimensions (cf. section 2.4. In
order to keep the analysis succinct, the development of a qualitative technique for configuring
business processes will be constrained to optimize cycle time of configurable business processes.
Cycle time is defined as the total average time of a case to complete the process. Cycle time is
an important and well-established performance criteria: The speed at which a certain process
can be executed is often vital for customer satisfaction, since shorter cycle time typically more
satisfactory higher service levels. Furthermore, it has the attractive property to be monotone
in the sense that less is better. In the following, this property will allow for a step-by-step
customization process. Lastly, cycle time is a performance indicator, which is strongly a↵ected
by the structure of a business process. This renders it particularly suitable as performance
indicator, because the upcoming analysis is primarily concerned with the structure of a business
process. To summarize, the research objective of this thesis is:
“Develop a qualitative approach for customizing configurable business processes to optimize
cycle time”
In conclusion, by pursuing the posed research objective, this thesis connects to
literature by taking a di↵erent approach towards customization-time decisions of
process models. It contributes to the by developing a quantitative approach to
businesses processes customization, which does not su↵er from the constraints of a
analysis.
3.2
the existing
configurable
configurable
quantitative
Research Methodology
This section elaborates on the chosen research methodology. Furthermore, it links the sections
of the thesis to the di↵erent research phases.
The present research is characterized as the development of new qualitative theory. Therefore,
the here applied research methodology follows the step-wise approach of exploration, explanation and validation as suggested by Kerssens van Drongelen [35]. This approach builds on the
regulative cycle methodology for developing qualitative theory [35, 36]. It features an iterative
process of stating the problem, problem analysis, developing a solution design, implementation
of the design and evaluation of the findings. After one cycle is completed a restating or refinement of the problem, incorporating findings from the previous cycle, may be carried out
and a new cycle can be started to improve the developed theory. Figure 3.1 shows this process
diagrammatically.
10
Figure 3.1: The regulative cycle, adapted from [35]
In this thesis, each of the research stages will be addressed as follows:
1. Problem statement. In this stage, the problem to be investigated, is defined. In order
to provide background to the posed problem statement, section 2 summarizes existing
literature on the topic. Based on the literature, section 3.1 formulates the problem statement and research objective. The present section formalizes the process of achieving the
research objective.
2. Analysis. In this phase, requirements (section 4.1), assumptions (section 4.3) and the
scope (section 4.2) for the to be developed theory are established.
3. Design. The solution to the posed problem statement (i.e. the to be developed theory)
is designed in this phase. Section 4 is concerned with this phase.
4. Implementation. After the solution has been developed, an appropriate setting for
evaluation must be found. The implementation stage bridges the gap between the theoretical solution and an empiric evaluation by establishing a feasible evaluation framework.
Section 5.1 considers this stage.
5. Evaluation. In this stage the previously developed solution is evaluated. Section 5.2 is
dedicated to the evaluation.
11
Chapter 4
Analysis
In this chapter, the framework of heuristic customization is developed. It represents the analysis
stage within the regulative cycle methodology.
4.1
Requirements
This section describes the requirements of the heuristic customization framework. Two quality
requirements (QR) are considered: Generality and comparability. These design requirements
are imposed on the heuristic customization framework in order to ensure the that the framework
is applicable to commonly used configurable business process models. The quality requirements
are addressed in section 4.4 and 4.5.
4.1.1
QR1 Generality
The goal of this thesis is to develop a qualitative approach to customize configurable business processes. The applicability of heuristic customization should be as great as possible. To
achieve this, it should be applicable in a wide range of possible scenarios. Put di↵erently, heuristic customization should be able to be applicable to as many di↵erent configurable processes as
possible. If heuristic customization would only be applicable in narrowly defined situations/models, it would not constitute much added value for the process analyst.
This is important, because in real life, businesses use BPM to manage a diverse set of processes.
A qualitative framework is only useful if it can cater many of those situations. Therefore, heuristic customization should fulfil a generality property. Generality means that the theory can in
fact be applied to a wide range of real life processes. This property is addressed in section 4.1.1.
4.1.2
QR2 Comparability
A configurable business process model supports multiple variants, whose performance is not
easily assessed (cf. section 2.8). In quantitative analysis, the di↵erent process variants can
simply be compared by ordering variants according to the numeric value of the KPI of interest.
12
Since the heuristic redesign is a qualitative framework, no numeric answer is intended to be
given regarding the performance of possible variants.
Instead, heuristic customization will make an ordinal ordering of variants possible, meaning
that an answer will be given which variant will be the best performing one but not “how much”.
To do so, the proposed framework will make use of business process redesign heuristics. In
the context of redesign heuristics, the impact of di↵erent heuristics on process performance
has only been evaluated categorically by di↵erentiating between four dimensions: time, quality,
cost and flexibility [22]. For example, the application of particular redesign heuristic is said to
improve the cost dimension of a process and decrease the quality dimension. They do however
not allow a ranking of competing models to be inferred. Thus, for choosing among mutually
exclusive process variants, categorical indications of post-redesign process performance is not
sufficient. Hence, the proposed methodology aims to arrive at an ordinal ordering of variants.
This represents a clear added value for a process analyst, since then it is possible to make a
judgement as to which variant performs better. More formally, heuristic customization should
return a (non-strict) well-ordered set of process variants. This requirement is addressed in
section 4.1.2.
4.2
Scope
Before the heuristic customization framework can be laid out, it is necessary to define the scope
of the analysis.
This research brings together two formerly distinct strands of research: Redesign heuristics and
configurable business processes. Both of which have defined their own framework of looking at
business processes.
In this research, configurable business processes will be captured by the formalism of a configurable Process Tree as developed by Schunselaar et al. [1, 26, 37]. A configurable Process Tree
depicts the control flow of a configurable businesses process with configuration options. Those
options are blocking, hiding and substitution (see section C.1. Since these customizations are
options to alter the control flow of the process, the present analysis will mostly focus on this
perspective of a process tree.
The literature on redesign heuristics takes on a broader view of business processes. The following dimensions of a business process (and its context) are distinguished: customers, products,
business process operations, business process behaviour, organization, information, technology
and external environment [22]. Since the present analysis is primarily concerned with analysing
the control flow of a process, mainly business process behaviour and business process operations
will be considered, because they directly relate to the control flow perspective of a configurable
Process Tree. The business process operations view is concerned with how the workflow is
organized (size of tasks etc.). The business process behavioural view relates to when a particular task is executed (sequence, concurrency etc.). These two groups of redesign heuristics are
deemed to be most applicable to customize the control flow of the configurable business process
model. Moreover, hiding is addressed by the use of a technology heuristic and an information
heuristic.
Business process redesign heuristics are evaluated along four major dimensions: time, cost, quality and flexibility. Applying each redesign heuristic is thought to have an e↵ect on one or many
of those dimensions. In this thesis, the time dimension will be the dimension of interest. Earlier
13
research has already investigated this dimension through the use of a quantitative technique [1].
Thus this thesis is a continuation of this line of thought. In addition, quantitative techniques
are well suited to evaluate the time dimension (cf. section 5.1). As mentioned in section 3.1,
average cycle time will be the investigated KPI of the time dimension. To summarize, the scope
of this research is the analysis of the control flow of configurable Process Trees using mainly
business process operations and business process behaviour heuristics to find optimal variants
in terms of cycle time.
4.3
Assumptions
No theory exists without assumptions. In order to build heuristic customization on a solid
logical foundation, the following assumptions are made:
1. Structure does not influence activity behaviour. For example, an activity embedded in a
sequence takes the same amount of time as if it would be embedded in a XOR structure.
This assumptions ensures that di↵erent structural elements with the same activities are
comparable in terms of KPI performance.
2. All possible variants make sense from a business logic point of view. A possible customization must retain the business logic of the process in the sense that the product or service
can still be delivered to the customer. For example, if all tasks must be executed in a
sequence, then a customization option can never entail the option to execute them in
parallel. This assumption ensures that variants are ”sound” from a business logic point
of view. The configurable process model is a collection of those variants.
3. Variants entail the same or fewer activities. Process Tree notation depicts configurable
models as ”least common multiplier” of all variants. Hence, configuration is achieved by
changing the structure of the same activities or removing activities (blocking). Models
were a di↵erent task is incorporated as a ”replacement” for another activity are not considered, because with no additional information about such a replacement, no judgement
about the process performance can be made.
4. Resources allocation is fixed. This assumption specifies that every resource (e.g. an employee) can only perform a predefined set of activities e.g. due to specialized training.
Choosing for a particular customization option does not influence the allocation of resources to activities.
5. Branching probabilities are unknown but the same for competing variants. Heuristic customization will require no explicit knowledge about how likely a case takes a particular
branch within a choice element. However, when an exclusive and inclusive choice are
elements of a substitution, then they are assumed to have the same choice probabilities
on their respective branches. Put di↵erently, it is assumed that choice probabilities stay
constant across variants.
6. Information on activity behaviour is unavailable. It is assumed that there is no numerical
information available about, most notably, processing times. However, it is assumed that
manual task take a non-zero time to be completed while automatic tasks have a processing
time of zero.
14
4.4
Addressing QR1: Generality
After the scope and assumptions of this research are established, in this section the first quality
requirement of the heuristic customization framework is addressed.
Redesigning a business process is a non-trivial task. The performance behaviour of a process is
determined by various factors, such as technology, resources, control flow structure etc., whose
interaction might be obscure and complex. Configurable business processes add an additional
layer of complexity, because not only the configurable model but also a specific customization
must be designed. Therefore customization could be seen as constrained process design. From
a practical point of view it is deemed to be impossible to discover an optimal solution directly,
given this complexity. The various interplaying factors need to be disentangled in to find optimal
configurations. In order to do so, a divide and conquer approach will be used. Therein, the
problem at hand (designing an optimal configuration) is divided into smaller problems, which
can be analysed separately. After all sub-problems are solved, the overall solution is derived by
combining the solutions of the smaller problems.
In order to ensure that the proposed methodology is general i.e. applicable to a wide range of
processes, the methodology cannot take context specific information of the process into account,
since otherwise generality would be violated. Thus, it will only be looked at abstract properties
of the of a business process. Moreover, the analysis will focus on the control flow perspective of
a business process, as justified in section 4.2.
What are abstract control flow properties of a business process? Tasks in a business process are
causally related, for example in a sequence, exclusive choice et cetera. In this research, abstract
control flow properties will be defined as those causal relationships among tasks. In addition to
the various structural elements (sometimes also coined workflow patterns) of the control flow,
the resources utilized and the technology used in the business process is considered. The totality
of all control flow structural elements defines the control flow perspective of the business process.
Therefore, these structural elements are general and abstract properties of a business process. A
business process can then be seen as a composition of those structural elements. The structural
elements considered are:
• Sequence: SEQ
• Exclusive choice: XOR
• Inclusive choice: OR
• Parallel execution: AND
• Loop: LOOP
Table A.1 shows those structural elements in the configurable Process Tree notation and BPMN.
The methodology is developed with these five structural elements. For all common business process modelling languages, such as EPC and BPMN, the control flow perspective can be built
from these structural elements. Thus the unit of analysis will consist of these aforementioned
structural elements of a process.
Technology used in the process will be captured by automatic tasks. These tasks are assumed
to be handled automatically by a machine (e.g. a computer system) with no human labour
input needed and a processing time of zero. Within the configurable process tree notation, the
15
Figure 4.1: Example configurable process
hiding option indicates that a given task can be customized to be automated by a computer.
Having defined the control flow structures as unit of analysis of heuristic customization, the next
step is to “extract” the relevant control flow structures from a configurable business process.
The Process Tree notation is especially useful in this respect since its tree like structure avoids
unsound models. Its leaves are tasks, whose control flow structure is defined by their corresponding block. To carry out heuristic customization, only the customizable parts of the
business process need to be examined, since other sections of the business process are invariable
and due to assumption 1 do not influence the behaviour of the customization options. Figure
4.1 shows an example process.
In this example process, four customization options have to be chosen. They are shown in figure
4.4:
1. Task B might be replaced by an automatic task
2. A SEQ or AND structure has to be chosen
3. A XOR or OR structure has to be chosen
4. Task F can be blocked
These four customization options will determine the space of possible customizations. Note
that option 3 & 4 constitute a nested structure of configuration options. Figure 4.4 displays
customization options 1-4 of the example model in figure 4.1. These customization options are
the unit of analysis, which are supposed to be analysed as a binary tradeo↵. In case of option
1, one needs to decide whether to automate this task or not. Options 2 entails to decide on
embedding the corresponding tasks in a sequence or in parallel, whereas option 3 entails to
decide between an exclusive- or inclusive- choice structure. Option 4 entails the blocking of
activity “G”. How to analyse these tradeo↵s is presented in the next section.
In sum, this section presents how one identifies abstract control flow elements from the Process
Tree notation, which constitute the building blocks of heuristic customization: By subdividing
a Process Tree into its configurable structural elements, each of the competing customization
options can be analysed as a separate customization choice.
16
Figure 4.2: Customization options from Figure 4.1
4.5
Addressing QR2: Comparability
Recall that the aim is to derive a ordinal ordering of variants. In the previous section, generality
has been addressed by “extracting” customization options from the configurable process model.
In this section, those options are compared such that an ordinal ordering wrt. to cycle time can
be derived. The goal of this section is twofold: Firstly, it will be explained how one can arrive at
the best performing variant from the multitude of customization options. Secondly, it provides
a justification of why a certain customization choice is better than another wrt. cycle time. In
essence, the tradeo↵ of di↵erent customizations of the tasks and structure of the configurable
model will be analysed.
4.5.1
Discovering best variants
A major difficulty of analysing configurable business processes is the potentially large number
of variants. The space of possible configuration of a configurable business process grows exponentially in the configuration options: A configurable process model with n customization
options (binary choices), has 2n possible variants. This makes a comparison of each variant to
each other variant practically not feasible. Therefore, a stepwise approach is proposed in which
each customization option is analysed independently one after another. For the following, the
at-least-as-good relation of two control flow structures will be utilized. For a more detailed
description thereof see section C.2 in Appendix C.
A stepwise analysis of customization options is sensible, because each structural element contributes to the total average cycle time in a linear fashion. For the trivial case of just one
customization option, the variant with the “faster” customization option chosen has the shorter
cycle time. This logic can be extended to configurable processes with more than one customization option by successively making the better choice wrt. cycle time for each customization
option of a configurable process. Then, only a partial ordering of variants (wrt. to their cycle
time) is possible but the best performing variant can always be inferred: Imagine a configurable
process Vxy , which entails two customization options, x & y, both of which represent a binary
choice of how the option is chosen (cf. section 4.1.1). Those choices are indicated with 0 or
1. Hence, the space of possible variants of process Vxy are V00 , V10 , V01 and V11 . Imagine that
choice 0 in option x is at-least-as-good as choice 1 and choice 1 in option y is at-least-as-good
as choice 0. Then variant V01 must be at-least-as-good as all other variants, because in both
options the better choice is made. Variant V10 must be the worst variant, because in both
17
options the worse choice is made. It is not possible to determine whether variant V00 or V11 is
more advantageous in terms of cycle time, because there is no information about the magnitude
of the e↵ect on cycle time of each option. Hence, the ordinal ordering of variants from best to
worst is Vxy is V01 , V00 or V11 , V10 . This logic can be expanded to more customization options,
as one can always chose the best option for each customization option and therefore arrive at
the best model.
By applying this logic to configurable business processes it is possible to find best variants in
an ordinal way. In the following section, the various types of configuration options are analysed
with the goal of deriving “decision rules” for making the best choice for each configuration
option.
4.5.2
Customization choices
After one has broken down the configurable Process Tree into its structural components, each
of the customization options can be analysed independently one after another. For example,
figure 4.4 depicts the to be independently analysed customization options of figure 4.1. The
goal of this section is to derive decision rules for deciding on the customization options of a
configurable business process.
To determine the e↵ect of each customization option on the cycle time of its structural element
(and thereby the entire process), a mapping of customization options and redesign heuristics is
created. The mapping of redesign heuristics and customization options has the use of explaining
why a certain customization choice is better in terms of average cycle time than another. Section
4.2 elaborated, that every redesign heuristic has an e↵ect on one or many process performance
dimensions. How a given customization option is chosen, is viewed like applying the mapped
redesign heuristic on the process. For example, arranging task in an AND structure is viewed as
the application of the parallelization redesign heuristic (see below). Thus the postulated e↵ect of
applying the redesign heuristic is determines which customization choice is more advantageous
in terms of average cycle time. Customization-time decisions are made with the help of redesign
heuristics (cf. figure 2.1).
Redesign heuristics are the justification of choosing one or the other customization option. An
overview of the mapping is presented in table A.3.
For each of the conceivable customization options defined within the configurable Process Tree
notation, a decision rule, based on the mapping of customization options and redesign heuristics,
will be derived below. By following these decision rules, best performing variants can be derived
by following the logic of ordinal ordering as explained in section 4.5.1. Recall, that it is only
necessary to analyse the configurable parts of a configurable Process Tree, because other parts
are invariable and due to assumption 1, they have no e↵ect on the cycle time of the customizable
parts.
As mentioned in section 4.2 there are three di↵erent types of configuration options within the
configurable Process Tree notation: Hiding, blocking and substitution. Hiding and blocking are
concerned with customizing the model at the task level. In contrast, substitution entails the
option to alter the structure of the process. Arguably, substitution is the most complex way of
customizing a process, because within the hiding and blocking option we are only faced with
the choice to block/hide the activity or not, whilst within substitution a multiple tradeo↵s are
18
possible. There exists a logical order in which the customization options should be analysed.
For each task or structure the customization options should be analysed in the following order:
First, blocking is applied to all suitable options, then hiding and last substitution is carried out.
Blocking and hiding precede substitution, because after blocking and hiding, some substitution
options might have become obsolete. For example, blocking activity G in figure 4.1 would
render the XOR structure obsolete, because only one task remains, such that the XOR block
is not a choice any more. Note, that customization options may be nested such as option 3
and 4 in figure 4.1. In this case the option(s), which are lower in the tree structure should
be analysed first. Figure 2.1 visualizes the entire process of heuristic customization. Next, all
possible configuration options of the configurable Process Tree notation are discussed.
4.5.2.1
Blocking
Blocking is the option to exclude a particular task from the process variant. In the configurable
Process Tree formalism, the blocking of an activity has the e↵ect of denying entry into that subtree altogether. For the present analysis, blocking will be redefined, such that it will only a↵ect
the blocked activity itself. The control flow can still enter a subtree with a blocked activity.
The first redesign heuristic, which is applicable within blocking is the task elimination heuristic.
If a certain task can be omitted from the process because it is not value-adding for the customer,
then it should be excluded from the model. Often times certain ”checks” can be blocked if for
example this check is not required in a particular variant. The task elimination heuristic is said
to improve time of a process, since fewer activities need to be carried out.
The resequencing heuristic is also applicable when blocking a certain activity. In a variant where
a task is blocked, the preceding and following task are now executed right after another. In this
way a more meaningful order of activity execution may be achieved. Resequencing improves
the time dimension of a business process. Blocking an activity within an SEQ, AND or LOOP
structure has straightforward implications. In all of those structures the average cycle time
cannot increase when blocking an activity. In the loop-segment and in the sequence simply
less activities are carried out which obviously reduces cycle time. In the case of the parallel
structure this cycle time will decrease if the activity with the longest duration is blocked and
remain unchanged otherwise.
The case of blocking within XOR and OR gates is more complicated. Simply blocking one of the
choice branches does not necessarily decrease the cycle time, because of the ambiguous e↵ect
on the execution probability of other branches. For example, if one branch within an XOR
gate is processed particularly fast, then blocking this activity might actually increase average
cycle time, because slower branches are now taken more frequently. A particular activity should
only be blocked if the post-blocking average cycle time of the XOR/OR gate is reduced after
blocking. If this cannot be determined, the particular activity should not be blocked. Note that
blocking options in (non XOR or OR structures) of subtrees of a should still be applied.
Therefore, the case of blocking within a XOR or OR structure is a special case. In all other
customization options the choice of one single option is optimizing the cycle time of the process.
In case of a blocking option within an XOR or OR structure the blocking and the non-blocking
of the activities must seen as “better” choice for this particular option. Thus, in this case, at the
end of the heuristic customization process, multiple variants can be considered best variants.
In processes without a blocking option within an XOR or OR structure a single variant will be
considered the best variant. For example in model 6 in table B.2, activity “b” can be blocked.
19
Hence in this model, there will be two variants (one where activity b is blocked and one where
it is not blocked), which are customized to be best performing in terms of cycle time.
Customization Rule 1: Blocking: In order to improve cycle time, block non-value adding activities from SEQ, AND and LOOP structures. Do not block activities from XOR/OR structures
if post-blocking behaviour is unknown
4.5.2.2
Hiding
Within the configurable process tree formalism, the hiding option indicates the replacement of
a task with a silent transition [26]. For the purpose of this analysis, hiding is defined as the
option to replace a manual task with an automatic task (a task executed by a computer). For
example, an ERP system might automatically notify the sta↵ if a particular item is low in stock.
Note that hiding represents the automation of an activity while blocking is the exclusion of an
activity from the business process.
This form of customization is addressed by the task automation and bu↵ering heuristic. The
task automation redesign heuristic states that cost and time can be improved if a task is performed by a computer. Task automation is a technology heuristic. Another situation in which
tasks may be automated, is the acquisition of external information. For example, instead of
manually downloading information form a database, an import script can automatically query
such data. The bu↵ering heuristic addresses this option. By subscribing to automated information updates instead of requesting information manually, the time spent on a task can be
considerably reduced. The bu↵ering heuristic is an information heuristic. It is assumed that
a automatic task takes zero time to be executed. Therefore it is concluded that an automatic
task is at least as good as a manual task, no matter the control flow structure it is embedded
in.
Customization Rule 2: Hiding: In order to improve cycle time, automate tasks when possible.
4.5.2.3
Substitution
Substitution is the option to choose a particular structure of the control flow. For example
in figure 4.1 there are two substitution options: Option 3 is a choice between a XOR and an
OR gate and option 4 is a choice between a sequence and a parallel execution. There are
potentially more than two substitution options to choose from in customization option. Such a
non-binary choice can be transformed by comparing each option to every other option, such that
a ordinal ordering can still be derived. Given the considered five structural elements, there are
(5 ⇤ 5 5)/2 = 10 distinct combinations of structural elements to evaluate. These combinations
are shown in table 4.1.
The aim is to compare the control flow structures in an ordinal way. To achieve this, the
resequencing, task elimination, order-types, exception and parallelism heuristics will be used to
infer which structural choices at-least as good as their counterparts with respect to cycle time.
Next, each of the substitution tradeo↵s are analysed. Each substitution tradeo↵ is indicated
by the control flow structures’ abbreviation (see table A.1) in bold face. For example, OR XOR considers the substitution tradeo↵ between a inclusive and exclusive choice. Note that for
example an OR - XOR and XOR - OR are conceptually the same tradeo↵.
20
SEQ - OR. Customization might entail the option to order tasks in a sequence or choosing to
execute some of the tasks. Intuitively, a structure which executes all tasks in a sequence should
be less time efficient than a structure which has a probability of not executing some of those
tasks. The order types heuristic’s can be applied in this situation. If the business process is
executed in sequence, then for each and every case, all tasks need to be executed. For some cases,
not all of the tasks might actually be necessary/value-adding. Therefore a choice concerning
whether they are executed or not, might lead to a more efficient processing of di↵erent types of
cases. In a similar fashion, the OR structure might be more suitable to deal with exceptions.
A particular case might necessitate an additional step which is not required for all cases. In
contrast, the SEQ structure forces this step to be executed for all cases, leading to a slower
throughput of cases. The exception heuristic addresses this issue. Moreover, executing an ORgate means that the activated branches are executed in parallel. By the parallelism heuristic,
this should speed up the execution process. Also from a resource perspective the OR-join is
more advantageous. The option to not execute a certain task not only saves upon the time of
executing these tasks but also frees up resource involved in this particular step. In sum, an OR
gate is at least as good as a sequence of the same tasks.
Customization Rule 3: SEQ - OR: In order to improve cycle time, chose an OR structure over
an SEQ structure.
SEQ - XOR. The tradeo↵ between a sequence and a exclusive choice can be analysed analogously to the SEQ - OR tradeo↵. Having the option to execute only one of a number of tasks
should speed up the execution of the process and might lead to a more efficient processing of
certain case types, as explained by the order types redesign heuristic. The XOR structure is in
this respect more restrictive than the OR structure, since it allows only one branch to be taken.
Therefore, a XOR gate is said to be at least as good as a sequence.
Customization Rule 4: SEQ - XOR: In order to improve cycle time, chose a XOR structure in
favour of a SEQ structure.
SEQ - AND This structural choice can be addressed by the parallelism heuristic. If activities
can be carried out in parallel, this can considerably reduce cycle time, since a case is not
processed any more in a linear fashion but concurrently. The literature recognizes that the
potential for this heuristic is large, because ”tasks were mostly ordered sequentially without the
existence of hard logical restrictions prescribing such an order” [22]. In fact, cycle time of a
business process should be minimized if all tasks, which are able to, are arranged in parallel.
In addition, parallel tasks can improve the resource utilization, as one resource does not need
to wait any more for the completion of work by other resources. This can of course only be
achieved if di↵erent resources are assigned to the parallel tasks. A potential drawback of this
heuristic is that unnecessary work is performed, because within the parallel execution there
might be knock-outs, rendering the case ”dead”, while other strands of the parallel split are still
being executed [38]. Moreover, there might be hidden coordination costs or time of bringing
the work done on the case back together. Nevertheless, an AND structure is considered to be
at least as good as a SEQ structure.
21
Customization Rule 5: SEQ - AND: In order to improve cycle time, chose an AND structure
in favour of a SEQ structure.
OR - XOR A case may take one of several exclusive choices or take multiple paths of a
decision. Firstly, an OR structure activates multiple branches and thus the case has to wait
until all activated branches arrive. Thus an XOR gate should be performed faster, since there
is no probability that the case has to wait for other branches to be completed. Moreover,
there might be hidden costs by processing cases in a parallel manner in the OR structure (see
above). Lastly, choosing one branch exclusively can also free up resources, since on average
fewer activities are carried out. Note, that equal branching probabilities are assumed.
Customization Rule 6: XOR - OR: In order to improve cycle time, chose an XOR structure
over an OR structure.
OR - AND.
A collection of tasks may be carried out in parallel or those tasks may be chosen as an inclusive
choice. This tradeo↵ is similar to the OR - SEQ choice, since the OR gate permits to not-execute
one or several of the tasks. Therefore the “order types” heuristic justifies the usage of an OR
gate to optimize cycle time, empowers the business process to adjust the steps taken to specifics
of the case. In addition, the option of not activating all branches of a workflow may reduce the
waiting time of cases for the completion of all branches.
Customization Rule 7: OR - AND: In order to improve cycle time, chose an OR structure over
an AND structure.
LOOP - SEQ/OR/XOR/AND A loop structure entails the possibility to rework the embedded tasks. In the Process Tree notation, loops are constructed with a “do” and a “redo” part.
The “do” part is that part of the process which needs to be carried out every time (including
the first time) the loop is executed, while the “redo” part only needs to be executed in the
“back-loop”. There is a spectrum of task allocations within the “do” and “redo” part of the
loop. A structural comparison of a loop and other structures wrt. to cycle time can only be
made if all tasks are within the “do” part of the loop, since otherwise, in some cases, not all of
the tasks would be performed. Since the probability of rework is assumed to be unknown and a
comparison wrt. to cycle time is not feasible. Hence, it is assumed that all tasks are embedded
in the “do” part of the loop and no tasks are in the “redo” part. From this we conclude that
all other structures execute their embedded tasks at most once per process instance, while a
the loop entails a probability to perform the tasks more than once. Executing tasks only once
is obviously more favourably in terms of time. In reality, loops are often necessary to ensure
that a specific condition is met. For example a budgeting plan needs to be revised until it is
approved or a user is prompted to provide input until all input requirements are met. In these
situations there is often no other way of organizing the workflow. Therefore it is believed that
in a real business setting, the possibilities of substituting a LOOP with other structures are
rather limited.
Customization Rule 8: LOOP - SEQ/OR/XOR/AND : In order to improve cycle time, chose
a SEQ, OR, XOR or AND structure over a LOOP if all activities in the loop are executed at
22
least once. Otherwise add all models to the collection of best models.
Table 4.1 below summarizes the derived decision rules of the substitution customization option.
A “>” indicates that the row structure should be chosen in favour of the column structure,
while a “<” indicates the reverse. Note that the table is symmetric.
SEQ
SEQ
XOR
OR
AND
LOOP
>
>
>
<
XOR
<
<
<
<
OR
<
>
<
<
AND
<
>
>
LOOP
>
>
>
>
<
Table 4.1: Summary heuristic customization rules for substitution options
4.5.3
Resources
As the emphasis of this thesis is the customization of the control flow, little attention has been
spent on resources so far. Nevertheless some thought will be spend on the e↵ect of resources on
cycle time:
Hitherto the analysis assumed a given resource allocation. Two general attributes of resources
are their quantity and the allocation of resources to tasks. Generally, the addition of resources
should improve the cycle time of a business process, since the probability that a case has to wait
for a resource being available decreases. This is an application of the extra resources redesign
heuristic. Moreover, the allocation of resources can play a critical role in the speediness of
process execution. If some task require a very specialized resource, then the unavailability of
this resource can cause significant bottlenecks. Therefore, the cycle time of a business process
should improve as the flexibility of resources with respect to task allocation increases. This
logic is utilized by the flexible assignment redesign heuristic, which states that resources should
be allocated in such a way that the greatest possible flexibility is maintained for the future
[22]. As discussed previously, parallelization is expected to improve cycle time significantly.
However, gains from parallelization are very dependent on the resources performing the parallel
activities. If the same resources work on the parallel activities this will increase their utilization
and therefore increase average cycle time [38]. This is restriction on the previously derived
relation of SEQ and AND, in the sense that in practice the reduction in cycle time might be
limited if the same resource works on parallel activities.
4.5.4
Heuristic customization process
In section 4.5.1 and 4.5.2 the two major steps of applying heuristic customization have been
described in detail. To summarize, applying heuristic customization to find best performing
variants in terms of cycle time, begins by identifying all customization options. Thereafter, one
considers first each blocking option, second each hiding option and third each substitution option. For each option the better choice should be made. Blocking options should be executed in
all but XOR and OR structures, hiding options should always be executed. Substitution options
should be decided upon according to the derived decision rules (table 4.1). The justification
23
of those rules is grounded in redesign heuristics. The variant(s) where for each customization
choice, the better choice is made, is the best variant. Figure 4.3 depicts the procedure of
heuristic customization diagrammatically.
Figure 4.3: The heuristic customization process
24
4.5.5
Example case heuristic customization
This last section of heuristic customization development showcases the application of heuristic
customization to a real life process, in order to illustrate how a process analyst might use
heuristic customization to optimize cycle time.
Figure 4.4 shows the ordering process of a popular Surinamese fast-food restaurant in Amsterdam. For simplicity, the resources performing the various activities are indicated at the bottom
of each activity.
The process begins with the customer ordering the food at the cashier. The cashier registers the
order in the cash desk. Then the customer pays the order while the cashier prints the recipe.
The payment can be automated through electronic payment. If the customer has ordered a
drink, he can get it from a fridge next to the cash desk. Meals are prepared in first-in-first-out
manner. Since the restaurant is quite popular, the customer has to queue for getting his meal.
When it is his turn, he can collect the order. In this process, a substitution option of SEQ
and OR is distinguished: In case of a sequential ordering of activities, all customers need to
queue until their meal is prepared. However, an alternative OR structure is distinguished in
this process: Not all customers need to queue, because they have a “simple” order, like certain
kinds of pastries and snacks. These products are do not need to be prepared in the kitchen
while customers are waiting/queuing. Hence, customers with a “simple” order can pick up their
order right away without queuing.
Figure 4.4: Example process: Ordering process of a fast food restaurant
The first step of the heuristic customization process (see figure 4.3) is the identification of each
customization option. In this process there is one hiding and one substitution option. There
are no blocking options in the present process, so no task can be blocked. Next, hiding is applied. The activity “pay” can be automated with an automatic payment system. According to
customization rule 2, the more favourable choice with regard to cycle time is the automation
of this activity. Hence, this hiding option is executed. The other customization choice is the
substitution choice of a SEQ or OR structure. According to customization rule 3, the OR structure should be chosen in this option. In this situation, one can clearly see how the logic of a
redesign heuristic justifies the choice of an OR structure. The order types heuristic postulates,
that a more efficient process can be derived by removing or altering parts of a process, which are
specific for a certain case type. In the present example, the case type is the type of order of a
customer. Pastry and snack orders do not need to be processed in the kitchen of the restaurant
and can be given to the customer right away without queuing. Hence, one should chose the
OR-structure over the SEQ-structure to align the structure of the process with the di↵erent
25
customer types and thereby reduce cycle of the process.
Having identified the better choices for each customization options, the best model can be
derived by choosing the better option in both of the customization options. Hence, the paying
process should be automatized and an OR structure should by chosen in favour of a sequential
structure. Figure 4.5 shows the heuristically customized variant of the configurable business
process.
Figure 4.5: Example process: Ordering process of a fast food restaurant, customized
26
Chapter 5
Evaluation
In this chapter, heuristic customization is evaluated empirically. Firstly, section 5.1 elaborates
why the chosen evaluation method is chosen. Secondly, section 5.2 carries out the evaluation.
5.1
Implementation
In this section heuristic customization is evaluated empirically. It represents the implementation
stage of the research methodology. Ideally, the framework should be implemented and tested in
a number of real-life business processes. However, implementing all of the here analysed cases
in real life and monitoring process performance is hardly feasible. There is a lack of configurable
process models with sufficient performance data. To the best of the author’s knowledge, there
is no database which contains configurable business process models with all information needed
for analysis. Process model databases such as APROMORE [39] only depict the control flow of
configurable models but lack performance data, which would be necessary to compare di↵erent
kinds of variants.
Facing these difficulties, the most feasible and comprehensive way of evaluating the methodology
is to test the framework against the quantitative assessment of the same models. Thus, randomly generated models are generated as a sample of models to test the heuristic customization
framework. This set of randomly generated models is analysed with two di↵erent techniques:
simulation, a quantitative technique and heuristic customization, a qualitative technique. In
this way, the heuristic customization framework can be tested against a quantitative methodology of assessing process performance. The quantitative evaluation is seen as benchmark of more
accurately assessing process performance, because more information (see below) is exploited to
assess process performance. The aim is to discover whether heuristic customization can hold
up to a quantitative evaluation in terms of identifying best configurations with respect to cycle time. Randomly generated models may lack the validity of a real life model but has the
great advantage that the environment of the business process is stable across all variants. This
enables the testing of all above stated rules in a standardized setting, such that di↵erences in
performance can be linked to the di↵ering structure of each variant and the evaluation is not
a↵ected by “noise” of real-life data.
27
Figure 5.1: Phases of a simulation study, adapted from [14].
5.2
Evaluation
This section presents the evaluation of the proposed heuristic customization framework.
The previous section argued that randomly generated models are well-suited to test the heuristic
customization framework. To that end, a simulation of business processes is used. Simulation
is an established technique in BPM and has been a powerful analysis tool [14]. In essence
it is nothing but replaying a modelled situation many times and recording and analysing the
outcomes. Simulation can be used to analyse a wide variety of business processes. Insights
from simulation are based on statistical analysis of the observed performance data (see below).
Thus, a simulation-based evaluation provides great flexibility and control of the process environment. In the remainder of this chapter a simulation study to evaluate heuristic customization
is conducted.
5.2.1
Business Process Simulation
Business process simulation can be a very powerful quantitative analysis tool. In process analysis
and redesign it can deliver answers to many “what-if” questions. Therefore, it can be seen as
an experiment, which can be conducted much more easily, quickly and with lower cost than a
real-life experiment. Often, the performance, in terms of some KPI, is compared given di↵erent
simulation settings. For example, a typical question to be answered might be: “How will average
cycle time be a↵ected if 20% more customers arrive per hour?”. However, the assumptions made
and parametrization of the simulation are crucial in order to avoid arrive at misleading results.
A traditional business process simulation study is typically divided into several distinct phases.
Figure 5.2.1 shows the phases of a simulation study [14].
In this paper, the phases depicted in figure 5.2.1 will be followed. The process of conducting a
simulation is a sequential process. However, sometimes one needs to revert to an earlier phase of
the analysis when for example the validation of the model fails such that the executable model
needs more fine tuning. In the following the di↵erent phases are described and carried out.
5.2.1.1
Problem Definition
The problem definition states the goal and the scope of the simulation. The goal of this evaluation is to assess whether the heuristic customization framework discovers models with the
shortest average cycle time. To this end, randomly generated configurable business process
models will be created and simulated. Then, the best model(s) based on heuristic customization are compared to the best models based on the simulation. Among the simulated models
the aim is to discover the proportion of models for which heuristic customization has found
the the best performing variants, identified by the simulation. The question to be answered is
28
“Are heuristically customized variants among the best performing variants with respect to cycle
time?”.
The scope of the evaluation is the simulation of 15 randomly generated configurable configurable business processes. Given the scope of this thesis, 15 models are deemed to be sufficient
to evaluate heuristic customization. The 15 models contain blocking and hiding options and all
possible substitution tradeo↵s.
5.2.1.2
Conceptual Model
The conceptual model of the simulation is based on the configurable Process Trees business process models, defining the control flow of the business processes. The goal throughout this paper
is to derive variants of business processes without knowing detailed behavioural information of
the process. However, the parametrization of the simulation requires such information. Thus,
randomly generated models need to be enriched with artificial performance data on the basis of
which performance is computed. Hence, the information used during heuristic customization is
a subset of the information used in the simulation.
How can (mean) KPI’s be inferred from a simulation? During simulation, repeated observations
of KPI’s are computed and recorded. Since the (mean) value of a KPI is a random variable
(deriving from the arrival process, distribution of processing times etc.), it is not valid to just
run one long simulation and record the value of the KPI of interest, because a valid estimate
of the variance of the mean cannot be inferred from just once observing the mean. Instead,
in order to obtain reliable estimations of the variance of the mean, the simulation needs to
be divided into independent subruns. The subruns are portions of the same simulation, whose
mean KPI observations are treated as independent observations. The mean value of all subrun
means can then be seen as an estimation of the unknown population value. From the subruns,
the sampling distribution of the subrun means can then be used to compute the variance of the
mean. Independence of subrun mean observations can be ensured by choosing a large subrun
length (i.e. the number of cases per subrun). As a example, a simulation with 30 subruns will
yield 30 mean KPI observations. Then the variance of those mean KPI observations is used to
infer the confidence interval of the mean. The mean of the subrun means and corresponding
confidence interval are the final values of the KPI of the simulation.
5.2.1.3
Executable Model
Before the simulation can begin, an executable model of the business process needs to be created.
In this context, an executable model is a configurable Process Tree, enriched with behavioural
information such that is can be simulated in a simulation software. An executable model of
a simulation requires detailed information on process behaviour. Besides the control flow, the
following properties with respect to control flow, resources and simulation environment need to
be specified [14]:
• Control Flow:
1. Branching probabilities of choices
2. Activity duration
29
• Resources:
1. Resource allocation
2. Number of resources
• Simulation environment:
1. Arrival process
2. Subrun settings
3. Simulation length
4. Queuing principle
An executable model must be implemented in a simulation software. The software used in this
study is the Petra [1] plug-in to the open source process-mining software ProM 1 . Petra features
a specialized framework for quantitatively analysing configurable process variants. Therein, the
executable simulation model is defined by the configurable Process Tree formalism. In addition
the properties mentioned above need to be specified.
In the present setting, the parameters are chosen as follows: Branching probabilities of XOR and
OR gates are randomly generated with a uniform distribution range of [0.05, 1]. In addition,
rework probabilities in LOOP structures are constrained to not exceed 0.4. This is to avoid
unstable processes. In each model, there are 3 customization options, such that each model has
23 = 8 variants. In each of the simulated models at least one substitution and one blocking
or hiding is made. Activity duration follows a normal distribution with a mean of 10 minutes
and a standard deviation of one minute. Each activity can be performed by one resource only,
which has no additional utilization. There are no breaks in the work schedule, that is everybody
works all the time. The arrival rate of new cases follows a negative exponential distribution
with an inter-arrival rate of 15 minutes. Each configurable process tree is specified to generate
8 variants. Each simulation is divided into 30 subruns. Thus 30 observations for each mean per
variant are generated. The simulation length is chosen to be 3000 iterations per subrun with a
warm up period of 3000. The queuing principle of cases is “first-in-first-out” (FiFo).
5.2.1.4
Validated Model
The randomly generated models are artificial models. Therefore, no verification against a reallife process needs to be done. In terms of realism of the simulated models, the author believes,
from his own professional experience as a process analyst, that the simulated models have
a realistic scope. Most real-life models do not exceed 15 activities. In terms of structural
complexity, real life models are often more linear and and hence less complex than the here
simulated models.
Table 5.1 below shows the number of activities in each model and the substitution tradeo↵(s)
made in each model. The column “Success” indicates whether heuristic customization was able
to identify the best performing model in terms of cycle time.
A complete list of all configurable process models can be found in in tables B.1, B.2 and B.3.
Each simulated model has 8 variants, so the number of all variants of the 15 configurable models
1
See: http://www.processmining.org/prom/start
30
would amount to 8 ⇤ 15 = 120 variants. For the sake of conciseness, these 120 variants are not
included in this thesis but are available from the author upon request.
Model
Nr.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Activities
9
11
12
10
11
11
10
10
9
7
11
13
10
9
10
CT worst
variant (min)
49.8
53.6
83.8
53.4
70.5
78.7
65.9
70.1
78.2
72.1
60.5
60.0
36.9
80.0
50.8
CT best
variant (min)
35.4
47.5
76.2
41.4
51.2
59.3
40.1
56.1
51.5
45.8
28.6
46.4
28.0
68.0
39.8
Success
yes
yes
no
yes
yes
no
yes
no
yes
yes
yes
yes
no
yes
yes
Table 5.1: Properties of simulated models
5.2.1.5
Simulation Results
For each of the 15 configurable business process models, all variants are simulated and their
average cycle time recorded. The best performing variant of each model has the lowest amount
of cycle time of all variants. Then, each of the simulated models is heuristically customized as
described in section 4.5.4 in order to find the best performing variant in terms of cycle time.
Of the 15 simulated models, heuristic customization was able to identify the best performing
variant (as identified through the simulation) in 11 models. The models where heuristic customization failed to identify the best variant, are models number 3, 6, 8 and 13. Three out
of the four non-correctly identified models, contain a loop as one of their substitution tradeo↵.
The remaining non identified model entails an AND - OR tradeo↵.
What might be the reason why heuristic customization did not succeed in some cases? Model
8 was not correctly identified. Figure B.1.1 shows the best performing variant of model 8 according to the simulation and B.1.1 shows the best performing variant identified by heuristic
customization. The best performing variant according to the simulation di↵ers from the heuristically customized variant only by the hiding of activity “d” within an AND block. Since within
an AND block all activities are carried out in parallel, the cycle time of this structure is determined by the branch with the longest cycle time. In this particular AND block, all branches
have only one activity, whose mean duration is 10 minutes. Therefore, the hiding of activity
“d” might actually have little e↵ect, because the hiding takes place in a branch which is of the
same length as the other branches. Consequently, the maximum cycle of this AND block is
una↵ected by the hiding of this activity and the fact that another variant was evaluated to be
the best performing variant is credited to the random variation in the model. Thus, the failure
31
of identifying the best variant in this model is no threat to the logic of heuristic customization
as such, because in principle a hidden activity might actually be the activity with the longest
duration and hence determining the cycle time of the AND block.
Notable is the failure of identifying three out of five models with a LOOP tradeo↵. According to
Customization rule 8, a LOOP structure is the least preferred structure if one aims to improve
cycle time. Loops can lead to bottlenecks in the efficient processing of processes, if certain cases
need to be reworked often. These cases can lead to other the congestion of parts of the process.
Hence, LOOP structures might have non-local e↵ects on the cycle time of the process. Non-local
e↵ects are an obvious problem for heuristic customization, since the logic developed in section
4.5.1 would apply any more. However, in reality LOOP structures are often necessary to ensure
that certain conditions are met. For example, a building permit needs to be reworked until the
responsible governmental agency approves the permit. Hence the applicability of substitutions
with a LOOP control flow is rather limited in real life business processes. This renders the
weakness of heuristic customization of dealing with loops less relevant from a practical point of
view.
In sum, the evaluation showed that heuristic customization has succeeded in 11 out of 15 cases
to find the best performing models in terms of cycle time. Given the large space of possible
configurable model variants, finding best configurations in over 70% of the models is satisfactory.
However, the evaluation also showed that heuristic customization has its limitations in finding
best variants in models with rework.
This section concludes the regulative cycle research methodology. To summarize, the problem of
developing a qualitative framework for configurable business processes was addressed by firstly,
developing requirements of the theory. Secondly, the requirements were addressed in the by
consulting redesign heuristics. Thirdly, the theory was tested on a set of randomly generated
models. Based on the simulation, heuristic customization was able to find best configurations.
32
Chapter 6
Conclusion
6.1
6.1.1
Discussion
Heuristic customization strengths and weaknesses
This thesis develops a new approach towards customizing configurable business processes. In
contrast to previous research, configurable models are customized by applying a qualitative
rather than a quantitative technique.
The evaluation shows that the presented approach mostly succeeded in discovering the most
time-efficient variants. This demonstrates that it is possible for a qualitative technique to analyse
configurable business processes. Heuristic customization has a number of advantages: Due to its
intuitive, iterative setup, heuristic customization is easy to use and can serve to “quick-analyse”
competing model variants. Naturally the cycle time optimized variant might not be the overall
most desirable variant, since there are other KPI’s to consider as well. However it might serve
as a starting point for e↵ective process redesign. Heuristic customization is also applicable to
a wider range of situations than a quantitative analysis, since only a subset of the information
required for quantitative analysis, is needed: Quantitative techniques rely on the availability of
detailed behavioural information of the process, which is often times impossible or too costly to
obtain. Especially when many steps in the process are not supported by an information system,
which allows the computation of activity duration. On a related note, quantitative techniques
and heuristic customization may be seen as complimentary analysis techniques for configurable
business processes. Some KPI’s are particularly well suited for a quantitative evaluation, while
others are harder to assess in a quantitative manner because they are harder to measure (e.g.
quality and flexibility measures). To get a holistic picture of competing variants, quantitative
and qualitative techniques could be combined such that, where possible, quantitative techniques
can give numeric answers and heuristic customization could give ordinal indications concerning
variant performance (cf. section 6.2.2). Looking at the substitution relations (see table 4.1), one
can see a pattern in the relations: A configurable business process is thought to perform better
in terms of cycle time, the more freedom there is in its execution and the less activities there
are. Put di↵erently, a highly linear and rigid process has a higher cycle time than a concurrent,
flexible process. The evaluation section confirms this notion, as variants with choices as chosen
substitutions tended to perform better in terms of cycle time. This narrative may be seen as
a more general conclusion of this research and might also be applicable to process (re)design
33
at large. Business process analysts might ask themselves whether in a given process there are
opportunities to parallelize the work and give more flexibility to its execution. Especially, the
“order types” redesign heuristic should be consulted when designing business processes, as often
business processes are designed for the “average” case but not all cases might require each and
every step in the process and therefore a variant could be distinguished.
The presented framework of heuristic customization has also its shortcomings. Firstly it relies
heavily on the proposition that competing model variants are comprised of the same activities
such that variants are only concerned with the automation, blocking and structural rearrangement of the same activities. Hence heuristic customization only gives an indication of how to
structure a given set of activities but not how to distinguish them in the first place. This is
clearly a shortcoming, since in a real-life process (re)design project, often mutually exclusive
activities are considered. Secondly, cycle time is a strictly monotone KPI, meaning less is better.
For a non-monotone KPI such as utilization heuristic customization is not feasible, because one
can not apply the logic of iteratively making the better customization choice for each option to
arrive at the best variant. Thirdly, constraints on customization options have not been considered. Implicitly, it was assumed that all customization options are available independently of
each other. In a real life situation this might not always be the case. For example, arranging
tasks in parallel might only be possible if some of the activities are also automated. Such dependencies could render heuristic customization not feasible.
It should be noted that optimizing the cycle time of a configurable business process through
heuristic customization most likely a↵ects other process performance criteria. For example,
in the discussed example process 4.4, implementing the OR structure “favours” customers who
have only simple orders. This might be detrimental to the experience of other customers as they
feel that they have to queue while customers with simple orders can skip the queue. Hence,
choosing for an OR gate in this process might have a negative e↵ect on the perceived quality of
service. This example illustrates that heuristic customization should in real life not be followed
blindly but be pursued with the context of the process at hand in mind. The postulated e↵ect
of the mapped redesign heuristics (A.3) on other performance criteria might be a starting point
for assessing possible e↵ects on other process dimensions.
6.1.2
Validity of assumptions
In section 4.3 the assumptions of the heuristic customization framework are established. In this
section, the realism of these assumptions is briefly reflected upon.
Assumption 1 is particularly critical for the integrity of heuristic customization. It states that
activity behaviour is assumed to be independent of the control flow structure. The validity of
this assumption is critical for the logic of heuristic customization and especially the comparison
of di↵erent control flow structures within substitution. It ensures that the cycle time of that a
particular segment of a business process is only a↵ected by the control flow structure itself. Put
di↵erently, it does not matter for the cycle time of the activity in which structural arrangement
a particular activity is carried out. One particular mechanism through which the activity
duration could be a↵ected by their control flow structure are the resources performing those
activities. On the one hand one might argue that the assumption holds up to reality because
in a large organization, often the di↵erent activities of a business process are scattered across
34
multiple departments and functional units, such that the resources performing those activities
often do not have complete information about their role in the process. Hence, for them it does
not matter in which control flow structure their assigned task is embedded in. On the other
hand, particular structures might influence individual activities through through introducing
complexities. For example, arranging tasks in parallel instead of a sequence, might complicate
the work on a task, because certain tacit information can be inferred from work already done
on the case. Besides, combining work from several sources can have additional detrimental
e↵ects in terms of time and quality (coordination costs). Similarly, assumption 5 establishes,
that branching probabilities are independent of a particular variant. If choices within a business
process reflect conditions external to the process, such as the the type of order in the example
process of figure 4.4, then this assumptions is quite realistic.
Assumption 2 ensures that the the distinguished variants make sense from a business point of
view. This assumption is deemed to be realistic, because a the point of a configurable business
process is to depict possible real-life variants.
Assumption 3 is necessary to ensure that only the same activities are compared across variants.
This assumption is necessary from a conceptual point of view, because otherwise one cannot
compare variants in an ordinal way. Since assumption 6 established that information about
activity duration is unavailable, heuristic customization is build on the notion that activity
actual behaviour might be unknown but it is known that it is the same for each task in each
variant.
Next, assumption 4 states that the resource allocation of is fixed. In reality we observe that
modern economies are characterized by the division of labour causing specialists to perform
individual tasks in specific processes [3]. Therefore, this assumption is believed to hold up to
reality.
Finally assumption 5 is deemed realistic: Often (parts of) processes are not supported by
a information system, which produces log data. Moreover, expertise to extract procedural
information out of an information system might be lacking or this kind of analysis might be too
lengthy and costly for businesses.
6.2
6.2.1
Conclusion and future work
Conclusion
In section 3.1.1 the research goal of developing a qualitative framework for finding best performing variants was established. This goal was attained by developing heuristic customization, a
qualitative technique, that uses business process redesign heuristics to discover best performing
variants in terms of cycle time. In the section 5.2, it was demonstrated that heuristic customization is capable of identifying best performing variants in terms of cycle time of configurable
business processes in most cases. Thus, the research goal is achieved.
Heuristic customization requires fewer information about process behaviour than quantitative
techniques to discover best variants. Most notably, no information about activity duration is
needed to heuristically customize configurable business process models. Heuristic customization
fulfils two criteria: Generality, i.e. it is applicable to a wide range of business process models
and comparability, i.e. possible variants can be compared with respect to cycle time. The comparison is ordinal, meaning that one can only infer which variant is better than another but no
35
quantitative (how much) judgement can be made. The best performing variant(s) are discovered by iteratively making best customization choices within each customization option. The
framework of heuristic customization is assessed by comparing its ability to find best performing
variants against a collection of quantitatively evaluated models. A set of 15 randomly generated
model is simulated and best performing variants are identified. In 11 out of 15 cases heuristic
customization is able to find the best performing variant. Heuristic customization tends to work
better in models without loops. Businesses can derive value from this thesis by consulting the
customization rules derived in section 4.1.2, which can be used to (re)design more time efficient
processes, in particular in situations where no data on process behaviour is available.
6.2.2
Future work
Configurable business processes are an exciting area of research in the BPM in the field of
BPM. This thesis connects to the existing literature by developing a qualitative technique for
customizing configurable business processes. Future research could focus on whether redesign
heuristics are also suited for process discovery: Throughout this thesis, an existing configurable
process was taken as basis of the analysis. Future research might explore not the customization
of configurable business processes through redesign heuristics but using them for the generation
of variants. For example, the parallelization heuristic is concerned with arranging tasks in
parallel rather than sequentially. As noted before, there does not necessarily always exist a
need for organizing tasks in a sequence. Hence, the parallelization heuristic might be useful
for discovering a variant of an existing process where tasks are characterized be concurrency.
Similarly, the automation heuristic might be able to identify tasks which could be automated.
Future research could explore this direction by taking an existing non-configurable business
process and explore the possibilities to generate variants thereof by consulting process redesign
heuristics. An extension to the here proposed framework might be the incorporation of resources
into the customization process. In this study, resources have had a rather passive role. The
literature on redesign heuristics provides organization heuristics, which are primarily concerned
with the allocation of resources (human labour) amongst the activities in a business process.
Those redesign heuristics could be projected onto configurable business processes in a similar
fashion. Lastly, heuristic customization could be further developed to incorporate other KPI
than cycle time. In this research, it was shown that the framework of heuristic customization is
capable of discovering best variants in terms of cycle time. Hence, it is possible that the logic
of heuristic customization can be applied to other KPI’s as well, such that the the variant(s)
performing best in terms of costs or quality can be discovered. Important in this regard is, that
chosen KPI behave in a monotone fashion (more/less is better).
36
Appendix A
Definitions
A.1
Process Tree Notation
Structure
Process Tree
BPMN
SEQ
AND
XOR
OR
LOOP
Table A.1: Process Tree elements and corresponding BPMN elements
37
A.2
Redesign Heuristics
Table A.2 displays the definitions of the used redesign heuristics in section 4. For more detail
see [22].
Heuristic
Task elimination
Resequencing
Task automation
Bu↵ering
Parallelism
Order types
Exception
Definition
Eliminate unnecessary tasks from a
business process.
Move tasks to more appropriate
places.
Consider automating tasks.
Instead of requesting information
from an external source, bu↵er it by
subscribing to updates.
Consider whether task may be executed in parallel.
Determine whether tasks are related
to the same type of order and, if necessary, distinguish new business processes.
Design business processes for typical
orders and isolate exceptional orders
from normal flow.
Table A.2: Definition of used redesign heuristics
38
A.3
Customization options and redesign heuristics
Option
Configurable process tree notation
Redesign heuristics
blocking
• task-elimination • resequencing
hiding
•
task automation
• bu↵ering
substitution
• order types • exception
• parallelism • knock-out
Table A.3: Customization options and considered redesign heuristics
39
Appendix B
Simulation Models
B.1
Analysed models
Model
Nr.
Model
1
2
3
4
Table B.1: Models analysed in the evaluation phase
40
Model
Nr.
Model
5
6
7
8
9
10
11
Table B.2: Models analysed in the evaluation phase (continued)
41
Model
Nr.
Model
12
13
14
15
Table B.3: Models analysed in the evaluation phase (continued)
42
B.1.1
Model 8 variants
Figure B.1: Model 8: Best variant identified by simulation
Figure B.2: Model 8: Best variant identified by heuristic customization
43
Appendix C
Preliminaries
C.1
Configurable Process Trees
Schunselaar et al. [1, 26, 37] develop a new approach for modelling configurable business process models with tree-like structures. This configurable Process Tree notation has the attractive
property, that process models are always sound and reversible while not yielding more complex
models than previous approaches. The control flow perspective of a process tree consists of
directed arcs, connecting nodes, which can represent tasks or blocks. Tasks are work activities,
which need to be executed. Blocks indicate the causal relationship between tasks and hence
define the structure of the process. See table A.1 in the appendix for details. In this way, a tree
can be created with task as leaves.
A process tree o↵ers the possibility to add configurable parts through the use of three configuration options. Blocking (no entry sign) indicates that a particular subtree can be configured to be
excluded from the execution of the process. If one task within a subtree can is blocked, then the
entire sequence is blocked. Hiding (curved arrow) is used to for substituting a particular task
with an automatic task (i.e. a silent transition). Finally, substitution (dashed nodes) can be
used to replace a particular sub-structure of a process with other sub-structures. For example
the same tasks could be connected by an AND or by a OR node. In this research, configurable
processes will be depicted using the process tree notation due to its aforementioned attractive
properties.
Configurable Process Trees can be obtained from an event log by using specialized process
mining algorithms such as the ETMc algorithm [40] .
C.2
At-least-as-good relation
The comparison of di↵erent control-flow structures is closely related to the concept of monotonicity (see section 2.8). Monotonicity has been used to (partially) order process variants in
such a way, that one variant can be judged “at-least-as-good” as another variant with the aim
to prune the space of models, which need to be analysed in a simulation. A partial ordering
of all possible models can be derived such that a large part of the possible configuration space
does not need to be analysed, because they can never be better than models, which are at least
as good.
44
In this research, the at-least-as-good notion is used to derive an ordinal ordering of structural
process elements. The intuitive notion that one control-flow structure of a process might be
better suited to improve the performance behaviour than another structure is adopted from the
concept of monotonicity. In this thesis, the at-least-as-good relation is used in the context of
the (average) cycle time of a business process. If a control flow structure is said to at-least-asgood as another, this refers to the average cycle time of the structure. Individual runs of the
at-least-as-good structure might still be slower, but the average over many cases is not.
45
Bibliography
[1] DMM Schunselaar, HMW Verbeek, WMP van der Aalst, and HA Reijers. Petra: A tool
for analysing a process family. In International Workshop on Petri Nets and Software
Engineering (PNSE’14), number 1160, pages 269–288, 2014.
[2] James E. Davenport, Thomas H; Short. The new industrial engineering: Information
technology and business process redesign. Sloan Management Review, 31(4):11–17, 1990.
[3] Marlon Dumas, Marcello La Rosa, Jan Mendling, and Hajo A Reijers. Fundamentals of
business process management. Springer, 2013.
[4] Wil MP Van Der Aalst, Arthur HM Ter Hofstede, and Mathias Weske. Business process
management: A survey. In Business process management, pages 1–12. Springer, 2003.
[5] Michael Hammer. Reengineering work: don’t automate, obliterate. Harvard Business
Review, 68(4):104–112, 1990.
[6] Petia Wohed, Wil MP van der Aalst, Marlon Dumas, Arthur HM ter Hofstede, and Nick
Russell. On the suitability of BPMN for business process modelling. Springer, 2006.
[7] Dirk Fahland, Jan Mendling, Hajo A Reijers, Barbara Weber, Matthias Weidlich, and
Stefan Zugal. Declarative versus imperative process modeling languages: the issue of
maintainability. In Business Process Management Workshops, pages 477–488. Springer,
2010.
[8] Maja Pesic and Wil MP Van der Aalst. A declarative approach for flexible business processes management. In Business Process Management Workshops, pages 169–180. Springer,
2006.
[9] Paul Pichler, Barbara Weber, Stefan Zugal, Jakob Pinggera, Jan Mendling, and Hajo A
Reijers. Imperative versus declarative process modeling languages: An empirical investigation. In Business Process Management Workshops, pages 383–394. Springer, 2012.
[10] Dirk Fahland, Daniel Lübke, Jan Mendling, Hajo Reijers, Barbara Weber, Matthias Weidlich, and Stefan Zugal. Declarative versus imperative process modeling languages: The
issue of understandability. In Enterprise, Business-Process and Information Systems Modeling, pages 353–366. Springer, 2009.
[11] Beate List and Birgit Korherr. An evaluation of conceptual business process modelling
languages. In Proceedings of the 2006 ACM symposium on Applied computing, pages 1532–
1539. ACM, 2006.
46
[12] Kostas Vergidis, Ashutosh Tiwari, and Basim Majeed. Business process analysis and optimization: Beyond reengineering. Systems, Man, and Cybernetics, Part C: Applications
and Reviews, IEEE Transactions on, 38(1):69–82, 2008.
[13] Andrew Kusiak, T Nick Larson, et al. Reengineering of design and manufacturing processes.
Computers & Industrial Engineering, 26(3):521–536, 1994.
[14] Wil MP van der Aalst. Business process simulation survival guide. In Handbook on Business
Process Management 1, pages 337–370. Springer, 2015.
[15] Wil Van Der Aalst. Process mining: discovery, conformance and enhancement of business
processes. Springer Science & Business Media, 2011.
[16] Wil MP van der Aalst, Hajo A Reijers, Anton JMM Weijters, Boudewijn F van Dongen,
AK Alves De Medeiros, Minseok Song, and HMW Verbeek. Business process mining: An
industrial application. Information Systems, 32(5):713–732, 2007.
[17] Michael Hammer and James Champy. Reengineering the Corporation: Manifesto for Business Revolution, A. Zondervan, 2009.
[18] Mohamed Zairi and David Sinclair. Business process re-engineering and process management: a survey of current practice and future trends in integrated management. Management decision, 33(3):3–16, 1995.
[19] Majed Al-Mashari, Zahir Irani, and Mohamed Zairi. Business process reengineering: a
survey of international experience. Business Process Management Journal, 7(5):437–455,
2001.
[20] Paul Harmon. The scope and evolution of business process management. In Handbook on
Business Process Management 1, pages 37–80. Springer, 2015.
[21] John A Buzacott. Commonalities in reengineered business processes: models and issues.
Management Science, 42(5):768–782, 1996.
[22] Hajo A Reijers and S Liman Mansar. Best practices in business process redesign: an
overview and qualitative evaluation of successful redesign heuristics. Omega, 33(4):283–
306, 2005.
[23] Selma Limam Mansar and Hajo A Reijers. Best practices in business process redesign:
validation of a redesign framework. Computers in Industry, 56(5):457–471, 2005.
[24] S Limam Mansar and Hajo A Reijers. Best practices in business process redesign: use and
impact. Business Process Management Journal, 13(2):193–213, 2007.
[25] Marcello La Rosa, Wil MP van der Aalst, Marlon Dumas, and Fredrik P Milani. Business
process variability modeling: A survey. 2013.
[26] Dennis MM Schunselaar, Eric Verbeek, Wil MP van der Aalst, and Hajo A Raijers. Creating
sound and reversible configurable process models using cosenets. In Business Information
Systems, pages 24–35. Springer, 2012.
[27] Barbara Weber, Manfred Reichert, and Stefanie Rinderle-Ma. Change patterns and change
support features–enhancing flexibility in process-aware information systems. Data & knowledge engineering, 66(3):438–466, 2008.
47
[28] Wil MP van Der Aalst, Maja Pesic, and Helen Schonenberg. Declarative workflows: Balancing between flexibility and support. Computer Science-Research and Development, 23
(2):99–113, 2009.
[29] Michael Rosemann and Wil MP van der Aalst. A configurable reference modelling language.
Information Systems, 32(1):1–23, 2007.
[30] DMM Schunselaar, HMW Verbeek, HA Reijers, and van der WMP Aalst. Using monotonicity to find optimal process configurations faster. 2014.
[31] Michael Rosemann and Wil MP van der Aalst. A configurable reference modelling language.
Information Systems, 32(1):1–23, 2007.
[32] Florian Gottschalk. Configurable process models. PhD thesis, Technische Universiteit Eindhoven, 2009.
[33] DMM Schunselaar. Configurable Declare. PhD thesis, Master’s thesis, Eindhoven University
of Technology, The Netherlands, 2011.
[34] Wil Van Der Aalst, Niels Lohmann, Marcello La Rosa, and Jingxin Xu. Correctness
ensuring process configuration: An approach based on partner synthesis. In Business
Process Management, pages 95–111. Springer, 2010.
[35] Inge Kerssens-van Drongelen. The iterative theory-building process: rationale, principles
and evaluation. Management Decision, 39(7):503–512, 2001.
[36] Pieter J Van Strien. Towards a methodology of psychological practice the regulative cycle.
Theory & Psychology, 7(5):683–700, 1997.
[37] DMM Schunselaar, HMW Verbeek, WMP van der Aalst, and HA Reijers. Petra: Process
model based extensible toolset for redesign and analysis. 2014.
[38] Wil MP van der Aalst. Re-engineering knock-out processes. Decision Support Systems, 30
(4):451–468, 2001.
[39] Marcello La Rosa, Hajo A Reijers, Wil MP Van Der Aalst, Remco M Dijkman, Jan
Mendling, Marlon Dumas, and Luciano Garcı́A-BañUelos. Apromore: An advanced process
model repository. Expert Systems with Applications, 38(6):7029–7040, 2011.
[40] Joos CAM Buijs, Boudewijn F van Dongen, and Wil MP van der Aalst. Mining configurable
process models from collections of event logs. In Business Process Management, pages 33–
48. Springer, 2013.
48