BPMN Symbole (Kurz erklärt)
BPMN-2.0 Symbole bilden ab, wie Arbeit durch einen Prozess fließt. Die häufigsten Symbole sind Events (Kreise), Aktivitäten (abgerundete Rechtecke), Gateways (Rauten) und Sequenzflüsse (Pfeile). Mit diesen Bausteinen modellieren Teams Verantwortlichkeiten, Entscheidungen und Ausnahmen in einem gemeinsamen Standard.
- Die meisten nützlichen BPMN-Diagramme nutzen Events, Tasks und Exclusive Gateways.
- Swimlanes machen Ownership sichtbar – kritisch für echte Workflows.
- Gateway-Zweige mit expliziten Bedingungen labeln (nicht vage Worte).
- Freigaben als explizite Aktivitäten modellieren – mit genehmigt/abgelehnt Pfaden.
- Diagramme lesbar halten: in Subprozesse aufteilen.
Events (Start, Intermediate, Ende)
Events beschreiben etwas, das passiert.
- Start-Event: wie der Prozess beginnt
- Intermediate Event: etwas passiert während des Prozesses (Message, Timeout, Error)
- End-Event: wie der Prozess endet
Praktischer Tipp: Events sparsam nutzen. Ihr Diagramm soll Arbeit erzählen (Aktivitäten), nicht Event-Typen katalogisieren.
Aktivitäten (Tasks und Subprozesse)
Aktivitäten beschreiben Arbeit, die erledigt wird.
- Task: eine Arbeitseinheit (z. B. “Request prüfen”)
- Subprozess: Gruppe von Tasks (nutzen, wenn das Diagramm zu lang wird)
Benennungsregel: Verb-Objekt:
- ✅ “Rechnung freigeben”
- ✅ “Kundendaten validieren”
- ❌ “Rechnungsfreigabe”
Gute Benennung ist der schnellste Lesbarkeits-Win.
Die 12-Schritte-Heuristik
Wenn der Happy Path mehr als ~12 Aktivitäten hat, sind Sie vermutlich auf der falschen Detailebene. In Subprozesse splitten.
Gateways (XOR, AND, OR) – was Sie wirklich brauchen
Gateways beschreiben Verzweigungslogik.
- Exclusive (XOR): ein Pfad wird gewählt (am häufigsten)
- Parallel (AND): Pfade laufen parallel
- Inclusive (OR): ein oder mehrere Pfade können laufen
Best Practice: Ausgehende Flows mit Bedingungen labeln:
- ✅ “Betrag > 10.000”
- ✅ “Kunde ist Enterprise”
- ❌ “Hoher Wert”
- ❌ “Vielleicht”
Wenn Bedingungen unklar sind, wird Ausführung unklar.
Important
Unbeschriftete Gateways sind eine häufige Ursache für Misalignment. Wenn man einen Zweig unterschiedlich interpretieren kann, wird es später zur Ausnahme.
Pools und Lanes (Ownership im Modell)
Swimlanes zeigen, wer die Arbeit macht.
Nutzen Sie Lanes, um Responsibility explizit zu machen:
- “Sales”
- “Operations”
- “Finance”
- “IT”
Hier schlägt BPMN generische Flowcharts: Übergaben und Accountability werden sichtbar.
Beispiel: Freigabe richtig modellieren
Freigaben sollten explizite Aktivitäten sein.
Ein einfaches Muster:
- “Request prüfen” (Task)
- “Request freigeben” (Task)
- XOR-Gateway:
- “Genehmigt” → weiter
- “Abgelehnt” → Antragsteller informieren und enden
Dieses Muster macht Governance und Audit Trails einfach.
Ihr erstes BPMN-Diagramm: was rein soll (und was nicht)
Rein:
- ein Start-Event
- Aktivitäten, die echte Arbeit beschreiben
- ein bis zwei Gateways für echte Entscheidungen
- explizite Freigaben
- Lanes für Rollen
- ein End-Event (oder klare Outcomes)
Nicht rein:
- jede mögliche Ausnahme
- seltene Event-Typen
- zu viel Detail innerhalb eines Tasks
BPMN ist zuerst ein Kommunikationswerkzeug. Ausführung kommt später.
Häufige Fehler, die Sie vermeiden sollten
Lernen Sie von anderen, um dieselben Fallstricke zu vermeiden.
BPMN nur als Zeichnung nutzen
Ownership, Bedingungen und Ausführungssemantik gehen verloren.
Rollen (Lanes), explizite Entscheidungen und Freigaben modellieren.
Gateway-Bedingungen nicht beschriften
Zweige werden unterschiedlich interpretiert.
Jeden Zweig mit expliziten Bedingungen labeln.
Ein riesiges Diagramm
Niemand liest es und es wird unwartbar.
In Subprozesse splitten und lesbar halten.
Handeln Sie
Ihre Aktions-Checkliste
Wenden Sie das Gelernte mit dieser praktischen Checkliste an.
Start- und End-Events nutzen
Tasks mit Verb-Objekt benennen
Lanes für Rollen ergänzen
XOR-Gateways für wichtige Entscheidungen nutzen
Jeden Gateway-Zweig beschriften
Freigaben explizit modellieren
Bei Bedarf in Subprozesse splitten