BPMN: Geschäftsprozesse in einer gemeinsamen Notation

BPMN (Business Process Model and Notation) ist eine standardisierte grafische Sprache, mit der Geschäftsprozesse als Diagramm beschrieben werden. Die Fassung 2.0 wird von der Object Management Group gepflegt und ist auch als internationale Norm ISO/IEC 19510 veröffentlicht. Fachabteilung und Entwicklung lesen damit dieselbe Darstellung eines Ablaufs.

Was BPMN leistet und was nicht

Die Notation beantwortet drei Fragen an einen Ablauf: Was löst ihn aus, welche Schritte folgen in welcher Reihenfolge, und wer ist für welchen Schritt zuständig. Als offener Standard definiert sie neben den Symbolen auch ein XML-Austauschformat. Ein Modell lässt sich deshalb, mit Einschränkungen im Detail, zwischen Werkzeugen weitergeben: vom Zeichenprogramm der Geschäftsprozessmodellierung bis zur Process Engine, die ein Modell unmittelbar ausführt.

Was die Notation nicht leistet: Sie beschreibt keine Datenstrukturen, keine Bildschirmmasken und keine Geschäftsregeln im Einzelnen. Für Entscheidungstabellen gibt es mit DMN (Decision Model and Notation) einen eigenen, ebenfalls von der Object Management Group gepflegten Standard. Ein Diagramm ersetzt außerdem keine Untersuchung: Es zeigt einen Ablauf so, wie die modellierende Person ihn verstanden hat. Ob das der gelebte Ablauf ist, klärt erst die Prozessanalyse.

Die vier Grundelemente

• Ereignisse (Kreise) markieren, dass etwas geschieht: Eine Anfrage geht ein, eine Frist läuft ab, eine Zahlung wird gebucht. Start-, Zwischen- und Endereignis unterscheiden sich an der Randlinie: einfach, doppelt, fett.
• Aktivitäten (Rechtecke mit abgerundeten Ecken) sind Arbeitsschritte, etwa „Angebot erstellen“. Ein kleines Symbol in der Ecke zeigt, ob ein Mensch, ein Programm oder ein Nachrichtenversand den Schritt ausführt.
• Gateways (Rauten) verzweigen oder vereinen den Fluss. Das exklusive Gateway wählt genau einen Weg („Angebot angenommen?“), das parallele öffnet mehrere Wege zugleich, das inklusive einen oder mehrere.
• Flüsse verbinden die Elemente: der Sequenzfluss als durchgezogene Linie innerhalb eines Ablaufs, der Nachrichtenfluss als gestrichelte Linie zwischen Beteiligten.

Mit diesen vier Gruppen lässt sich der größte Teil eines Auftragswegs darstellen. Die Spezifikation kennt deutlich mehr Zeichen, etwa für Kompensation oder Eskalation. In Modellen für die Fachabteilung bleiben sie meist weg, weil jedes zusätzliche Zeichen erklärt werden muss und das Diagramm sonst niemand außerhalb der Modellierung liest.

Pools und Lanes: Zuständigkeit sichtbar machen

Ein Pool steht für einen eigenständigen Beteiligten, etwa den Kunden oder das eigene Unternehmen. Innerhalb eines Pools teilen Lanes den Ablauf nach Rollen oder Systemen auf: Vertrieb, Auftragsbearbeitung, Buchhaltung. Zwischen Pools fließen nur Nachrichten, denn keiner steuert die Schritte des anderen. Das Unternehmen schickt das Angebot; ob und wann der Kunde annimmt, entscheidet er selbst.

Gerade auf dem Weg von der Anfrage zur Zahlung zeigen Lanes, wo eine Übergabe stattfindet. Jeder Pfeil, der eine Lane-Grenze kreuzt, ist ein Moment, in dem ein Vorgang liegen bleiben oder eine Angabe neu erfasst werden kann. Wer diese Übergänge im Diagramm zählt, hält bereits eine erste Liste möglicher Ansatzpunkte für die Automatisierung in der Hand.

Ein BPMN-Modell in drei Detailstufen

Ein häufiger Grund für unbrauchbare Modelle ist die falsche Detailtiefe. In der Praxis haben sich drei Stufen bewährt:

1. Beschreibend: wenige Elemente, der Weg auf einer Seite, für die Geschäftsführung und die Abstimmung zwischen Abteilungen.
2. Analytisch: alle Ausnahmen, Fristen und Zwischenereignisse, etwa die Teillieferung, die Gutschrift oder die Mahnung nach ausbleibender Zahlung. Auf dieser Stufe wird sichtbar, wo Regeln fehlen.
3. Ausführbar: Das Modell trägt technische Angaben wie Datenobjekte, Aufrufe und Bedingungen und kann von einer Process Engine gesteuert werden.

Nicht jeder Ablauf braucht die dritte Stufe. Ob eine Engine den Weg steuert oder ein Programm die Schritte als Code abbildet, ist eine Frage der Architektur; das Modell der zweiten Stufe bleibt in beiden Fällen die Vorlage, gegen die geprüft wird. Das Ziel, Standardfälle ohne menschlichen Eingriff durchlaufen zu lassen, heißt Dunkelverarbeitung. Die Ausnahmen des analytischen Modells sind genau die Fälle, die dabei weiterhin bei einem Menschen landen.

Typische Modellierungsfehler

• Das Sollbild zeichnen. Wer den Ablauf so modelliert, wie er laut Handbuch aussehen sollte, automatisiert in den Fehler hinein.
• Aktivitäten ohne Verb. „Rechnung“ ist kein Schritt, „Rechnung prüfen“ schon.
• Entscheidungen im Gateway verstecken. Eine Raute „Kunde in Ordnung?“ enthält eine ganze Regelsammlung, die gesondert beschrieben werden muss.
• Ein Diagramm für alle Zwecke. Wer beschreibende und ausführbare Stufe mischt, erhält ein Bild, das weder die Geschäftsführung noch die Entwicklung liest.
• Kein Endereignis für den Misserfolg. Der abgelehnte Auftrag und die uneinbringliche Forderung sind ebenfalls Ergebnisse des Ablaufs und gehören ins Modell.

Vom Modell zur Automatisierung

Wir modellieren den Auftragsweg eines Auftraggebers auf der analytischen Stufe, nachdem wir ihn auf echten Daten verfolgt haben, und besprechen das Diagramm mit den Menschen, die den Ablauf täglich bearbeiten. Dabei tauchen regelmäßig Regeln auf, die bisher nur im Kopf oder im Chat standen; in einem Projekt wurden 50 Regeln aus dem Chatverlauf an einem Tag in eine produktive Wissensbasis übernommen. Jedes Gateway mit einer solchen Regel wird zu einem prüfbaren Kriterium im Angebot. Wie daraus ein laufender Ablauf wird, beschreibt die Seite Workflow-Automatisierung, woran er gemessen wird, der Artikel Prozesskennzahlen.