BPMN 2.0 — Ein praktischer Einstieg in die Geschäftsprozessmodellierung

Die Business Process Model and Notation in der Version 2.0 ist seit Jahren der bevorzugte Standard, wenn Organisationen ihre Abläufe formal beschreiben wollen. Sie wird von der Object Management Group gepflegt und ist sowohl in großen Konzernen als auch in mittelständischen Unternehmen verbreitet. Entscheidend für ihre Durchsetzung war der Anspruch, eine gemeinsame Sprache für Fachbereich, IT und Prozessmanagement zu schaffen.

Warum BPMN überhaupt?

Viele Organisationen arbeiten über Jahre mit Flussdiagrammen, Textbeschreibungen oder hausinternen Notationen. Das funktioniert, solange der Kreis der Beteiligten überschaubar bleibt. Sobald Prozesse jedoch über Abteilungsgrenzen laufen, automatisiert werden sollen oder regulatorisch nachweisbar sein müssen, stoßen informelle Darstellungen an ihre Grenzen.

BPMN 2.0 bietet in dieser Lage drei Vorteile:

• Eine präzise Semantik, die Missverständnisse zwischen Fachbereich und IT reduziert.
• Eine herstellerneutrale Notation, die den Wechsel zwischen Tools erleichtert.
• Die Möglichkeit, Modelle nicht nur zu dokumentieren, sondern auch ausführbar zu machen, etwa auf einer Process Engine.

Die wichtigsten Elementgruppen

BPMN wirkt auf den ersten Blick umfangreich. In der Praxis reicht eine überschaubare Teilmenge für den Großteil der Modelle.

Aktivitäten, Ereignisse, Gateways

Die drei Grundbausteine sind schnell erklärt:

1. Aktivitäten sind abgerundete Rechtecke und stehen für etwas, das getan wird, zum Beispiel Rechnung prüfen oder Kunden informieren.
2. Ereignisse sind Kreise und markieren Start, Ende oder Zwischenpunkte, etwa den Eingang einer E-Mail oder einen Timer.
3. Gateways sind Rauten und bilden Entscheidungen oder Parallelitäten ab. Das exklusive Gateway (XOR) ist dabei das mit Abstand häufigste.

Pools und Lanes

Ein Pool steht für einen Prozessteilnehmer, zum Beispiel eine Organisation oder ein System. Innerhalb eines Pools strukturieren Lanes die Zuständigkeiten, etwa Rollen oder Abteilungen. Eine saubere Aufteilung hilft, Verantwortlichkeiten sichtbar zu machen, ohne dass der Prozessfluss zerfasert.

Nachrichten und Datenobjekte

Wenn zwei Pools interagieren, fließen zwischen ihnen Nachrichten, dargestellt als gestrichelte Pfeile. Datenobjekte ergänzen den Fluss um Informationen über Eingaben und Ergebnisse, ohne dass sie den Ablauf selbst steuern.

Typische Stolperfallen

Gerade am Anfang schleichen sich Muster ein, die Modelle unnötig schwer lesbar machen. Die folgenden sind besonders häufig:

• Gateway-Inflation: Jede kleine Bedingung wird als Gateway modelliert, statt sie in der Aktivität oder in einer Geschäftsregel zu kapseln.
• Fehlende Endereignisse: Pfade enden ins Leere, obwohl BPMN 2.0 jeden Ablauf sauber abschließen will.
• Vermischte Abstraktionsebenen: In einem Diagramm stehen grobgranulare Teilprozesse neben detaillierten Klickpfaden.
• Lanes ohne klare Definition: Was genau eine Lane repräsentiert, bleibt implizit und wird bei Änderungen zum Streitpunkt.

Eine gute Gegenstrategie ist, vor der Modellierung die Abstraktionsebene zu fixieren und diese auch im Dateinamen oder Titel zu kennzeichnen, etwa Level 2 – Auftragsbearbeitung.

Fachliches Modell versus ausführbares Modell

Ein häufiges Missverständnis lautet, BPMN sei immer gleich BPMN. Tatsächlich unterscheidet der Standard zwischen verschiedenen Konformitätsklassen. Für die reine Dokumentation reicht die Descriptive-Klasse. Sobald ein Modell in einer Engine ausgeführt werden soll, kommen zusätzliche Details hinzu, etwa technische Attribute an Gateways, Fehler-Ereignisse und Service-Tasks.

Für Prozessmanagerinnen und Business Analysten ist es wichtig, diesen Unterschied früh zu klären. Ein Modell, das ausschließlich der Kommunikation dient, sollte nicht mit Implementierungsdetails überladen werden. Umgekehrt reicht ein rein fachliches Modell nicht aus, um es eins zu eins an eine Engine zu übergeben.

Wann lohnt sich BPMN?

Nicht jede Prozessbeschreibung braucht BPMN. Für schnelle Skizzen in Workshops sind einfache Swimlane-Diagramme oft genug. Sinnvoll wird BPMN, wenn mindestens einer der folgenden Punkte zutrifft:

• Der Prozess ist überregional oder abteilungsübergreifend und betrifft viele Rollen.
• Es ist Automatisierung angedacht, sei es in einer Workflow-Engine oder in einem RPA-Tool.
• Der Prozess unterliegt Audits oder Regulatorik und braucht nachvollziehbare Dokumentation.
• Verschiedene Teams nutzen unterschiedliche Tools und brauchen einen austauschbaren Standard.

Nächste Schritte

Wer BPMN neu einführt, sollte schrittweise vorgehen. Ein typisches Vorgehen:

1. Eine kleine Notationskonvention festlegen, die nur die wirklich benötigten Elemente enthält.
2. Zwei bis drei Referenzprozesse modellieren und sie als Vorbild veröffentlichen.
3. Modellierende früh schulen, am besten anhand eigener Prozesse statt abstrakter Beispiele.
4. Reviews etablieren, damit Stil und Detailtiefe über Modelle hinweg vergleichbar bleiben.

Mit diesem Fundament wird BPMN 2.0 zu einem Werkzeug, das Kommunikation erleichtert, statt sie zu verkomplizieren. Der Standard löst keine Prozessprobleme von selbst, aber er schafft die Grundlage, sie sichtbar und diskutierbar zu machen. Wer denselben Prozess zusätzlich in anderen Notationen wie EPK oder Wertstrom abbilden will, ohne ihn doppelt zu pflegen, findet im Multi-Modell-Prozessmodellierer von process era den passenden Ansatz.