Prozessbeschreibung nach BPMN 2.0: Elemente und Notationselemente richtig einsetzen

Das Wichtigste auf einen Blick

BPMN 2.0 ist eine Spezifikation der Object Management Group (OMG), veröffentlicht im Januar 2011 als Dokument formal/2011-01-03.
Die Notation besteht aus vier GruppenFlussobjekte, Verbindungsobjekte, Swimlanes und Artefakte.
Aufgaben stehen für Tätigkeiten, Ereignisse für Zustandswechsel, Gateways für Verzweigungen.
Ein Modell ist schlüssig, wenn jeder Pfad an einem Endereignis endet und jedes Gateway eine Bedingung oder einen Default-Fluss besitzt.

Vier Bausteine tragen jede Prozessbeschreibung

Flussobjekte bilden das Rückgrat: Aufgaben, Ereignisse und Gateways. Verbindungsobjekte verknüpfen sie, wobei der Sequenzfluss die Reihenfolge innerhalb eines Pools vorgibt und der Nachrichtenfluss den Austausch zwischen zwei Pools beschreibt.

Swimlanes ordnen Zuständigkeiten. Ein Pool steht für einen Teilnehmer, Lanes unterteilen ihn nach Rollen oder Abteilungen. Artefakte ergänzen das Modell, ohne den Ablauf zu steuern: Das Datenobjekt "Rechnungsbetrag" hält eine Information fest, die Gruppe "Rückfrage-Fall" bündelt Elemente rein optisch, und die Textannotation "Zahlung erst nach Vier-Augen-Prinzip" notiert eine Regel am Element.

Verbindliche Darstellungsregeln halten Modelle über Abteilungen und Werkzeuge hinweg vergleichbar. Das Basiswissen zu Normen und Standards beschreibt, wie solche Festlegungen entstehen und wirken.

Notationselemente und ihr Einsatz

Die wichtigsten Elemente, ihre Darstellung und ihr Einsatz im Überblick:

Element	Darstellung	Einsatz
Aufgabe	Rechteck mit runden Ecken	Tätigkeit, benannt mit Verb und Objekt
Ereignis	Kreis	Zustandswechsel; dünner Rand für Start, dicker für Ende, doppelter für Zwischenereignis
Gateway	Raute	Verzweigt oder führt Pfade zusammen
Sequenzfluss	Linie mit gefüllter Pfeilspitze	Reihenfolge innerhalb eines Pools
Nachrichtenfluss	gestrichelte Linie mit offener Pfeilspitze	Austausch zwischen zwei Pools
Pool	Rechteck mit Bezeichnung	Ein Teilnehmer am Prozess
Lane	Unterteilung im Pool	Rolle oder Abteilung
Datenobjekt	Rechteck mit umgeknickter Ecke	Information, die eine Aufgabe liest oder erzeugt
Gruppe	gestrichelte eckige Klammer	Bündelt Elemente ohne Wirkung auf den Ablauf
Textannotation	offene Klammer mit Text	Hinweis oder Regel zu einem Element

BPMN-Notationselemente im Überblick

Element

Aufgabe: Rechteck, abgerundet
Ereignis: Kreis
Gateway: Raute
Sequenzfluss: Linie, geschlossener Pfeil
Nachrichtenfluss: gestrichelt, offener Pfeil

Darstellung

Aufgabe: Tätigkeit einer Rolle
Ereignis: Start, Zwischen, Ende
Gateway: Verzweigung, Zusammenführung
Sequenzfluss: Reihenfolge im Pool
Nachrichtenfluss: Austausch zwischen Pools

Einsatz

Aufgabe
Ereignis
Gateway
Sequenzfluss
Nachrichtenfluss

Aufgaben, Ereignisse und Gateways im Detail

Eine Aufgabe benennt Tätigkeit und Objekt, also "Rechnung prüfen" statt "Rechnung". Der Typ legt fest, wer oder was ausführt. Beim User Task arbeitet eine Person, beim Service Task ruft das System automatisch einen Dienst auf; Script Task, Manual Task und Business Rule Task decken Skripte, körperliche Arbeit und Regelwerke ab.

Diese Typwahl entscheidet über den Automatisierungsgrad eines Schritts. Welche Rahmenbedingungen und Förderwege für Automatisierungsvorhaben in Deutschland gelten, fasst das BMWK unter Förderung und Rahmenbedingungen für Prozessautomatisierung zusammen; für die Notation selbst ergeben sich daraus keine Vorgaben.

Ereignisse sind Kreise und markieren Zustandswechsel. Ein dünner Rand steht für den Start, ein dicker für das Ende, ein doppelter für ein Zwischenereignis. Auslöser wie Nachricht, Timer, Fehler oder Signal erscheinen als Symbol im Kreis und bestimmen, wann ein Pfad beginnt oder abbricht.

Gateways sind Rauten und steuern den Weg. Ein exklusives Gateway wählt genau einen Pfad, ein paralleles alle gleichzeitig, ein inklusives mindestens einen. Jede verzweigende Raute braucht auswertbare Bedingungen; ein Default-Fluss fängt den Fall ab, in dem keine Bedingung zutrifft.

Beispiel: Rechnungsfreigabe in fünf Schritten

Rechnungsfreigabe in fünf Schritten

Startereignis vom Typ NachrichtDie Rechnung ist eingegangen.
User Task "Rechnung prüfen" in der Lane Buchhaltung.
Exklusives Gateway "Freigabe erteilt?" mit den Bedingungen ja und nein sowie einem Default-Fluss.
Service Task "Zahlung anweisen" im Freigabepfad, User Task "Klärung einleiten" im zweiten Pfad.
Endereignis "Rechnung bearbeitet", in das beide Pfade münden.

Der weitere Weg mit den Bedingungen am Gateway:

Startereignis Nachricht -> User Task "Rechnung prüfen" -> Gateway "Freigabe erteilt?"
freigabe = true -> Service Task "Zahlung anweisen" -> Endereignis "Rechnung bearbeitet"
Default-Fluss, gültig bei freigabe = false -> User Task "Klärung einleiten" -> Endereignis "Rechnung bearbeitet"

Typische Modellierungsfehler

Sequenzfluss über eine Poolgrenze ziehen statt Nachrichtenfluss zu verwenden.
Ein Gateway ohne Bedingung und ohne Default-Fluss modellieren.
Aufgaben ohne Verb benennen, also "Rechnung" statt "Rechnung prüfen".
Für jeden Sonderfall ein eigenes Startereignis anlegen.
Eine Schleife ohne Abbruchbedingung schließen.

Häufige Fragen

Reicht die BPMN-Notation für eine vollständige Prozessbeschreibung?

Die Notation liefert Ablauf, Zuständigkeiten und Ereignisse. Für eine belastbare Beschreibung kommen Datenobjekte, Regeln und Textannotationen hinzu, weil das Diagramm allein keine Bearbeitungshinweise transportiert.

Woran erkenne ich ein regelkonformes Modell?

Prüfen Sie vier Punkte: Trägt jede Aufgabe ein Verb und ein Objekt? Hat jedes verzweigende Gateway eine Bedingung oder einen Default-Fluss? Endet jeder Pfad an einem Endereignis? Ist der Austausch zwischen Pools als Nachrichtenfluss modelliert? Viele Werkzeuge validieren zusätzlich gegen die OMG-Spezifikation und melden unzulässige Kombinationen.

Gilt BPMN 2.0 auch als Norm?

Ja. Die Spezifikation wurde als ISO/IEC 19510:2013 übernommen und ist damit zusätzlich zur OMG-Fassung als internationale Norm verfügbar. Entscheidend ist, dass alle Beteiligten dieselbe Fassung verwenden.

Wie gehe ich mit automatisierten Entscheidungen im Modell um?

Service Tasks und Business Rule Tasks können Entscheidungen ohne manuelle Bearbeitung ausführen. Im Rechnungsbeispiel wertet ein Business Rule Task den Freigabegrenzwert des Unternehmens aus. Unterhalb der Grenze entsteht freigabe = true, oberhalb ein User Task für die zweite Prüfung.

Was das rechtlich bedeutet, erläutert der DIHK unter KI im Klartext: Vom Paragrafen zur Praxis.