BPMN 2.0 E-Book

Thomas Allweyer

• Herausgeber: Books on Demand
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch
• Veröffentlichungsjahr: 2016

Seitenzahl: 216

Beschreibung

BPMN (Business Process Model and Notation) is the established standard for business process modeling. Only a few years after its first publication, it has gained widespread adoption in practice. All important modeling tools support BPMN diagramming. It is possible to create business-oriented diagrams, but also technical models for process execution in business process management systems (BPMS). This book provides a stepwise introduction to BPMN, using many examples close to practice. Starting with the basic elements for modeling sequence flow, all BPMN 2.0 diagrams are presented and discussed in detail. You will gain a profound understanding of the complete notation, and you will be able to make correct use of the different language elements. In the second edition, a collection of useful modeling patterns has been added. These patterns provide best-practice solutions for typical problems arising in the practice of process modeling.

Leseprobe

Contents

BPMN – A Standard for Business Process Modeling

1.1 Why a Notation?

1.2 Development of BPMN

1.3 Contents of BPMN 2.0

1.4 Business-Level Models and Executable Models

1.5 About this Book

BPMN by Example

2.1 A First BPMN Model

2.2 BPMN Constructs Used

2.3 Sequence Flow Logic

2.4 Presentation Options

2.5 Appending Additional Information

Gateways: Splitting and Merging

3.1 Exclusive Gateway

3.2 Parallel Gateway

3.3 Different Process Instances at a Parallel Join

3.4 Inclusive Gateway

3.5 Complex Gateway

Splitting and Merging without Gateways

4.1 Splitting without Gateways

4.2 Merging without Gateways

4.3 Modeling with or without Gateways?

Collaborations

5.1 Example of a Collaboration

5.2 Modeling Message Flows

5.3 Message Flows to Black Box Pools

5.4 Private and Public Processes

5.5 Multi-Instance Participants

5.6 Use of Collaborations and Sequence Flows

5.7 Modeling Message Contents

Events

6.1 Example of the Use of Events

6.2 Start Events

6.3 End Events

6.4 Intermediate Events

6.5 Event-Based Decisions

Activities

7.1 Sub-Processes

7.2 Loops and Multi-Instance Activities

7.3 Ad-hoc Sub-Processes

7.4 Types of Tasks

7.5 Calling Processes and Global Tasks

7.6 Examples of Sub-Processes and Called Processes

Handling Exceptions

8.1 Interrupting Intermediate Events

8.2 Non-Interrupting Intermediate Events

8.3 Handling of Errors

8.4 Escalation Events

8.5 Event Sub-Processes

Transactions and Compensations

9.1 Modeling of Transactions

9.2 Direct Call of Compensations

9.3 Event Sub-Processes for Compensations

9.4 Use of Exceptions, Transactions, and Compensations

Data Objects in Processes

10.1 Modeling Data Flow

10.2 Multiple Data Objects

10.3 Data and Events

10.4 Data Stores

10.5 Passing Data to Called Activities

10.6 Use of Data Objects

Choreographies

11.1 Choreography Diagrams

11.2 Choreography within Collaboration

11.3 Choreography Sub-Processes

11.4 Gateways in Choreographies

11.5 Events in Choreographies

11.6 Calling Choreographies and Global Choreography Tasks

11.7 Use of Choreographies and Collaborations

Conversations

12.1 Conversation Diagrams

12.2 Message Correlations

12.3 Hierarchies of Conversations

12.4 Calling Global Conversations and Collaborations

12.5 Use of Conversation Diagrams

Artifacts and Extensions of BPMN

13.1 Artifacts

13.2 How to Extend BPMN

BPMN Modeling Patterns

14.1 Four Eyes Principle

14.2 Decisions in Sub-Processes

14.3 Tasks with Multiple Actors

14.4 Parallel Checks

14.5 Process Interfaces

14.6 Synchronizing Parallel Paths

14.7 Requests with Different Types of Replies

14.8 Processing Cancelations

14.9 Deadline Monitoring

14.10 Dunning Procedure

14.11 Call for Proposals

Bibliography

BPMN in the Internet

Index

1 BPMN – A Standard for Business Process Modeling

1.1 Why a Notation?

In order to manage business processes, they have to be described and documented. There are various possibilities to do so. The easiest way is the usage of textual or tabular descriptions. Flow chart diagrams are quite often created using presentation and graphics software. These diagrams mostly consist of small boxes and arrows, not following a defined method.

Unfortunately, this does not meet the requirements of exactly representing extensive processes with all relevant aspects, such as splitting rules, events, organizational units, data flow, etc. For this, appropriate notations are required. A notation for graphic business process modeling defines, for example, the symbols for the various process elements, their correct meaning, as well as their possible combinations.

Thus, a notation is a standardized language for the description of business processes. Everybody, who is familiar with this language, can understand models created by someone else. Furthermore, processes can be systematically analyzed, and their dynamic behavior can be simulated based on a standardized representation.

The subject of “Governance, Risk, and Compliance” (GRC) , which is getting increasingly important, also requires a standardized and complete documentation of adequate processes that makes sure that any legal and industry-specific demands with respect to risk management, quality management, and the compliance with safety rules, etc., are met.

Models also provide a basis for the development of information systems for executing and supporting business processes. Therefore, the models need a standardized structure, and they have to contain all information relevant for system development.

System-supported processes are more and more controlled by business process management systems (BPMS). These contain process engines which directly control the workflows using appropriate process models or formal process descriptions. For this purpose, the models have to meet very strict demands because they are not converted into a computer program by a human being, but directly processed by a machine.

In the course of time, several notations for process modeling emerged. These were quite often proprietary notations of special modeling tools or workflow management systems. By now, standards for executable process descriptions have been established, such as XPDL (XML Process Definition Language) [Workflow Management Coalition 2012], and BPEL (Business Process Execution Language) [OASIS 2007]. But XPDL and BPEL are no graphic notations, and their primary area of application is the definition of automated processes.

In the area of business-oriented process modeling, the notation of the event-driven process chain (EPC) is still frequently used. This notation was rather popular before the development of BPMN. However, EPC is not a standard, and many users have replaced EPC with BPMN. Today, most EPC modeling tools also support BPMN modeling.

Other standards, such as the activity diagrams of the Unified Modeling Language (UML), did not become accepted for business process modeling in practice. Their use basically remained restricted to the area of object-oriented software design, where UML is the accepted standard.

During the last years, BPMN (Business Process Model and Notation) has become accepted as the leading standard for business process modeling. The website bpmnmatrix.github.io contains a list of more than 50 tools which support BPMN modeling. An increasing number of websites, weblogs, and publications demonstrate the growing interest in this notation (e.g. [Debevoise and Taylor 2014], [Freund and Rücker 2014], [Herrera 2015], [Silver 2012]). Even a novel on process modeling with BPMN has been published [Grosskopf et al. 2009]. A selection of interesting internet sources can be found in the annex of this book.

Many organizations are providing their process management teams with BPMN training, and they are rolling out BPMN as their organization-wide modeling standard. In the e-government standards of Switzerland, for example, the use of BPMN is recommended as a common notation [Fischli et al. 2016]. Other examples of organizations which have published their BPMN modeling guideline documents are the public administrations of Queensland (Australia) [Queensland Government 2016] and British Columbia (Canada) [Lindner 2014]. In a recent survey on the use of BPM tools, BPMN was also the most widely used process modeling notation [Lübbe and Schnägelberger 2015].

1.2 Development of BPMN

Originally, BPMN was developed by the Business Process Management Initiative (BPMI), a consortium which consisted mainly of software companies. In the beginning, the purpose was to provide a graphical notation for process descriptions expressed in BPML (Business Process Modeling Language). Comparable to BPEL, BPML was used for specifying process descriptions which could be executed by a BPMS. BPML is not being developed further anymore; it has been given up in favor of BPEL.

The first version of the BPMN specification was developed by a team lead by Stephen A. White from IBM. It was published in 2004. In the meantime, BPMI has become a part of the Object Management Group (OMG). This organization is known for several software standards, such as the aforementioned UML (Unified Modeling Language).

In 2006, BPMN version 1.0 was officially accepted as an OMG standard. After some smaller changes in versions 1.1 and 1.2, version 2.0 brought more comprehensive changes and extensions. It was published in 2011. The latest version of the specification document, version 2.0.2 was released in 2013 [OMG 2013]. The actual content has not changed from version 2.0, as only minor corrections of the text have been made. In 2013, BPMN also became an official ISO standard [ISO 2013].

The most recent version of the BPMN specification can be found here:

www.omg.org/spec/BPMN

1.3 Contents of BPMN 2.0

For the majority of BPMN users, the most important aspect is the graphical representation of the models. BPMN provides three diagram types:

Process or collaboration diagram:

In this type of diagram, the process flow can be modeled, including activities, splits, parallel flows, etc. It is also possible to show the collaboration between two or more processes with their exchanged messages. Process diagrams and collaboration diagrams are of the same diagram type. A diagram with only one process is often called process diagram, while a diagram with several interacting processes is a collaboration diagram.

Choreography diagram:

Modeling of the data exchange between different partners, similar as in collaborations. However, each data exchange is modeled as an activity, so that on this level it is possible to visualize splits, loops, etc. in order to represent complex exchange protocols.

Conversation diagram:

A conversation diagram is an overview of several partners and their interrelations.

The process or collaboration diagram is the most frequently used diagram type. Some BPMN tools and books are even restricted only to this type. Although it is undoubtedly the most important type, there are useful application areas for the other diagram types, as well. Therefore, they are also discussed in this book.

The BPMN specification explains the various notational elements not only verbally, but also defines them in a metamodel. The metamodel is documented with UML class diagrams that graphically show the features of the different BPMN constructs and their relationships. Such a metamodel is more accurate and definite than strictly verbal descriptions. The metamodel also has got additional language constructs that cannot be represented in graphic models. Such constructs are required, for example, by process engines to capture the necessary additional information for process execution.

The typical modeler does not need to work with the metamodel. Normally, he will use a modeling tool that only allows the creation of models complying with the specification, and thus with the metamodel. Therefore, it is rather the vendors of modeling tools, process engines, and similar software, who have to deal with the metamodel.

The metamodel is also the basis of an exchange format for BPMN models. Before BPMN 2.0 it was almost impossible to transfer BPMN models from one tool to another. Now, the specification defines a standardized exchange format. Many tool vendors support this standard format so that it is possible to exchange BPMN models not only between different modeling tools but also between a modeling tool and a BPMS. However, not all implementations of the exchange format are entirely consistent, so that sometimes there still may be problems and losses of some details.

For process automation, it needs to be defined how to execute each of the different BPMN elements. For this purpose, the specification defines execution semantics. The objective is to make sure that different process engines all interpret and execute a specific model in the same way. Like the exchange format, the execution semantics have not been implemented uniformly by all vendors, so there may be some differences when executing the same model on another process engine.

In spite of these occasional deviations, both the exchange format and the execution semantics are very useful, because otherwise model exchanges between different vendors‘ tools would be entirely impossible, and there would be much more differences in how process models are executed.

In the first version, the abbreviation BPMN stood for “Business Process Modeling Notation”. In version 2.0, the name was changed to “Business Process Model and Notation”. This name change emphasizes the fact that BPMN not only consists of the graphic notation, but also comprises the metamodel, the exchange format, and the execution semantics.

1.4 Business-Level Models and Executable Models

The origin of BPMN was in the field of process descriptions that can be performed by the process engine of a workflow or business process management system (BPMS). But the developers of BPMN claim that this notation allows for creating technical as well as business-level models. BPMN is supposed to be a common language of both, business experts and IT experts.

And in practice, BPMN is actually being used both for business-level modeling and for executable models. This becomes clear by looking at the tool market. BPMN is the predominant notation both for business process analysis tools and for modeling components of BPMS.

Although having a common notation, business-level models and technical models are quite different in practice. The main focus of business-level models is on the comprehension of the basic process flow. Thus, the usage of too many details is avoided. Conditions at the exits of a decision gateway are rather expressed in plain text than in exact formal terms. Exceptions and rare cases are quite often not modeled in detail but explained by notes and descriptions.

The source of some BPMN constructs is quite clearly the field of executable process definitions. BPMN contains among others special loop constructs, exception handling, and transactions. Programmers and IT-specialists are familiar with these subjects. Business process modelers, on the other hand, normally omit such items. In accordance to this, typical business-level models only comprise a subset of the whole notation.

Some BPMN experts recommend using the rather technical modeling constructs also in business-level models, to be able to show business-relevant exceptions and their handling in processes. Silver refers to the well-known 80-20 rule. He estimates that 80% of the costs, delays, and errors are caused by only 20% of the cases – the exceptions. Examples are cancelations, order changes, items out of stock, and timeouts [Silver 2012].

Those who want to apply BPMN for business process modeling should decide in advance which constructs should be used and how certain cases should be represented. It makes sense to document such decisions in the form of modeling conventions. Should the processes be modeled on a business level, and then be automated by a process engine, the way of transforming business-level models into models of executable processes has to be specified, i.e. how to complement, reorganize and detail the models.

The transition from business-oriented models to executable models is discussed in [Stiehl 2014].

1.5 About this Book

This book provides an introduction to the graphical notation of BPMN 2.0. Starting with a small example process, the basic BPMN elements for modeling simple flows are discussed. Step-by-step, the different BPMN concepts are introduced and explained using examples. The examples are generally intelligible business domain models, so that the reader does not need to have any specific IT know-how. There are only a few examples actually referring to process execution by a BPMS which are required for understanding some of BPMN’s more technical features.

Since the main focus is on the application of the notation for business-oriented process modeling, the BPMN metamodel is not part of this book, nor are the execution semantics discussed. A comprehensive discussion of the execution semantics can be found in [Kosak et al. 2014].

This book presents the entire notation. Although as described above, not for every modeling purpose all BPMN elements will be required, modeling experts still should be familiar with the entire BPMN. Only then they can reasonably select what is required and useful for their own modeling activities.

It was taken care that the discussion of the various BPMN concepts conforms to the official BPMN specification, as much as possible. Sometimes it was necessary to interpret the descriptions from the specification to some degree. Therefore, the explanations in this book always represent the author’s understanding. The author is always happy to receive feedback concerning mistakes and suggestions for improvement.

The book is an introduction to the BPMN standard. Thus, it does not discuss topics outside the standard, such as a specific methodology, the use of tools, etc. There are entirely different ways of using BPMN. Some suggestions can be found in [Silver 2012] and [Freund and Rücker 2014].

In the second edition, a new chapter has been added, containing a collection of useful modeling patterns. They provide best-practice solutions for typical problems arising in the practice of process modeling.

Apart from that, the overall structure and the main contents of the book have not been changed. The general introduction of BPMN in this chapter has been updated, as well as the bibliographical references. Several smaller improvements and minor modifications have been made throughout the book.

The book’s website can be reached at www.bpmn-introduction.com. It contains up-to-date additions, information about BPMN’s further development, as well as additional links to BPMN-related content.

2 BPMN by Example

2.1 A First BPMN Model

As a starting point, a simple BPMN process model is considered. The model of posting a job in figure 1 can be directly understood by most people who previously have been concerned with any kind of process modeling. The way of modeling is similar to well-known flow charts and activity diagrams.

Figure 1: A simple BPMN model

A business department and the human resources department are involved in the process “Post a Job”. The process starts when an employee is required. The business department reports this job opening. Then the human resources department writes a job posting. The business department reviews this job posting.

At this point, there are two possibilities: Either the job posting is okay, or it is not okay. If it is not okay, it is reworked by the human resources department. This is once more followed by the business department reviewing the job posting. Again, the result can be okay or not okay. Thus, it can happen that the job posting needs to be reviewed multiple times. If it is okay, the posting is published by the human resources department, and the end of the process is reached.

In reality, the process for creating and publishing a job posting can be much more complex and extensive. The presented example is – like all examples in this book – a simplification in order to have small and easily understandable models which can be used for explaining the different BPMN elements.

2.2 BPMN Constructs Used

Below, each element of the model in figure 1 is explained in more detail.

The entire process is contained in a pool. This is a general kind of container for a complete process. In the example above, the pool is labeled with the name of the contained process.

Every process is situated within a pool. If the pool is not important for understanding the process, it is not required to draw it in the diagram. In a process diagram which does not show a pool, the entire process is contained in an invisible, implicit pool.

Pools are especially interesting when several pools are used in order to model a collaboration, i.e. the interplay of several partners’ processes. Each partner’s process is then shown in a separate pool. This will be described in chapter 5.

The pool from figure 1 is partitioned into two lanes. A lane can be used for various purposes, e.g. for assigning organizational units, as in the example, or for representing different components within a technical system. In the example, the lanes show which of the process’s activities are performed by the business department and which by the human resource department.

Pools and lanes are also called “swimlanes”. They resemble the partitioning of swimming pools into lanes. Every participant of a competition swims only in his own lane.

The process itself begins with the start event “Employee required”. Every process usually has such a start event. Its symbol is a simple circle. In most cases it makes sense to use only one start event, not several ones.

A rounded rectangle represents an activity. In an activity something gets done. This is expressed by the activities’ names, such as “Report Job Opening” or “Review Job Posting”.

The connecting arrows are used for modeling the sequence flow. They represent the sequence in which the different events, activities, and further elements are traversed. Often this is called control flow, but in BPMN there is a second type of flow, the message flow, which influences the control of a process as well, and is therefore some kind of control flow, too. For that reason, the term “sequence flow” is used. For distinguishing it from other kinds of flow, it is important to draw sequence flows with solid lines and filled arrowheads.

The process “Post a Job” contains a split: The activity “Review job posting” is followed by a gateway. A blank diamond shape stands for an exclusive gateway. This means that from several outgoing sequence flows, exactly one must be selected. Every time the right gateway in the job posting process is reached, a decision must be taken. Either the sequence flow to the right is followed, leading to the activity “Publish Job Posting”, or the one to the left is selected, triggering the activity “Rework Job Posting”. It is not possible to follow both paths simultaneously.

The logic of such a decision is also called “exclusive OR”, abbreviated “XOR”. The conditions on the outgoing paths determine which path is selected. If a modeling tool

Figure 2: A start event creates a token

is used and the process has to be executed or simulated by a software program, then it is usually possible to formally define exact conditions. Such formal descriptions, which may be expressed in a programming language, can be stored in special attributes of the sequence flows.

If, on the other hand, the purpose of a model is to explain a process to other people, then it is advisable to write informal, but understandable, statements directly into the diagram, next to the sequence flows. The meaning of “okay” and “not okay” after the activity called “Review Job Posting” is clear to humans – a program could not make use of it.

Gateways are also used for merging alternative paths. In the sample process, the gateway on the left of the activity “Review Job Posting” merges the two incoming sequence flows. Again, this is an exclusive gateway. It expects that either the activity “Write Job Posting” or “Rework Job Posting” is carried out before the gateway is reached – but not both at the same time. It should be taken care to use a gateway either for splitting or for joining, but not for a combination of both.

The last element in the example process is the end event. Like the start event, it has a circle as symbol – but with a thick border.

2.3 Sequence Flow Logic

The flow logic of the job posting process above is rather easy to understand. In more complex models it is sometimes not clear how the modeled structure exactly is to be interpreted. Therefore, it is helpful if the meaning of the sequence flow’s elements is defined in an unambiguous way.

The logic of a process diagram’s sequence flow can be explained by “tokens”. Just as in a board game tokens are moved over the board according to the game’s rules, one can imagine moving tokens through a process model according to BPMN’s rules.

Figure 3: An activity receives a token and forwards it after completion

Figure 4: Routing of a token by a merging exclusive gateway

Every time the process is started, the start event creates a token (cf. figure 2). Since the job posting process is carried out more than once, many tokens can be created in the course of time. Thereby it can happen that the process for one job posting is not yet finished, when the process for posting another job starts. As it moves through the process, each token is independent from the other tokens’ movements.

The token that has been created by the start event moves through the sequence flow to the first activity. This activity receives a token, performs its task (in this case it reports a job opening), and then releases it to the outgoing sequence flow (cf. figure 3).

The following activity forwards the token, too. It then arrives at the merging exclusive gateway. The task of this gateway is simple: It just takes a token that arrives via any incoming sequence flow and moves it to the outgoing sequence flow. This is shown in figure 4. In case A, a token arrives from the left, in case B from below. In both cases, the token is routed to the outgoing sequence flow to the right.

Figure 5: Routing of a token by a splitting exclusive gateway

Figure 6: An end event removes an arriving token

The task of the splitting exclusive gateway is more interesting. It takes one arriving token and decides according to the conditions, to which sequence flow it should be moved. In case A in figure 5, the condition “okay” is true, i.e. the preceding review activity has produced a positive result. In this case, the token is moved to the right. Otherwise, if the condition “not okay” is true, the token is moved to the downwards sequence flow (case B).

The modeler must define the conditions in such a way that always exactly one of the conditions is true. The BPMN specification does not state how to define conditions and how to check which conditions are true. Since the considered process is not executed by software, the rather simple statements used here are sufficient. Otherwise, it would be necessary to define the conditions according to the requirements and rules of the software tool.

The token may travel several times through the loop for reworking the job posting. Finally, it arrives at the end event. This simply removes any arriving token and thus finishes the entire process (figure 6).

The sequence flow of every process diagram can be simulated in this way with the help of tokens. This allows for analyzing whether the flow logic of a process has been modeled correctly.