The current issue and full text archive of this journal is available on Emerald Insight at:

www.emeraldinsight.com/1463-7154.htm

Flexibility of
A quantitative approach for business
measuring the degree of flexibility process models

of business process models

Asma Mejri 1023
RIADI Laboratory,
Received 8 March 2017
Ecole Nationale des Sciences de l’Informatique (ENSI), Sousse, Tunisia Revised 16 September 2017
Sonia Ayachi-Ghannouchi Accepted 27 January 2018

High Institute on Management of Sousse, Sousse, Tunisia, and

Ricardo Martinho
Department of Computer Science, School of Technology and Management,
Polytechnic Institute of Leiria, Leiria, Portugal and
CINTESIS – Centre for Research in Health Technologies and Information
Systems, Porto, Portugal

Abstract
Purpose – The purpose of this paper is to measure the flexibility of business process models. The authors
give the notions of flexible process distance, which corresponds to the number of change operations needed
for transforming one process model into another, considering the different perspectives (functional,
operational, behavioral, informational, and organizational).
Design/methodology/approach – The proposed approach is a quantitative-based approach to measure
the flexibility of business process models. In this context, the authors presented a method to compute the
distance between two process models. The authors measured the distance between a process model and a
process variant in terms of the number of high-level change operations (e.g. to insert or delete actors) needed
to transform the process model into the respective variant when a change occurred, considering the different
perspectives and the flexible features.
Findings – To evaluate the flexibility-measurement approach, the authors performed a comprehensive
simulation using an emergency care (EC) business process model and its variants. The authors used a real-world
EC process and illustrated the possible changes faced in the emergency department (possible variants). Simulation
results were promising because they fit the flexibility needs of the EC process users. This was validated using the
authors’ previous work which consists in a guidance approach for business process flexibility.
Research limitations/implications – The authors defined six different distances between business
process models, which are summarized in the definition of total process distance. However, changes in one
perspective may lead to changes in other perspectives. For instance, adding a new activity may lead to
adding a new actor.
Practical implications – The results of this study would help companies to obtain important information
about their processes and to compare the desired level of flexibility with their actual process flexibility.
Originality/value – This study is probably the first flexibility-measurement approach which incorporates
features for capturing changes affecting the functional, operational, informational, organizational, and
behavioral perspectives as well as elements related to approaches enhancing flexibility.
Keywords Quantitative approach, Business process flexibility, Change operations, Emergency care process,
Measurement distance, Model variant
Paper type Research paper

1. Introduction
The field of BPM has gained the attention of organizations. BPM includes methods,
Business Process Management
techniques, and tools to support the design, enactment, management, and analysis of Journal
operational business processes (Nurcan, 2008). In particular, the topic of business process Vol. 24 No. 4, 2018
pp. 1023-1049
flexibility has become a center of attention from both commercial and research institutions © Emerald Publishing Limited
1463-7154
as understanding of requirements for business processes (Mulyar et al., 2008). Flexibility DOI 10.1108/BPMJ-03-2017-0058
BPMJ has also been following the evolution of BPM, especially because of its ability to adapt
24,4 business processes to predicted and unpredicted real-world changing scenarios.
Although business process flexibility is abundantly mentioned in literature, it is difficult
to express in concrete quantifiable terms what the flexibility of a business process entails
(Eijndhoven et al., 2008). Therefore, this paper addresses business process flexibility issues
focusing on their measurement, taking into account the different perspectives and
1024 considering the flexible features of a business process. We also consider that changes can
occur at the process type/model or instance levels, or both. Such changes will allow
obtaining different modeling variants for considered business process. In order to compare
these variants, distances between corresponding variants could be measured. In this
context, the main contributions related to measuring distances between business process
models have been brought by Li et al. (2008). These contributions mainly consider
measuring distance between two process models in terms of the number of high-level
change operations (e.g. to insert, delete or move activities). They considered only the
variability of activities, whereas the variability of other perspectives (e.g. data and
resources) has yet to be considered. To overcome this limitation, we focus not only on the
functional perspective but we also suggest a measurement approach which incorporates
features for capturing changes affecting the operational, informational, organizational,
behavioral and elements related to the approaches that enhance flexibility.
The main contribution of this paper is to provide a quantitative approach to measure the
flexibility of business process models. This quantitative approach is based on how many
changes users need to perform in a process model by learning from a process model and a
collection of its process variants. This approach has considered the functional, operational,
organizational, behavioral and informational perspectives. Many concepts related to the
approaches enhancing flexibility are also considered.
This work is a post-validation approach for our previous work, in (Mejri et al., 2015a, b),
that addresses the challenge of developing an approach to help practitioners and academics
to choose business process modeling paradigms and tools that best fit their organization’s
BP flexibility needs. Therefore, the aim of this work is to measure the flexibility of business
processes modeled and executed in the recommended business process management
systems (BPMSs). This is done by counting the number of changes a user needs to perform
in those processes (using that BPMS) to achieve the desired flexibility. Therefore, we are
going to analyze the performance of our business process flexibility guidance approach, by
measuring the flexibility of the resulted models (modeled in the BPMSs scored by our
BPFlexGuide tool).
This paper is organized as follows. Section 2 introduces our previous work, and Section 3
presents the necessary concepts of our methodology for measuring business process
flexibility. Section 4 describes our flexibility-measurement approach. First, we have defined
what a flexible business process model is by using concept maps. Next, we conducted a
quantitative approach that was based on the definition of flexible business process model
that incorporates the flexible features and elements related to the different perspectives.
Section 5 is dedicated to the presentation of the flexible emergency care (EC) process from
the healthcare domain. More precisely, this section introduces the EC process and illustrates
the changes faced by the emergency department. Section 6 evaluates the algorithm that we
have developed using a simulation of the flexibility-measurement algorithm. Finally,
Section 7 recaps our contribution and gives some perspectives for future research.

2. Related work
In this section, we present some background on business process flexibility measurement.
In literature, there is very little explicit criteria that can be used to measure business process
flexibility. In this setting, many research works have developed this idea, such as Kasi and
Tang (2005), Eijndhoven et al. (2008), and Jansen-Vullers et al. (2007). Flexibility can also Flexibility of
refer to the degree of variation that a process permits. This flexibility can be discussed in business
relation to the event logs the process produces (Dumas et al., 2013). process models
Kasi and Tang (2005) proposed a framework for the comparison of business processes in
which they express the flexibility according to three dimensions: time (which implies that
the process should adapt to change more quickly), cost (which indicates that the process
should adapt to change with less cost), and ease (which means that the process should adapt 1025
to change with maximum ease).
According to Eijndhoven et al. (2008), other definitions are presented, including: time
(i.e. less items), cost (having the items that have to be changed in one place), and ease.
Ease implies the ability to make the translation from the new requirements for process
change to executable workflow in fewer stages (e.g. specifying new requirements in a
manner that is closely related to the executable workflow).
In Dumas et al. (2013), flexibility is defined as the criterion which is least noted
to measure. Flexibility can be defined in general terms as the ability to react to changes.
These changes may concern various parts of the business process. For instance, it includes
the ability of resources to execute different tasks within a business process setting, the
ability of a business process as a whole to handle various cases and changing workloads,
the ability of the management in charge to change the used structure and rules allocation,
and the organization’s ability to change the structure and responsiveness of the business
process to wishes of the market and business partners.
In Jansen-Vullers et al. (2007), authors proposed the following set of flexibility
performance measures: mix flexibility, labor flexibility, routing flexibility, volume
flexibility, and process modification flexibility. Mix flexibility is the ability to process
different kinds of cases for resources, for tasks and for the workflow as a whole. Labor
flexibility is the ability to perform different tasks for resources, specifically the number of
executable tasks and for the workflow. Routing flexibility is the ability to process a case
using multiple routes (number of different sequences in the workflow).Volume flexibility is
the ability to handle changing volumes of input (available time per employee). Process
modification flexibility is the ability to modify the process, such as the number of sub-flows
in the workflow, complexity, number of outsourced tasks, etc.
Gong and Janssen (2010) proposed an approach for measuring both flexibility and
agility in an e-government context. They argued that performance and cost can reflect
flexibility and agility. On this basis, they identified seven key metrics, which reflect
flexibility and agility. These metrics are throughput (i.e. the ability of the system to
execute a certain number of business processes within a unit of time), response time
(i.e. the time needed to interact within the target information system), case handling time
(i.e. the time from the point that a case is created till the point that the case is finalized), law
implementation time (i.e. the time spent on implementing a new or a new version of
law and regulation), operational cost (i.e. the cost spent on daily operation), law
implementation cost (i.e. the cost spent on implementing a new or a new version of law and
regulation), and quality (i.e. the measurement from the point of view of client satisfaction).
This work is a combination of qualitative and quantitative study. Indeed, it provides the
direction of measurement, which is the performance and cost aspect. Besides, it introduces
dimensions that can be quantified.
Another way of approaching the flexibility dimension is to distinguish between run-time
and build-time flexibility. In Dumas et al. (2013) and Jansen-Vullers et al. (2007), authors
separate two types of measurement purposes for process models. The first type is the
measurement of the process model design (the “static” or “build-time” property) considering
the possibility of changing the business process structure. The second type consists of
measuring results of a process model execution (the “dynamic” or “run-time” property).
BPMJ This concerns the opportunities of handling changes and variations while executing a
24,4 specific business process.
Table I represents a comparison between the existing approaches that were stated above.
Each of these approaches has considered different flexibility measures. Almost all the
existing approaches can only be understood by researchers. It cannot be used by companies.
To the best of our knowledge, rare are the approaches which have defined quantitative
1026 ways of measuring business process flexibility. For instance, Gong and Janssen (2010)
considered a quantitative and qualitative approach for measuring flexibility. Nevertheless,
their approach is limited to a specific field which is the e-government domain.
To the best of our knowledge, our approach is the only approach that proposes a
quantitative approach for measuring business process model flexibility, while considering
BP perspectives. It incorporates features for capturing changes affecting the functional,
operational, informational, organizational, and behavioral perspectives, as well as elements
related to approaches enhancing flexibility. Nevertheless, the majority of presented works
do not offer a concrete way for assessing the obtained degree of flexibility in BP model,
while taking into account all the BP perspectives. In this paper, we are going to present a
new methodology for measuring flexibility. Aside from considering flexibility in build-time
and run-time, it is increasingly important to distinguish the flexibility of a business process
from the other dimensions. Moreover, our methodology should take into account various
levels related to the considered perspectives.

3. Background
3.1 Previous work
Guidance in the BPM domain has a rich research background. Our work combines aspects of
guidance in BPM, comparison and evaluation of existing tools, paradigms, approaches or
methods related to BP flexibility. Guidance addresses the issue of guiding users during the BPM
lifecycle. Specifically, in literature some studies combine guidance in BPM and comparison
between existing tools, paradigms, approaches or methods related to BPM. Our research method
is based on a two-step research approach that integrates both a general classification of BPMSs
and process modeling paradigms, and the implementation of a guidance system that foresees
input from users regarding their needs in terms of business process flexibility, and later guiding
them to choose the best-suited BPMS for their organizations. Figures 1 and 2 present the main
activities developed within these major two steps.

Quantitative/ Can be used by

qualitative Considered BP researchers
Approach Flexibility measures approach perspectives /practitioners

Kasi and Tang Time Qualitative NM Researchers

(2005) Cost
Ease
Eijndhoven et al. Time Qualitative NM Researchers
(2008) Cost
Ease
Dumas et al. (2013) Concern various parts of the BP Qualitative NM Researchers
Jansen-Vullers Mix flexibility Qualitative NM Researchers
et al. (2007) Labor flexibility
Volume flexibility
Table I. Routing flexibility
Comparison between Process modification flexibility
the existing Gong and Janssen Seven key metrics Quantitative and NM Researchers and
approaches (2010) qualitative practitioners
 Flexibility of
business
Expert
process models

1027
Taxonomy of Regev et al. Questionnaire

General
classification of
Figure 1.
Flexibility
BPMSs and
Overview of Step 1 of
criteria
paradigms
our research method

General
Users’ classification
needs of paradigms
User and BPMSs

Similarity study

Specific
classification

Figure 2.
Recommended Recommended Overview of Step 2 of
BPMSs paradigms our research method

These activities can be summarized as follows:

• Step 1: classification of BPMSs:
– Identification of flexibility criteria (FC): we began by identifying a set of criteria
that we derived from Regev et al.’s taxonomy, in order to evaluate flexibility
within BPMSs. From this activity, we have specified 11 FC.
– Development of the questionnaire “Evaluation of Business Process Management
Systems (BPMS)”: we developed a questionnaire for BPMS developers and
researchers to answer based on their advanced knowledge of the BPMS’s they
BPMJ develop and research upon. We also selected these BPMS’s taking into account their
24,4 prominence in literature as well as their ability to support business process
flexibility. We could then analyze the answers to the questionnaires and classify
BPMS’s accordingly regarding their support on flexibility and modeling paradigms.
• Step 2: development of the BPFlexGuide guidance system:
– Identification of user’s business process flexibility needs: here we also developed
1028 a proper questionnaire targeting the collection of business process flexibility
needs from the users (process engineers) of our BPFlexGuide system. This
questionnaire implied efforts of mapping the well-known flexibility taxonomy of
Regev et al. into a set of questions to be understood by general users without a
profound knowledge of business process flexibility.
– Similarity study: here we compared the obtained answers from the users’ needs
questionnaire and the previous classification of BPMS’s in order to derive a score
in terms of flexibility.
– Specific classification: we then classified and sorted the BPMS’s and modeling
paradigms with an algorithm and presented the associated recommendations
to users.
The approach, described in the previous section, is supported and tested by a
corresponding tool implementation. Thereby, we did not develop a tool from scratch, but
built upon an existing open-source solution – the ProM tool (Verbeek et al., 2010).
We implemented our approach by a new plugin, entitled BPFlexGuide. This plugin allows
users to pick, from a list, the FC which best fit her/his needs on flexibility (based on the
taxonomy of Regev et al.). Users get as a result the ranking of the different BPMS’s and of
the modeling paradigms.
In this paper, we plan to propose a post-validation approach for the BPMS’s
recommended by our BPFlexGuide tool. This will imply measuring the flexibility of
business processes modeled and executed in the recommended BPMS’s, by counting the
number of changes a user needs to perform in those processes (using that BPMS) to achieve
the desired flexibility. Therefore, in order to analyze the performance of our business
process flexibility guidance approach, an approach of measurement of flexibility of the
resulted models (modeled in the resulted BPMS’s) is used.
Figure 3 presents the general methodology used for the purpose of validating our
guidance approach. Considering the output of the BPFlexGuide plugin, we first model the
BP models using the recommended BPMS’s. These BP models are subjected to several
changes resulting in different process variants. Our flexibility-measurement approach,
which will be presented in the next sections, is applied for each one of these variants.
As a result, we got a degree of flexibility for each BP model.
In this paper, we explain the basic concepts related to our post-validation approach.
We will present a new methodology for measuring business process models’ flexibility.
We apply the proposed methodology to EC process. We discuss the obtained simulation
results, comparing them with the BPFlexGuide plugin (the recommended BPMS’s) and
considering the EC process users’ flexibility needs.
3.1.1 BP modeling paradigms. Flexibility has become one of the major research topics in
the area of BPM. In fact, flexibility is an essential property for maintaining proper alignment
of fit between business processes and their supporting systems in changing environments
(Regev and Wegmann, 2005).
The field of BPM has gained the attention of organizations. BPM includes methods,
techniques, and tools to support the design and enactment literature provides various process
modeling paradigms that we classify into: constraint-based, rule-based, case handling, and
 Changes modeling
BP models flexibility
Flexibility of
Output of the BPflexGuide BP modeling Change 1
measurement approach
business
Variant 11
plugin: Recommended
BPMSs process models
Change 2 Flexibility
Variant 12 measurement for Flexibility
BPMS°1 Model 1
model 1 Degree 1

BPusers’ BPflexGuide
flexibility
needs
plugin Change i
Variant 1i 1029
BPMS°2 Model 2

Change 1
Variant 21

Change 2 Flexibility
Variant 22 Flexibility
measurement for
Degree 2
model 2

Change i
Variant 2i

Figure 3.
Methodology for
our post-validation
approach

adaptive process modeling paradigms. Each category has its underlying approach that may
be examined in terms of its appropriateness to flexible process modeling and execution.
The constraint-based paradigm focuses on constraints as rules that have to be followed
during the process execution. Possible executions of constraint-based process models are
specified implicitly as all executions that satisfy the model constraints. This makes it
unnecessary to explicitly predict and model all possible execution paths in advance which
proves to be very helpful for certain domains such as those related with clinic healthcare
processes (Pesic, 2008).
The main concept in the case handling paradigm is the case and not the process activities
or paths. The case is the “product” which is manufactured and at any time workers should
be aware of this context. Case handling is a paradigm for supporting flexible and
knowledge-intensive processes by strongly integrating them with data (Chiao et al., 2013).
It follows a revolutionary approach leaving traditional workflow processes and their strict
separation of data and control flow behind.
A paradigm is called rule-based if the logic of its control flow, data flow, and resource
allocation is declaratively expressed by means of business rules. Business rules are
recognized as powerful representation forms that can potentially define the semantics of
business process models and business vocabulary (Sun et al., 2006).
The adaptive process management paradigm can be seen as an evolutionary technique,
solidly based on traditional workflow, while adding new features to dynamically and safely
adapt the process definition at any point in time (Guenther et al., 2008).

3.2 Basic concepts

This work was based on a set of definitions which were proposed in the work of Li et al.
(2009a, b). These definitions are as follows: process change, process variant, change log, and
process distance.
A process change is accomplished by applying a sequence of change operations to a given
process model. Such operations structurally modify the initial process model. Thus, each
application of a change operation results in a new process model (Li et al., 2009b).
In their work, Li et al. (2009a) consider the following definitions (Definitions 1 and 2) of
BPMJ consecutively the process change, process variant, and the change log. We consider the same
24,4 definitions in our work:
Definition 1. Process change and process variant.
Let P denote the set of possible process models and C be the set of possible process changes;
let S, S′ ∈ P be two process models; let Δ ∈ C be a process change; and let σ ¼ [Δ1, Δ2, …, Δn]
be a sequence of changes performed on initial model S. Then:
1030
• S [ Δ〉 S′ is applicable to S and S′ is the sound process model resulting from the
application of Δ to S.
• S [ σ〉 S′ if ∃ S1, S2, …, Sn+1∈ P with S ¼ S′, S′ ¼ Sn+1, and S[Δi〉 S′i+1 for i∈ {1, 2, …, n}.
We denote S′ as process variant of S′.
Definition 2. Change log.
Let P denote the set of possible process models.
Let S ∈ P be a process model and let Si∈ P for i ∈ {1, 2, …, n} be its variants.
A change log cL is defined as a set {σi | S [σi〉 S′i+1} (σi denotes a sequence of change
operations transforming S into Si).
In Li (2010a, b), the author provided how to measure process distance based on change
operations which indicate how costly it is to transform process model S into S0. This
distance (Definition 3) considers only the functional perspective. Generally, it is possible to
have more than one minimal sequence of change operations to transform S into S′:
Definition 3. Process distance.
Let S, S′ ∈ P be two process models.
Let σ ¼ [Δ1, Δ2, …, Δn] ∈ C be a sequence of change operations performed on the
operations of the initial model S, transforming it into S′.
Functional distance d(S, S′) between S and S′ corresponds to the minimal number of
high-level change operations performed on the set of activities needed to transform S into S′,
and can be defined as follows:

   
d S; S 0 ¼ min jsjs A C4S siS 0

In our work, we focus on considering not only the functional perspective but also
operational, informational, organizational, and behavioral perspectives. These perspectives
are, respectively, clarified in Definition 5-Definition 9.

4. Methodology for measuring flexibility

In this paper, we provide a new methodology for measuring flexibility of business
processes. We explain first the research methodology we have followed in order to define
the different steps.

4.1 Research methodology

In order to deeper understand BP flexibility, the first step is the identification of the different
concepts that we use. We give definitions related to BP model, BP change, BP variant, and
change log. Thereby, we first present our concept maps of flexible business processes.
This concept map contains the most important concepts and relationships which help us to
formally define these different concepts. These definitions are considered in order to define
the distances regarding the different BP perspectives (functional, operational, informational,
organizational, etc.), which are related to the different perspectives. On the basis of these
distances, we elaborate our algorithm for measuring BP flexibility.
4.2 Concept maps for flexible BPs Flexibility of
Novak and Cañas (2008) defined a concept as “a perceived regularity in events or objects, business
or records of events or objects designated by a label.” Thus, concept maps consist of pairs process models
of concepts joined by link lines with descriptive labels (e.g. has a, is a, leads to, etc.) that
indicate the relationship between pairs of concepts (Clariana et al., 2013). The concept
maps were elaborated, using the methods described in Novak and Cañas (2007, 2008).
Thus, we provided answers to the focus question “How can a business process be 1031
flexible?” We obtained the diagrams presented in Figures 4-6. Most of the concepts were
extracted from the Regev et al. (2006), Nurcan (2008), Reichert and Weber (2012a) and
Schonenberg et al. (2008) taxonomies.
A business process could be defined as a range of inter-related elements that collectively
lead to a business goal (Figure 1). The business process model is the center for conducting
business or improving how the business is operated. The evolving models also help
developers focus on their thinking. Working with these models increases their
understanding of the business and hopefully their awareness of new opportunities for
improving business (Eriksson and Penker, 2000). A business process model aims to capture
the different ways in which a process instance can be handled (Aalst, 2013). A business
process instance represents a concrete case in the operational business of a company,
consisting of activity instances (Weske, 2012).
According to the taxonomy of flexibility defined by Reichert and Weber (2012b), flexible
business processes are characterized by variability as a major flexibility need. Process
variability requires processes to be handled differently resulting in different process variants

Flexible business process

is combination of

element

goal
lead to

is represented by

is represented by
uses concepts defined by is instantiated from

model
meta model instance real world

is a

is a
is a
is a rigid representation
is a

representation

is not subjected to

is a

change
flexible representation
has is subjected to

property is controlled by

is triggered by
has

change log

is a set of Figure 4.
Concept map on
change operation
variant BP flexibility
driver
BPMJ execute
is performed by is related by has

24,4
is played by

actor control connector activity condition rule case

operation role

1032 resource

is a is a is a
constraint is a
is a
is a is a
is a is a
Figure 5. ????
Generalization
is a
relationships for the
concept of element element

external driver internal driver delete

modify mandatory constraint optional constraint
add

move
is a ???? is a

is a

driver constraint
change operation

revolutionary permanent planned ad hoc temporary corrective immediate

momentary
Figure 6.
Generalization deferred
incremental
relationships for the
is a
concepts: driver, ????
property, constraint,
and change operation
property

depending on a given context. Process adaptation and process evolution are defined as two main
characteristics of flexible processes in the taxonomy of Reichert and Weber (2012b). Process
adaptation represents the ability to adapt the process and its structure to emerging events. It is
triggered by different drivers. Process evolution, as a characteristic of flexible processes,
represents the ability of the process implemented in a PAIS to change when the corresponding
business process evolves. According to Reichert and Weber (2012b), process adaptation and
process evolution are triggered by different drivers that could be external or internal.
Both Reichert and Weber (2012a) and Regev et al. (2006) focused on defining the
properties of change. Thus, a change has a property. As defined in Regev et al. (2006),
the properties of change include extent, duration, swiftness, and anticipation of change.
The extent of change refers to the amount of change realized, either being applied to an
existing process model (incremental change), or abolishing it and creating a completely new
one. Duration of change refers to how long a certain change will last: temporarily (only lasts
for a period of time), or permanently (lasts until the next change). Swiftness of change
reflects the choice between an immediate propagation of change over the existing process
instances (including the running ones), or a deferred propagation affecting only new
instances of the changed process.
 Process change is accomplished by applying a sequence of change operations to a given Flexibility of
process model. Such operations structurally modify the initial process model. Thus, each business
application of a change operation results in a new process model (Li et al., 2009a, b). process models
According to Li (2010a, b), though the depicted change operations were discussed in relation
to the ADEPT change framework, they are generic in the sense that they can also be applied
in connection with other process meta-models. While insert, delete, move, and modify
operations are important for changing the set of elements in a process model, other change 1033
operations are also possible.
As presented in Figure 4, the changes regard the various elements (that compose the
business process that can be changed), as presented in the taxonomy of Regev et al. (2006)
(the subjects of change). The subjects of change can be differentiated by associating them with
different perspectives. The functional perspective describes activities to perform during
process execution. A process performs activities. Activities are logical units of work
(Van der Aalst and Berens, 2001). In the behavioral process perspective, an activity can have
pre-conditions and post-conditions. The coordination between activities (conditional control
pattern) is then specified by control connectors. The operational perspective defines
elementary operations performed into the atomic activities. Activities can execute one or
several operations. The informational perspective deals with the production and use of
information. An activity consumes and/or produces informational resources. An informational
resource is system data, application data, or process data. The organizational perspective
describes relationships between roles and actors giving them authorization to perform atomic
activities. An atomic activity is performed by a role which is played by several actors. On the
basis of these perspectives, a business process encompasses a number of elements, namely
activities, operations, informational resources, roles, control connectors, and actors. The
different elements, using concept mapping, are presented in Figure 5.
In order to best take into account the flexibility in BP, we especially add in our concept
map concepts related to the business process modeling paradigms (such as the constraint-
based, the rule-based, the adaptive process management, etc.) dealing with flexibility in
process management.
A constraint-based process model supports users by being able to keep track of multiple
constraints in multiple business processes and preventing users from violating these
constraints. In addition, it is also possible to distinguish between the mandatory constraints
(i.e. that must be followed) and optional constraints (i.e. that should be followed) (Van Der
Aalst et al., 2009) (cf. Figure 6).
On the other hand, rule-based approaches have been proposed to deal with the flexibility
requirement in a proper way by modeling the logic of a process with a set of rules
(Boukhebouze et al., 2011). Hay et al. (2000) defined business rules as the set of policies for
regulating the whole business within and outside an organization.” Thus, business
processes can be modeled as a set of business rules. The rule-based approaches are flexible
because they are able to express the temporal requirements. They also take advantage of
adaptation to ad hoc modification at run-time and exceptions (Bekki and Belbachir, 2012).
The case handling paradigm focuses mainly on the case itself (Wohed et al., 2009).
The central concept for case handling is the case and not the activities. The case is the
“product” which is manufactured, and at any time workers should be aware of that
(Van der Aalst and Berens, 2001). The case should be considered as a “product” with
structure and a current state (Van der Aalst and Berens, 2001). Each case is linked to one
process but one process can be linked to many cases (Van der Aalst and Berens, 2001).
The adaptive process management is solidly based on traditional workflow and it is,
moreover, extended with features to dynamically and safely adapt the process definition at
any point in time. In addition, the ability to change both single cases and complete process
types is possible (Guenther et al., 2008).
BPMJ In the next section, these concept maps have been exploited in order to define, in a formal
24,4 way, what a flexible process is. Moreover, we will define, formally, business process change,
business process variant, and change log.

4.3 Measuring flexibility

In this section, we provide basic definitions for flexible process model, process
1034 change, process variant, and change log. The definition of the flexible business process
model was based on the concept maps presented in the previous section (specifically
Figures 4 and 5):
Definition 4. Flexible BP model: a flexible process model is represented as a graph which
comprises:
(1) a set of nodes – either representing process steps (i.e.: activities) or control
connectors;
(2) a set of roles;
(3) a set of information elements;
(4) a set of resources;
(5) a set of operations; and
(6) a set of DECLARATIVE elements or decision elements.
Generally, the functional perspective (1) is compulsory to be given by the process definition.
Regarding the other elements (from 5 to 10), they are associated to the other perspectives
(behavioral, operational, organizational and informational).
4.3.1 Distances. We clarify the definitions (Definition 5-Definition 10) of the following:
• Functional distance: deals with the change of the activity set.
• Operational distance: deals with the changes of the operations.
• Informational distance: deals with the change of data, documents, or forms.
• Organizational distance: deals with change of the actors.
• Behavioral distance: deals with change of the conditions.
• Declarative distance: deals with changes related to the rules, constraints or cases.
In Li (2010a, b), the author provided how to measure process distance based on
change operations which indicate how costly it is to transform process model S into S′.
This distance (Definition 4) considers only the functional perspective. Generally,
it is possible to have more than one minimal sequence of change operations to transform
S into S′:
Definition 5. Functional distance.
Let S, S′ ∈P be two process models.
Let σfun ¼ [Δ1, Δ2, …, Δn] ∈ C be a sequence of change operations performed on the
operations of the initial model S, transforming it into S′.
Functional distance dfun(S, S′) between S and S′ corresponds to the minimal number of
high-level change operations performed on the set of activities needed to transform S into S′,
and can be defined as follows:

   
dfun S; S 0 ¼ min jsfun jsfun A C4S sfun S 0
In our work, we focus on considering not only the functional perspective but also the Flexibility of
operational, informational, organizational and behavioral perspectives. These perspectives business
are, respectively, shown in Definition 6-Definition 9: process models
Definition 6. Operational distance.
Let S, S′ ∈P be two process models.
Let σop ¼ [Δ1, Δ2, …, Δn] ∈ C be a sequence of change operations performed on the 1035
operations of the initial model S, transforming it into S′.
Operational distance dop(S, S′) between S and S′ corresponds to the minimal number of
high-level change operations performed on the operations needed to transform S into S′, and
can be defined as follows:

   
dop S; S 0 ¼ min sop sinf A C4S ½sinf iS 0

Definition 7. Informational distance.

Let S, S′ ∈P be two process models.
Let σinf ¼ [Δ1, Δ2, …, Δn] ∈ C be a sequence of change operations performed on the
operations of the initial model S, transforming it into S′.
Informational distance dinf(S, S′) between S and S′ corresponds to the minimal number of
high-level change operations performed on data needed to transform S into S′, and can be
defined as follows:
 
dinf ðS; S'Þ ¼ min jsinf jsinf AC4S ½sinf iS 0

Definition 8. Organizational distance.

Let S, S′ ∈P be two process models.
Let σorg ¼ [Δ1, Δ2, …, Δn] ∈ C be a sequence of change operations performed on roles in
the initial model S, transforming it into S′.
Organizational distance dorg(S, S′) between S and S′ corresponds to the minimal number
of high-level change operations performed on data needed to transform S into S′, and can be
defined as follows:

     
d org S; S 0 ¼ min sorg sorg A C4S sorg S 0

Definition 9. Behavioral distance.

Let S, S′ ∈ P be two process models.
Let σbeh ¼ [Δ1, Δ2, …, Δn] ∈ C be a sequence of change operations performed on
conditions in the initial model S, transforming it into S′.
Behavioral distance dbeh(S, S′) between S and S′ corresponds to the minimal number of
high-level change operations performed on conditions needed to transform S into S′, and can
be defined as follows:

  
d beh S; S 0 ¼ min jsbeh jsbeh A C4S ½sbeh iS 0

Definition 10. Declarative distance.

Let S, S′ ∈P be two process models.
BPMJ Let σdec ¼ [Δ1, Δ2, …, Δn] ∈ C be a sequence of change operations performed on
24,4 conditions in the initial model S, transforming it into S′.
Declarative distance ddec(S, S′) between S and S′ corresponds to the minimal number
of high-level change operations performed on the decision elements needed to transform
S into S′, and can be defined as follows:

  
d dec S; S 0 ¼ min jsdec jsdec A C4S ½sdec iS 0
1036
To measure the total transformation from S to S′, we formally define total process distance.
Varied transformation types have been considered in our paper and they all impact on our
total process distance measure:
Definition 11. Total process distance.
Let S, S′ ∈P be two process models.
The total process distance d(S, S′) between S and S′ corresponds to the sum of the
functional, operational, behavioral, organizational, informational, and declarative distances
that correspond to the sum of all the operations performed on the initial model
S, transforming it into S′, and can be defined as follows:




d S; S 0 ¼ df un þdop þ dbeh þd org þ dinf þddec S; S 0

We then need to define the average weighted distance between a process model S and its
variants. Average weighted distance between a model and its process variants represents
how “close” they are:
Definition 12. Average weighted distance.
Let S∈P be a process model. Let M be a set of process variants Si∈ P for i∈{1, 2, …, n}, with
wi, representing the number of process instances that were executed on the basis of Si.
The average weighted distance D(S, M) between S and M can be computed as follows:
Xn Xn
DðS; M Þ ¼ d
i¼1 ðS;S i Þ
Uwi = w
i¼1 i

4.3.2 Change operations. In this paper, we define change operations, which can be applied to
the different perspectives of a process model.
We assume that a process change will be accomplished by applying a sequence of
change operations to the respective process variants. We also consider that these operations
can concern the different elements of the process.
In Gerth (2013), the high-level change operations include insert activity, delete activity, and
move activity. While “insert” and “delete” modify the set of activities in a process model,
“move” changes activity positions and thus the structure of the process model (Li, 2010a, b).
Though the depicted change operations were discussed in relation to the ADEPT framework,
they are generic in the sense that they can be also applied in connection with other process
meta-models (Gerth, 2013). Thus, in our work, the changes in the process include changes
concerning the five perspectives defined in the taxonomy of Regev et al. In fact, we focus
on altering the process set of activities and their order relations, its set of roles, of information/
data, of conditions and operations. We also focus on altering its declarative elements.
The declarative elements could be added, deleted, or changed. It is important to mention that
these change operations can be performed either in run-time or build (design) time.
4.3.3 Algorithm. In this section, we propose a flexibility-measurement algorithm. This
algorithm takes as input the business process model and the process variant collection. It gives
as output the average weighted distances. In this respect, the first step is the computation of the Flexibility of
distances for each process variant. The second one is the computation of the total process business
distance. Finally, on the basis of the total process distance and the number of process instances, process models
the average weighted distances of the process model could be finally calculated.
Algorithm 1.
Flexibility-measurement algorithm.
1037
Input: a business process model and a process variant collection.
Output: average weighted distance.
(1) For each process variant do compute:
• the functional, operational, behavioral, organizational, informational, and
declarative distances;
• the total process distance; and
• the number of process instances.
4.3.4 Compute the average weighted distances. We briefly introduce a motivational example
to illustrate how our flexibility-measurement algorithm works in general. First, a business
process model and its process variant collection are considered, as shown in Figure 7.
The process variant collection contains three process variants. Therefore, the number of
process instances is three. In our example, we consider all three process variants (S′1, S′2 and S′3).
On the basis of these variants, a number of process instances were executed. While considering
this business process model and its process variants, the functional, operational, behavioral,
organizational, informational, and declarative distances for each of these variants should be
assigned. It is important to mention that in this example the measures of the different distances
and the number of instances are merely used for illustration purposes (though these measures
will be calculated in the real case study which will be explained in the following section).
We use Definition 11 to compute the total process distance for each of the process
variants: d(S, S′1) ¼ 9, d(S, S′2) ¼ 11, d(S, S′3) ¼ 8. Using Definition 12, we obtain 3.55 as the
average weighted distance. This means we need to perform on average 3.55 high-level
change operations to configure a process variant (and related instance, respectively) out of
the process model.
The simple example shows how the flexibility-measurement algorithm generally works.
We will deeply consider a case study in the next section, and systematically use the
algorithm in order to measure the average weighted distances while considering different
BPMSs in order to compare their level of flexibility.

BP model: S BP Variant 2: S’2

A2 i =1 i =2 i =3
dfun(S,S’i ) 1 1 0
A1
Start End
A1 A3 dop(S,S’i ) 3 1 2
event event
Inclusive gateway
dinf(S,S’i ) 0 3 2
A3
dorg(S,S’i ) 5 4 3
BP Variant 1: S’1 BP Variant 3: S’3 dbeh(S,S’i ) 0 2 0
ddec(S,S’i ) 0 0 1 Figure 7.
Illustrative example
wi 12 23 28
explaining the
A1 A2 A1 A2 A3 flexibility-
measurement
algorithm
BPMJ 5. Case study: an EC business process
24,4 In this section, we are going to give first a description of the EC process. Then, we will
present the main changes that can occur.

5.1 Research method

As a case study to illustrate our flexibility-measurement approach, we consider an EC
1038 process which initiates with the patient registration and ends with her/his discharge from
the emergency department. The EC process was analyzed and modeled at first in Ayachi
Ghannouchi and Ghannouchi (2008), using the BPMN language. In their work, Ayachi
Ghannouchi and Ghannouchi (2008) divide the process into two cases according to the
patient’s condition:
(1) Valid patient: it is the case where the patient can move between the various sectors
of the emergency department. The majority of the patients are valid patients.
(2) A patient in serious harm or a patient on a gurney: these patients are brought into
the emergencies service by diverse ways (such as by ambulance, Emergency
Medical Service). They take precedence over the valid patients because they require
an immediate intervention by physicians.
The main technique used to elicit flexibility needs of the EC process was interviews.
The target group of the respondents of these interviews was professionals who work in the
EC process. The interview was grouped into the following two sections:
(1) Changes that can occur in the EC process: roles and causes.
(2) Flexibility needs to be considered for the choice of a BPMS.
The aim of the first section was planned to collect data about the roles responsible for
changes in the EC process and the causes of these changes. The second section was
designed to get information from the respondents about their needs in terms of flexibility
and in order to guide decision makers in choosing the best-suited BPMS tools.

5.2 EC process description

The main actors in this process are physicians, nurses, paramedical providers, and patients.
Tasks of the EC process include:
(1) Registration and payment: these are administrative tasks. Every patient has to
perform these two tasks at the beginning of this process. They are directly made by
the patient (in the case of valid patient) or by her/his guides (in the case of patient in
serious harm). We find in the emergency a registration desk and a cash box which
are opened 24 hours a day. The patient has to pay the charges with regard to social
insurance coverage.
(2) Consultation: it is the most important task in the studied process. It is completed by
physicians (medical interns or medical residents). We find three types of
consultations according to the patient’s condition and according to the place:
• Simple consultation: for the valid patients, it is completed in the outpatient block.
• Surgical consultation: for the injured patients, it is completed in the surgery
block.
• Immediate consultation: for the patients in serious harm, it is made in the
surveillance or crash room.
 (3) Complementary examinations: it has a great importance in the progress of our Flexibility of
process. Two situations can appear. The first one does not require the movement of business
the patient. The examinations are made in the emergency department (simple process models
radiography and blood tests). The second one forces to bring the patient in the
medical imaging department (ultrasounds, scanner).
(4) Treatment and care: realized by physicians or by nurses. These tasks can be
achieved in all blocks. 1039
(5) Hospitalization: if the situation of the patient requires long treatments, he is going to
be admitted. The physician is the only one who can decide on the hospitalization of
the patient.
(6) The patient is sent to a specialty consultation: a letter is written by the emergency
physician and given directly to the patient after which he will request an
appointment through the secretary.
(7) Preparing of certificates: provide the patient with a certificate, depending on his/her
situation, which includes the information about their emergency department use.
We have validated this process within the scope of this work, using observations and
interviews with the main actors of the process. In addition, we arrived at a deeper
understanding of the process and its different activities. The main activity that we have
added was the sorting. This activity is done generally by physicians. It consists of sorting
the patients, depending on their conditions, in order to send them to one of the following
emergency department sectors:
• the delayed emergency;
• the waiting room while seated or lying down;
• the crash room; and
• the supervision room.

5.3 Changes in the EC process

The main technique used to elicit changes of the EC process was interviews. The target
group of the respondents of these interviews was professionals who work in the EC process.
According to interviewees, physicians and nurses must be free to change the execution of
the different steps. They are familiar with such deviations of the pre-planned process.
They are also trained to do that because of the changeable patient’s health status and
because of exceptional situations that could be handled in the process. For instance, in the
work of Ouni (2012), the author studied four health crises faced by the emergency
department of the Hospital Farhat Hached Sousse between 2007 and 2010. These crises
provided significant changes to the EC process, and four main variants of this process could
be associated with each one, including:
• Train accident: the accident occurred in the region of Sidi Bouali November 19, 2007,
with several people injured. Carts and wheelchairs were prepared for moving victims
within the service to consulting rooms or radiology unit. Victims could also be
transferred directly to the crash room in case of life-threatening emergencies or need
for resuscitation.
• Smoke poisoning: the fire that started in an academic home in 2008 resulting in
many casualties/victims. The victims were put under high concentration masks in
the halls of observation room. All the victims were kept under supervision for at
least 12 hours. One of the patients was hospitalized in the intensive care unit.
BPMJ The state of anxiety and panic among victims persisted despite their healing, which
24,4 required the call of specialists in psychiatry. Psychiatric interviews were made for
all the girls to calm and facilitate the return to the academic home where the
disaster occurred.
• Collective food poisoning: the collective food poisoning occurred at the construction
site of the airport in 2009. There were 156 victims. The reception room was
1040 reserved for victims of the poisoning. The sorting step depended on the severity of
digestive and alteration in the level of consciousness of the patient’s condition.
To facilitate patient’s management, special forms were issued to victims of
poisoning containing certain personal data: their names, their ages, their
nationalities, and the suspect food. Moreover, another emergency form and
medical form must be completed by doctors. On these forms they must provide
details of the physical examination, the requested balance sheets and results,
treatment, history and patient progress.
• AH1N1 flu pandemic: the AH1N1 flu pandemic was occurred between November
2009 and March 2010. It was considered essential to organize the triage of AH1N1 flu
pandemic patients and create an isolation area to limit the transmission of the disease
between the consultants of the service and the patients. To reduce the risk of
transmission of the disease, a segmentation of the service was necessary. The waiting
room has been converted into an isolation room for flu pandemic patients. This room
accommodates a spaced dozen chairs. Patients had to be separated from their
accompanying persons. A special form “AH1N1 sheet,” containing information about
epidemiological and clinical patients, had to be carefully and properly completed by
the doctor.

6. Simulation
In our simulation, we describe how the simulation is setup in the next subsection, and
discuss simulation results afterwards.

6.1 Results using our guidance approach “Business Process Flexibility Guidance approach”
First, it is important to analyze the flexibility needs of the EC process. These flexibility
needs will serve as an input for our BPFlex Guide plugin. The main technique used to elicit
flexibility needs on the EC process was interviews. The target group of the respondents of
these interviews was professionals working in the EC process. We have concluded that:
• Regarding the abstraction level of modeling, when asking physicians this question
“Do changes affect all the new patients or only one patient?” They held that the
changes concern neither of them.
• Regarding the dimensions, our study focused on the five known dimensions defined
in the Regev et al.’s taxonomy which are the functional, operational, behavioral,
informational, and organizational dimensions. Interviewees believe that it would be
useful to know of the functional perspective. For instance, it would be important to
introduce or remove some activities of the EC process. Concerning the operational
dimension, interviewees think that a change in the process level does not require the
review of the implementation of applications of information technology that are used
in the emergency department. Respondents answered that changing the order of
activities can affect changes in the EC process. Thus, they affirm that it is very useful
to focus on the behavioral perspective when modeling the EC process. For the
informational perspective, respondents believe that it would be very important that
 changes concern the emergence of new types of information or data that can be Flexibility of
exchanged between the different actors involved in the EC process. Concerning the business
organizational perspective, interviewees see that it would be useful that the changes process models
also consider the roles associated to process activities.
• Concerning the properties of change, according to interviewees, the changes in the
model concern the entire model in some cases. For instance, the model could be totally
changed through the effective implementation of the disaster plan. The changes can 1041
also concern a part of the model. This can occur, for example, in the cases of
contagious or mental diseases. Regarding the duration of change, changes in the EC
process should be temporary. They should occur in a limited interval of time (even for
months). Because of patient’s needs of immediate care, the changes should be
immediate. They should not be delayed in time. In addition, interviewees believe that
the plans must be developed and must be planned well in advance. However, actions
can occur at unexpected times. To sum up, regarding the anticipation of change, both
the planned and ad hoc changes have to be provided.
Using the BPFlexGuide plugin, we have entered the flexibility needs of the EC process
(cf. Table II). The goal of the case study was to help process participants and decision makers
to choose the most appropriate BPMS that best fit their needs on flexibility. As a result,
EC participants and decision makers were guided to use the following two BPMSs:
(1) AristaFlow BPM suite: it enables process composition in a “plug and play” style, ad
hoc changes of single process instances, process model evolution and instance
migration, and change diagnosis (Reichert and Weber, 2012b).
(2) jBM: jBPM, an open-source community project by JBoss initially started as simple
workflow engine, is used for the enactment of business processes, which has grown
significantly in the last few years, to support the entire business process lifecycle,
from process authoring and analysis, to execution, monitoring, and management
(Nie et al., 2007) (Figure 8).

6.2 Modeling the EC process in AristaFlow BPM suite

Figure 9 shows the EC process model in ADEPT2 notation modeled using the AristaFlow
BPM suite. It comprises many activities which are connected through control edges.

Response

Dimensions of flexibility according to the taxonomy of Regev et al.

Abstraction level of change
BP type No
Subjects of change
BP instance No
Functional perspective 2
Operational perspective 0
Behavioral perspective 3
Informational perspective 4
Organizational perspective 3 Table II.
Properties of change Flexibility needs of
Extent of change Incremental and revolutionary the EC process,
Duration of change Temporary according to the
Swiftness of change Immediate taxonomy of Regev
Anticipation of change Both et al.
BPMJ
24,4

1042

Figure 8.
Screen capture of the
output of
BPFlexGuide plugin
(input: EC users’
needs)

Figure 9.
Screenshot of the EC
process model in
AristaFlow BPM suite

Generally, control edges specify precedence relations between activities. For example, activity
order treatment and care is followed by activity complementary examinations, whereas activities
registration and payment can be executed in parallel. Furthermore, the process model contains a
loop structure, which allows for the repetitive execution of the depicted process fragment. Finally,
data flow is modeled by linking activities with data elements. Respective data links either
represent a read or a write access of an activity to a data element. In our model, for instance,
activity sorting reads data element patient ID, which is written before the activity registration.

6.3 Modeling the EC process in jBPM 6

In order to model our process, we used jBPM6 (De Maio et al., 2014) which provides a large
variety of nodes including events, activities, gateways, etc. We frequently used human task,
rule task, and ad hoc sub-process in our implementation. Since most medical activities cannot
be completely automated, but instead require a lot of user interaction, we used human task for
modeling clinical scenarios. Moreover, we use ad hoc sub-processes to realize our notion of
workflow flexibility because it allows for EC participants (modelers and performers) to decide
what should happen through the use of ad hoc sub-process modeling elements. jBPM is
closely integrated with Drools for specifying rule-based logic (in different formats, e.g. decision Flexibility of
tables, rule files etc.). In our model, we have rule files (such as sorting-rule.drl). Drools rule files business
have a .drl (Drools Rules Language) extension. process models
This process has several human tasks, e.g. “registration” and “payment,” which require
interaction with clinicians. Clinical data are obtained from human tasks by user input and
are then accessible to the workflow engine. In particular, we have two ad hoc sub-processes
for composite activities to be customized at run-time. 1043
“Consultation ASP1” and “treatment ASP2” are two composite activities that contain a
number of atomic activities. The manner the contained activities will be executed and the
order of their execution is unknown at design time. For instance, “consultation ASP1” refers to
the set of consultation activities that are likely to follow the sorting. Nevertheless, it is not
possible to predict what types of consultation the doctor will do. Similarly, the complementary
examinations and treatment and care activities cannot be predicted and depend on the status
of the patient. Hence, the execution semantics for instantiating an ad hoc sub-process is only
known when this node is reached at the execution time. The procedure for patient treatment
depends on his/her test results, further diagnosis, and medical history.

6.4 Simulation results

In the next sub-sections, we present the results we obtained for the EC process modeled in
ADEPT2. In summary, we generated four variants related to the different changes for each
model. We further discussed the results. The first step consisted of identifying the change
log when using the ADEPT2 notation (AristaFlow BPM suite) for each possible change that
can occur in the EC process. Table III contains the change log for each possible change
presented in Section 5.2.
Generally, a large number of process instances, being in different states, may run on a
particular process model. Furthermore, the four variants are weighted. In the context of our
work, we define the weight wi of a process variant Si as the number of process instances that

Changes Change log

Train accident Add activity “evacuation of the rooms” between the two activities “no. 4” and “orientation”
Delete activity “Complementary examinations”
Add activity “moving to the radiology units” between the two nodes “treatment and care”
and payment
Smoke poisoning Add activity “wearing masks” between the two nodes “no. 4” and “orientation”
Add activity “psychiatry interviews” between node no. 19 and discharge
Add resource : “psychiatric specialists”
add data element: “Glasgow score”
Collective food Add data element: “severity of digestive”
poisoning Add data element “consciousness”
add data elements : “nationality”
Add activity “completing questionnaires”
Add activity “completing forms”
Pandemic flu Add activities
“wearing surgical masks” between activity “no. 24” and “sorting”
“education” between activities “no. 19” and “discharge”
“declaration to the crisis unit” between activities “education” and “discharge”
“consultation in a post-emergency room”
Add data “pandemic flu” Table III.
Add resource “family member” Possible operations
Delete conditions done in AristaFlow
related to “patient status” in the “orientation” BPM suite for
related to “discharge” in the “reorientation” each change
BPMJ were executed on basis of Si. In our example, 16 instances were executed on basis of process
24,4 variant S1, 14 instances ran on S2, 156 instances ran on S3 while 3,081 instances ran on S4.
We assume that we take the process model S (Figure 10) as a process model to measure
flexibility of the business process model. As presented in Table IV, the total process distance
between S and each of the four process variants is given by d(S, S1) ¼ 3, d(S, S2) ¼ 4,
d(S, S3) ¼ 5, d(S, S4) ¼ 8.
1044 Taking variant weights into account as well, we obtained 7.81 as the average weighted
distance. This means we need to perform on average 7.81 high-level change operations to
configure a process variant (and related instance respectively) out of the process model,
using the ADEPT2 notation.
We then repeated this procedure (as described earlier in Algorithm 1) for the jBPM6
BPMS, taking into account the process model from Figure 10. Table V contains the change
log for each possible change presented in Section 5.2.
For this case, we obtained for the average weighted distance the value of 8.86. This
means we need to perform on average 8.86 high-level change operations to configure a
process variant (and related instance respectively) out of the process model, using the
jBPM6 BPMS. Table VI explains the obtained values.

6.5 Discussion
The simulation is an illustration of the distance measures on a real-life EC process for which
four variants were defined, each as a consequence of some disaster situation. We can analyze
the results presented in Table IV to highlight how important the changes applied are for each
perspective ( functional, operational, organizational, behavioral and informational), compared
to the degree of change in the performed change operations in each perspective. We have
totally performed ( for the three different variants) 11 change operations that concern the
functional perspective, 5 change operations related to the informational perspective, and
2 change operations that concern the organizational perspective. No change operations related

Consultation ASP1
Treatment ASP2
Discharge

Delayed
Registration Crash room emergency
Treatment and care

Obtain a letter
Sorting supervision room Discharge? to an extern
Trauma room
consultation
Complementary
examinations

Payment Hospitalization
Orient to be
hospitalized in
a specialized
department

Figure 10.
EC process in jBPM6

Variants
Distances S1 S2 S3 S4

Functional distance 3 2 2 4
Operational distance 0 0 0 0
Behavioral distance 0 0 0 2
Table IV. Informational distance 0 1 3 1
Flexibility Organizational distance 0 1 0 1
measurement of the Declarative distance 0 0 0 0
EC process model in Total process distance 3 4 5 8
AristaFlow BPM Number of instances 16 14 156 3,081
suite BPMS Average weighted distance 7.81
Changes Change log
Flexibility of
business
Train accident Add activity “evacuation of the rooms” before the “sorting” activity process models
Add activity “moving to the radiology units” in the treatment ASP2 sub-process
Modify rule related to the “treatment ASP2” sub-process
Smoke poisoning Add activity “wearing masks” after the start event
add activity “moving to the radiology units” in the treatment ASP2
Add activity “psychiatry interviews” after the “sorting” activity 1045
Add resource : “psychiatric specialists”
Add data element: “Glasgow score”
Modify rule related to the “treatment ASP2” sub-process
Collective food poisoning Add data element: “severity of digestive”
add data element “consciousness”
Add data elements : “nationality”
Add activity “completing questionnaires” after the “sorting activity”
Add activity “completing forms”
Modify the rule associated to the discharge rule task
Add condition associated to the completing forms activity
Pandemic flu Add activities
“wearing surgical masks” between activity “no. 24” and “sorting”
“education” between activities “no. 19” and “discharge”
“declaration to the crisis unit” between activities “education” and “discharge”
“consultation in a post-emergency room”
Add data “pandemic flu”
Add resource “family member” Table V.
Delete conditions Possible operations
related to “patient Status” in the “Orientation” for each change (using
related to “discharge” in the “reorientation” jBPM6 BPMS)

Variants
Distances S1 S2 S3 S4

Functional distance 2 3
Operational distance 0 0
Behavioral distance 0 0
Informational distance 0 1
Organizational distance 0 1
Declarative distance 1 1
Total process distance 3 6
Number of instances 16 14
Average weighted distance 8.86
2 4
0 0
1 2
3 1
0 1 Table VI.
1 3 Flexibility
7 9 measurement for the
156 3,081 EC process model in
the jBPM6 BPMS

to the operational perspective were performed. Besides, changes concerning the behavioral
perspective are 2 for the ADEPT2.
Besides, the changes that were performed using the ADEPT2 BPMS could be performed
during the run-time and/or build (design)-time. We can also find out that the disasters with
large numbers of victims get a higher weight, because the average weighted distance
measure is weighted by the number of instances of a process variant. It is important to
mention that victims of AH1N1 flu pandemic represent the greatest number of individuals
who had an impact on the average weighted distance. In addition, clearly the less you have
to change, the more flexible the business process model is. The ideal is to have a business
process so flexible that you could perform the minimal number of change operations in
order to comply with a certain process variant.
BPMJ We discuss below which of the BPMS (ADEPT2 or jBPM6) is the most flexible for this
24,4 case study, and we verify if the results are consistent with the output of the BPFlexGuide.
We also discuss then if the results are compliant with the needs of the EC process users that
were presented in Section 4.3.
To analyze the results, we consider Tables IV and VI in order to compare the flexibility of the
ADEPT2 and jBPM BPMSs. We can analyze how important the changes applied for each
1046 perspective ( functional, operational, organizational, behavioral and informational) are by
comparing to what degree we have performed change operations in each perspective. Regarding
the ADEPT2 and the jBPM BPMSs, we have performed in total ( for the three different variants)
11 change operations that concerned the functional perspective, 5 change operations related to
the informational perspective, and 2 change operations that concern the organizational
perspective. No change operations related to the operational perspective were performed. Besides,
changes concerning the behavioral perspective are 2 for the ADEPT2, and 1 for the jBPM.
Comparing the different values, we conclude that we have performed change operations
for each perspective with different values, except the operational perspective. This is
compliant with the needs of the EC process described in Section 6.1. jBPM supports the
rule-based paradigm (Mejri et al., 2015a, b) due to its integration with the Drools rule engine,
which allows to create rules (De Maio et al., 2014). The rules are considered as the declarative
elements which could be added, changed, or deleted. Thus, the total declarative distance
(considering the three variants) is 6.
In our study, we aim to compare change efforts that could be offered by the
selected BPMSs. This will result in comparing the “average weighted distance” values.
In total, average weighted distance is 7.81 (using the ADEPT2 BPMS) and 8.86 (using the
jBPM BPMS) (cf. Tables IV and VI). Clearly the less you have to change, the more flexible the
BPMS is. The ideal would be to have a BPMS so flexible that you could perform a minimal
number of change operations in order to comply with a certain process variant/set of variants.
Thus, this complies with the output of the BPFlex Guide plugin which classifies ADEPT2 as
the first ranked BPMS. Besides analyzing the values of the average weighted distances for the
BPMSs, it is important to mention that another main difference between the changes that were
performed using the ADEPT2 and jBPM BPMSs is that changes using the ADEPT2 BPMS
could be performed during run-time and/or build (design)-time, while using jBPM BPMS,
changes could only be performed during build (design)-time.

7. Conclusion and future work

7.1 Implications to theory and practice
We believe that our approach is useful in many other aspects than just combining support to
users and evaluation of existing BPMSs and paradigms. First, we presented a concept map
supporting the most important concepts related to flexible business processes. On the basis
of this concept map, we defined what a flexible business process model is. We also defined
other concepts (i.e. process change, process variant and change log).
Second, we gave the notions of flexible process and flexible process distance, which
corresponds to the number of change operations needed for transforming one process model
into another, considering the different perspectives. We presumed, then, that the average
distance between a process model and related process variants is given by the average
amount of changes that are required to perform for adapting all the variants.
Third, in this context, we presented a method to compute the distance between two
process models. We measured the distance between a process model and a process variant
in terms of the number of high-level change operations (e.g. to insert, delete or move
activities) needed to transform the process model into the respective variant when a change
is occurred, considering the different perspectives. We then introduced an algorithm to
evaluate the distance between a process model and its variants.
 Fourth, we had systematically tested the properties of our algorithm by comprehensive Flexibility of
simulations based on an EC process model. For the involved process modelers, this is important business
information in order to compare the desired level of flexibility with the actual flexibility (Dumas process models
et al., 2013). We have thus evaluated our flexibility-measurement algorithm by performing a
comprehensive simulation using an EC business process model and its variants.

7.2 Limitations 1047

A limitation of the work presented in this work is the lack of the BPMSs and paradigms that
we studied, since not many business process approaches have formally implemented
flexibility. However, we considered those which have a great impact on the business process
management research area. Moreover, the provided guidance needs to be extended including
other dimensions that are not considered in the taxonomy of Regev et al. Users might require
very detailed and specific information about their flexibility needs for a certain processes.

7.3 Future research

Though results look promising, a number of issues are still open and can be the subject of
future work. As for the validation we used the EC process since healthcare processes are
commonly known for having flexibility needs. It would be useful to consider other processes
such as the Scrum framework for software development that we have already considered in
our work in Mejri et al. (2015b).
In addition, we are going to study in future research the impact of the atomic changes of
each perspective on the total process distance, and the impact of the changes on one
perspective in the perspective-bound distances. In fact, six different distances between
business processes are defined, in this paper, and finally summarized in the definition of total
process distance. However, changes in one perspective can be performed independently from
changes in another perspective. For instance, adding activities (i.e. functional perspective)
might lead to changes in role allocation (i.e. organizational perspective), changes in operations
(i.e. operational perspective), etc. While this is not a problem per se for each of the perspective-
bound process distance definitions, such relationships may have their impact on the total
process distance. Finally, other perspectives can also be considered in our flexibility measure
methodology such as cost and ease (Eijndhoven et al., 2008).

References
Aalst, W.M.P. (2013), “Business process management: a comprehensive survey”, ISRN Software
Engineering, pp. 1-37, doi: 10.1155/2013/507984.
Ayachi Ghannouchi, S. and Ghannouchi, S.-E. (2008), “Une expérience de bpr dans un hôpital tunisien”,
Systèmes d’information & management, Vol. 13 No. 1, pp. 89-116.
Bekki, K. and Belbachir, H. (2012), “A flexible integration of security concern in rule based business
process modeling”, Proceedings of ICWIT, pp. 222-231.
Boukhebouze, M., Amghar, Y., Benharkat, A.-N. and Maamar, Z. (2011), “A rule-based approach to
model and verify flexible business processes”, International Journal of Business Process
Integration and Management, Vol. 5 No. 4, pp. 287-307.
Chiao, C.M., KÃOEnzle, V. and Reichert, M. (2013), “Enhancing the case handling paradigm to support
object-aware processes”, in Accorsi, R., Ceravolo, P. and Cudré-Mauroux, P. (Eds), SIMPDA,
Volume 1027 of CEUR Workshop Proceedings, CEURWS, pp. 89-103, available at: http://dblp.
uni-trier.de/db/conf/simpda/simpda2013.html#ChiaoKR13
Clariana, R.B., Engelmann, T. and Yu, W. (2013), “Using centrality of concept maps as a measure of
problem space states in computer-supported collaborative problem solving”, Educational
Technology Research and Development, Vol. 61 No. 3, pp. 423-442.
BPMJ De Maio, M.N., Salatino, M. and Aliverti, E. (2014), jBPM 6 Developer Guide, Packt Publishing Ltd, ISBN
24,4 178328661X 9781783286614, 300pp.
Dumas, M., Rosa, M.L., Mendling, J. and Reijers, H.A. (2013), Fundamentals of Business Process
Management, Springer, Berlin and Heidelberg.
Eijndhoven, T.V., Iacob, M.-E. and Ponisio, M.L. (2008), “Achieving business process flexibility with
business rules”, Proceedings of the 2008 12th International IEEE Enterprise Distributed Object
1048 Computing Conference, IEEE Computer Society, Washington, DC, pp. 95-104.
Eriksson, H.-E. and Penker, M. (2000), Business Modeling with UML: Business Patterns at Work,
John Wiley & Sons, NewYork, NY.
Gerth, C. (2013), “Business process models – change management”, PhD thesis, LNCS, Vol. 7849,
University of Paderborn, Springer, Berlin and Heidelberg.
Gong, Y. and Janssen, M. (2010), “Measuring process flexibility and agility”, Proceedings of the 4th
International Conference on Theory and Practice of Electronic Governance, ACM, pp. 173-182.
Guenther, C.W., Reichert, M. and Van der Aalst, W.M. (2008), “Supporting flexible processes with
adaptive workflow and case handling”, Workshop on Enabling Technologies: Infrastructure for
Collaborative Enterprises, WETICE’08, IEEE, June 17, pp. 229-234.
Hay, D., Healy, K.A. and Hall, J. (2000), “Defining business rules-what are they really”, The Business
Rules Group.
Jansen-Vullers, M., Loosschilder, M., Kleingeld, P. and Reijers, H. (2007), “Performance measures to
evaluate the impact of best practices”, Proceedings of Workshops and Doctoral Consortium of the
19th International Conference on Advanced Information Systems Engineering (BPMDS
workshop), Vol. 1, Tapir Academic Press, Trondheim, pp. 359-368.
Kasi, V. and Tang, X. (2005), “Design attributes and performance outcomes: a framework for
comparing business processes”, Proceedings of the Eighth Annual Conference of the Southern
Association of Information Systems, pp. 226-232.
Li, C. (2010a), “Mining process model variants: challenges, techniques, examples”, PhD thesis, SIKS
Dissertation Series No. 2010-47, Enschede.
Li, C. (2010b), Mining Process Model Variants: Challenges, Techniques, Examples, University of Twente,
Enschede.
Li, C., Reichert, M. and Wombacher, A. (2008), “On measuring process model similarity based on high-
level change operations”, International conference on Conceptual Modeling-ER 2008, Springer,
pp. 248-264.
Li, C., Reichert, M. and Wombacher, A. (2009a), “Discovering reference models by mining process
variants using a heuristic approach”, in Dayal, U., Eder, J., Koehler, J. and Reijers, H. (Eds),
‘Business Process Management’, Vol. 5701 of LectureNotes in Computer Science, Springer, Berlin
and Heidelberg, pp. 344-362.
Li, C., Reichert, M.U. and Wombacher, A. (2009b), “A heuristic approach for discovering reference
models by mining process model variants”, CTIT Technical Report Series No. TR-CTIT-09-08,
Databases (DB), Enschede.
Mejri, A., Ghanouchi, S.A. and Martinho, R. (2015a), “Evaluation of process modeling paradigms
enabling flexibility”, Procedia Computer Science, Vol. 64, pp. 1043-1050.
Mejri, A., Ghanouchi, S.A. and Martinho, R. (2015b), “Examining flexibility in scrum under a scientific
approach a survey study”, 26th IBIMA Conference on Innovation Management and Sustainable
Economic Competitive Advantage, Madrid, October.
Mulyar, N., van der Aalst, W.M. and Russell, N. (2008), Process Flexibility Patterns, Technische
Universiteit Eindhoven, Eindhoven.
Nie, P., Seppälä, R. and Hafrén, M. (2007), “Open source power on BPM – a comparison of jBoss jBPM
and Intaglio BPMS”, Special Course in Information Systems Integration (2007): Business Process
Integration, pp. 1-26.
Novak, J.D. and Cañas, A.J. (2007), “Theoretical origins of concept maps, how to construct them, and Flexibility of
uses in education”, Reflecting Education, Vol. 3 No. 1, pp. 29-42. business
Novak, J.D. and Cañas, A.J. (2008), “The theory underlying concept maps and how to construct and use process models
them”, technical report, Florida Institute for Human and Machine Cognition, FL.
Nurcan, S. (2008), “A survey on the flexibility requirements related to business processes and modeling
artifacts”, Proceedings of the 41st Annual Hawaii International Conference on System Sciences,
IEEE, pp. 378-378.
1049
Ouni, A.B. (2012), “Plan blanc et gestion des crises sanitaires aux urgences”, PhD thesis, Faculté de
médecine Sousse.
Pesic, M. (2008), “Constraint-based workflow management systems: shifting control to users”,
doctoral dissertation, Technische Universiteit Eindhoven.
Regev, G. and Wegmann, A. (2005), “A regulation-based view on business process and supporting
system-exibility”, Proceedings of the CAiSE, Vol. 5, pp. 91-98.
Regev, G., Soffer, P. and Schmidt, R. (2006), “Taxonomy of flexibility in business processes”,
BPMDS, Luxembourg.
Reichert, M. and Weber, B. (2012a), “AristaFlow BPM Suite”, Enabling Flexibility in Process-Aware
Information Systems, Springer-Verlag, Berlin, pp. 441-464.
Reichert, M. and Weber, B. (2012b), Enabling Flexibility in Process-aware Information Systems:
Challenges, Methods, Technologies, Springer Science & Business Media, Berlin and Heidelberg.
Schonenberg, H., Mans, R., Russell, N., Mulyar, N. and van der Aalst, W. (2008), “Process flexibility: a survey
of contemporary approaches”, Advances in Enterprise Engineering, Springer-Verlag, Berlin, pp. 16-30.
Sun, X., Liu, X.-Z., Jiao, W.-P., Huang, G. and Mei, H. (2006), “A rule-based approach to supporting
adaptable web service composition”, Chinese Journal of Computers Chinese Edition, Vol. 29 No. 7,
p. 1084.
Van der Aalst, W.M. and Berens, P. (2001), “Beyond workflow management: product-driven case
handling”, ‘Proceedings of the 2001 International ACM SIGGROUP Conference on Supporting
Group Work, pp. 42-51.
Van Der Aalst, W.M., Pesic, M. and Schonenberg, H. (2009), “Declarative workflows: balancing between
flexibility and support”, Computer Science-Research and Development, Vol. 23 No. 2, pp. 99-113.
Verbeek, H.M.W., Buijs, J.C.A.M., van Dongen, B.F. and van der Aalst, W.M.P. (2010), “ProM 6: the process
mining toolkit”, ‘Proceedings of BPM Demonstration Track, CEUR-WS.org, Vol. 615, pp. 34-39.
Weske, M. (2012), Business Process Management: Concepts, Languages, Architectures, Springer Science
& Business Media, Berlin and Heidelberg.
Wohed, P., Russell, N., ter Hofstede, A.H., Andersson, B. and van der Aalst, W.M. (2009), “Patterns-
based evaluation of open source {BPM} systems: The cases of jBPM, openWFE, and Enhydra
Shark”, Information and Software Technology, Vol. 51 No. 8, pp. 1187-1216.

Further reading
Melcher, J. (2014), Process Measurement in Business Process Management: Theoretical Framework and
Analysis of Several Aspects, KIT Scientific Publishing.

Corresponding author
Asma Mejri can be contacted at: mejri.assma@gmail.com

For instructions on how to order reprints of this article, please visit our website:
www.emeraldgrouppublishing.com/licensing/reprints.htm
Or contact us for further details: permissions@emeraldinsight.com