BPMN 2.0
7 typische Fehler bei der BPMN-Modellierung
BPMN 2.0 ist deshalb so wirkungsvoll, weil Fachbereich und IT dieselbe Notation lesen können – vorausgesetzt, sie wird sauber angewendet. In der Praxis sehe ich immer wieder dieselben sieben Fehler, die ein Modell entweder unverständlich oder schlicht falsch machen.
1. Fehlende oder falsche Swimlanes
Swimlanes zeigen, wer für welchen Schritt verantwortlich ist. Werden sie weggelassen „der Übersicht halber“, geht genau die Information verloren, die für die Umsetzung am wichtigsten ist: die Zuständigkeit. Ein Prozess ohne klare Lane-Zuordnung lässt sich später kaum in Rollen und Berechtigungen übersetzen.
2. Gateways ohne eindeutige Bedingung
Ein exklusives Gateway ohne beschriftete Ausgänge ist keine Modellierung, sondern eine Verlegenheitslösung. Jede abzweigende Kante braucht eine Bedingung, die auch jemand ohne Kontextwissen versteht. Sonst wird das Modell im Review zur Ratesession.
3. Falscher Detailgrad
Ein häufiges Extrem: entweder wird jeder Klick in der Anwendung als eigene Aktivität modelliert, oder ein kompletter Vorgang steckt in einer einzigen Box. Beides macht das Modell unbrauchbar. Die Faustregel: eine Aktivität sollte eine fachlich abgeschlossene Handlung einer Person oder eines Systems beschreiben – nicht mehr, nicht weniger.
4. Start- und Endereignisse werden verwechselt
Prozesse mit mehreren möglichen Startpunkten oder ganz ohne definiertes Ende sind in der Praxis erstaunlich häufig. Das Ergebnis: Unklarheit darüber, wann ein Vorgang überhaupt beginnt oder abgeschlossen ist – mit direkten Folgen für Kennzahlen wie Durchlaufzeiten.
5. Unklare Aktivitätsnamen
„Bearbeiten“, „Prüfen“, „Klären“ – solche Aktivitätsnamen sagen nichts über das eigentliche Handeln aus. Besser ist die Konvention Verb + Objekt: „Rechnung prüfen“, „Freigabe erteilen“. Das erzwingt Klarheit schon beim Modellieren.
6. Ausnahmen werden ignoriert
Der Standardfall ist meist schnell modelliert. Der eigentliche Wert eines Prozessmodells zeigt sich aber im Umgang mit Ausnahmen: Was passiert bei Fristüberschreitung, bei fehlender Freigabe, bei einem Systemausfall? Wer diese Pfade weglässt, liefert ein Hochglanzmodell, das an der Realität vorbeigeht.
7. Kein Pflegeprozess nach der Modellierung
Der größte Fehler passiert oft nicht während der Modellierung, sondern danach: Niemand ist dafür zuständig, das Modell aktuell zu halten. Ein Prozessmodell ohne Owner und ohne Reviewzyklus ist nach einem Jahr Makulatur.
Ein BPMN-Modell ist kein Abschlussdokument eines Projekts – es ist eine lebende Beschreibung der Organisation.
Fazit
Die meisten dieser Fehler entstehen nicht aus Unwissen über die Notation, sondern aus Zeitdruck: Modelliert wird für die nächste Präsentation, nicht für den langfristigen Betrieb. Wer BPMN 2.0 von Anfang an als Governance-Instrument versteht statt als Grafik für ein Kickoff-Meeting, vermeidet die meisten dieser Fallstricke automatisch.
Nächster Schritt