Grundlagen der Modellierung - Geschäftsprozessmodellierung: Unterschied zwischen den Versionen
K (JUNGBAUER Christoph verschob die Seite Grundlagen der Modellierung - Geschätfsprozessmodellierung nach Grundlagen der Modellierung - Geschäftsprozessmodellierung) |
Aktuelle Version vom 1. November 2023, 11:52 Uhr
Geschäftsprozessmodellierung
Ergänzend zu den bereits betrachteten Modellen der Prozess- und Ablaufmodellierung gibt es noch einige spezielle Geschäftsprozessmodelle. In dieser Lektion werden nun die Grundlagen von zwei der diesbezüglich wichtigsten Modelle erläutert. Diese Modelle dienen der organisatorischen Betrachtung von Geschäftsprozessen und werden auch von Nicht-Technikern eingesetzt. Sie dienen oft auch als gemeinsame Basis bei der Spezifikation der Anforderungen von IT-Systemen und ihrer Unterstützung der Geschäftsprozesse.
Ereignisgesteuerte Prozessketten (EPK)
Die Ereignisgesteuerten Prozessketten (EPK) wurden 1992 durch Keller, Nüttgens und Scheer entwickelt. Sie wurden von den Petri-Netzen abgeleitet und dienen der prozessorientierten Modellierung von Geschäftsprozessen. Sie sind Teil des Rahmenkonzeptes der Architektur integrierter Informationssysteme (ARIS) und dort im Bereich der Steuerungssicht angesiedelt. Zusätzlich zu den Prozessabläufen ermöglichen Sie in ihrer aktuellen Version auch direkte Verbindungen zur Daten- und Funktionssicht. Das ARIS-Konzept selbst wurde entwickelt, um die Vielzahl unterschiedlicher Methoden der Anwendungsentwicklung und Unternehmensentwicklung zu strukturieren. (Keller G., 1992, S. 3f)
Die "Ereignisgesteuerte Prozeßkette" stellt den zeitlich-logischen Ablauf von Funktionen und eine Verknüpfung der Elemente des Daten- und des Funktionsmodells dar. Sie ist somit eine zentrale Komponente innerhalb der Informationsmodellierung. (Keller G., 1992, S. 15)
Aufbau einer EPK
Eine EPK besteht aus Elementen, Pfaden und Operatoren. Der Prozess wird durch die möglichen Pfade beschrieben, welche zu Elementen hin und von ihnen weg führen. Mittels Operatoren können diese Pfade geteilt, parallelisiert und auch wieder zusammengeführt werden.
Die möglichen Elemente einer einfachen EPK sind:
- Ereignisse und
- Funktionen.
Ein Ereignis stellt dabei einen eingetretenen Zustand dar und ist damit eine passive Komponente des Systems. Funktionen werden von Ereignissen ausgelöst und damit gestartet. Sie können wiederum Ereignisse auslösen und so weiter. Eine Funktion stellt dabei eine bestimmte Tätigkeit dar, welche für den Prozess ausgeführt wird. Das bedeutet auch, dass auf ein Ereignis niemals ein Ereignis und auf eine Funktion keine Funktion folgen kann. (Keller G., 1992, S. 10f)
Die Pfade des Kontrollflusses werden als gestrichelte Linie dargestellt. Der Kontrollfluss entspricht dabei dem Prozessablauf. Pfade des Datenflusses werden durch durchgehende Linien repräsentiert. Dabei handelt es sich um die Verbindung von Informationsobjekten und Organisationseinheiten zu den Funktionen, welche später im Abschnitt 4.1.2 genauer beschrieben werden. Die grafische Darstellung von einem Ereignis, welches eine Funktion auslöst ist in der Abbildung "EPK: Ereignis und Funktion" dargestellt.
Der Prozessablauf wird über einen Token-Ansatz abgearbeitet. Das bedeutet, dass immer ganz bestimmte Teilpfade des Kontrollflusses aktiv sind, wobei es möglich ist, eine parallele Ausführung mehrerer Pfade durchzuführen, indem der aktuelle Token auf mehrere Teilpfade aufgeteilt wird. Ein Zusammenführen oder Synchronisieren mehrerer Pfade zu einem einzigen Pfad ist ebenfalls möglich. Diese Teilung und Zusammenführung erfolgt über logische Operatoren. Folgende Operatoren sind dabei möglich:
- exklusiver Oder-Operator (XOR),
- inklusiver Oder-Operator (OR) und
- Und-Operator (AND).
Die Darstellung der logischen Operatoren erfolgt mittels Kreissymbol mit dem jeweiligen Typ darin. Die Darstellungsformen der Operatoren-Typen sind in der Abbildung "EPK: Operatoren" angeführt.
Beim exklusiven Oder-Operator wird genau einer der Pfade ausgewählt und der Prozessfluss dort weitergeführt. Bei einem inklusiven Oder-Operator wird der Prozesspfad an einem oder mehreren möglichen Pfaden fortgesetzt. In beiden Fällen ist der eingeschlagene Weg von dem Eintreten des nachfolgenden Ereignisses abhängig. Ein Oder-Operator darf daher nur von einer Funktion weg zu mehreren Ereignissen führen aber nicht von einem Ereignis zu mehreren Funktionen. Anderenfalls wäre nicht eindeutig unter welchen Umständen (Ereignis) welcher Pfad gewählt werden soll.
Der Und-Operator kann sowohl nach einem Ereignis, als auch nach einer Funktion eingesetzt werden. Er teilt immer den aktuellen Pfad in mehrere parallel ausgeführte Pfade. Es ist somit damit auch möglich durch ein einzelnes Ereignis mehrere Funktionen auszulösen.
Werden die Operatoren für die Zusammenführung mehrerer Kontrollflüsse verwendet, gilt die oben beschriebene Logik ebenfalls. So werden beim inklusiven Oder-Operator mehrere Pfade zu einem zusammengeführt und beim exklusiven Oder-Operator einer aus mehreren Pfaden fortgesetzt. Beim Und-Operator wird abgewartet, bis alle eingehenden Kontrollflüsse vorhanden sind und dann mit dem ausgehenden Kontrollfluss fortgesetzt. Er kann daher für die Synchronisierung mehrerer Abläufe verwendet werden. Sollen mehrere Prozessflüsse an einer Stelle synchronisiert werden, jedoch getrennt weiterlaufen, kann dies mit zwei aufeinander folgenden Und-Operatoren geschehen. Diese Vorgehensweise ist im Beispiel in der Abbildung "EPK: Synchronisation mehrerer paralleler Kontrollflüsse" dargestellt.
Um in einer EPK die Ausführung eines Sub-Prozesses anzustoßen werden Prozesswegweiser eingesetzt. Diese ermöglichen die Auslagerung von komplexeren oder mehrfach genutzten Prozessteilen in eigene Prozesse. Der Prozesswegweiser repräsentiert dabei immer die komplette Ausführung des Sub-Prozesses. Das bedeutet, dass nach seinem Aufruf auf die Abarbeitung des aufgerufenen Prozesses gewartet, und der Prozessfluss danach hinter dem Prozesswegweiser wieder fortgesetzt wird. Das Symbol eines Prozesswegweisers ist das einer Funktion mit einem dahinter befindlichen Ereignis. Er wird als Funktionsaufruf behandelt und daher immer von einem Ereignis aufgerufen. Weiter folgt ihm auch immer ein Ereignis nach. Der Aufruf eines Prozesswegweisers ist in der Abbildung "EPK: Prozesswegweiser" dargestellt.
Erweiterte Ereignisgesteuerte Prozessketten (eEPK)
Die erweiterten Ereignisgesteuerten Prozessketten (eEPK) sind eine direkte Ergänzung der EPK um weitere Elemente. Dadurch ist es möglich das Prozessumfeld und Zuständigkeiten genauer zu beschreiben.
Die wesentlichen Zusatzelemente sind:
- Organisationseinheiten und
- Informationsobjekte.
Die Zusatzelemente werden mittels Informationspfaden, welche als Pfeile mit durchgehenden Linien gezeichnet werden, mit den zugehörigen Funktionen verbunden. Sie sind damit genau diesen Funktionen zugeordnet.
Die Organisationseinheiten repräsentieren die Prozessteilnehmer, welche die zugehörige Funktion durchführen. Prozessteilnehmer können bestimmte Organisationseinheiten oder Funktionen eines Unternehmens sein. Sie werden als Oval mit einem innenliegenden vertikalen Strich an der linken Seite gezeichnet und beinhalten den Namen des Prozessteilnehmers.
Informationsobjekte dienen der Darstellung von Daten, welche von der zugehörigen Funktion genutzt oder erstellt werden. Als Daten gelten hier jedoch alle Arten von Informationen, auch wenn sie nicht in elektronischer Form vorliegen. Die Darstellung eines Informationsobjektes geschieht in Form eines Rechtecks mit spitzen Ecken (im Gegensatz zu den abgerundeten Ecken der Funktion).
Eine Funktion mit zugehörigen Daten und einer Organisationseinheit ist in der Abbildung "eEPK: Organisationseinheit und Informationsobjekt" dargestellt.
Objektorientierte Ereignisgesteuerte Prozessketten (oEPK)
Bei den objektorientieren Ereignisgesteuerten Prozessketten handelt es sich um eine andere Form der Herangehensweise an die Modellierung. Im Gegenzug zur herkömmlichen, rein prozessbezogenen Betrachtung, überwiegt hierbei der Objektbezug. Das bedeutet insbesondere eine Definition von Objekten und ihrer Interaktionen. Die Geschäftsprozesse werden hierbei über die Abbildung der Objekte und ihrer Interaktion mittels ereignisgesteuerter Nachrichten realisiert. Die in dieser Form modellierten Objekte können daher auch als Geschäftsobjekte bezeichnet werden. (Scheer, Nüttgens, & Zimmermann, Objektorientierte Ereignisgesteuerte Prozeßkette (oEPK) - Methode und Anwendung, 1997, S. 16ff)
Zuerst werden die einzelnen Objektklassen modelliert, welche selbst Variablen und Methoden enthalten können. Für den Nachrichtenaustausch werden den Objekten weiter Ereignisse zugewiesen, welche dann im Prozessfluss verwendet werden können.
Zur Definition einer Objektklasse wird ein, vom EPK Prozessfluss getrenntes, Modell erstellt, welches die Objektklasse und ihre zugehörigen Funktionen und Instanzvariablen beinhaltet. Weiter werden alle möglichen Ereignisse angeführt, die von der Objektklasse ausgelöst werden können. Das Symbol der Instanzvariablen ist ein Rechteck, welches links und rechts mit einem Halbkreis abgeschlossen wird. Sie repräsentieren die Daten des Objektes. Die Funktionen des Geschäftsobjektes können auch als Methoden bezeichnet werden. Eine mögliche Modellierung einer oEPK Objektklasse ist in der Abbildung "oEPK: Modell einer Objektklasse" dargestellt.
Die Einbindung der Objektklasse in eine EPK geschieht direkt über das Objektklassen-Symbol. Es wird dabei wie eine Funktion eingesetzt, wird von Ereignissen aufgerufen und kann wiederum selbst Ereignisse auslösen. Die einzelnen Funktionen, Instanzvariablen und Ereignisse des Objektes werden hier nur angeführt, wenn sie an der jeweiligen Position der EPK gerade verwendet werden. Alle übrigen Komponenten werden ausgeblendet. Es werden daher auch nur die Folgeereignisse angeführt, welche an dieser Position ausgelöst werden können.
Beispiel einer eEPK
Im Beispiel, in der Abbildung "eEPK Beispiel einer Kaffeeküche", soll der Prozess einer Kaffeezubereitung in einer Büroküche modelliert werden. Die Teilnehmer des Prozesses sind alle Mitarbeiter der Abteilung und ein Service-Verantwortlicher. Sobald ein Mitarbeiter einen Kaffee möchte, prüft er zuerst ob die Kaffeemaschine korrekt funktioniert. Ist dies der Fall, sucht er sich einen Kaffee (Espresso, Ristretto oder Lungo) aus und bereitet diesen zu. Nach der Zubereitung trinkt er den Kaffee und hat seinen Kaffeebedarf damit gestillt. Sollte die Kaffeemaschine nicht funktionieren, informiert er den für das Service verantwortlichen Kollegen. Dieser setzt die Kaffeemaschine wieder in Stand und informiert anschließend wieder die Mitarbeiter der Abteilung.
Business Process Model and Notation (BPMN)
Die Business Process Model and Notation (BPMN) wurde ursprünglich von Stephen A. White entwickelt und 2004 von der Business Process Management Initiative (BPMI) veröffentlicht. Seit Februar 2011 gibt es die BPMN nun in ihrer aktuellen Version 2.0, welche offiziell von der Object Management Group (OMG) verabschiedet und publiziert wurde. BPMN dient der Modellierung von Prozessen und kann daher andere Strukturen, wie eine übergeordnete Prozesslandschaft und Ablauforganisationen, nicht abbilden. (Freund & Rücker, 2014, S. 8f, 22)
Alle Elemente und der Aufbau von BPMN 2.0 sind in der zugehörigen, 538 Seiten langen, Spezifikation (Object Management Group (OMG), 2011) genau definiert. Nachfolgend werden nun die davon wichtigsten Grundaspekte erläutert.
Aufbau der BPMN
Die BPMN kann in fünf Hauptelementtypen gegliedert werden (Freund & Rücker, 2014, S. 23):
- Flussobjekte,
- verbindende Objekte,
- Artefakte,
- Teilnehmer und
- Daten.
Die Flussobjekte beschreiben alle Entscheidungen, Aktivitäten und Ereignisse. Sie werden selbst wiederum über die verbindenden Objekte vernetzt und mit Hilfe der Artefakte beschrieben. Ergänzend können dann noch die Teilnehmer und relevanten Daten des Prozesses in das Modell eingefügt werden.
Generell wird, ähnlich wie bei den EPK, ein Token-Ansatz verwendet. Der Prozessfluss findet also entlang des definierten Pfades statt, welcher von einem Token durchlaufen wird. Dieser kann wiederum in mehrere parallele Token geteilt und umgekehrt wiederum zu einem einzelnen zusammengeführt werden.
Die möglichen Flussobjekte sind
- die Aktivität,
- das Event und
- das Gateway.
Die grafische Darstellung der Flussobjekte ist in der Abbildung "BPMN Flussobjekte" ersichtlich.
Die Aktivität beschreibt dabei eine konkrete Tätigkeit, die bei ihrem Aufruf durchgeführt wird. Diese kann in komplexeren Modellen wiederum selbst aus Unteraktivitäten bestehen. Auf diese Form der weiteren Untergliederung wird hier jedoch nicht weiter eingegangen. Eine Aktivität hat immer eine Bezeichnung und kann zusätzlich eine bestimmte Ausprägung haben. Diese wird in der linken oberen Ecke in Form eines Symbols angezeigt. Aktivitäten werden oft auch als Aufgaben bezeichnet, wenn sie selbst nicht mehr in Teilaufgaben teilbar sind. Ein Beispiel hierfür wäre die Zubereitung eines Kaffees mit einer Kaffeemaschine. Das „Zubereiten eines Espressos“ wäre eine Aktivität, da sie auch weiter in „Tasse unterstellen“ und „Espressotaste drücken“ geteilt werden könnte. Der Druck auf die Espressotaste hingegen wäre eine Aufgabe, da sie nicht weiter teilbar ist.
Eine Aktivität ohne spezielle Ausprägung wird als abstrakt bezeichnet. Die unterschiedlichen Ausprägungen und ihre Symbole sind in der Abbildung "BPMN Aktivitäten mit Ausprägung" aufgelistet und beschrieben.
| Aktivitätsausprägung | Symbol | Beschreibung |
|---|---|---|
| Service-Aktivität | wird durch ein automatiches System durchgeführt | |
| Sende-Aktivität | führt das Senden einer Nachricht durch (Erstellung und Versand) | |
| Empfangs-Aktivität | führt das Empfangen einer Nachricht durch (Empfang und Verarbeitung) | |
| Benutzer-Aktivität | wird durch einen oder mehrere Menschen durchgeführt | |
| Manuelle-Aktivität | wird durch einen oder mehrere Menschen manuell und ohne IT Unterstützung durchgeführt | |
| Geschäftsregel-Aktivität | führt eine BPMN Geschäftsregel aus (wird in dieser Lektion nicht weiter behandelt) | |
| Script-Aktivität | führt ein Script innerhalb der Prozessumgebung aus (wird in dieser Lektion nicht weiter behandelt) |
BPMN Aktivitäten mit Ausprägung (Object Management Group (OMG), 2011, S. 385, 430)
Weiter ist es möglich, über eine Aktivität einen Sub-Prozess aufzurufen. Damit kann das Modell vereinfacht und mehrfach ausgeführte Prozessabläufe zusammengefasst werden. Ein Sub-Prozess wird durch ein kleines Quadrat mit einem Pluszeichen in der Mitte des unteren Bereiches der Aktivität dargestellt. Der Inhalt des Sub-Prozesses wird in Form eines eigenen Pools modelliert, welcher in diesem Abschnitt weiter unten genauer beschrieben wird. Ein Beispiel für einen Sub-Prozess Aufruf ist in der Abbildung "BPMN Sub-Prozesses Aufruf" dargestellt.
Ein Event ist ein bestimmtes Ereignis, welches eintreten und ausgelöst werden kann. Es kann dabei sowohl von außerhalb ausgelöst werden, als auch durch den modellierten Prozess selbst. Dabei wird zwischen Start-, Zwischen- und End-Events unterschieden. Ein Start-Event ist ein Ereignis, welches außerhalb des modellierten Prozesses ausgelöst wird und damit einen Einfluss auf einen Teil des Prozesses von außen hat. Start-Events werden daher auch zum Start des Prozesses eingesetzt. End-Events beenden einzelne Abläufe des Prozesses. Ist kein Teil des Prozesses mehr aktiv, da jeder Pfad in einem End-Event geendet hat, ist damit der gesamte Prozess beendet. Eine Ausnahme ist hierbei das End-Event vom Typ Terminierung, welches bei seinem Aufruf den gesamten Prozess beendet. Weiter gibt es noch Events, welche innerhalb des Prozesses ausgelöst werden und wiederum einen anderen Teil des eigenen Prozesses beeinflussen. Diese Events werden als Zwischen-Events bezeichnet.
Je nachdem um welchen Event Typ es sich handelt wird die Umrandung des Kreises anders dargestellt. Die unterschiedlichen Event-Typen sind in der Abbildung "BPMN Event-Typen" dargestellt.
Der Start eines Prozessflusses wird immer durch ein oder mehrere Start-Events begonnen und durch ein oder mehrere End-Events beendet.
Zusätzlich kann der Typ eines Events durch einen zugehörigen Auslöser oder ein Resultat beschrieben werden. Die wichtigsten Auslöser oder Resultate sind:
- Nachricht,
- Signal,
- Timer,
- Bedingung,
- Verknüpfung und
- Terminierung.
Bei einer Nachricht handelt es sich um eine Benachrichtigung von außen an den Prozess oder umgekehrt, sowie möglicher Benachrichtigungen zwischen Aktivitäten. Signale sind, im Gegensatz zu Nachrichten, Benachrichtigungen welche ohne bestimmte Empfänger an alle gerichtet sind, die sie auffangen können. Timer erlauben, zwischen den Aktivitäten ein bestimmtes Zeitintervall oder einen Zeitpunkt abzuwarten und Start-Events in einem bestimmten Intervall oder Zeitpunkt zu starten. Bei Bedingungen handelt es sich um Events, welche unter einer bestimmten Bedingung ausgeführt werden oder auf eine bestimmte Bedingung warten. Bei den Verknüpfungen handelt es sich um einen Sonderfall von Events, welche eine grafische Möglichkeit darstellen den Prozessfluss innerhalb des Diagramms zu unterbrechen und an einer anderen Stelle fortzusetzen. Dabei ist es wichtig, die Verknüpfung an beiden Stellen im Diagramm gleich zu benennen. Die Terminierung beendet den gesamten Ablauf unmittelbar nach ihrem Eintreten, egal ob noch parallele Aktivitäten offen sind, oder nicht.
In Tabelle 7 findet sich eine Tabelle der wichtigsten Symbole der Auslöser und Resultate und in welchen Event-Typen ihre Verwendung zulässig ist.
Tabelle 7 – BPMN Event Auslöser und Resultate (Object Management Group (OMG), 2011, S. 261)
| Symbol | Zulässig als Start-Event | Zulässig als Zwischen-Event | Zulässig als Ende-Event | |
|---|---|---|---|---|
| Nachricht | Ja | Ja | Ja | |
| Signal | Ja | Ja | Ja | |
| Timer | Ja | Ja | Nein | |
| Bedingung | Ja | Ja | Nein | |
| Verknüpfung | Nein | Ja | Nein | |
| Terminierung | Nein | Nein | Ja |
Gateways dienen dem Ablauffluss zwischen den Aktivitäten untereinander und zwischen Aktivitäten und Events. Sie ermöglichen den Ablauf zu teilen und wieder zusammenzuführen. Der Ablauf findet dabei immer nach dem Token-Ansatz statt. Das bedeutet, dass es immer einen bestimmten Teil des Pfades gibt, der gerade aktiv ist. Durch die Teilung des Prozess-Flusses mittels Gateways können mehrere parallele Abarbeitungen erfolgen und auch bestimmte Pfade unter bestimmten Bedingungen ausgewählt werden.
Die wichtigsten Gateway-Typen sind:
- Exklusives Oder (Entweder-Oder Verbindung),
- Inklusives Oder (Und-Oder Verbindung),
- Parallel (Und Verbindung) und
- Komplex (Kombination mehrerer Verbindungsarten).
Mit einem exklusiven Oder-Gateway werden mögliche Pfade vorgegeben, von denen genau einer eingeschlagen werden kann. In der Abbildung "BPMN: Exklusives Gateway" ist die mögliche Verwendung von Gateways mit exklusivem Oder dargestellt. Hier löst des Event Start die Aktivität 1 aus und wird nachher durch das exklusive Oder geteilt. Je nachdem ob Bedingung 1 oder Bedingung 2 erfüllt ist, wird der Ablauf bei Aktivität 2 oder Aktivität 3 fortgesetzt. Damit beide Aktivitäten am Event Ende abschließen können, werden die Pfade nach den beiden möglichen Aktivitäten wieder über ein exklusives Oder zusammengeführt. Grundsätzlich werden Pfade immer mit demselben Gateway-Typ zusammengeführt, mit dem sie auch geteilt wurden.
Bei einem inklusiven Oder-Gateway werden mögliche Pfade vorgegeben, von denen einer oder mehrere eingeschlagen werden können. In der Abbildung "BPMN: Inklusives Gateway" ist die mögliche Verwendung von Gateways mit inklusivem Oder dargestellt. Hier löst des Event Start ebenfalls die Aktivität 1 aus und wird nachher durch das inklusive Oder geteilt. Je nachdem ob Bedingung 1 oder Bedingung 2, oder beide Bedingungen, erfüllt sind, wird der Ablauf bei Aktivität 2, Aktivität 3 oder bei beiden Aktivitäten parallel fortgesetzt. Damit beide Aktivitäten am Event Ende abschließen können, werden die Pfade nach den beiden möglichen Aktivitäten wieder über ein inklusives Oder zusammengeführt. Das zusammenführende inklusive Oder wartet, je nach der Anzahl der eingeschlagenen Pfade des verteilenden inklusiven Oder auf nur eine oder beide eingehenden Aktivitäten.
Damit es bei der Aufteilung der Pfade nicht zum Stillstand des Gesamtablaufes kommen kann wird empfohlen, bei Oder-Bedingungen, einen zusätzlichen Standardfluss ohne Bedingung zu modellieren welcher ausgeführt wird, wenn keine der übrigen Bedingungen zutrifft (ähnlich dem Default-Zweig eines Select-Case Statements). (Freund & Rücker, 2014, S. 39f)
Bei einem Parallel-Gateway werden mögliche Pfade vorgegeben, welche alle gleichzeitig, ohne zusätzliche Bedingungen, eingeschlagen werden. In der Abbildung "Parallel Gateway" ist die mögliche Verwendung von Parallel Gateways dargestellt. Hier löst des Event Start wieder die Aktivität 1 aus und wird nachher durch das Parallel Gateway geteilt. Der Ablauf wird daher parallel bei Aktivität 2 und Aktivität 3 fortgesetzt. Damit der Prozess-Fluss, nach der Ausführung beider Aktivitäten, am Event Ende abschließen kann, werden die Pfade wieder über ein Parallel Gateway zusammengeführt. Das bedeutet, dass das Gateway abwartet, bis beide seiner Eingangspfade, nach dem Abschluss aller parallel ausgeführten Aktivitäten, aktiv sind und erst dann die Ausführung mit der Auslösung des Events Ende fortsetzt.
Ein komplexes Gateway kann zur Kombination mehrerer verketteter Gateway-Arten in einem einzelnen Gateway genutzt werden. Die Aktivierung der einzelnen Pfade ist dabei von einer rein verbalen Bedingung abhängig, welche beliebig komplex sein kann (z.B.: zwei Aktivitäten aus fünf möglichen müssen ausgeführt werden). Genauso verhält es sich auch beim Zusammenführen paralleler Pfade. In der Abbildung "BPMN: komplexes Gateway" ist die mögliche Verwendung von komplexen Gateways dargestellt. Hier löst des Event Start wieder die Aktivität 1 aus und wird nachher durch das Gateway geteilt, wobei zwei aus fünf möglichen Aktivitäten ausgeführt werden müssen. Nach dem Abschluss der beiden Aktivitäten wird dann die Ausführung wieder mit der Auslösung des Events Ende fortsetzt. Die verbale Beschriftung der Gateways erfolgt dabei direkt mittels Freitext-Anmerkungen.
Wie im vorherigen Beispiel der komplexen Gateways bereits eingesetzt, gibt es die Möglichkeit bestimmte Freitext-Anmerkungen zu einzelnen Elementen zu machen, indem eine eckige Klammer mit einer gestrichelten Linie mit dem jeweiligen Element verbunden wird. Hinter die Klammer wird dann die Freitext-Anmerkung geschrieben. Diese Anmerkungen gehören zur Gruppe der Artefakte.
Ein weiteres Artefakt ist die Gruppierung. Dabei können mehrere Teile des Diagramms durch ein gepunktet-gestricheltes Rechteck eingefasst werden, um ihre logische Zusammengehörigkeit zu verdeutlichen. Dies hat jedoch keinerlei Auswirkung auf die Funktionalitäten des Prozesses. In das System zusätzlich eingebrachte eigene Symbole gelten auch als Artefakte und haben ebenfalls keine Auswirkung auf den Ablauf. Ein Beispiel für eine Gruppierung ist in der Abbildung "BPMN: Gruppierung" dargestellt. Hier sind die Elemente Aktivität 2 und Aktivität 3 zu einer Gruppe mit der Bezeichnung Gruppe 1 zusammengefasst. Auf den Ablauf des Modells hat dies jedoch keinerlei Auswirkung.
Die Teilnehmer eines Prozesses werden über Pools mit darin optional enthaltenen Lanes dargestellt. Dabei ist zu beachten, dass es sich bei einem Teilnehmer nicht immer um eine Person, sondern auch um eine Personengruppe, Rolle, Organisationseinheit oder auch um ein bestimmtes System handeln kann. Innerhalb eines Pools werden all die Prozessteile dargestellt, die von seinen Teilnehmern ausgeführt werden. Innerhalb eines Pools können weitere Unterteilnehmer definiert werden, welche den definierten Teilnehmerkreis weiter unterteilen. Diese Unterteilungen werden als Lanes bezeichnet und können wiederum weiter ineinander verschachtelt werden. Wichtig ist dabei, dass diese Unterteilnehmer innerhalb des übergeordneten Teilnehmerkreises an demselben Prozess beteiligt sind. Eine Aktivität wird dabei immer in der Lane des Teilnehmers eingezeichnet, der sie durchführt. Soll eine Aktivität von mehreren Teilnehmern durchgeführt werden, muss sie in jeder Lane separat eingezeichnet werden. Eine Aktivität darf nicht über mehrere Lanes hinweg gezeichnet werden. Der Grund dieser Regel liegt in der Eindeutigkeit der Aktivitätsdurchführung und Zuständigkeit. Wird beispielsweise eine Aktivität entweder von Teilnehmer 1 oder Teilnehmer 2 ausgeführt, wird sie vorab über ein exklusives Oder-Gateway in zwei idente Aufgaben in beiden Lanes aufgeteilt und anschließend wieder zusammengeführt. Damit ist sichergestellt, dass für ihre Ausführung genau einer der beiden Teilnehmer erforderlich ist. In der Abbildung "BPMN: Pool mit Lanes" ist ein einfaches Prozessdiagramm dargestellt, welches das Zusammenspiel mehrerer Lanes in einem Pool zeigt. Hier führt nach dem Start des Prozesses Teilnehmer 1 die Aktivität 1 aus. Danach werden Aktivität 2 von Teilnehmer 2 und Aktivität 3 von Teilnehmer 3 gestartet. Sobald beide Aktivitäten abgeschlossen sind, wird noch Aktivität 4 von Teilnehmer 1 ausgeführt und der Prozessfluss danach abgeschlossen. Es wurde in diesem Beispiel weiter davon ausgegangen, dass Aktivität 2 und Aktivität 3 thematisch zusammengehören und daher eine Gruppierung eingezeichnet. Dies hat jedoch keinen Einfluss auf den Ablauf und dient einzig der Übersichtlichkeit.
Gibt es in einem Prozessdiagramm mehrere Pools, stellen diese getrennte Teilnehmerkreise mit getrennten Prozessabläufen dar. Es handelt sich dabei um kollaborative Prozesse. Hierbei ist zu beachten, dass die Prozesse nicht direkt über Gateways oder Aktivitäten miteinander verknüpft werden dürfen, da sie in getrennten Systemen stattfinden. Zur Interaktion mehrerer Pools werden Nachrichtenflüsse verwendet. Diese werden als gerichtete gestrichelte Linie dargestellt. Dabei muss beachtet werden, dass ein Gateway keine direkten Aufrufe von Aktivitäten in einem anderen Pool durchführen darf und auch nicht mit Gateways des anderen Pools verknüpft werden kann. Befindet sich ein Nachrichtenfluss direkt zwischen zwei Aktivitäten, handelt es sich um eine Abstimmung der Aktivitäten mittels Nachrichten. Zwischen einer Aktivität und einem Ereignis wird ein Ereignis ausgelöst oder empfangen. Zusätzlich ist es möglich, nicht mit einem Prozessteil eines Pools, sondern mit seinen Teilnehmern zu interagieren. Dazu wird ein Nachrichtenfluss direkt zur Außenkante des gewünschten Poos gezeichnet. Damit ist es auch möglich, Nachrichten an und von Teilnehmern darzustellen, deren Prozess inhaltlich nicht modelliert wird.
Die unterschiedlichen Formen von Nachrichtenflüssen sind in der Abbildung "BPMN: Mehrere Pools und Nachrichtenflüsse" dargestellt. Hier gibt es zwei verschiedene Prozessabläufe zweier unterschiedlicher Teilnehmerkreise und damit unterschiedlicher Pools. Der Teilnehmerkreis 1 teilt sich selbst wiederum in zwei unterschiedliche Teilnehmer, welche mittels Lanes in den Pool integriert sind. Der erste Nachrichtenfluss findet zwischen Aktivität 1 und dem Startevent im Pool von Teilnehmerkreis 2 statt. Dabei wird durch die Ausführung von Aktivität 1 eine Nachricht ausgelöst, welche gleichzeitig auch der Start-Event von Teilnehmerkreis 2 ist. Der nächste Nachrichtenfluss geschieht zwischen Aktivität B und Aktivität 3. Hier benötigt Aktivität 3 Informationen aus Aktivität B. Der letzte Nachrichtenfluss geschieht durch Ausführung von Aktivität 4. Diese benachrichtigt jedoch kein Element in Teilnehmerkreis 2, sondern den Teilnehmerkreis 2 selbst.
Web Service Business Process Execution Language (WS-BPEL)
Bei der Web Service Business Process Execution Language (WS-BPEL) handelt es sich um eine Möglichkeit, die in der BPMN modellierten Prozesse in einem technischen Prozessmodell abzubilden. Dazu wird eine XML Struktur verwendet, welche viele der BPMN Elemente und ihre Interaktionen beinhaltet. Das Hauptaugenmerk liegt hierbei in der Zusammenführung von Webservices zu einem integrierten Prozess. WS-BPEL war ursprünglich der direkte Vorgänger von BPMN und ist durch seine spezielle Ausrichtung, hin zu XML Webschnittstellen, sehr in seinen Anwendungsmöglichkeiten beschränkt. (Freund & Rücker, 2014, S. 231f)
In der BPMN 2.0 Spezifikation sind die Überführungen von der BPMN zur WS-BPEL im Detail beschrieben. (Object Management Group (OMG), 2011, S. 445ff)
Beispiel eines BPMN
In diesem Beispiel soll der Prozess einer Kaffeezubereitung in einer Büroküche modelliert werden. Die Teilnehmer des Prozesses sind alle Mitarbeiter der Abteilung. Diese untergliedern sich in die Mitarbeiter, die Kaffee trinken wollen, und den Mitarbeiter, der ebenfalls für die Wartung der Kaffeemaschinezuständig ist.
Sobald ein Mitarbeiter einen Kaffee möchte, prüft er zuerst ob die Kaffeemaschine korrekt funktioniert. Ist dies der Fall, sucht er sich einen Kaffee (Espresso, Ristretto oder Lungo) aus und bereitet diesen zu. Nach der Zubereitung trinkt er den Kaffee und hat seinen Kaffeebedarf damit gestillt. Sollte die Kaffeemaschine nicht funktionieren informiert er den Service-Verantwortlichen der Abteilung. Dieser überprüft wiederum die Kaffeemaschine hinsichtlich ihrer möglichen Probleme. Ist sie verkalkt, entkalkt er sie, fehlen Bohnen, füllt er Bohnen nach und wenn sie defekt ist, beauftragt er den Hersteller-Service mit einer Reparatur. Alle Probleme können auch gleichzeitig vorhanden sein, daher ist es auch möglich, dass er mehrere der Servicetätigkeiten parallel vornimmt. Im Falle eines Gerätedefektes wird der Service-Verantwortliche wieder vom Hersteller-Service informiert, sobald die Kaffeemaschine repariert ist. Sind alle Servicearbeiten beendet, und die Maschine damit wieder einsatzbereit, informiert der Service-Verantwortliche Kollege die Mitarbeiter der Abteilung. Stellt er hingegen fest, dass überhaupt kein Problem besteht, informiert er direkt die Mitarbeiter der Abteilung, ohne Servicetätigkeiten durchzuführen.
