BPMN 2.0 - Business Process Model and Notation E-Book

Thomas Allweyer

• Herausgeber: Books on Demand
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2020

Seitenzahl: 203

Beschreibung

BPMN (Business Process Model and Notation) ist der etablierte Standard für die Geschäftsprozessmodellierung, der in nur wenigen Jahren eine weite Verbreitung in der Praxis gefunden hat. Alle wichtigen Modellierungswerkzeuge bieten die BPMN zur grafischen Darstellung betrieblicher Abläufe an. Es lassen sich sowohl fachliche Modelle als auch technisch ausgerichtete Diagramme erstellen, die als Grundlage für die Ausführung in einem Workflow- oder Business Process Management-System (BPMS) dienen. Dieses Buch führt anhand zahlreicher praxisorientierter Beispiele schrittweise in die BPMN ein. Ausgehend von den grundlegenden Elementen zur übersichtlichen Ablaufmodellierung werden nach und nach alle Diagramme der BPMN 2.0 detailliert vorgestellt. Sie lernen die komplette Notation kennen und verstehen. Sie erfahren, wie sie die verschiedenen Sprachkonstrukte korrekt einsetzen. Eine Sammlung bewährter Muster hilft Ihnen bei der Lösung typischer Fragestellungen aus der Praxis der Prozessmodellierung.

Leseprobe

Inhalt

BPMN – Ein Standard für die Geschäftsprozessmodellierung

1.1 Wozu eine Notation?

1.2 Entwicklung der BPMN

1.3 Inhalte der BPMN 2.0

1.4 Fachliche und ausführbare Modelle

1.5 Über dieses Buch

BPMN am Beispiel

2.1 Ein erstes BPMN-Modell

2.2 Verwendete Konstrukte der BPMN

2.3 Logik des Sequenzflusses

2.4 Darstellungsmöglichkeiten

2.5 Hinterlegung von Zusatzinformationen

Gateways: Verzweigungen und Zusammenführungen

3.1 Exklusiver Gateway

3.2 Paralleler Gateway

3.3 Verschiedene Prozessinstanzen an einer parallelen Zusammenführung

3.4 Inklusiver Gateway

3.5 Komplexer Gateway

Verzweigungen und Zusammenführungen ohne Gateways

4.1 Verzweigungen ohne Gateways

4.2 Zusammenführungen ohne Gateways

4.3 Modellieren mit oder ohne Gateways?

Zusammenarbeit in Kollaborationen

5.1 Beispiel für eine Kollaboration

5.2 Modellierung von Nachrichtenflüssen

5.3 Nachrichtenflüsse zu Pools ohne Prozessdarstellung

5.4 Private und öffentliche Prozesse

5.5 Mehrfachteilnehmer

5.6 Verwendung von Kollaborationen und Sequenzflüssen

5.7 Darstellung von Nachrichteninhalten

Ereignisse

6.1 Beispiel für den Einsatz von Ereignissen

6.2 Startereignisse

6.3 Endereignisse

6.4 Zwischenereignisse

6.5 Ereignisbasierte Entscheidungen

Aktivitäten

7.1 Unterprozesse

7.2 Schleifen und Mehrfachaktivitäten

7.3 Ad-hoc-Unterprozesse

7.4 Typen von Tasks

7.5 Aufruf von Prozessen und globalen Tasks

7.6 Beispiel für Unterprozesse und aufgerufene Prozesse

Behandlung von Ausnahmen

8.1 Abbrechende Zwischenereignisse

8.2 Nicht-unterbrechende Zwischenereignisse

8.3 Behandlung von Fehlern

8.4 Eskalationsereignisse

8.5 Ereignis-Unterprozesse

Transaktionen und Kompensationen

9.1 Modellierung von Transaktionen

9.2 Direkter Aufruf von Kompensationen

9.3 Ereignis-Unterprozesse für Kompensationen

9.4 Nutzung von Ausnahmen, Transaktionen und Kompensationen

Datenobjekte in Prozessen

10.1 Modellierung von Datenflüssen

10.2 Mehrfach-Datenobjekte

10.3 Daten und Ereignisse

10.4 Datenspeicher

10.5 Datenübergabe bei Aufrufaktivitäten

10.6 Nutzung von Datenobjekten

Choreographien

11.1 Choreographiediagramm

11.2 Kollaboration mit eingebetteter Choreographie

11.3 Choreographie-Unterprozesse

11.4 Gateways in Choreographien

11.5 Ereignisse in Choreographien

11.6 Aufruf von Choreographien und globalen Choreographie-Tasks

11.7 Verwendung von Choreographien und Kollaborationen

Konversationen

12.1 Konversationsdiagramm

12.2 Korrelation von Nachrichten

12.3 Hierarchisierung von Konversationen

12.4 Aufruf von Kollaborationen und globalen Konversationen

12.5 Einsatz von Konversationsdiagrammen

Artefakte und Erweiterungen der BPMN

13.1 Artefakte

13.2 Erweiterungsmöglichkeiten der BPMN

BPMN-Modellierungsmuster

14.1 Vier Augen-Prinzip

14.2 Entscheidung durch Unterprozess

14.3 Tasks mit mehreren Akteuren

14.4 Parallele Prüfungen

14.5 Prozesswegweiser

14.6 Synchronisation paralleler Pfade

14.7 Anfrage mit unterschiedlichen Antworten

14.8 Stornierungen verarbeiten

14.9 Frist überwachen

14.10 Mahnverfahren

14.11 Ausschreibung

A.

Literatur

B.

BPMN im Internet

Index

1 BPMN – Ein Standard für die Geschäftsprozessmodellierung

1.1 Wozu eine Notation?

Wer Geschäftsprozesse managen will, muss sie beschreiben und dokumentieren. Hierzu gibt es verschiedene Möglichkeiten. Im einfachsten Fall werden textuelle oder tabellarische Beschreibungen verwendet. Häufig werden Präsentations- oder Grafikprogramme genutzt, um einfache Ablaufdiagramme zu erstellen. Sie bestehen meist aus Kästchen und Pfeilen, wobei keiner bestimmten Methodik gefolgt wird.

Zur genauen Darstellung komplexerer Prozesse mit allen relevanten Aspekten, wie Verzweigungsregeln, Ereignissen, ausführenden Organisationseinheiten, Datenflüssen usw., genügt dies nicht. Hierfür werden geeignete Notationen benötigt. Eine Notation für die grafische Geschäftsprozessmodellierung legt unter anderem fest, mit welchen Symbolen die verschiedenen Elemente von Prozessen dargestellt werden, was sie genau bedeuten und wie sie miteinander kombiniert werden können.

Eine solche Notation ist also eine einheitliche Sprache zur Beschreibung von Geschäftsprozessen. Jeder, der diese Sprache beherrscht, ist in der Lage, die von anderen Modellierern erstellten Diagramme zu verstehen. Eine einheitliche Darstellungsweise ermöglicht es auch, Prozesse systematisch zu analysieren oder ihr dynamisches Verhalten zu simulieren.

Auch das zunehmend relevante Thema „Governance, Risk and Compliance“ (GRC) erfordert den Aufbau und die einheitliche und vollständige Dokumentation geeigneter Prozesse, mit denen sichergestellt wird, dass alle gesetzlichen und branchenspezifischen Anforderungen bzgl. Risikomanagement, Qualitätsmanagement, Sicherheit usw. erfüllt werden.

Schließlich dienen Modelle auch als Grundlage für die Entwicklung von Informationssystemen zur Abwicklung und Unterstützung der Geschäftsprozesse. Auch hierfür muss sichergestellt werden, dass die Modelle einheitlich aufgebaut sind und alle für die Systementwicklung relevanten Informationen beinhalten.

Zunehmend werden für die Ausführung von Prozessen Business Process Management-Systeme (BPMS) eingesetzt. Ein BPMS enthält eine Process Engine, die die Abläufe direkt anhand geeigneter Prozessmodelle oder formaler Prozessbeschreibungen steuert. Hierfür müssen die Modelle ganz besonders strikten Anforderungen genügen, da sie ja nicht von Menschen in ein Computerprogramm umgesetzt, sondern direkt von einer Maschine abgearbeitet werden.

Im Laufe der Zeit entstanden verschiedene Notationen zur Prozessmodellierung. Häufig handelte es sich um proprietäre Notationen spezieller Modellierungstools oder Workflow Management-Systeme. Im Bereich der durch BPMS ausführbaren Prozessbeschreibungen wurden Standards entwickelt, wie z. B. BPEL (Business Process Execution Language) [OASIS 2007]. BPEL definiert eine textbasierte XML-Beschreibung ohne grafische Darstellungen und ist auch nur auf die Definition automatisch ausführbarer Prozesse beschränkt.

Im Bereich der fachlich orientierten Geschäftsprozessmodellierung wird häufig noch die Notation der Ereignisgesteuerten Prozesskette (EPK) eingesetzt, die vor der Entwicklung des BPMN-Standards eine starke Verbreitung erfuhr. Dabei handelt es sich jedoch nicht um einen Standard, und mittlerweile wird die EPK vielerorts von BPMN abgelöst. Die meisten EPK-Modellierungswerkzeuge erlauben heute auch die Prozessmodellierung mit BPMN.

Andere Standards, wie z. B. die Aktivitätsdiagramme der Unified Modeling Language (UML), konnten sich in der Praxis nicht für die Geschäftsprozessmodellierung durchsetzen. Ihr Einsatz blieb weitgehend auf den Bereich des objektorientierten Software-Entwurfs beschränkt, wo die UML der akzeptierte Standard ist.

BPMN (Business Process Model and Notation) hat sich in den vergangenen Jahren als Standard für die Prozessmodellierung auf breiter Basis durchgesetzt. BPMN ist die Prozessmodellierungsnotation, die von den meisten Modellierungstools unterstützt wird, wie eine Marktanalysen zeigt [Lübbe und Schnägelberger 2016]. Auf der Webseite www.bpmn.org findet sich eine Liste mit über 60 Tools, die die BPMN-Modellierung unterstützen. Eine zunehmende Zahl von Webseiten, Weblogs und Veröffentlichungen zeigt das große Interesse an dieser Notation (z. B. [Debevoise und Taylor 2014], [Freund und Rücker 2019], [Göpfert und Lindenbach 2012], [Herrera 2015], [Silver 2012]). Es ist sogar ein Roman zur Prozessmodellierung mit BPMN erschienen [Grosskopf et al. 2009]. Eine Auswahl interessanter Internet-Quellen ist im Anhang dieses Buches aufgeführt.

Viele Organisationen bilden ihre im Prozessmanagement tätigen Mitarbeiter in BPMN-Modellierung aus und rollen BPMN als unternehmensweiten Modellierungsstandard aus. So wird etwa in den Schweizer eGovernment-Standards die Verwendung von BPMN als einheitliche Notation empfohlen [Fischli et al. 2016]. Ähnliche Modellierungsrichtlinien wurden unter anderem von den Regierungen der kanadischen Provinz British Columbia und des australischen Bundesstaats Queensland veröffentlicht [Lindner et al. 2016], [Queensland Government Chief Information Office 2016]. In einer Umfrage unter Anwendern von Modellierungstools war BPMN die am häufigsten eingesetzte Prozessmodellierungsnotation [Lübbe und Schnägelberger 2015].

1.2 Entwicklung der BPMN

Entwickelt wurde die BPMN ursprünglich von der Business Process Management Initiative (BPMI), einem Konsortium, das hauptsächlich aus Vertretern von Software-Unternehmen bestand. Der Zweck bestand zunächst darin, eine grafische Notation zur Darstellung von Prozessbeschreibungen der BPML (Business Process Modeling Language) bereitzustellen. BPML diente zur Spezifikation von Prozessbeschreibungen, die durch ein BPMS ausgeführt werden können, vergleichbar BPEL. Die Entwicklung der BPML wird nicht mehr fortgeführt, sie wurde zugunsten von BPEL aufgegeben.

Die erste Version der BPMN-Spezifikation wurde unter Federführung von Stephen A. White von IBM erstellt und im Jahr 2004 veröffentlicht. Zwischenzeitlich ist die BPMI in der Object Management Group (OMG) aufgegangen. Diese Organisation ist durch Standards im Softwarebereich bekannt geworden, wie die bereits erwähnte UML (Unified Modeling Language).

Im Jahr 2006 wurde die BPMN in der Version 1.0 offiziell als OMG-Standard angenommen. Nach eher kleinen Erweiterungen in den Versionen 1.1 und 1.2 brachte die 2011 erschienene Version 2.0 umfangreiche Änderungen und Weiterentwicklungen. Die aktuelle Version des Spezifikationsdokuments aus dem Jahr 2013 trägt die Nummer 2.0.2 [OMG 2013]. Sie enthält lediglich minimale Korrekturen am Text, aber keine inhaltlichen Änderungen gegenüber BPMN 2.0. Seit 2013 ist BPMN auch offizieller ISO-Standard [ISO 2013].

Die jeweils aktuelle Version der BPMN-Spezifikation findet sich unter

www.omg.org/spec/BPMN

1.3 Inhalte der BPMN 2.0

Für die meisten BPMN-Anwender dürfte die grafische Darstellung der Prozesse das Wichtigste sein. Hierzu bietet BPMN insgesamt drei Diagrammtypen:

Prozess- bzw. Kollaborationsdiagramm:

Damit lässt sich der Prozessablauf mit den einzelnen Aktivitäten, Verzweigungen usw. darstellen. Außerdem können Kollaborationen von zwei oder mehr Prozessen modelliert werden. Das Zusammenspiel der Prozesse erfolgt über ausgetauschte Nachrichten. Bei Prozess- und Kollaborationsdiagramm handelt es sich um denselben Diagrammtyp. Ein Diagramm mit nur einem Prozess wird meist als Prozessdiagramm bezeichnet, eines mit mehreren interagierenden Prozessen als Kollaborationsdiagramm.

Choreographiediagramm:

Ähnlich wie bei Kollaborationen geht es hier um den Nachrichtenaustausch zwischen verschiedenen Partnern. Doch werden nicht mehr die einzelnen Prozesse der beteiligten Partner modelliert, sondern nur noch ihr Zusammenspiel. Jeder Nachrichtenaustausch wird als eigene Aktivität dargestellt, und man kann auch für die Reihenfolge der Nachrichtenaustausche Verzweigungen, Schleifen u. ä. modellieren und somit komplexere Austauschprotokolle zwischen Prozessen abbilden.

Konversationsdiagramm:

Hierbei handelt es sich um eine Übersichtsdarstellung mehrerer Partner mit ihren Kommunikationsbeziehungen.

Am häufigsten werden Prozess- bzw. Kollaborationsdiagramme eingesetzt. Teilweise beschränken sich BPMN-Werkzeuge und -Bücher auch nur auf diesen Diagrammtyp. Auch wenn er zweifellos am wichtigsten ist, gibt es doch auch Einsatzmöglichkeiten für die beiden anderen Diagrammtypen, weshalb sie im vorliegenden Buch ebenfalls beschrieben werden.

Die BPMN-Spezifikation erläutert die verschiedenen grafischen Notationselemente und Regeln zur Modellierung nicht nur verbal, sondern definiert sie auch in Form eines Metamodells. Mit Hilfe von UML-Klassendiagrammen werden die verschiedenen BPMN-Konstrukte und ihre Beziehungen zueinander beschrieben. Ein solches Metamodell ist exakter und eindeutiger als rein verbale Beschreibungen. Hinzu kommt, dass in dem Metamodell zusätzliche Sprachkonstrukte enthalten sind, die in den grafischen Modellen gar nicht dargestellt werden. Sie werden beispielsweise von Process Engines benötigt, um für die Prozessausführung erforderliche Zusatzinformationen erfassen zu können.

Als gewöhnlicher Modellierer muss man sich nicht mit dem Metamodell auseinandersetzen. In der Regel wird man eine Modellierungssoftware verwenden, die dafür sorgt, dass man nur Modelle erstellen kann, die der Spezifikation und damit dem Metamodell entsprechen. Hauptadressaten des Metamodells sind somit eher die Hersteller von Modellierungswerkzeugen, Process Engines und ähnlicher Software.

Das Metamodell ist auch die Basis eines Austauschformats für BPMN-Modelle. Früher war es bis auf wenige Ausnahmen nicht möglich, die in einem Werkzeug erstellten BPMN-Modelle in ein anderes Werkzeug zu übertragen. Seit Version 2.0 steht ein standardisiertes Austauschformat zur Verfügung. Eine Reihe von Toolherstellern unterstützt dieses Standardformat, so dass man BPMN-Modelle zwischen unterschiedlichen Modellierungstools und z. B. auch zwischen einem Modellierungstool und einem BPMS austauschen kann. In der Praxis sind die Implementierungen dieses Austauschformats bislang jedoch noch nicht immer ganz einheitlich, so dass es beim Austausch von Modellen gelegentlich zu gewissen Schwierigkeiten oder Verlusten mancher Details kommen kann.

Sollen mit BPMN modellierte Prozesse mit Hilfe einer Process Engine automatisiert werden, so muss festgelegt werden, wie die verschiedenen Modellierungskonstrukte ausgeführt werden sollen. Auch diese Ausführungssemantik ist in der Spezifikation festgelegt. Damit soll erreicht werden, dass ein und dasselbe Modell von verschiedenen Process Engines gleich interpretiert und damit auf die gleiche Weise ausgeführt wird. Auch die BPMN-Ausführungssemantik wurde nicht von allen BPMS-Herstellern komplett einheitlich implementiert, so dass es bei der Ausführung ein und desselben Modells auf verschiedenen Process Engines ebenfalls gewisse Unterschiede geben kann.

Doch trotz der teilweise anzutreffenden Abweichungen sind sowohl das Austauschformat als auch die Ausführungssemantik sehr nützlich, da ansonsten überhaupt kein herstellerübergreifender Modellaustausch möglich wäre und bei der Prozessausführung wesentlich größere Unterschiede auftreten würden.

In der ersten Version stand die Abkürzung BPMN noch für „Business Process Modeling Notation“. Mit Version 2.0 wurde dies zu „Business Process Model and Notation“ geändert. Damit wird ausgedrückt, dass BPMN nicht nur die grafische Notation umfasst, sondern auch das Metamodell, das Austauschformat und die Ausführungssemantik. Streng genommen dürfte man im Deutschen damit auch nicht mehr „die BPMN“ sagen, da es zwar „die Notation“, aber „das Modell“ heißt. Der Einfachheit halber wird in diesem Buch aber weiterhin „die BPMN“ geschrieben.

1.4 Fachliche und ausführbare Modelle

Die BPMN entstand ursprünglich im Umfeld von Prozessbeschreibungen, die von der Process Engine eines Workflow- oder Business Process Management-Systems (BPMS) ausgeführt werden können. Die Entwickler der BPMN haben aber den Anspruch, dass man mit dieser Notation sowohl technische als auch fachlich ausgerichtete Modelle erstellen kann. BPMN soll eine gemeinsame Sprache von betriebswirtschaftlich ausgerichteten Fachexperten und IT-Experten darstellen.

Und in der Tat wird BPMN sowohl für die rein fachliche Prozessmodellierung als auch für die ausführungsnahe Modellierung verwendet. So handelt es sich bei den in [Lübbe und Schnägelberger 2016] aufgeführten Modellierungstools, die mehrheitlich BPMN als Prozessmodellierungsnotation anbieten, um vorwiegend fachlich ausgerichtete Werkzeuge. Ausführbare Prozesse stehen hingegen bei den in [Adam et al. 2014] untersuchten BPM-Systemen im Vordergrund. Hier kommt bei der Mehrzahl der Tools ebenfalls BPMN zum Einsatz.

Trotz Verwendung einer gemeinsamen Notation unterscheiden sich fachliche und technische Modelle in der Praxis sehr deutlich voneinander. Bei fachlichen Modellen steht das Verständnis des grundlegenden Prozessablaufs im Vordergrund. Deshalb wird darauf verzichtet, zu viele Details darzustellen. So werden etwa Bedingungen an Verzweigungen eher im Klartext als in Form exakter logischer Ausdrücke formuliert. Ausnahmen und selten auftretende Fälle werden oft nicht ausmodelliert, sondern mit Hilfe von Anmerkungen und Beschreibungen erläutert.

Die Herkunft einiger BPMN-Konstrukte liegt ganz deutlich im Bereich ausführbarer Prozess-Spezifikationen. So finden sich in der BPMN u. a. spezielle Schleifen-Konstrukte, Ausnahmebehandlungen und Transaktionen. Programmierern und IT-Fachleuten sind diese Themen vertraut. In fachlichen Prozessmodellen findet man derartiges normalerweise nicht. Entsprechend wird in der fachlichen Modellierung zumeist nur ein Teil der gesamten Notation angewandt.

Einige BPMN-Experten sind der Ansicht, dass manche dieser eher dem technischen Bereich entstammenden Konstrukte auch für die fachliche Modellierung angewandt werden sollten, um z. B. aus fachlicher Sicht relevante Ausnahmen und ihre Behandlung im Prozess darstellen zu können. So weist Silver auf die bekannte 80-20-Regel hin. Seiner Einschätzung nach werden 80% der Kosten, Verzögerungen und Fehler von 20% aller Fälle verursacht, nämlich den Ausnahmen. Beispiele sind Stornierungen, vergriffene Waren oder nicht eingehaltene Zeitlimits [Silver 2012].

Wer die BPMN zur fachlichen Prozessmodellierung einsetzen möchte, sollte sich daher im Vorfeld entscheiden, welche Konstrukte verwendet und wie bestimmte Sachverhalte damit dargestellt werden sollen. Es ist sinnvoll, derartige Entscheidungen in Form von Modellierungskonventionen festzuschreiben. Sollen die auf fachlicher Ebene modellierten Prozesse anschließend durch eine Process Engine automatisiert werden, so ist weiterhin festzulegen, wie die fachlichen Modelle in ausführungsnahe Modelle überführt werden, d. h. wie notwendige Ergänzungen, Umstrukturierungen und Detaillierungen durchgeführt werden.

Mit dem Übergang von der fachlichen zur ausführbaren Prozessmodellierung beschäftigen sich u. a. [Allweyer 2014a] und [Stiehl 2013].

1.5 Über dieses Buch

Das vorliegende Buch bietet eine Einführung in die grafische Notation der BPMN 2.0. Ausgehend von einem kleinen Beispielprozess werden zunächst die elementaren BPMN-Elemente zur einfachen Ablaufmodellierung erläutert. Nach und nach werden dann die verschiedenen Konzepte der BPMN eingeführt und anhand von Beispielen erklärt. Hierbei werden allgemein verständliche, fachliche Beispiele verwendet, so dass für das Verständnis kein IT-Know-how erforderlich ist. Lediglich bei der Erläuterung einiger in der BPMN enthaltenen technischen Details wird auf die Ausführung eines Prozesses durch eine Process Engine Bezug genommen.

Da der Schwerpunkt auf der fachlichen Modellierung liegt, wird bewusst darauf verzichtet, das Metamodell zu erläutern. Auch die Ausführungssemantik wird nicht behandelt. Eine ausführliche Diskussion der Ausführungssemantik findet sich in [Kosak et al. 2014].

Es wird der gesamte Sprachumfang der Notation vorgestellt. Auch wenn wie oben beschrieben nicht für jeden Anwendungsfall alle BPMN-Elemente erforderlich sind, sollten Modellierungsexperten doch die gesamte BPMN kennen, um gezielt auswählen zu können, was davon für den eigenen Gebrauch sinnvoll ist.

Bei der Vorstellung der verschiedenen BPMN-Konzepte wurde auf eine größtmögliche Übereinstimmung mit der offiziellen BPMN-Spezifikation geachtet. An der einen oder anderen Stelle war es dabei nötig, die Beschreibungen in der Spezifikation geeignet auszulegen. Von daher handelt es sich bei den Darstellungen in diesem Buch immer auch um die Deutungen des Autors, der für Hinweise auf Fehler und für Verbesserungsvorschläge dankbar ist.

Das Buch stellt eine Einführung in den BPMN-Standard dar. Zwar werden an einigen Stellen Empfehlungen für die Anwendung bestimmter Konstrukte gegeben, doch werden keine speziellen Modellierungskonventionen zugrunde gelegt. Einige Vorschläge finden sich z. B. in [Allweyer 2012], [Silver 2012] sowie [Freund und Rücker 2019].

Auch die in Kapitel 14 vorgestellten Modellierungsmuster können als Anregungen dienen. Dabei handelt es sich um bewährte Vorschläge, wie bestimmte immer wieder auftretende Sachverhalte einheitlich modelliert werden können. Ein Großteil dieser Muster entstand in Zusammenarbeit mit BPMN-Trainern der Firma AXON IVY AG.

In der vierten Auflage wurden einige Aktualisierungen sowie kleinere Verbesserungen und Überarbeitungen vorgenommen.

Die Website zum Buch ist erreichbar unter

www.kurze-prozesse.de/bpmn-buch

Dort finden sich aktuelle Ergänzungen, Informationen über die Weiterentwicklung der Notation sowie weitere Links und Hinweise zur BPMN.

2 BPMN am Beispiel

2.1 Ein erstes BPMN-Modell

Zur Einführung wird ein einfaches BPMN-Prozessdiagramm betrachtet. Das in Abbildung 1 dargestellte Modell einer Stellenausschreibung ist für die meisten Menschen unmittelbar verständlich, die sich bereits mit irgendeiner Art der Ablaufmodellierung beschäftigt haben. Die Darstellung ähnelt bekannten Flussdiagrammen und Programmablaufplänen.

Abbildung 1: Ein einfaches BPMN-Modell

An dem Prozess „Stelle ausschreiben“ sind eine Fachabteilung und die Personalabteilung beteiligt. Er beginnt, wenn ein Mitarbeiter benötigt wird. Die Fachabteilung meldet diesen aufgetretenen Mitarbeiterbedarf. Daraufhin verfasst die Personalabteilung eine Stellenausschreibung. Die Fachabteilung prüft diese Stellenausschreibung.

Hierbei gibt es zwei Möglichkeiten: Entweder die Stellenausschreibung ist okay, oder sie ist nicht okay. Ist sie nicht okay, wird sie von der Personalabteilung überarbeitet. Hierauf folgt erneut die Prüfung durch die Fachabteilung, wobei das Ergebnis wiederum okay oder nicht okay sein kann. Es kann also vorkommen, dass die Stellenausschreibung mehrfach überarbeitet werden muss. Ist die Stellenausschreibung okay, so wird sie von der Personalabteilung veröffentlicht. Damit ist die Stelle ausgeschrieben, womit das Ende des Prozesses erreicht ist.

In der Praxis kann der Ablauf zur Erstellung und Veröffentlichung einer Stellenanzeige wesentlich komplexer und umfangreicher sein. Das dargestellte Modell stellt – wie alle Beispiele in diesem Buch – eine starke Vereinfachung dar, um übersichtliche Modelle zu erhalten, an denen sich die verschiedenen Elemente der BPMN gut erläutern lassen.

2.2 Verwendete Konstrukte der BPMN

Im Folgenden werden die einzelnen Elemente des Modells aus Abbildung 1 näher betrachtet.

Der gesamte Ablauf befindet sich in einem sogenannten „Pool“. Hierbei handelt es sich ganz allgemein um eine Art „Behälter“ für einen kompletten, abgeschlossenen Prozess. Im Beispiel ist der Pool mit dem Namen des enthaltenen Prozesses bezeichnet.

Ein Prozess befindet sich prinzipiell innerhalb eines Pools. Ist dieser jedoch für das Verständnis des Prozesses nicht von Bedeutung, kann man darauf verzichten, ihn in der Grafik darzustellen. Ist in einem Prozessdiagramm also kein Pool eingezeichnet, befindet sich der gesamte Prozess in einem unsichtbaren, „impliziten“ Pool.

Interessant werden Pools vor allem dann, wenn mehrere Pools verwendet werden, um eine „Kollaboration“ zu modellieren, also das Zusammenspiel von Prozessen mehrerer Partner. Dann werden die Prozesse der verschiedenen Partner in unterschiedlichen Pools dargestellt. Dies wird in Kapitel 5 beschrieben.

Der Pool aus Abbildung 1 ist in zwei Bahnen unterteilt. Eine Bahn (engl. „Lane“) kann beispielsweise verwendet werden, um – wie hier – die Zuordnung zu einzelnen Organisationseinheiten vorzunehmen, oder innerhalb eines technischen Systems die Aufgaben einzelner Komponenten darzustellen.

Im betrachteten Beispiel wird mit Hilfe der Bahnen dargestellt, welche Aktivitäten des Prozesses von der Fachabteilung und welche von der Personalabteilung durchgeführt werden.

Pools und Bahnen werden auch „Swimlanes“ („Schwimmbahnen“) genannt. Dies erinnert an die Unterteilung von Schwimmbecken in einzelne Bahnen, wobei sich jeder Wettkampfteilnehmer nur innerhalb seiner Bahn bewegt.

Der Ablauf selbst beginnt mit dem Startereignis (engl. „Start Event“) „Mitarbeiter benötigt“. Prozesse beginnen im Normalfall mit einem solchen Startereignis. Dieses wird durch einen einfachen Kreis dargestellt. Meist ist es auch sinnvoll, genau ein Startereignis zu verwenden, und nicht mehrere.

Ein Rechteck mit abgerundeten Ecken stellt eine Aktivität (engl. „Activity“) dar. In einer Aktivität wird etwas getan. Dies kommt in den Bezeichnungen zum Ausdruck, z. B. „Mitarbeiterbedarf melden“ oder „Stellenausschreibung prüfen“.

Die Verbindungspfeile oder Kanten werden zur Modellierung des Sequenzflusses (engl. „Sequence Flow“) verwendet. Sie stellen dar, in welcher Reihenfolge oder Sequenz die verschiedenen Ereignisse, Aktivitäten und weiteren Elemente durchlaufen werden. Häufig wird dies als Kontrollfluss bezeichnet, doch gibt es in der BPMN auch noch Nachrichtenflüsse (engl. „Message Flow“), die z. T. ebenfalls den Ablauf beeinflussen und somit ebenfalls zum Kontrollfluss gezählt werden können. Daher wurde der neue Begriff „Sequenzfluss“ geschaffen. Zur Unterscheidung von anderen Flüssen und Kanten ist es auch wichtig, Sequenzflüsse mit durchgehenden Linien und ausgefüllten Pfeilspitzen zu zeichnen.

In dem Prozess „Stelle ausschreiben“ gibt es eine Verzweigung: Auf die Aktivität „Stellenausschreibung prüfen“ folgt ein „Gateway“. Eine leere Raute bezeichnet dabei einen exklusiven Gateway (engl. „Exclusive Gateway“). Dies bedeutet, dass von mehreren ausgehenden Sequenzflüssen immer genau einer gewählt werden muss. Jedes Mal, wenn im Rahmen der Stellenausschreibung der in der Abbildung rechts dargestellte Gateway erreicht wird, muss also entschieden werden, ob dem Sequenzfluss nach rechts zur Aktivität „Stellenausschreibung veröffentlichen“ oder dem nach links zur Aktivität „Stellenausschreibung überarbeiten“ gefolgt wird. Beides gleichzeitig ist nicht möglich.

Die Logik einer solchen Entscheidung wird auch als „exklusives Oder“ bezeichnet, abgekürzt „XOR“. Welchem der ausgehenden Pfade gefolgt wird, wird mit Hilfe von Bedingungen (engl. „Condition“) an den ausgehenden Sequenzflüssen bestimmt. Wenn man ein Modellierungstool verwendet und der Prozess von einer Software simuliert oder ausgeführt werden soll, dann können Bedingungen zumeist ganz exakt mit Hilfe einer formalen Beschreibung oder einer Programmiersprache in spezielle Attribute der Sequenzflüsse geschrieben werden. Dient das Modell hingegen nur dazu, den Prozess anderen Menschen verständlich zu machen, empfiehlt es sich, die Bedingungen im Klartext an die Sequenzflüsse zu schreiben. „Okay“ und „Nicht okay“ im Anschluss an die Aktivität „Stellenausschreibung prüfen“ ist für Menschen unmittelbar verständlich – eine Software könnte damit wenig anfangen.

Auch zur Zusammenführung alternativer Pfade werden Gateways verwendet. Im Beispielprozess führt der links von der Aktivität „Stellenausschreibung prüfen“ gezeigte Gateway die beiden eingehenden Sequenzflüsse zusammen. Es handelt sich wiederum um einen exklusiven Gateway. Dieser erwartet, dass im Prozess vorher entweder die Aktivität „Stellenausschreibung verfassen“ oder „Stellenausschreibung überarbeiten“ durchgeführt wird – nicht jedoch beide zugleich. Es sollte darauf geachtet werden, dass man einen Gateway immer nur entweder als Verzweigung oder als Zusammenführung verwendet, nicht jedoch als Kombination aus beiden.

Das letzte Element des betrachteten Prozesses ist das Endereignis (engl. „End Event“). Es wird wie das Startereignis als Kreis dargestellt – allerdings mit einem dicken Rand.

2.3 Logik des Sequenzflusses

Die Ablauflogik des obigen Stellenausschreibungsprozesses ist recht leicht verständlich. Bei komplizierteren Prozessmodellen tauchen aber gelegentlich Unklarheiten auf, wie eine bestimmte modellierte Struktur genau zu verstehen ist. Es ist daher hilfreich, wenn die Bedeutung der im Sequenzfluss verwendeten Elemente möglichst eindeutig definiert ist.

Die Logik des Sequenzflusses in einem Prozessdiagramm lässt sich mit Hilfe von „Marken“ (engl. „Token“) erklären. Wie bei einem Gesellschaftsspiel Spielmarken entsprechend den Spielregeln über den Spielplan geschoben werden, kann man gedanklich Marken nach den Regeln der BPMN durch ein Prozessmodell schieben.

Jedes Mal wenn der Prozess gestartet wird, erzeugt das Startereignis eine Marke (vgl. Abbildung 2). Da der Stellenausschreibungsprozess öfter durchgeführt wird, können im Laufe der Zeit ganz viele Marken erzeugt werden. Dabei kann es vorkommen, dass der Prozess für die eine Stellenausschreibung noch gar nicht beendet ist, wenn der Prozess für die Ausschreibung einer anderen Stelle startet. Jede Marke durchläuft den Prozess völlig unabhängig von den anderen Marken.

Abbildung 2: Ein Startereignis erzeugt eine Marke.

Die vom Startereignis erzeugte Marke wandert über den Sequenzfluss zur ersten Aktivität. Diese nimmt die über den eingehenden Sequenzfluss ankommende Marke entgegen, führt ihre Aufgabe aus (in diesem Fall „Mitarbeiterbedarf melden“) und gibt anschließend über den ausgehenden Sequenzfluss wieder eine Marke aus (vgl. Abbildung 3).

Abbildung 3: Eine Aktivität nimmt eine Marke entgegen und gibt anschließend wieder eine Marke aus.

Auch die folgende Aktivität gibt eine Marke weiter. Sie gelangt dann zum zusammenführenden exklusiven Gateway. Die Aufgabe dieses Gateways ist einfach: Er nimmt lediglich eine Marke entgegen, die über einen beliebigen eingehenden Sequenzfluss ankommt, und gibt diese Marke über den ausgehenden Sequenzfluss weiter. Dies ist in Abbildung 4 dargestellt. Im Fall A kommt eine Marke von links an, im Fall B von unten. In beiden Fällen wird diese Marke über den rechten Sequenzfluss wieder ausgegeben.

Interessanter ist die Aufgabe des verzweigenden exklusiven Gateways. Er nimmt eine ankommende Marke entgegen und entscheidet nun aufgrund der Bedingungen, über welchen der ausgehenden Sequenzflüsse er eine Marke ausgibt. Abbildung 5 zeigt oben den Fall, dass die Bedingung „Okay“ zutrifft, d. h. dass die vorangehende Prüfung ein positives Ergebnis erbracht hat. In diesem Fall wird die Marke über den rechten Sequenzfluss ausgegeben. Ansonsten, wenn die Bedingung „Nicht okay“ zutrifft, wird die Marke entsprechend über den unteren Sequenzfluss ausgegeben.

Abbildung 4: Weitergabe einer Marke durch einen zusammenführenden exklusiven Gateway