BPMN

Was ist BPMN 2.0?

BPMN 2.0 ist die international genormte Notation für Geschäftsprozesse. Sie legt fest, welche Symbole ein Prozessdiagramm verwendet, was jedes Symbol bedeutet und wie ein Modell als XML-Datei gespeichert wird. Seit 2013 ist die Notation als ISO/IEC 19510 veröffentlicht, gepflegt wird sie von der Object Management Group (OMG 2014; ISO/IEC 19510:2013).

Der Anspruch der Notation steht in der Spezifikation selbst: Sie soll für alle Beteiligten lesbar sein, vom Fachbereich, der den ersten Entwurf zeichnet, über die Entwickler, die den Prozess technisch umsetzen, bis zu den Verantwortlichen, die ihn später steuern. BPMN will damit die Lücke zwischen fachlichem Prozessentwurf und technischer Umsetzung schließen (Weske 2024, S. 210). Anders als ihre Vorgänger, etwa UML-Aktivitätsdiagramme oder ereignisgesteuerte Prozessketten, deckt BPMN alle Abstraktionsebenen ab, von der groben Fachsicht bis zum ausführbaren Modell.

Damit Werkzeuge vergleichbar bleiben, definiert der Standard Konformitätsklassen. Für die Modellierung gibt es drei Teilmengen: die beschreibende Teilmenge mit wenigen Symbolen für Fachmodelle, die analytische Teilmenge mit dem erweiterten Symbolvorrat und die ausführbare Teilmenge für Prozesse, die eine Engine steuern soll (Weske 2024, S. 211). Wer Prozesse dokumentiert, arbeitet fast immer in der ersten Klasse.

Welche Elementkategorien hat BPMN?

Die Spezifikation ordnet alle Symbole fünf Kategorien zu: Flussobjekte, Daten, Verbindungsobjekte, Swimlanes und Artefakte (OMG 2014, S. 25 f.). Wer diese fünf Gruppen kennt, kann jedes BPMN-Diagramm lesen, auch wenn ein einzelnes Symbol unbekannt ist, weil sich die Bedeutung aus der Kategorie ergibt.

• Flussobjekte bestimmen das Verhalten des Prozesses. Es gibt drei Arten: Ereignisse (Kreise), Aktivitäten (abgerundete Rechtecke) und Gateways (Rauten).
• Daten zeigen, welche Informationen ein Prozess braucht oder erzeugt: Datenobjekte, Dateneingaben, Datenausgaben und Datenspeicher.
• Verbindungsobjekte verknüpfen die Elemente: Sequenzflüsse für die Reihenfolge, Nachrichtenflüsse für die Kommunikation zwischen Beteiligten sowie Assoziationen und Datenassoziationen.
• Swimlanes ordnen Zuständigkeiten zu. Ein Pool steht für einen Beteiligten, Lanes unterteilen ihn nach Rollen oder Abteilungen.
• Artefakte liefern Zusatzinformationen ohne Einfluss auf den Ablauf: Gruppen und Textanmerkungen.

In der Praxis genügt für fachliche Modelle ein kleiner Ausschnitt: Aufgaben, Start- und End-Ereignisse, XOR- und AND-Gateways, Pools, Lanes und Sequenzflüsse. Die Basisnotation orientiert sich bewusst an bekannten Swimlane-Diagrammen, deshalb verstehen auch ungeübte Leser Rechtecke als Tätigkeiten, Kreise als Ereignisse und Rauten als Entscheidungen (Gadatsch 2025, S. 157).

Wie liest man ein BPMN-Diagramm?

Ein BPMN-Diagramm liest sich von links nach rechts entlang des Sequenzflusses: Es beginnt mit einem Start-Ereignis, durchläuft Aufgaben und Gateways und endet in einem oder mehreren End-Ereignissen. Die Abbildung oben zeigt genau diesen Grundfall.

Der Pool steht für ein Unternehmen, die beiden Lanes für die Abteilungen Vertrieb und Support. Das grüne Start-Ereignis löst den Prozess aus, etwa durch eine eingehende Anfrage. Die Aufgabe „Anfrage prüfen“ liegt in der Lane Vertrieb, weil diese Abteilung dafür zuständig ist. Das XOR-Gateway stellt eine Entweder-oder-Entscheidung dar: Entweder wird das Angebot erstellt, oder der Support klärt zuerst eine Rückfrage. Jeder Pfad endet in einem roten End-Ereignis.

Drei Leseregeln helfen bei jedem Diagramm. Erstens: Die Lane sagt, wer eine Aufgabe ausführt, nicht die Beschriftung. Zweitens: Ein Gateway trifft keine Entscheidung, es zeigt nur, dass sich der Ablauf verzweigt oder zusammenführt; die Bedingung steht an der ausgehenden Kante. Drittens: Nachrichtenflüsse (gestrichelt) verlassen einen Pool, Sequenzflüsse (durchgezogen) bleiben immer innerhalb eines Pools.

Welche Modellierungsregeln haben sich bewährt?

Die empirisch am besten belegten Regeln sind die sieben Modellierungsrichtlinien von Mendling, Reijers und van der Aalst. Sie beruhen auf Untersuchungen, welche Modelleigenschaften Verständlichkeit und Fehlerquote beeinflussen (Mendling et al. 2010).

1. So wenige Elemente wie möglich verwenden. Größere Modelle sind schwerer verständlich und fehleranfälliger.
2. Die Zahl der ein- und ausgehenden Kanten je Element klein halten.
3. Genau ein Start- und ein End-Ereignis verwenden, wo immer es geht.
4. So strukturiert wie möglich modellieren: Zu jedem öffnenden Gateway gehört ein schließendes desselben Typs.
5. OR-Gateways vermeiden, weil ihre Zusammenführung mehrdeutig ist.
6. Aktivitäten nach dem Muster Verb plus Objekt beschriften, etwa „Rechnung prüfen“.
7. Modelle mit mehr als 50 Elementen in Teilprozesse zerlegen.

Gadatsch ergänzt drei Praxisregeln für lesbare Fachmodelle: unnötige Details weglassen, den Kontrollfluss konsequent von links nach rechts führen, ohne dass sich Kanten kreuzen, und im Unternehmen einheitliche Symbole und Beschriftungsregeln festlegen (Gadatsch 2025, S. 170).

Wo liegen die Grenzen von BPMN?

BPMN beschreibt Abläufe, nicht die Organisation und nicht die Daten eines Unternehmens. Wer ein Organigramm, ein Datenmodell oder eine Systemlandschaft braucht, benötigt ergänzende Darstellungen. Auch die Bedingungen an Gateways und die Ausdrücke in ausführbaren Modellen regelt der Standard nicht; sie bleiben dem Modellierer oder dem Werkzeug überlassen, weshalb Weske BPMN eher als Rahmenwerk denn als vollständige Sprache beschreibt (Weske 2024, S. 212).

Die Kehrseite des großen Symbolvorrats ist der Schulungsaufwand. Bei vollständigem Einsatz sind Notation und Regeln komplex, und ohne Modellierungswerkzeug lassen sich BPMN-Modelle kaum pflegen (Gadatsch 2025, S. 171). Für kleine und mittlere Unternehmen heißt das: mit der beschreibenden Teilmenge starten, Regeln für Symbole und Beschriftungen festlegen und den Symbolvorrat erst erweitern, wenn ein konkreter Bedarf entsteht.