Addressing Ambiguous BPMN Patterns: A Case Study at The BrainCap Group

(1)

Page | 1

Addressing Ambiguous BPMN

Patterns

A Case Study at The BrainCap Group

Hayo Bart (10254846)

27-06-2014

Bachelor Project Information Sciences

BSc. Informatiekunde

Universiteit van Amsterdam

Supervisor: Prof. Dr. H. Afsarmanesh &

(2)

Page | 2

0 Abstract

Organizations can use the Business Process Model and Notation (BPMN) to model their business processes. The use of certain control-flow patterns in BPMN, however, can cause issues either prior to or during run-time, such as an inability to convert certain constructs to executable code or a deadlock of the process. The patterns that cause such issues are referred to as ambiguous patterns. Although many researchers acknowledge the existence of these ambiguous patterns, most of the research has focused on resolving those patterns by proposing formalized semantics for the constructs that cause these ambiguous patterns. To the best of our knowledge, no research, however, addresses the ambiguous patterns from a practical point of view. This research aims to fill this gap by identifying and resolving the ambiguous patterns that arise in the business processes of a real-world company, i.e. The BrainCap Group. We identified and formalized 15 business processes of The BrainCap Group, which were captured in 25 business process diagrams. First we identify BPMN’s ambiguous constructs as well as their corresponding control-flow patterns. This knowledge was subsequently applied to the business process diagrams and resulted in the identification of nine ambiguities across seven business process diagrams. Subsequently we have resolved these ambiguities by redesigning the business processes. We were able to generalize the proposed solutions to some of the ambiguities into two general solutions, which can be applied to almost any occurrence of the ambiguous Inclusive Join Gateway in a structured context. The redesigned processes, as well as the original models, were validated by domain experts from The BrainCap Group.

(3)

Page | 3

1 Introduction

Each business in our world conducts multiple business processes (Ko, 2009). One of the first persons that implicitly wrote about business processes was the economist Adam Smith. He described the division of labor by making use of the well-known example of the pin factory: whereas pins initially were assembled completely by each employee individually, Smith (1776) proposed the division of (this) labor (i.e. process) into multiple branches (i.e. operations) each performed by different

employees. According to Smith (1776) this division of labor would lead to an increase in productivity. In this thesis, we use Davenport’s (1993) definition of a business process:

“[A business process is] a structured, measured set of activities designed to produce a specified output for a particular customer or market. […] A process is thus a specific ordering of work activities across time and place, with a beginning, an end, and clearly identified inputs and outputs: a structure for action” (p. 5)

In the early days, businesses used information systems mainly to store and retrieve data. An ongoing trend, however, is the shift towards a more process oriented use of information systems (Van Der Aalst, Ter Hofstede, & Weske, 2003), meaning that information systems nowadays are used for Business Process Management (BPM). In their paper on BPM, Van Der Aalst, Ter Hofstede, and Weske, define BPM as follows:

“Supporting business processes using methods, techniques, and software to design, enact, control, and analyze operational processes involving humans, organizations, applications, documents and other sources of information” (p. 4).

BPM thus is used to design, implement, execute, get grip on, and further optimize business processes by making use of various tools.

One of the methods that is inherent to BPM is Business Process Modelling, which is used to provide a representation of the activities that make up a business process, their causal and temporal relationships, and specific business rules for process execution by making use of a (graphical) Business Process Modelling Language (BPML) (Van Der Aalst, Ter Hofstede & Weske, 2003). Modelling of the business processes is done for two reasons: first, it reduces the risk of ambiguity in understanding or communicating the processes; and second, it increases the ability to analyze, and subsequently improve, processes (Ko, 2009; Van Der Aalst, Ter Hofstede & Weske, 2003).

Business process modelling can be facilitated by making use of one of several BPMLs, some of which have been identified and reviewed by List and Korherr (2006): UML 2.0 (Activity Diagram) (AD), Business Process Definition Metamodel (BPDM), Business Process Model and Notation (BPMN), Event Driven Process Chain (EPC), Integrated DEFinition Method 3 (IDEF3), Petri Net and Role Activity Diagram (RAD) (List & Korherr, 2006). In this research the main focus is on the Business Process Model and Notation (BPMN). The main objective of BPMN is to provide a standard notation that is intuitive enough to be understood and used by business users, for the design and analysis of business

processes, and, on the other hand, is expressive enough to be used by technical users to automatically execute business processes (Object Management Group, 2013).

Besides describing business processes, BMPN aims at the execution of business processes by providing a mapping between its modelling notations and the constructs of execution languages, e.g. Business Process Execution Language (BPEL) (OASIS, 2007). The provided mappings can generate an

(5)

Page | 5 executable code from a business process described by a BPMN diagram. However, the use of some patterns within the BPMN diagrams causes runtime problems, such as deadlock and synchronization problems for the generated code (Van Der Aalst, Ter Hofstede, Kiepuszewski, & Barros, 2003). For instance, the existence of two OR-Join gateways together, known as synchronizing merge pattern (Van Der Aalst, Ter Hofstede, Kiepuszewski, et al., 2003), causes the run-time system to not know for how many branches of the second gateway it should wait, before proceeding to the next step.

Synchronizing merge is an instance of the patterns that are referred to as ambiguous patterns in the literature (Russell, Ter Hofstede, Van der Aalst, & Mulyar, 2006).

Though these ambiguous patterns are acknowledged by many researchers, most research takes on a theoretical point-of-view in attempting to resolve the ambiguous patterns by proposing formal semantics for the constructs that constitute the ambiguous patterns (Dumas, Grosskopf, Hettel, & Wynn, 2007; Völzer, 2010; Wynn, Edmond, Van Der Aalst & Ter Hofstede, 2005). Existing research, however, lacks to address the ambiguous patterns from a practical point-of-view. This research aims to address this gap by taking such a practical point-of-view by identifying ambiguous patterns that arise in real-world business processes and subsequently proposing solutions to redesign these business processes without using the ambiguous patterns. This redesign takes the form of substituting the ambiguous patterns by their non-ambiguous equivalents. The business processes in this research will be sourced from the IT consultancy company The BrainCap Group.

In this thesis, we aim at addressing the following research question:

“How can we resolve ambiguous patterns identified in business processes, modelled in BPMN, of the IT consultancy company BrainCap?”

With this research we aim to make three contributions. The first contribution we aim to achieve is that of providing an overview of the ambiguous workflow patterns. The second contribution we aim to achieve is that of formalizing, and clearly, modelling (some of) the business processes of The BrainCap Group, which can subsequently be used in practice by the organization. Lastly we aim to identify ambiguities in the business processes and resolve these ambiguities using a practical point-of-view. Although this contribution seems to focus more on the organization, a more general solution to the identified ambiguities might be an additional academic contribution that might result from this practical contribution.

The remainder of this thesis is structured as follows. In Section 2, we provide background information about BPMN, workflow patterns, and ambiguous patterns, which is required for the retrieval and modelling of BrainCap’s business processes that is described in Section 3. Section 4

covers the identification and subsequent resolution of the ambiguities that are found in the modelled business processes. This is followed by a discussion of the limitations of this research and possible future work in Section 5. Finally, Section 6 concludes the thesis.

(6)

Page | 6

2 Background

Before being able to model business processes, let alone identify ambiguous patterns and resolve these patterns, an understanding of several aspects of BPMN has to be developed. This section therefore provides an overview of: (1) how BPMN is used to model business processes; (2) the workflow patterns that can be identified in BPMN; and (3) the ambiguous patterns in this set of workflow patterns. This understanding will be developed by reviewing relevant literature on the topics of BPMN, workflow patterns, and ambiguities in those workflow patterns.

In Section 2.1, we will provide an overview of the BPMN standard, including the elements it comprises and how it can be used to model business processes. Section 2.2 subsequently provides an introduction to the workflow, and specifically the control-flow, patterns, while Section 2.3 identifies the ambiguous BPMN constructs and the control-flow patterns that utilize those constructs.

2.1 Modelling Business Processes using BPMN

An excellent source on BPMN and how it can be used to model business processes is the organization that developed the standard. BPMN is meticulously explained in the publication of the Object

Management Group (OMG) on the BPMN 2.0.2 standard which was published in 2013 (Object Management Group, 2013). This section will therefore be based on this particular publication, unless otherwise indicated.

As mentioned in Section 1, the main objective for BPMN is to bridge the gap between the modelling of business processes for internal use, such as design and analysis, and the execution languages that are used to, possibly automatically, execute business processes by defining a standard notation that can be used by both business and technical users, and furthermore enables the mapping of a designed business process to an execution language. The BPMN standard furthermore enables organizations to exchange their business processes in a uniform and standard manner.

The BPMN standard was first introduced in 2006, with the publication of version 1.0. BPMN 1.0 was developed by the Business Process Management Initiative (BPMI). This organization aimed to promote the development of BPM. BPMN 1.0 was first developed to provide a notation for the Business Process Modelling Language (BPML), which was also developed by BPMI. In 2007, BPMN 1.1 was introduced, followed by BPMN 1.2 in 2009. These versions mainly fixed bugs in BPMN 1.0 and BPMN 1.1 respectively. With these new releases, BPMN more and more became a general modelling notation for the modelling of business processes, within and between companies (Earls, 2011b). The introduction of BPMN 2.0 in 2011 brought significant changes to BPMN. In BPMN 2.0 an increased focus was put on the interchangeability and execution of business processes. Furthermore, models were introduced to enable the modelling of interactions between process participants (Chinosi & Trombetta, 2012; Earls, 2011a).

2.1.1 BPMN Elements

The visual side of BPMN consists of a number of elements which can be used to visually model business processes. These elements are grouped into five basic categories: 1) flow objects, 2) data, 3) connecting objects, 4) swimlanes and 5) artifacts. Each of these basic categories contains a number of BPMN elements. The elements in each category can be enhanced with additional information to support more complex requirements within a particular business process. Each of the categories and their respective elements are briefly discussed in the sections below, for a more extensive description of the elements comprising each category, and their use, please refer to the BPMN 2.0.2 Standard (Object Management Group, 2013).

(7)

Page | 7

Flow objects

Flow objects are the building blocks that define the behavior of business processes. There are three flow objects: 1) events, 2) activities, and 3) gateways. Each of these objects is briefly discussed below. Events

An event is something happens during the course of a business process and affects the flow of the process. Events usually are triggered by a particular action or have a particular result. Three types of events can be distinguished based on when the process flow is affected: 1) a start event, 2) an intermediate event, and 3) an end event. The symbols used in BPMN to represent each of these three types of events are depicted in Figure 1. A start event indicates the start of a particular process, furthermore a start event can only react to a trigger. An end event, on the other hand, indicates that no further activities have to be performed. In case all tokens1_{in the process model are consumed by} the end events, it functions as a termination of the process. End events can only create a particular results, such as termination or cancellation. Intermediate events can occur between start and end events, and affect the process flow. These intermediate events can both react to triggers, such as messages and signals, and create results but not in a way that will start or terminate the process. Activities

Any work that an organization performs in a process can be referred to as an activity. Activities can be either atomic or compound. When the work cannot be broken down further into a set of

sub-activities, the activity is said to be atomic and is referred to as a task. A compound activity, on the other hand, can be broken down into a set of sub-activities and, when it is included in a business process, it is referred to as a sub-process. A sub-process can either be expanded or collapsed, in which case the set of sub-activities is and is not visible respectively. Sequence flows within a sub-process

1_{The term “token”, originally from Petri Net theory, defines the execution of a model (Wang, 2007). Tokens are}

contained in places of a model, which are activities, events, and gateways in BPMN, which are able to create additional tokens or remove tokens from the model (Jensen, 1997). A token can be seen as an execution instance of a model which flows through the model to simulate the execution of the model. The state of a model is represented by a so-called “marking”, which captures the distribution of the tokens in the model at a point in time (Jensen, 1997; Wang, 2007).

(8)

Page | 8 cannot cross the boundary of that particular sub-process. The symbols used in BPMN to represent each of these three types of activities are depicted at the right hand side of Figure 1.

Gateways

The divergence into, and convergence from multiple paths of the sequence flows in a business process are controlled by gateways. A gateway thus either divides an incoming path into two or more

alternative outgoing paths or combines two or more incoming paths into one outgoing path. Various types of flow control (either divergence or convergence) are exercised by gateways, which include: 1) the exclusive gateway, 2) the event-based gateway, 3) the inclusive gateway, 4) the complex gateway, and 5) the parallel gateway. The symbols used in BPMN to represent each of these gateways are depicted at the bottom of Figure 1. Each of the gateways is briefly discussed below.

The characteristic that is distinctive for the exclusive gateway is that upon a branching point only one of the alternative paths is chosen while at a merging point only one of the incoming paths is used to trigger the continuation of the outgoing sequence flow. The selection of the alternative path that is followed or triggers the outgoing sequence flow is based on mutually exclusive conditions. The sequence flow corresponding to the condition that first evaluates to true will be followed at a

branching point, while the incoming sequence flow that arrives first at the merging point triggers the outgoing (merged) sequence flow (IBM Corporation, 2013).

An event-based gateway is like an exclusive gateway: an incoming path is divided into two or more alternative outgoing paths of which only one can be followed. There are, however, two slight differences with respect to the exclusive gateway. The first difference is that the event-based gateway can only be used for branching, and not for merging (IBM Corporation, 2013). The second difference is that the alternative path to be followed at a branching point is chosen based on an event that occurs at that point in the process instead of on a condition.

The characteristic that is distinctive for the inclusive gateway is that upon a branching point one or more of the alternative paths can be taken while at a merging point multiple incoming sequence flows can be used to trigger the continuation of the outgoing sequence flow. Again, the selection of the alternative path(s) that is / are followed or trigger(s) the outgoing sequence flow is based on conditions. The conditions, and thus sequence flows, at the inclusive gateway, however, can be seen as a grouping of independent decisions. At a branching point, each of the outgoing sequence flows corresponding to a condition that evaluates to true will therefore be followed. Multiple incoming sequence flows to an inclusive gateway, on the other hand, can all trigger the outgoing sequence flow. At a merging point the inclusive gateway waits until all active sequence flows have arrived at the gateway before the subsequent sequence flow is enabled.

The complex gateway appears to be similar to the inclusive gateway: upon a branching point one or more of the alternative paths can be taken while at a merging point multiple incoming sequence flows can trigger the continuation of the outgoing sequence flow. The distinctive

characteristic of the complex gateway, however, is that it can be used to define complex conditions which shall be met before the sequence flow continues. One example of such a complex condition is that, in case of a branching point, two out of the four outgoing alternative paths need to be taken, or, in case of a merging point, two out of the four incoming paths are needed before the sequence flows will be merged and the flow will be continued.

The distinctive characteristic of the parallel gateway is that is enables the branching into (forking) and merging of (joining) multiple outgoing respectively incoming parallel paths. The parallel gateway thus enables the concurrent performance of particular activities and either branches a single

(9)

Page | 9 sequence flow into multiple parallel sequence flows or merges multiple parallel sequence flows into a single sequence flow.

Data

The data category is used to model items that are produced, manipulated, and used during the execution of a business process. Four elements are contained within this category. The data object is the first element in this category. This element is used to model the data that is used during a process. The second element, a data store, models a database that stores information that will persist after completion of a business process and can be accessed by activities to retrieve and update this information. The third and fourth element in this category, data input and data output, model the data that is required respectively produced by activities of a process. The BPMN symbols that are used for these four elements are shown at the left side in Figure 2.

Connecting objects

The connecting objects enable the creation of relationships between flow objects or between a flow object and other information. Three basic connecting objects can be distinguished: 1) sequence flows, 2) message flows, and 3) associations. The symbols used in BPMN to represent each of these objects are depicted at the right side of Figure 2. Each of these objects is briefly discussed below.

A sequence flow is used to show the order in which activities in a business process will be performed. A sequence flow is said to be normal whenever it does not start from an intermediate event located at the boundary of an activity. Conditions can be applied to a sequence flow to

determine, at runtime, whether a sequence flow will be followed. These sequence flows are referred to as conditional flows and they are widely applied in the use of gateways, especially at the exclusive, inclusive, and complex variants of gateways. A flow that is not affected by any conditions or does not pass through a gateway, on the other hand, is referred to as an uncontrolled flow. The default flow is a sequence flow that will be followed if all other outgoing conditional sequence flows are evaluated as being false at runtime. Therefore this sequence flow is mostly used at exclusive and inclusive

gateways.

A message represents the communication between two participants (which are represented by pools; see “Swimlanes”) whereas a message flow represents the flow of messages between two participants that are prepared to send and receive them. Message flows thus have to cross pool boundaries.

Additional information and artifacts, which are defined later on, can be linked to flow elements using an element called an association. Associations can be directional or direction-less.

Swimlanes

The primary modelling elements, mentioned above, can be grouped by making use of swimlanes. This grouping can be performed at two levels: between participants and within participants. A participant can be considered to be a business entity, and is represented by a pool. The grouping of elements between participants is thus achieved by making use of pools. Processes can be modelled within pools

(10)

Page | 10 but a pool can also be a “black box” and thus not contain any internal details. The processes that are contained within a pool can be organized and categorized by making use of lanes. Lanes divide a pool and extend over the entire length of the pool. Lanes can be used to organize the activities in a pool according to internal roles, systems or internal departments. The BPMN symbols that are used for these elements are shown at the left side of Figure 3.

Artifacts

Additional information about a process can be provided by making use of artifacts. Two standardized artifacts are present, but new artifacts can be added as needed. The first artifact is that of a group. A group enables the modeler to group and highlight elements that are within the same category. These categories can be used for documentation or analysis purposes. Groups do not affect the sequence flow of the process. As groups are not activities, they cannot be connected to other objects by sequence or message flows. Groups are furthermore allowed to cross pool and lane boundaries. The second artifact is a text annotation, which can be used by a modeler to provide additional textual information to the reader of a BPMN diagram. A text annotation can be connected to a specific object by making use of an association. Text annotations do not affect the process flow. The BPMN symbols used to represent these two artifacts are shown at the right side of Figure 3.

2.1.2 BPMN Diagrams

In general, business processes could now be modelled using the BPMN elements that were introduced above. A business process would primarily exist of a combination of several activities, events, and gateways that are related and linked to each other by making use of sequence flows.

Modelling business processes, however, is not as simple as this. Business processes can namely be modelled in BPMN from two basic perspectives. One perspective focuses on the detailed procedures that are internal to a specific organization and that together compile a business process. The second perspective on the other hand focuses on the interactions and behavior between participants. Business processes can be modelled from each of these two perspectives using one or more sub-models that are part of BPMN.

The internal point of view can be modelled using the processes (or orchestration) sub-model. Private business processes best describe these processes that are internal to an organization. As the focus of the private business processes is on the internal steps needed to be taken to complete the process, these processes are usually quite detailed. These private business processes can either be executable or non-executable. Executable processes are modelled with the goal of execution,

(11)

Page | 11 according to the BPMN semantics, in mind. Non-executable processes, on the other hand, have been modelled to provide an overview of the process behavior and thus are less detailed than executable private business processes. A private business process will, when making using of swimlanes, be contained within a single pool and the process flow cannot cross the pool boundaries.

An example of an executable private process is shown in Figure 4. This process represents the shipment process of a hardware retailer, which covers the steps that the hardware retailer has to take before an order can be shipped (Object Management Group, 2010). The process is executed internally at the hardware retailer and therefore takes place in one pool. Different departments, however, are involved in this process and therefore multiple lanes are used. The use of a single pool restricts the model and causes that the communication between the different departments cannot be modelled within this model (Object Management Group, 2010).

The interaction point of view can be modelled using three sub-models, two of which model the flow of messages and one of which models the expected behavior of participants. The processes sub-model, and specifically the public processes, as well as the collaboration sub-model, model the flow of messages while the choreography sub-model models the expected behavior of participants.

A public process models the interactions, in the form of message flows, between a private business process and another process or participant, usually a “black box”. A public process is far less detailed than a private process as the public process only models the activities that are used to communicate to the other participant instead of all the internally performed activities. These modelled activities can be seen as touch-points between different participants.

A collaboration models the interaction between two or more participants (business entities), which are represented by pools. A collaboration is very similar to a public process as the collaboration can be viewed as the communication of two or more public processes with one another. The

collaboration thus shows the message exchange between participants by modelling the message flows between the different pools. A collaboration is less detailed than a private process as only the

message exchange at touch points between the different processes of the participants are modelled. A pool can be filled with modelled processes but can also be empty, and thus be a “black box”.

Figure 4 - An example (executable) private process which represents the shipment process of a hardware retailer. (Trisotech, 2012b)

(12)

Page | 12 An example of a collaboration model is shown in Figure 5. This collaboration models the interaction between two participants, namely the pizza customer and the pizza vendor, which are depicted as different pools (Object Management Group, 2010). The collaboration model furthermore simultaneously shows, in a somewhat summarized way, the tasks that are associated with the

handling of a pizza order for each of the participants. Note that it is not necessary for the collaboration diagram that the participants are different business partners, participants can also be identified in one company and consists, for example, of different departments, teams or even single workers (Object Management Group, 2010).

The choreography models the interactions between participants by defining their expected behavior. The focus of a choreography is on the exchange of information between participants and it can be seen as an extension of the collaboration sub-model that was described above (IBM

Corporation, 2013). Instead of being modelled within a pool, a choreography is modelled between pools. This also entails that there is no single participant responsible for the modelled process. Just like in a private business process, the choreography consists of a network of flow objects. The main distinctive characteristic of the choreography, however, is that its activities are modelled as interactions, representing a set of message exchanges that involve two or more participants. The graphical representation of these activities differs somewhat from the graphical representation of the activities used in the collaboration and process sub-models. Besides containing the name of the activity, the graphical representation of a choreography activity also displays the names of the participants in the particular activity and indicates which of the participants initiated the particular activity.

Figure 5 - An example collaboration model which represents the interaction between the two participants in handling a pizza order. (Trisotech, 2012c)

(13)

Page | 13 An example of a choreography model is shown in Figure 6. This collaboration model shows the tasks that are dedicated to the communication between the different process participants in handling an incident from a customer; all internal steps that are taken by different participants and have nothing to do with communication between the participants are not shown in this model (Object Management Group, 2010). In these choreography diagrams, activities consist of three parts. The upper and lower part of an activity represent the participants of the activity whereas the activity name is shown in the middle part of the activity. A white background of a participant or message indicates that the particular participant or message has an initiating role in the activity, whereas a grey

background indicates that the particular participant or message has a non-initiating role in the activity.

2.2 Workflow Patterns

A business process that is modelled in a detailed way that can be executed by a workflow

management system can be referred to as being a workflow (model) (Workflow Patterns Initiative, 2011c). A workflow model consists of a number of tasks which are connected in the form of a directed graph (Workflow Patterns Initiative, 2011c). Workflows can thus be seen as similar to the business process models which can be generated using BPMN.

During the modelling of workflows, various generic constructs might be used recurrently, both across different tools and standards for modelling workflows, and across different models in a

particular standard. Russell et al. (2006) refer to these kind of constructs, which are included in

different tools and standards in response to modelling requirements, as workflow patterns. Depending on the point of view from which a business, and its processes, are viewed, four different categories of workflow patterns can be distinguished (Workflow Patterns Initiative, 2011b). The control-flow patterns focus on recurrent constructs in the sequencing of tasks and activities, and mainly deal with parallelism, choices and synchronization of threads. The data patterns focus on recurrent constructs while representing, using, and interchanging of data in business processes. The resource patterns focus on recurrent constructs in the allocation of resources in business processes. Lastly, the exception handling patterns deal focus on recurrent constructs in dealing with errors in business processes. The focus of this research will be on the control-flow perspective.

Figure 6 - An example choreography model which represents the tasks that are dedicated to the communication between the different process participants in handling an incident from a customer. (Trisotech, 2012a)

(14)

Page | 14

2.2.1 Control-Flow Patterns

In 2003, twenty workflow patterns have been identified by Van der Aalst, Ter Hofstede, Kiepuszewski, et al. These patterns can be categorized into six categories. Some of these 20 patterns, however, contain ambiguities in their interpretation and implementation which can be removed by a more precise (i.e. restrictive) description of these particular patterns. Furthermore, some specific situations were not covered by these twenty patterns. Therefore, the original twenty control-flow patterns were reviewed and augmented with 23 new patterns, in 2006 by Russell et al. This brings the total to 43 control-flow patterns, which are categorized into eight categories (Workflow Patterns Initiative, 2011a). In order to preserve the clarity of the main text of this thesis, each of these categories, and the control-flow patterns they contain, is discussed in “Appendix A: Control-Flow Patterns”, instead of in the main text. References to control-flow patterns are indicated in the main text by a capitalized name (i.e. “Structured Synchronizing Merge”), which is either preceded or succeeded by the word “pattern” somewhere in the (part of the) sentence where the capitalized name occurs. In case we refer to a control-flow pattern in the remainder of the main text, we advise you to refer to Appendix A to get a brief overview of this pattern. It is assumed that each of the control-flow patterns operates in a model that is safe, unless otherwise indicated. A safe model comprises that each place in the model can contain at most one token at a time.

2.3 Ambiguous Workflow Patterns

In the previous section, an understanding of the workflow patterns, and especially of the control-flow patterns, was formed. This set of patterns forms the basis for the identification of the ambiguous patterns. Before proceeding with the identification of those ambiguous patterns, we need to define the concept of an ambiguous pattern. To the best of our knowledge, there is no clear definition of ambiguous patterns in literature. What we, however, do know is that the workflow patterns can be represented in a particular BPML by making use of the constructs of that BPML (Russell, et al., 2006). Based on this fact, we can thus infer that, in case a workflow pattern is ambiguous, its composing elements, the BPMN constructs, must be ambiguous as well. Based on this fact, we can thus define an ambiguous BPMN pattern as follows:

“A workflow pattern that is composed of one, or more, ambiguous BPMN constructs.” Using this definition, only workflow patterns that are either partially or fully supported by BPMN are considered during the identification of ambiguous patterns. This is due to the fact that workflow patterns that are not supported by BPMN, cannot be considered as ambiguous as these patterns cannot be represented in BPMN.

The focus thus has to be on ambiguous BPMN constructs, which compose the ambiguous workflow patterns. To this end, Börger (2012) has provided an overview of the shortcomings and problems of the BPMN 2.0 standard. One of the problems in the BPMN 2.0 standard that he has pointed out is “the numerous ambiguities in the descriptions and underspecifications of semantically relevant concepts” (p. 307). He indicates that those ambiguities are mainly caused by a lack of

precision and a lack of formal and / or clear semantics of numerous concepts and constructs. This can, in turn, lead to issues that arise prior or during run-time. One of these issues, for instance, is a

(15)

Page | 15 deadlock2_{that arises due to the fact that a particular gateway is waiting infinitely for a token to arrive,} which, however, never arrives. Another issue that can arise due to the lack of clear and / or formal semantics, is that a particular pattern cannot completely be converted to executable code due to uncertainty about how certain attributes of particular BPMN constructs shall be specified in order to achieve the behavior that is expected from the construct’s informal description.

We now proceed with the identification of ambiguous constructs. As was indicated above, ambiguous BPMN constructs are characterized by a lack of formal and / or clear semantics and based on this the ambiguous constructs are identified. Based on the ambiguous constructs we can easily identify the ambiguous workflow patterns by checking which of the control-flow patterns make use of the ambiguous BPMN constructs. Those patterns that make use of an ambiguous construct are identified as ambiguous workflow pattern.

One ambiguous BPMN construct that clearly comes forward from the literature is the Inclusive OR-join gateway. According to the BPMN 2.0.2 specification (Object Management Group, 2013), this converging gateway synchronizes, and thus waits, for all tokens produced upstream on all incoming branches that expect a token to arrive. When it is known that no token will arrive along a particular incoming branch, the OR-join does not wait for this branch. It is, however, not clear what is considered within the range of the term “upstream”, in terms of the process model (Dijkman, Dumas, & Ouyang, 2008). The usage of the term “upstream” indicates that the OR-join has a non-local semantics and also should consider the presence of tokens out of its immediate vicinity, possibly even far away in the model (Dumas, et al., 2007; Gruhn & Laue, 2007). These non-local semantics may cause a deadlock during the execution of this construct. Such a deadlock occurs whenever the OR-join is part of a loop and the firing of the OR-join depends on whether the OR-join will eventually fire. This leads to a so called vicious circle (Dijkman, Dumas, & Ouyang, 2008) in which the OR-join keeps waiting for itself and the sequence flow will not progress beyond the OR-join. Another case in which such a vicious circle occurs is described by Van Der Aalst, Desel, and Kindler (2002). They describe a situation in which two OR-joins wait for each other to be enabled. This situation is illustrated in Figure 7. In this situation “Inclusive Gateway 1” waits until it receives a token from “Parallel Gateway 2” as the second branch will, eventually, become active (once it receives a token from the first branch). Similarly,

2_{A deadlock is characterized by the fact that a process instance cannot continue working, while it has not}

reached its end (Awad & Puhlmann, 2008).

Figure 7 - The Vicious Circle, as described by Van Der Aalst, Desel, and Kindler (2002), due to two OR-Joins waiting for each other to fire.

(16)

Page | 16 “Inclusive Gateway 2” waits until it receives a token from “Parallel Gateway 1” as the first branch will, eventually, become active (once it receives a token from the second branch). The two inclusive gateways are thus waiting for each other to be triggered and are thus deadlocking, causing the sequence flows not to progress beyond the inclusive gateways. As the use of the OR-join construct might cause problems during the execution of a BPMN model due to its non-local semantics, the OR-join construct can be considered as being ambiguous. This leads to the workflow patterns that make use of the OR-join constructs being considered as ambiguous as well. The workflow patterns that we thus can consider as being ambiguous, and can be represented using BPMN, are the Structured Synchronizing Merge pattern and the Cancelling Discriminator pattern.

The Object Management Group (2013) has stated in the specification of the BPMN 2.0.2 standard that the Complex Gateway “uses the synchronization semantics of the Inclusive (Join) Gateway […] to determine whether it needs to wait for additional tokens before it can reset” (p. 294). As was indicated in the previous paragraph, those synchronization semantics of the Inclusive Join Gateway are non-local, which causes that construct to be ambiguous. As the Complex (Join) Gateway uses those same, non-local, semantics, this construct is considered as being ambiguous as well. The control-flow patterns that utilize this construct are thus considered as being ambiguous as well. The workflow patterns that we thus can consider as being ambiguous, and can be represented using BPMN, are the Structured Discriminator, the Blocking Discriminator, and the three Partial Join variants (Structured, Blocking, and Cancelling). The ambiguity of these patterns is reinforced by the fact that these patterns can usually not be completely converted executable code due to uncertainty about how the IncomingCondition expression on the Complex Join Gateway shall be specified as has been indicated by Russell, et al. (2006). As these patterns cannot be correctly executed in BPMN, due to the inconsistency in converting the pattern to executable code, they can be considered as being

(17)

Page | 17

3 Process Retrieval and Modelling

Central to this phase of the research is the retrieval and the modelling of 15 rather complex business processes from the IT consultancy company The BrainCap Group. Our focus is mainly on the rather complex business processes since simple processes most likely do not contain any ambiguities and thus do not provide any added value to this research.

The BrainCap Group is an IT Consultancy company focusing on consultancy for companies with a specific demand for information technology that support their businesses. The BrainCap Group has 150 employees and has a variety of clients from various industries. Some of their national and

international clients are: IBM, ABN AMRO Bank, Tata Steel, ING Bank, Unilever, ECT, Westland Utrecht Bank, RDW, KLM, Cybermak Kuwait, Ehosting, National Bank of Dubai, Saudi Aramco, DU Telecom Dubai, and Dunia (FFH).

Last year, The BrainCap Group also acquired the IT company Evologics. Evologics’ area of focus is on Advanced Planning and Scheduling (APS) systems, Enterprise Resource Planning (ERP) systems, Governance, Risk Management and Compliance (GRC) systems, and Business Process Management (BPM) systems. The solutions that Evologics provides with these systems can be standard off-the-shelf or tailor-made, depending on the client’s need. Besides solutions, Evologics also provides products and services to their client. The research will take place in the Evologics-branch of The BrainCap Group and thus will mainly focus on their business processes.

In Section 3.1, we present the method that we used to retrieve and model the business processes. This is followed by a description of the results of the process retrieval and modelling in

Section 3.2. Lastly, a validation of the retrieved and modelled processes is performed in Section 3.3.

3.1 Method

The business processes of Evologics could have been retrieved in either a direct or indirect fashion. In the direct fashion, the business processes would have been obtained directly from the company in the form of available process diagrams and process descriptions. The indirect fashion, on the other hand, would have required administering interviews with Evologics’ employees to get an overview of the duties and tasks that are performed as part of particular business processes. These interviews then should, subsequently, have been converted into process diagrams. The indirect fashion would thus require an additional step, compared to the direct fashion. The direct method was favored over the indirect method as the direct method would, likely, be more reliable than the indirect method due to the omission of the conversion step. This conversion step might introduce errors and inconsistencies into the business process diagrams, whereas these errors are prevented when the direct method would be applied due to the fact that the business process diagrams are directly provided by the company. Omission of the conversion step thus would lead to less errors and inconsistencies in the business processes, and therefore the direct method can be considered as being more reliable than the indirect method. Business processes thus first were attempted to be retrieved by making use of the direct method. In case this method not did not yield sufficient business processes, additional processes could have been retrieved by making use of the indirect method.

For the retrieval part, by making use of the direct method, to succeed, the available business process diagrams within the company had to be identified. To this end, we were provided with all available documents containing any form of business processes diagrams. The provided processes had different focus areas ranging from development to order handling, and from bug fixing to change management. We were especially interested in one document. This document covered the entire project management process, for APS and ERP systems, and included the processes that described the

(18)

Page | 18 sale of a solution, the delivery of a solution, and the maintenance of a solution. We considered this process as being interesting for this research as it provided a coherent overview of the core activities of the business, which are interesting to identify. This project management process covered 17 processes in total, which were distributed as follows: seven processes related to the sales part of the process, eight processes related to the delivery part of the process, and two processes related to the maintenance part of the process. As the sales and delivery parts of the process together covered the required 15 processes, and these processes were sufficiently interesting and complex, it was decided to focus on the sales and delivery parts of this project management process. There was, however, one problem to be overcome: the sales part of this process was not modelled in any diagram at all, whereas the delivery part was almost completely covered. We were, however, still provided with the missing diagrams by the company so that they provided a facilitating role in the research. The original process diagrams of the project management process can be downloaded from:

http://bit.ly/1mhrh8z.3

The received process diagrams are modelled at different levels of detail. Whereas a Level 0 process diagram provides a general overview of the complete process, Level 1 and Level 2 diagrams are more detailed. A Level 1 process diagram provides a general overview of a process and may contain sub-processes. A Level 2 process diagram is even more detailed and, on the other hand, cannot contain any sub-processes. The objective was to obtain as much Level 2 process diagrams as possible, because these models make use of more constructs and thus are more likely to contain ambiguous patterns. When these Level 2 process diagrams were not available, however, the Level 1 process diagrams were used as an alternative.

The received process diagrams were not modelled according to any standard. As this research uses the BPMN standard for business process modelling, these process diagrams needed to be mapped to BPMN models, while preserving the (business) semantics of the processes. Based on an observation of the received process models, a mapping from the visual constructs and patterns used in the received business process diagrams to the visual constructs and patterns in BPMN was

developed. This mapping is available in “Appendix B: Business Process Diagram Mapping”.

Applying the developed mapping to the received process diagram resulted in an initial BPMN version of the process diagrams. This initial version, as well as subsequent versions, of the process models was modelled by making use of Microsoft Visio 2013 (Professional Plus) with the BPMN 2.0 Modeler for Visio extension4_{. This initial version, however, still was quite raw and did not properly} mirror the intention of the processes from the original diagrams at certain points. At some points, the sequencing of tasks was not completely clear, which raised questions at the researcher’s side.

Furthermore, we were uncertain about the use of certain BPMN constructs in particular situations, and whether their contextual conveyed meaning matched their intended (business) meaning. It was therefore required to refine the initially mapped processes. This refinement proceeded in an iterative nature: first we posed a set of questions, related to the business processes itself as well as to the contextual conveyed meaning of certain BPMN constructs, to domain experts in the field of the business process, at Evologics, and in the field of BPMN, at the University of Amsterdam, respectively. These questions were subsequently answered by each of the domain experts and the process

diagrams were modified according to their answers. In some cases new questions, however, arose

3_{Please note that, due to business secrecy, the PDF-files containing business process diagrams have been}

password encrypted. Access can be requested by contacting the researcher at hayojay93@gmail.com. We highly recommend you to download the files instead of viewing them in the default Google Drive PDF viewer.

(19)

Page | 19 based on the provided answers to the previous set of questions or based on the revised process models. If this was the case, a new set of questions was posed to the domain experts, which were subsequently answered, and may again have led to new questions. This iterative refinement continued until all questions were answered, no new questions arose, and the domain experts agreed with the business process diagrams. The questions, that were posed to the business process domain expert at Evologics and the BPMN domain expert at the University of Amsterdam, and corresponding answers, are available in “Appendix C: Process related Questions” and in “Appendix D: BPMN related Questions” respectively.

3.2 Results

Iteratively refining, and incorporating all the feedback into the initial BPMN version of the business process diagrams resulted in a final version of the business process models (and diagrams) that was approved by both domain experts. The process retrieval and modelling yielded 25 business process diagrams. These business process diagrams represent 21 business processes, two master processes capturing the relationships between the business processes, and two sub-processes that provide a more detailed view of particular activities within a business process.

As mentioned in the previous section, only the processes in the sales and delivery parts of this project management process were covered. The sales part covered seven business processes and resulted in a total of ten business process diagrams. Those diagrams included one master process that represents the relationships between the different business processes within the sales part, and two sub-processes. The business process models (diagrams) can be downloaded from:

http://bit.ly/1lXFT2F. 5

The delivery part of the project management process covered 14 business processes and resulted in a total of 15 business process diagrams. Those diagrams included one master process that represents the relationships between the different business processes within the delivery part. The business process models (diagrams) can be downloaded from: http://bit.ly/1lfzQAo.5

3.3 Validation

It is important to make sure that the BPMN business process diagrams, which ultimately resulted from the modelling process, represent the processes that are performed in practice, and thus represent the original business process diagrams, correctly and in an appropriate manner. Furthermore it has to be ensured that the modelled processes do not contain any syntactical errors. The results of the process retrieval and modelling thus have to be validated.

This validation thus consists of two parts: whereas the first part checks the process diagrams for syntactical errors, the second part checks whether the modelled BPMN business processes correctly represent the processes that are performed in practice. The first part of the validation was performed by validating the models with the built-in validator of the BPMN 2.0 Modeler for Visio extension for Microsoft Visio (2013). Validation errors that came up were fixed and, eventually, all business process models were successfully validated and thus contained no errors. As was indicated in the “General” sub-section of Appendix D, on the BPMN related questions, sub-processes that were modelled as collaboration diagrams were converted to call activities due to the fact that the validator threw errors about the fact that sub-processes could not be modelled as collaborations.

(20)

Page | 20 The second part of the validation was performed by domain experts from Evologics. These domain experts checked the business process models for inconsistencies, missing tasks, and correct routing of the sequence flows. Each set of processes (delivery and sales) was validated by one domain expert from Evologics with a function in the particular field (delivery or sales) to which the processes apply. The validation took place through a Skype-call with the domain expert. Prior to the Skype-call the domain expert was informed about the purpose of the research and was provided with the process models it was supposed to validate as well as with the file containing the original process diagrams. During the Skype-call we first introduced the subject of the research, provided a brief introduction to the BPMN standard by explaining the core three elements, and indicated the purpose of the validation and the manner in which the validation would take place. We subsequently provided each of the modelled processes with an explanation and the domain expert subsequently checked the processes. The domain expert either directly approved the process or provided feedback on the particular business process by explaining what was missing or what was incorrectly modelled. Subsequently we incorporated the provided feedback into the process models. Once all process models had been validated, the domain expert was requested to sign a form that formally confirmed that the validation was successfully performed. These forms, both in signed and unsigned variants, are available in “Appendix E: Process Validation Forms”. Not all processes in each set were directly

validated. Provided feedback was incorporated into the processes to which the feedback applied. Eventually, all processes (in each of the sets) were successfully validated by their respective validators.

(21)

Page | 21

4 Ambiguity Identification and Resolution

In this section, we deal with the identification and resolution of the ambiguities, which were discussed in Section 2.3, in Evologics’ business processes that were modelled in the previous chapter. In Section 4.1, we identify the ambiguities in the modelled business processes. In Section 4.1.1, we present the method that we applied to identify the ambiguities. This is followed by a description of the identified ambiguities in Section 4.1.2. Section 4.2 covers the resolution of the identified ambiguities. To this end, we first discuss the related work on this topic in Section 4.2.1. This is followed by the

presentation of our method to resolve the ambiguities, in Section 4.2.2, and a description of the results of the ambiguity resolution, in Section 4.2.3. Lastly, the proposed solutions are validated in

Section 4.2.4.

4.1 Ambiguity Identification

This section presents how we identified the ambiguous processes and patterns in the set of modelled business processes. Furthermore, we present the results of the ambiguity identification and motivate for each of the identified ambiguities, why it is ambiguous.

4.1.1 Method

As discussed in Section 2.3, two BPMN constructs form the root-cause of the ambiguity. These two constructs are the Inclusive Join Gateway and the Complex Join Gateway. Furthermore, we discussed that due to the inherent ambiguity of these constructs, the control-flow patterns utilizing either, or both, of these constructs are considered as being ambiguous as well.

Based on this knowledge the ambiguous business processes in the set of modelled business processes and, more specifically, the ambiguities within those ambiguous business processes, were identified. Ambiguous processes, as well as the ambiguities itself, were thus identified by checking each of the modelled business processes for the occurrence of Inclusive Join Gateways and Complex Join Gateways. Whenever such a gateway occurred in a business process, the business process was marked as containing an ambiguity and thus as being ambiguous. The gateway itself was designated as the ambiguity in the business process.

4.1.2 Results

Each of the modelled business processes was checked for the occurrence of ambiguous BPMN constructs. This resulted in seven business process models being marked as ambiguous. These ambiguous business process models can be downloaded from: http://bit.ly/1muFML1.6_{Four of these} models modelled processes in the sales part of the project management process whereas the other three modelled processes in the delivery part of the project management process. Two out of the four ambiguous sales models covered sub-processes. Those seven models together contained nine

ambiguous constructs, all of which were Inclusive Join Gateways. Seven of those Inclusive Join Gateways could be matched to a prior Inclusive Split Gateway and thus occurred in a structured context. These seven Inclusive Join Gateways were thus classified as the Structured Synchronizing Merge control-flow pattern. The other two Inclusive Join Gateways did not occur in a structured context. Furthermore, two of the ambiguous process models exposed inappropriate behavior as they either did not properly capture the intention of the process in practice or violated a particular condition that must be met in order to allow the use of a pattern. Besides resolving the ambiguity,

(22)

Page | 22 those processes required a redesign. This redesign had to be performed in such a way that the

inappropriate behavior does not arise on any occasion in the redesigned process.

The remainder of this section provides a brief description of both the ambiguous processes as well as the ambiguity in each of those processes.

S3: Initial Deal Review

The “Initial Deal Review” process (S3) covers internally reviewing the potential that a particular deal with a prospect offers the company. The initial deal review (IDR) is performed through a meeting. Depending on the project type, different participants attend this meeting. For an OT2-project only the Sales and Development departments are invited whereas the Maintenance and Legal departments are invited as well for OT3-projects. After the IDR-meeting, the Sales department assesses the potential of the deal for the company according to the SCOTSMAN methodology. This methodology assesses a prospect on eight aspects and thereby qualifies it either as a prospect which is worth converting into a sale or as a prospect that is not worth converting into a sale (Stone, 2012). The SCOTSMAN

methodology assess a prospect on the solution it demands, the competition that the developing company faces, the originality of the solution, the timescale on which the prospect demands the solution, the size of the required solution, the money that the prospect has available, the authority of the prospect within his / her own company, and the needs of the prospect (Stone, 2012). In case a prospect is considered as being attractive enough, the next process (S4 – “Develop Solution”) will start. In case the prospect, however, is not being considered as attractive, the prospect will be turned down as the project is not attractive enough for the company.

As, depending on the project type, different guests are invited to attend the IDR-meeting, an Inclusive Split Gateway was used to split the control flow. After the meeting has completed, the Sales department has to check the SCOTSMAN coverage for the potential deal, and therefore a merge, of branches that diverged prior to the meeting, is required prior to this check. As the Inclusive Split Gateway can activate different branches, but not necessarily has to activate all, and these active branches subsequently have to be merged, an Inclusive Join Gateway is required to merge the different branches. This Inclusive Join Gateway matches a prior Inclusive Split Gateway, thus the workflow pattern that matches this pattern is the Structured Synchronizing Merge. Both this BPMN construct and this workflow pattern, however, are ambiguous and therefore this process was marked as ambiguous.

S7: Gain Commitment

The “Gain Commitment” process (S7) covers requesting whether the prospect decides to place an order or decides to decline the order. If the prospect decides to order, the contract is subsequently prepared and signed by the prospect. If the prospect, on the other hand, declines the order, the reason(s) for declining the order is / are requested and analyzed. Subsequently, corrective actions are taken, depending on the type(s) of reason(s) that the prospect provides, to still try to persuade the prospect to place the order. These reasons can be related to the proposed solution or to the client, or, in case of multiple reasons, they can be related to both the solution and the client. As a prospect can provide multiple reasons, the use of an Inclusive Split Gateway is justified. If any of the corrective actions that are taken, fails, it is not attractive enough for the company to close the deal and the prospect will be turned down. Whenever the corrective actions do succeed, this leads to the end of the “Gain Commitment” process, and, depending on the type of reasons that were given, (a) different process(es) is / are initiated, which is shown in the “Sales Overview” master process.

As an Inclusive Split Gateway was used to direct the control flow to the different types of reasons that the client can provide, an Inclusive Join Gateway was used to subsequently merge the

(23)

Page | 23 different threads of control prior to the end event. This Inclusive Join Gateway matches a prior

Inclusive Split Gateway, thus the workflow pattern that matches this pattern is the Structured Synchronizing Merge. The Inclusive Join Gateway, however, causes ambiguity and therefore this process was identified as being ambiguous.

A second issue that arises in this process, is that this Structured Synchronizing Merge pattern does not necessarily operate in a safe context. Let’s exemplify this with an example in which there are two reasons for declining an order, one of which is client related and the other of which is solution related. If the subsequent corrective actions both fail, two tokens will traverse through the same branch, passing through the exit activity and subsequently arriving at the Inclusive Join Gateway, thus causing an unsafe situation as the Inclusive Join Gateway contains two token in a single branch. This gateway, however, can only operate in a safe context according to the Structured Synchronizing Merge pattern, implying that only one token may be present in each branch at any time. The safe context is thus violated in case the corrective actions from both categories fail. This violation is mainly due to the fact that the modelled process inappropriately captured the behavior of the process in practice. In practice the deal is not closed and the prospect is turned down whenever any corrective action fails. It is not relevant to perform any subsequent activities after any of the corrective actions has failed, as the deal will not be closed anyway. The process can thus be terminated whenever any corrective action fails. In order to resolve the unsafe context and appropriately capture the behavior of the business process, this business process shall thus be redesigned in such a way that this termination is incorporated into the process model.

S7.1: Take Appropriate Internal Corrective Action(s)

The “Take Appropriate Internal Corrective Action(s)” process (S7.1) covers the performance of internal corrective actions which are taken when a prospect declines to place an order based on solution related reasons. Depending on the solution related reasons that the prospect provides, different internal corrective actions are taken. Any combination of reasons, and thus corrective actions, can occur and therefore the use of an Inclusive Split Gateway is justified. Before the process is ended, all internal corrective actions that are taken, which can be any combination, have to be completed. Therefore a corresponding Inclusive Join Gateway was used to merge, and synchronize, the branches that are enabled by the Inclusive Split Gateway. This Inclusive Join Gateway matches the prior

Inclusive Split Gateway and therefore the workflow pattern that matches this pattern is the Structured Synchronizing Merge. This join construct and this particular workflow pattern, however, are both ambiguous and therefore this process was identified as being ambiguous.

S7.2: Take Appropriate External Corrective Action(s)

The “Take Appropriate External Corrective Action(s)” process (S7.2) covers the performance of

external corrective actions which are taken when a prospect declines to place an order based on client related reasons. Depending on the client related reasons that the prospect provides, different external corrective actions are taken. Any combination of reasons, and thus corrective actions, can occur and therefore the use of an Inclusive Split Gateway is justified. Before the process is ended, all external corrective actions that are taken, which can be any combination, have to be completed. Therefore a corresponding Inclusive Join Gateway was used to merge, and synchronize, the branches that are enabled by the Inclusive Split Gateway. This Inclusive Join Gateway matches the prior Inclusive Split Gateway and therefore the workflow pattern that matches this pattern is the Structured Synchronizing Merge. This join construct and this particular workflow pattern, however, are both ambiguous and therefore this process was identified as being ambiguous.

(24)

Page | 24

D1: Startup Meeting

The “Startup Meeting” process (D1) covers the preparations that are performed within the organization to start a project. One of the activities that is performed during this process is the preparation of a first draft product document. This is done in parallel to scheduling a startup meeting and to the preparation of the first product initiation document. The first draft product document is, however, only prepared for an OT3-project. This was indicated by making use of an Exclusive Split Gateway prior to the Parallel Split Gateway, so that the first draft product document is only prepared for OT3-projects. This situation, however, causes problems at the merging point of these three branches in case a Parallel Join Gateway is used. The Parallel Join Gateway will namely deadlock in case the first draft document is not prepared, due to the fact that it will only receive two out of the three tokens at the gateway. In order to circumvent this deadlock and only synchronize the active branches, an Inclusive Join Gateway was thus used at this point in the process. This join construct, however, does not occur in a structured context as there is no matching Multi-Choice pattern in this process. The join construct thus corresponds to the General Synchronizing Merge pattern, which is not supported in BPMN. Therefore, and due to the ambiguous nature of the Inclusive Join Gateway, this process was identified as being ambiguous and requires a redesign.

D5: Operational Handover

The “Operational Handover” process (D5) covers meeting the client to discuss the delivery of the solution and, eventually, hand over the solution to the client. However, in case the client addresses issues with regard to the solution, the solution will not be delivered prior to those issues being resolved and the client does not address any other issues at a subsequent meeting. Issues are divided into three categories: 1) optimization issues, which require minor changes to the solution to optimize it; 2) “out of scope” issues are issues that do not comply with the scoping document and thus require additional work, which is performed after the regular project has finished; and, 3) any other issues that do not fit into the previously two defined categories. As the client can raise multiple issues, and any combination of issue types can occur, the use of an Inclusive Split Gateway is justified. Once all issues that are addressed, which can be of any combinations of types, are resolved, the client will be met again and delivery will be discussed. This continues until the client accepts the solution and no further issues are addressed. The use of an Inclusive Join Gateway at the merging point is thus

justified. This Inclusive Join Gateway would then match the prior Inclusive Split Gateway and therefore the workflow pattern that matches this pattern is the Structured Synchronizing Merge.

In case an issue of the “other” type is addressed by a client, the department responsible for the particular issue has to be determined, which is either the Sales or Development department. The responsible department subsequently has to resolve the issue. In case the client addresses multiple “other” issues, either Sales or Development might be responsible for all the issues, or Sales might be responsible for some of the issues and Development is responsible for the other issues. The use of an Inclusive Split Gateway, therefore, is justified at this point. A verification of the solutions is performed, after each department has resolved the issues it was responsible for. As any combination of

responsible departments might occur, the use of an Inclusive Join Gateway to merge the branches prior to this verification is justified. This Inclusive Join Gateway matches the prior Inclusive Split Gateway and therefore the workflow pattern that matches this pattern is the Structured Synchronizing Merge.

When the solutions are approved, the control flow continues on to the subsequent Inclusive Join Gateway at which it needs to wait for the optimization and “out of scope” issues, if any, to be

Addressing Ambiguous BPMN Patterns: A Case Study at The BrainCap Group