Geschäftsprozesse modellieren mit dem Business Process Model and Notation (BPMN)
https://bildung.social/@oerinformatik/113306383647472168
https://oer-informatik.de/bpmn
tl/dr; (ca. 8 min Lesezeit): Bevor Geschäftsprozesse optimiert und digitalisiert werden, müssen die bestehenden Geschäftsprozesse verstanden und modelliert werden. Eine Modellierungssprache, die sich hierauf spezialisiert hat, ist Business Process Model and Notation (BPMN). Das Flussdiagramm besteht aus Ereignissen, Aktivitäten und Gateways und bietet eine erweiterbare Notationsfülle. Eine Einführung und grundlegende Notationsmittel finden sich in diesem Artikel. (Zuletzt geändert am 04.05.2025)
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Nach Durchlesen des Artikels kann ich…
… Einsatzzweck und Vorteile von BPMN benennen,
… die Grundstruktur eines BPMN aus Ereignissen, Aktivitäten und Gateways erklären,
… alternative, parallele und Ereignis-basierte Verzweigungen modellieren,
… zwischen Sequenzfluss und Nachrichtenfluss unterscheiden,
… Geschäftsprozesse auf Lanes aufteilen und mit anderen Pools kommunizieren lassen,
… bekannte Geschäftsprozesse mithilfe der BPMN modellieren,
… BPMN-modellierte Geschäftsprozesse lesen, erklären und darauf basierend optimieren.
Das BPMN als Sprache der Problemdomäne
Flussdiagramme werden verwendet, um feste, immer gleiche Abläufe zu dokumentieren, sie so reproduzierbar zu machen und darüber Qualität zu sichern. Sie bestehen allgemein aus Knoten (Aktivitäten, Verzweigungen) und Kanten (Pfeilen). Wir kennen Flussdiagramme in der IT beispielsweise in Form von Programmablaufplänen, mit denen wir einfache Algorithmen beschreiben können. Komplexere Abläufe in der IT beschreiben wir beispielsweise mit dem UML-Aktivitätsdiagramm.
Programmablaufplan und Aktivitätsdiagramm sind geläufige Diagramme für Informatiker, sie beschreiben Daten- und Kontrollflussabläufe und dienen uns zur Beschreibung der Lösung eines bestimmten Problems. Sie gehören also der Lösungsdomäne an.
Neue IT-Projekte basieren häufig auf der Optimierung bestehender Geschäftsprozesse. Deren Verständnis ist in den auftraggebenden Unternehmen ein betriebswirtschaftliches: sie werden nicht als Daten- und Kontrollflussabläufe verstanden, sondern als Abfolge betriebswirtschaftlicher Aktivitäten, die Arbeitspakete repräsentieren. Die Geschäftsprozesse werden in Unternehmen in der Regel nicht von Informatiker*innen dokumentiert und beschrieben, sondern von der jeweiligen Fachabteilung. Entsprechend erfolgt die Dokumentation mithilfe von betriebswirtschaftlichen Auszeichnungen - in der Sprache der Problemdomäne.
Neben der Ereignisgesteuerten Prozesskette (EPK / eEPK) dient Business Process Model and Notation (BPMN) häufig als Flussdiagramm zur Modellierung und Dokumentierung von Geschäftsprozessen.
Wer sich direkt in der Primärquelle - der Spezifikation - informieren will, wird zunächst einen Schrecken bekommen: sie umfasst derzeit 532 Seiten. Die meisten Fragen klärt aber ein Blick in Kapitel 7.3.1 Basic BPMN Modeling Elements - hier werden auf 13 Seiten die Notationselemente und deren Besonderheiten kurz vorgestellt.
Ereignisse (Events) als Token-Quelle und Token-Senke
In einem Flussdiagramm wird beginnend von einem Startpunkt eine Abfolge durchlaufen. An welcher Stelle der Abfolge man sich gerade befindet, kann man sich mit einer Art imaginärer Markierung vorstellen - man nennt diese Token.
Der Startpunkt eines solchen Diagramms kann man als Tokenquelle verstehen - der Token fließt in Richtung der Pfeile durch das Diagramm. Der Token kann in Zwischenereignissen pausieren und wird am Ende im Endereignis konsumiert.
Alle Ereignisse werden als Kreise dargestellt (Start: einfach, Zwischenereignis: doppelt, Ende: dick). Ereignisse finden zwischen den eigentlichen Arbeitsschritten (den Aktivitäten) statt.
Zur näheren Beschreibung können nach BPMN Annotationen verwendet werden (siehe oben die Beschriftungen).
Ereignisse haben häufig einen Auslöser (trigger) und ein Ergebnis (result).
Alle Geschäftsprozesse beginnen und enden mit einem Ereignis, jedoch können Start- und Endereignis auch implizit aus dem Diagramm hervorgehen und müssen nicht in jedem Fall eingezeichnet werden.
Aktivitäten
Aktivitäten repräsentieren Arbeit, die während eines Geschäftsprozesses erledigt wird. Wenn eine Aktivität aus einer einzelnen, nicht weiter teilbaren Aufgabe besteht (atomic activity) spricht man von Tasks. Wenn Aktivitäten aus zusammengesetzten Aufgaben (compound activity) bestehen, spricht man von Subprozessen (Sub-Process).
Subprozesse können in kompakter Form dargestellt werden (collapsed sub-process), dann wird mit einem Pluszeichen angedeutet, dass die einzelnen Aktivitäten, aus denen sich ein Subprozess zusammensetzt, in einem weiteren Diagramm im Detail dargestellt werden.
Die Unteraktivitäten können aber auch direkt im selben Diagramm innerhalb des Subprozesses dargestellt werden (expanded sub-process):
Gateways
Die Abfolge von Aktivitäten muss nicht immer sequenziell sein, sondern kann verzweigt, zusammenführend oder parallel erfolgen. Das wird im BPMN mit Gateways in Rauten notiert.
Einfache Verzweigung (exklusives Oder)
Eine einfache Verzweigung ist ein exklusives Oder: nur eine der ausgehenden Kanten wird genommen. Die Bedingungen werden an den Kanten notiert, die Raute selbst darf leer sein - oder (besser, weil eindeutiger:) ist mit einem “X” gefüllt.
Sobald eine der an den Kanten genannten Bedingungsausdrücke zutrifft, wird der Pfad dieser Kante genommen und die weiteren Bedingungen nicht mehr geprüft. Häufig werden bei Verzweigungen default-Pfade angegeben: diese Pfade nimmt der Token, sofern keine der Bedingungen als zutreffend ausgewertet wurde. Gekennzeichnet wird der default-Zweig mit einem schrägen Strich auf dem Pfeil (und häufig dem Text “default” statt einer Bedingung) - in obigem Diagramm ist dies an dem rot markierten Pfad zu erkennen. Durch default-Zweige kann verhindert werden, dass bei einfachen Verzweigungen kein Pfad genommen werden kann - und somit der modellierte Ablauf eine Ausnahme (Exception) werfen muss (also so nicht navigierbar ist).
Die alternativen Sequenzflüsse können mit einem weiteren Gateway wieder vereinigt werden (merge, unten grün eingezeichnet) oder direkt mit mehreren eingehenden Kanten in eine Aktivität münden (unten blau eingezeichnet). Es reicht also, wenn an einer eingehenden Kante ein Token anliegt (anders beim UML-Aktivitätsdiagramm: hier müssen an allen eingehenden Kanten Token anliegen, damit die Aktivität gestartet wird).
Parallele Abläufe
Sofern mehrere Aktivitäten parallel ausgeführt werden müssen, wird dies mit dem parallel gateway notiert (eine Raute mit “+”). Die Pfade werden also alle durchlaufen (“Und”-Logik), nicht alternativ. Sobald an allen eingehenden Kanten ein Token anliegt wird an allen ausgehenden Kanten ein Token erzeugt. Daher kann dieses Gateway sowohl zur Parallelisierung (im Beispiel grün) als auch zur Synchronisierung (im Beispiel blau) verwendet werden:
Inklusive Abläufe
Sofern mehrere parallele Aktivitäten möglich, aber nicht zwingend erforderlich sind, kommt ein inklusives Gateway ins Spiel: bei dieser Art Verzweigung werden die Bedingungen an allen ausgehenden Kanten geprüft und überall, wo sie zutreffen wird ein Token gefeuert. Das Gateway wird als Raute mit einem Kreis dargestellt (im folgenden Diagramm gelb hervorgehoben):
Da es in diesem Fall wieder dazu kommen kann, dass die Bedingung an keiner ausgehenden Kante zutrifft (womit das BPMN dort nicht navigierbar wäre) ist zu empfehlen, wieder einen default-Pfad zu kennzeichnen (Strich durch den Pfeil, hier rot hervorgehoben). Dieser Pfad wird gewählt, sofern von keinem anderen Pfad die Bedingung zutrifft.
Ereignis-basierte Verzweigungen
Bisher haben wir anhand von Bedingungen entschieden, welcher Pfad genommen wird (exklusive und inklusive Verzweigungen). Darüber hinaus besteht die Möglichkeit, diese Entscheidung durch Eintreten unterschiedlicher Events zu treffen. Die Bedingungen sind häufig an interne Prozessdaten geknüpft, wohingegen Ereignisse häufig von aussen auf einen Geschäftsprozess treffen.
Im untenstehenden Beispiel wird die Bearbeitung des Angebots abhängig davon weitergeführt, ob ein Auftrag eingeht (message intermediate event, grün gekennzeichnet) oder das Angebot abgelaufen ist (timer intermediate event, hier blau gekennzeichnet). Das Gateway selbst wird durch ein in einen Doppelkreis eingefasstes Fünfeck in der Gateway-Raute notiert (hier lila gekennzeichnet). Alle folgenden Events müssen als Zwischenereignisse (intermediate events) ebenso in einen Doppelkreis eingefasst sein.
Sequenz- und Nachrichtenfluss
In der Informatik unterscheiden wir häufig Kontrollfluss und Datenfluss (beispielsweise im UML-Aktivitätsdiagramm). Im BPMN wird die Reihenfolge von Aktivitäten mit dem Sequenzfluss (sequence flow) abgebildet: die Token, die kennzeichnen, welche Aktivität gerade ausführt wird, bewegen sich in der Richtung der Sequenzflusspfeile (durchgezogene Linien, gefüllte Pfeilspitze). Die Entsprechung im Programmablaufplan und UML-Aktivitätsdiagramm wäre der Kontrollfluss.
Innerhalb eines Geschäftsprozesses kommt es auch zu Nachrichtenflüssen (message flow) zwischen den Teilnehmern. Der Nachrichtenfluss wird mit gestrichelten Linien und nicht-ausgefüllter Pfeilspitze dargestellt.
Einige Beispiele für Nachrichtenflüsse sind im Diagramm des folgenden Abschnitts farblich hervorgehoben.
Nachrichten können mit einem Message Start Event (unten gelb hervorgehoben) empfangen werden, das markiert den Beginn eines Prozesses. Innerhalb eines Prozesses können sie mit einem Catch-Message-Intermediate-Event (unten grün hervorgehoben) empfangen werden - der Prozess pausiert dann, bis die Nachricht eintrifft. Das gleiche Verhalten kann mit dem Receive Tasks (Aktivität mit nicht ausgefülltem Briefumschlag, unten blau markiert) erzielt werden.
Nachrichten senden kann man unter anderem mit einem Send Task (Aktivität mit ausgefülltem Briefumschlag, unten lila hervorgehoben), einem Throw-Message-Intermediate-Event (im Kreis, lila) oder einem Throw-Message-End-Event (im Kreis, rot).
Verantwortlichkeiten mit Swimlanes und Pools
Wenn an einem Geschäftsprozess mehrere Teilnehmer zusammenarbeiten, können diese Rollen, Teilnehmer oder Verantwortlichkeiten graphisch mit Pools oder Lanes abgebildet werden.
Ein Pool stellt hierbei einen Bereich dar, innerhalb dessen ein Geschäftsprozess abläuft. Es gibt keinen Sequenzfluss über die Poolgrenzen hinaus. Die gesamte Verantwortlichkeit eines Prozesses liegt innerhalb des Pools. Sollte Interaktion mit anderen Rollen/Verantwortlichkeiten ausserhalb des Pools nötig sein, so wird dies über Nachrichtenflüsse dargestellt. Ein Geschäftsprozess kann sich auf mehrere Lanes (hier: Fachabteilung, Buchhaltung) aufteilen, findet aber immer innerhalb eines Pools (hier: Dienstleister) statt.
Die Interaktion zwischen Pools kann als Blackbox dargestellt werden, ohne dass der gegenüberliegende Geschäftsprozess bekannt ist (siehe unten: Custom-Relationship-Datenbank) oder kann unmittelbar an Aktivitäten des Geschäftsprozesses eines anderen Pools andocken (siehe Kunde).
Weitere Notationen
Der BPMN-Standard umfasst über 500 Seiten - entsprechend viele weitere Notationsmittel gibt es. Darüber hinaus kann BPMN noch erweitert werden und so an die Bedürfnisse der Institutionen angepasst werden. Die hier genannten Notationsmittel stellen also nur einen ersten Einblick in die Fülle dar, wie Prozesse mit BPMN modelliert und dokumentiert werden können.
Da die Symbolik weitgehend selbsterklärend ist, sollte dieser Einblick trotzdem reichen, um bestehende BPMN richtig zu interpretieren, an Hand des Standards weitere Notationsmittel verstehen oder einfache BPMN selbst erstellen zu können.
Tools zur Erstellung von BPMN
Zur Erstellung eigener BPMN eignen sich u.a. die Online-Tools:
Auch draw.io / diagrams.net bietet die Möglichkeit, die BPMN-Notationselemente zu zeichnen.
Professionelle Tools zur Erstellung von BPMN sind beispielsweise:
Links und weitere Informationen
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Geschäftsprozesse modellieren mit dem Business Process Model and Notation (BPMN)” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/bpmn veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/projekt/prozessmodellierung. Stand: 04.05.2025.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
