Die meisten Teams greifen zu einem Flussdiagramm, wenn sie einen Prozess abbilden müssen. Für eine Skizze auf dem Whiteboard funktioniert das gut. Es funktioniert nicht mehr, sobald jemand aus der IT und jemand aus dem operativen Bereich dasselbe Diagramm lesen und mit demselben Verständnis davon weggehen sollen, was passiert, wer verantwortlich ist und wann.
BPMN existiert, weil allgemeine Diagramme nicht ausreichen. Nicht weil sie hässlich wären – das sind sie nicht –, sondern weil sie keine gemeinsame Bedeutung vermitteln. Zwei Personen können dasselbe Boxen-und-Pfeile-Diagramm betrachten und völlig unterschiedliche Schlüsse daraus ziehen, was es festlegt. BPMN löst dieses Problem, indem die Notation zu einem Standard wird und nicht zu einer Präferenz.
Das ist die zentrale Aussage, die hier verteidigt werden sollte: Ein BPMN-Diagramm ist kein aufwendigeres Flussdiagramm. Es ist eine formale Spezifikationssprache, die zufällig auch für Menschen lesbar ist, die nicht programmieren – und das ist schwieriger, als es klingt.
Was Menschen falsch verstehen, bevor sie überhaupt etwas zeichnen
- BPMN ist ein formaler Standard mit Ausführungssemantik, nicht nur eine visuelle Konvention.
- Vier Elementkategorien erfüllen jeweils spezifische Aufgaben – ihre Vermischung erzeugt Diagramme, die niemand implementieren kann.
- BPMN-2.0-Diagramme können Automatisierungs-Engines direkt steuern; genau das unterscheidet sie von Dokumentation.
- Komplexität ist keine Tugend – ein einseitiges BPMN-Diagramm, das echte Stakeholder nutzen, ist besser als ein erschöpfendes Diagramm, das niemand öffnet.
Was BPMN tatsächlich ist und warum es nicht nur ein Flussdiagramm ist
Die Object Management Group definiert BPMN als standardisierte grafische Notation zur Spezifikation von Geschäftsprozessen in einem Geschäftsprozessdiagramm. Dieser eine Satz enthält viel Bedeutung. „Standardisiert“ bedeutet, dass die Symbole organisations- und toolübergreifend vereinbarte Bedeutungen haben. „Grafische Notation“ bedeutet, dass Formen und Verbindungen mit definierter Semantik verwendet werden, keine beliebigen Zeichnungen. „Geschäftsprozessdiagramm“ ist ein spezifischer Artefakttyp mit Regeln dazu, was darin zulässig ist.
Ein allgemeines Flussdiagramm bietet nichts davon. Sie können beliebige Formen verwenden. Pfeile bedeuten, was auch immer die Autorin oder der Autor damit ausdrücken wollte. Es gibt keinen Unterschied zwischen einem Entscheidungspunkt, an dem Daten den Pfad bestimmen, und einem Entscheidungspunkt, an dem ein externes Ereignis den Pfad bestimmt. Es gibt kein Konzept für Nachrichtenflüsse zwischen getrennten organisatorischen Beteiligten. Es gibt keinen Mechanismus, um einen Prozess als Teilprozess zu kennzeichnen, der an anderer Stelle wiederverwendet werden kann.
Der Unterschied ist nicht ästhetisch, sondern semantisch. Ein Flussdiagramm vermittelt eine Absicht. Ein BPMN-Diagramm vermittelt eine Spezifikation. Deshalb können technische Teams ein BPMN-Diagramm nehmen und implementieren, ohne ein Meeting einberufen zu müssen, um die Bedeutung der Pfeile zu klären. Standardnotation macht ein Diagramm für alle selbsterklärend, die die Notation kennen – genau dafür gibt es Standards.
Der Standard für Geschäftsprozessmodelle und -notationen ist außerdem präzise genug definiert, damit automatisierte Tools prüfen können, ob ein Diagramm korrekt und nicht nur lesbar ist. Das kann ein allgemeines Flussdiagramm nicht für sich beanspruchen.
Eine kurze Geschichte von BPMN und wie Geschäftsprozessmodellierung zum Standard wurde
BPMN begann 2004 mit der Business Process Management Initiative (BPMI), einem Konsortium aus Anbietern und Praktikern, die dasselbe Problem frustrierte: Jedes Tool hatte seine eigene Notation für Geschäftsprozesse, und keines konnte mit den anderen kommunizieren. Ziel war ein einzelner Standard für die Geschäftsprozessmodellierung, den jedes Tool implementieren und jede Fachperson lesen konnte.
BPMI fusionierte 2005 mit der Object Management Group, wodurch die Verantwortung für den BPMN-Standard an OMG überging – dieselbe Organisation, die UML und andere bedeutende technische Spezifikationen verwaltet. Dieser Übergang war wichtig. OMG hat das institutionelle Gewicht, um einen Standard branchen- und anbieterübergreifend zu etablieren. Die Organisation ist außerdem ISO-anerkannt und veröffentlicht den Standard als ISO/IEC 19510. Deshalb finden Sie BPMN in Tools von Visio über Enterprise-BPM-Engines bis hin zu Open-Source-Modellierern.
Der Weg von BPMI über OMG bis zur ISO ist genau der Grund, warum so viele Tools gezielt BPMN statt einer proprietären Notation implementieren. Wenn ein Standard anbieterneutral und formal gepflegt wird, folgt die Akzeptanz. Für Praktiker bedeutet das: Sie lernen BPMN einmal und können dieses Wissen organisations-, tool- und branchenübergreifend einsetzen. Das ist keine geringe Annehmlichkeit. Für Business-Analysten, die zwischen Arbeitgebern wechseln, oder Berater, die für verschiedene Kunden arbeiten, sorgt ein Standard für Geschäftsprozessmodellierung dafür, dass Fachwissen übertragbar bleibt.
Die vier Kategorien von BPMN-Elementen, die jedes Diagramm verwendet
BPMN organisiert seine visuelle Grammatik in vier Kategorien. Jede übernimmt eine eigene Aufgabe. Sie zu verwechseln, ist der häufigste Grund dafür, dass ein erstes Diagramm richtig aussieht, aber das Falsche kommuniziert.
Flussobjekte: Ereignisse, Aktivitäten und das Gateway
Flussobjekte sind die aktiven Elemente eines BPMN-Diagramms – die Dinge, die passieren. Es gibt drei Typen, und die Unterscheidung zwischen ihnen ist nicht optional.
Ereignisse kennzeichnen etwas, das passiert und einen Prozess entweder startet, unterbricht oder beendet. Ein Startereignis, der Kreis am Anfang ohne oder mit einem Symbol darin, löst den Prozess aus. Ein Zwischenereignis befindet sich in der Mitte eines Ablaufs – ein Timer wird ausgelöst, eine Nachricht trifft ein, eine Eskalation erfolgt. Ein Endereignis markiert, wo der Prozess endet. Der Ereignistyp wird durch das Symbol im Kreis codiert: ein Punkt für ein Nachrichtenereignis, eine Uhr für einen Timer, ein Umschlag für Kommunikation. Diese Symbole sind nicht dekorativ – sie teilen einer Automatisierungs-Engine mit, worauf sie warten soll.
Aktivitäten sind die Arbeitsschritte. Aufgaben sind atomare Arbeitseinheiten. Teilprozesse enthalten einen eigenen internen Ablauf und können im Diagramm eingeklappt oder erweitert werden.
Das Gateway ist der Verzweigungsmechanismus – und hier machen Einsteiger am häufigsten ihre ersten Fehler. Nicht alle Gateways verhalten sich gleich. Ein exklusives Gateway, die Raute mit X, leitet abhängig von Datenbedingungen genau zu einem Pfad weiter. Ein paralleles Gateway, die Raute mit +, aktiviert alle ausgehenden Pfade gleichzeitig. Ein ereignisbasiertes Gateway leitet den Ablauf zu dem Ereignis weiter, das als Nächstes eintritt – nicht zu der Bedingung, die wahr ist, sondern zu dem Ereignis, das zuerst eintrifft. Ein ereignisbasiertes Gateway wie einen datenbasierten Entscheidungspunkt zu behandeln, erzeugt ein Diagramm, das gut aussieht und bei der Implementierung scheitert.
Verbindungsobjekte und wie Prozessabläufe gezeichnet werden
Verbindungen in BPMN sind typisiert, nicht beliebig. Hier frustrieren allgemeine Diagrammtools Praktiker am meisten: Das Tool lässt Sie jede beliebige Linie zeichnen, aber BPMN legt fest, welche Linie was bedeutet.
Ein Sequenzfluss, eine durchgezogene Linie mit Pfeilspitze, verbindet Elemente innerhalb desselben Pools und definiert die Ausführungsreihenfolge. Ein Nachrichtenfluss, eine gestrichelte Linie mit offener Pfeilspitze, überschreitet Poolgrenzen und stellt die Kommunikation zwischen getrennten Prozessbeteiligten dar – etwa zwischen einem Kunden und einem Unternehmen, zwei Abteilungen oder einem System und einem Nutzer. Eine Assoziation, eine gepunktete Linie, verbindet ein Artefakt wie eine Annotation mit einem Flusselement, ohne eine Richtung des Prozessablaufs zu implizieren.
Der praktische Grund dafür: Ein Nachrichtenfluss und ein Sequenzfluss sehen für jemanden, der die Notation nicht kennt, ähnlich aus, aber sie codieren in einem Prozessdiagramm völlig unterschiedliche Logik. Werden sie vermischt, stellt das Diagramm falsch dar, wer was initiiert und wo organisatorische Übergaben tatsächlich stattfinden.
Swimlanes und wie sie Verantwortlichkeiten darstellen
Swimlanes sind die Verantwortlichkeitsebene eines BPMN-Diagramms. Sie beantworten die Frage, die beim Zeichnen eines Prozesses alle zu vergessen scheinen: Wer ist tatsächlich für diesen Schritt verantwortlich?
Pools repräsentieren einen vollständigen Prozessbeteiligten: ein Unternehmen, ein System, eine Abteilung oder eine Rolle. Lanes unterteilen einen Pool in kleinere Verantwortungseinheiten – spezifische Rollen, Teams oder Untersysteme. Wenn Sie eine Aufgabe innerhalb einer Lane zeichnen, treffen Sie eine Aussage darüber, welcher Prozessbeteiligte sie ausführt.
Hier entdecken Teams am häufigsten funktionsübergreifende Lücken. Ich habe erlebt, wie Business-Stakeholder einen Prozess mündlich abbildeten, zehn Schritte problemlos durchgingen und dann ins Stocken gerieten, als sie die Swimlane-Grenze zwischen Vertrieb und Finanzen einzeichnen sollten. BPMN schafft die Verwirrung nicht – sie macht eine Verwirrung sichtbar, die immer vorhanden, aber unsichtbar war. Genau darin liegt ein großer Teil des Werts, ein Diagramm zu zeichnen.
Artefakte und unterstützende Informationen in einem BPMN-Diagramm
Artefakte sind die Kategorie, die die meisten Teams beim Erstellen ihrer ersten Diagramme auslassen. Das ist verständlich – Artefakte verändern nicht, wie der Prozess abläuft. Sie sind jedoch die Ebene, die ein Diagramm für jemanden wirklich nützlich macht, der es sechs Monate später in die Hand nimmt.
Datenobjekte repräsentieren Informationen, die durch den Prozess fließen: Dokumente, Formulare, Datensätze. Eine Gruppe zieht zu Referenzzwecken eine visuelle Grenze um zusammengehörige Elemente, ohne den Ablauf zu beeinflussen. Eine Annotation ist eine an beliebige Elemente angehängte Textnotiz – die Erklärung, warum ein Schritt so funktioniert, wie er funktioniert, welcher Schwellenwert ein Gateway auslöst oder welches System ein bestimmtes Datenobjekt besitzt.
Werden Artefakte ausgelassen, entstehen Diagramme, die vollständig aussehen, aber ein Gespräch zur Interpretation erfordern. Der Satz an Symbolen ist vorhanden, aber der Kontext, der sie ausführbar macht, fehlt. Teams bewahren diesen Kontext dann im Kopf einzelner Personen auf – genau diesen Zustand sollte BPMN ersetzen.
🤔 Moment.
Wenn Artefakte den Prozessablauf nicht beeinflussen, warum gehören sie dann zu den vier Elementkategorien von BPMN? Weil BPMN dafür entwickelt wurde, ausführbar und nicht nur lesbar zu sein. Eine automatisierte Workflow-Engine muss wissen, welche Dokumente bei welchen Schritten benötigt werden, nicht nur, welche Aktivitäten stattfinden. Ohne die Artefaktebene ist das Diagramm ein Kommunikationsmittel. Mit ihr wird das Diagramm zu einer Spezifikation.
BPMN 2.0: Was sich in Version 2.0 geändert hat und warum es wichtig ist
BPMN 2.0, 2011 von OMG veröffentlicht, ergänzte zwei Dinge, die veränderten, was ein Diagramm leisten kann: Ausführungssemantik und ein standardisiertes XML-Austauschformat.
Frühere BPMN-Versionen waren Dokumentationswerkzeuge. Die Spezifikation definierte, wie Diagramme aussehen sollten, aber nicht, wie sie ausgeführt werden sollten. BPMN 2.0 änderte dies, indem es die formale Semantik jedes Elements spezifizierte – also genau, was ein ereignisbasiertes Gateway bedeutet, wenn eine Automatisierungs-Engine es verarbeitet, und nicht nur, wie es gezeichnet werden soll. Dadurch wurde die zuvor bestehende Lücke zwischen einem BPMN-Diagramm und der Business Process Execution Language (BPEL) geschlossen. BPEL war der Standard für ausführbare Prozesslogik, jedoch für Business-Stakeholder zu technisch lesbar.
BPMN 2.0 definierte außerdem ein standardisiertes XML-Format für den Austausch. Zuvor konnte ein in einem Tool erstelltes Diagramm nicht sinnvoll in einem anderen geöffnet werden, selbst wenn beide BPMN-Unterstützung beanspruchten. Das standardisierte XML-Format bedeutete, dass ein in einem visuellen Modellierer erstelltes Diagramm direkt in eine Workflow-Engine oder BPM-Plattform importiert werden konnte, ohne es neu zu zeichnen. Deshalb geben moderne Plattformen Unterstützung für BPMN 2.0 und nicht nur für „BPMN“ an – frühere Versionen fehlt die Ausführungsebene, die Diagramme umsetzbar macht.
Praktisch betrachtet gilt: Wenn Sie einen Geschäftsprozess mit der Absicht modellieren, ihn zu automatisieren, ist BPMN 2.0 die richtige Version. Die Ebene für Webservices und das Ökosystem der Workflow-Tools bauen darauf auf. Alles Ältere ist von Grund auf nur für Dokumentation gedacht.
Wie BPMN die Lücke zwischen Geschäftsprozessmanagement und IT-Automatisierung schließt
Die Ausrichtung von BPMN auf zwei Zielgruppen macht die Notation wirklich nützlich und wird zugleich am häufigsten falsch dargestellt. Die OMG-Spezifikation ist eindeutig: BPMN soll für nicht technische Geschäftsanwender lesbar sein und gleichzeitig präzise genug für technische Entwickler und Automatisierungs-Engines. Das ist kein Kompromiss – es war von Beginn an das Designziel.
Der Irrtum, den ich immer wieder sehe, lautet, BPMN sei eine Entwicklersprache mit einer freundlich gestalteten Oberfläche. Diese Auffassung entsteht meist in Teams, in denen ein Entwickler BPMN gelernt hat und dann Diagramme voller Teilprozesse, Call Activities und Kompensationsereignisse erstellt, nach denen Business-Stakeholder in jeder Prüfung fragen müssen. Das ist jedoch ein Nutzungsproblem, kein Spezifikationsproblem. Ein gut gezeichnetes BPMN-Diagramm sollte für jeden lesbar sein, der 30 Minuten in das Erlernen der grundlegenden Symbole investiert hat. Die Spezifikation unterstützt das.
Call Activities machen diese Brücke für die Geschäftsprozessgestaltung konkret. Eine Call Activity ist eine Aufgabe in Ihrem Hauptprozessdiagramm, die einen separat definierten Teilprozess aufruft. Das bedeutet: Sie können den übergeordneten Geschäftsprozess lesbar halten – das Diagramm zeigt „Kundendokumente prüfen“ als einzelnen Schritt –, während die technische Implementierung dieses Schritts in einem separaten detaillierten Diagramm liegt. Business-Stakeholder lesen den Hauptablauf. Technische Entwickler implementieren den aufgerufenen Teilprozess. Derselbe Prozess, zwei Detailebenen, beide formal verbunden.
Für Teilprozesse, die lokal in einem Diagramm bleiben, unterstützt BPMN eingeklappte Teilprozesse, die als einzelne Box mit einem Pluszeichen angezeigt werden, bis Leser sie erweitern möchten. Diese Designentscheidung – auf hoher Ebene einfach und auf Detailebene präzise zu wirken – macht BPMN zu einer Brücke zwischen Geschäftsprozessen und IT-Automatisierung, statt alle Beteiligten auf einem unbequemen Abstraktionsniveau in der Mitte zusammenzuführen.
Ein praktisches Beispiel: Ein Business-Analyst eines mittelgroßen Unternehmens, mit dem ich kürzlich gearbeitet habe, pflegte einen Kunden-Onboarding-Prozess als BPMN-Diagramm mit 40 Schritten. Jeder Ausnahmepfad war im Hauptablauf enthalten. Niemand las es. Die Lösung war nicht technisch, sondern strukturell. Der Hauptablauf bestand anschließend aus sieben Schritten, wobei Call Activities auf separate Teilprozessdiagramme für die Ausnahmepfade verwiesen. Das Hauptdiagramm passte auf einen Bildschirm. Stakeholder begannen, es in Abstimmungsmeetings zu verwenden. Die Teilprozessdiagramme lieferten dem Implementierungsteam die benötigten Details. Genau dafür wurde BPMN entwickelt. Als es an der Zeit war, die wiederkehrenden Datenbewegungsschritte in diesem Onboarding-Ablauf zu automatisieren, erleichterte die klare BPMN-Struktur den Aufbau eines Latenode-Workflows, der den Hauptprozess abbildete: CRM-Phasentrigger, Dokumentenprüfungen über integriertes RAG, Verzweigungslogik in einem JavaScript-Node, Statusaktualisierungen über verschiedene Tools hinweg – alles entsprechend der Struktur, die das Diagramm bereits definiert hatte.
BPMN vs. UML: Wann Prozessabbildung das eine und nicht das andere benötigt
Beide sind OMG-Standards. Beide verwenden formale Notation. Sie wurden für unterschiedliche Probleme entwickelt, und ihre Vermischung führt zu Diagrammen, die keine der beiden Zielgruppen zufriedenstellen. Hier ist die Entscheidungstabelle:
| Notation | Primärer Anwendungsfall | Zielgruppe | Ausführbar? | Wann sie vorzuziehen ist |
|---|---|---|---|---|
| BPMN | Geschäftsprozessabläufe, durchgängige operative Workflows | Business-Analysten, operative Teams, Entwickler, Stakeholder | Ja (BPMN 2.0) | Abbilden, wie Arbeit über Rollen und Systeme hinweg erledigt wird; Automatisierung operativer Prozesse |
| UML (Aktivitätsdiagramm) | Softwareverhalten, Algorithmuslogik, Systemabläufe | Technische Entwickler, Softwarearchitekten | Nein (nur beschreibend) | Modellierung interner Softwaredesigns; Dokumentation von Entscheidungslogik auf Codeebene |
| UML (Sequenzdiagramm) | Objektinteraktionen, API-Aufrufsequenzen | Technische Entwickler | Nein | Spezifikation der technischen Interaktion von Softwarekomponenten |
Die praktische Entscheidungsregel: Wenn Ihr Diagramm von jemandem ohne Hintergrund in der Softwareentwicklung verstanden und validiert werden muss, verwenden Sie BPMN. Die Unified Modeling Language wurde gezielt für Softwaredesign entwickelt und setzt technische Leser voraus. Die BPMN-Notation für Geschäftsprozessmodellierung wurde gezielt für Geschäftsprozessabläufe entwickelt und setzt ein gemischtes Publikum voraus. Ein Compliance-Team, das einen Genehmigungsworkflow dokumentiert, sollte fast nie zu UML greifen. Ein Entwickler, der Objektinteraktionsmuster in einem neuen Service spezifiziert, sollte wahrscheinlich nicht zu BPMN greifen. Das Entscheidungsmodell richtet sich nach Zielgruppe und Absicht, nicht nach Diagrammkomplexität.
Wer BPMN-Diagramme tatsächlich verwendet und für welche Art der Prozessabbildung
In der Praxis tauchen wiederholt vier Nutzungsszenarien nach Rollen auf. Jede Rolle nutzt die Notation anders, und jede stößt ohne sie auf ein spezifisches Problem.
Business-Analysten, die Ist- und Soll-Prozesse abbilden
Ein Business-Analyst, der einen aktuellen Beschaffungsprozess dokumentiert, verwendet ein BPMN-Diagramm, um jede Übergabe, Entscheidung und jeden Ausnahmepfad über Abteilungen hinweg zu erfassen. Ohne standardisierte Notation bedeutet das, was der Analyst als „Genehmigungsschritt“ zeichnet, für den Finanzmanager, die Beschaffungsverantwortliche und das IT-System, das die Anfrage verarbeitet, jeweils etwas anderes. Der Sequenzfluss zwischen Aufgaben und die Swimlane-Zuordnung für jeden Schritt machen die Übergaben eindeutig. Das Soll-Diagramm wird dann zur Grundlage der Implementierung, nicht nur zu einer Wunschvorstellung. [Laut SNS Insider entfiel 2023 mehr als 26 % des gesamten Umsatzes im BPM-Markt auf Prozessmodellierung, was zeigt, wie stark Enterprise-Teams in eine korrekte Dokumentation investieren.]
Projektmanager, die funktionsübergreifende Übergaben dokumentieren
Ein Projektmanager, der eine Produkteinführung über Marketing, Engineering und Rechtsabteilung hinweg koordiniert, verwendet ein BPMN-Diagramm, um die Abfolge von Abhängigkeiten grafisch eindeutig darzustellen. Ohne standardisierte Notation beschreiben der Projektzeitplan und das Prozessdiagramm unterschiedliche Realitäten, und keines von beiden steuert das andere. In einem BPMN-Geschäftsprozessdiagramm codiert das Gateway vor dem rechtlichen Prüfschritt exakt, wann die Prüfung ausgelöst wird und was passiert, wenn Änderungen zurückkommen. Diese Präzision macht das Diagramm für die Koordination nützlich und nicht nur für die Dokumentation.
Enterprise-Architekten, die für Automatisierung entwerfen
Ein Enterprise-Architekt, der einen Eskalationsprozess im Kundenservice entwirft, nutzt die Swimlanes und Prozessmodellstruktur von BPMN, um festzulegen, welche Aufgaben zum CRM-System gehören, welche zum Ticketsystem und welche menschliches Eingreifen erfordern. Ohne die Notation bleiben das Architekturdokument und die Beschreibung des operativen Prozesses dauerhaft nicht aufeinander abgestimmt. Der BPMN-Nachrichtenfluss über Poolgrenzen hinweg macht Integrationspunkte explizit statt implizit – die grafische Version eines API-Vertrags.
Compliance-Teams, die prüfbare Prozessdokumentation erstellen
Ein Compliance-Beauftragter, der einen Datenverarbeitungsprozess für eine regulatorische Prüfung dokumentiert, verwendet BPMN-Vorlagen und -Formen, um Diagramme zu erstellen, die sowohl die Anforderungen des regulatorischen Prüfers erfüllen, der den Geschäftsablauf verstehen muss, als auch die des technischen Prüfers, der kontrollieren muss, ob die Implementierung der Spezifikation entspricht. Ohne standardisierte Notation sind Compliance-Dokumentation und technische Implementierung zwei getrennte Artefakte, die manuell abgeglichen werden müssen. Ein BPMN-Diagramm, das den Prozess auf Implementierungsebene spezifiziert, eliminiert diesen Abgleichschritt.
Drei BPMN-Irrtümer, die Teams zurück ans Zeichenbrett schicken
Ich habe beobachtet, wie drei konkrete Irrtümer Diagramme hervorbringen, die ignoriert werden, Teams, die genau die Menschen ausschließen, die am dringendsten einbezogen werden müssten, und Workshops, die damit enden, dass alle zustimmen, das Diagramm sei zu kompliziert für die Nutzung. Alle drei lassen sich beheben. Alle drei sind verbreitet.
BPMN ist nur ein aufwendiges Flussdiagramm
Dieser Irrtum verursacht die meisten Folgeprobleme, weil er Teams dazu verleitet, ihre bestehenden improvisierten Prozessskizzen in ein BPMN-Tool zu importieren und das Ergebnis BPMN-Diagramm zu nennen. Das Diagramm sieht nach BPMN aus – es enthält Kreise, Rauten und Boxen –, aber die Kreise unterscheiden nicht zwischen Start- und Endereignissen, die Rauten spezifizieren keinen Gateway-Typ, und die Swimlanes sind dekorativ statt verbindlich.
Was ein BPMN-Diagramm tatsächlich von einem Flussdiagramm unterscheidet, ist die von OMG spezifizierte Semantik hinter den Symbolen. Ein Startereignis mit einem Punkt darin bedeutet etwas Konkretes: Die Prozessinstanz wird erstellt, wenn eine Nachricht eintrifft. Ein Kreis am Anfang ohne Inhalt bedeutet etwas anderes: Der Prozess startet bedingungslos. Diese Unterschiede haben Folgen für die Implementierung. Das falsche Symbol erzeugt ein Prozessmodell, das vernünftig aussieht und die Spezifikation auf eine Weise verletzt, die erst sichtbar wird, wenn jemand versucht, es umzusetzen.
Die Lösung besteht nicht aus mehr Symbolen, sondern darin, vor dem Zeichnen zu lernen, was die grundlegenden Symbole tatsächlich bedeuten. Ein Diagramm mit korrekten Flussobjekten, typisierten Gateways und ehrlichen Swimlane-Zuordnungen kommuniziert mehr als ein dichtes Diagramm mit willkürlichen Dekorationen.
BPMN ist nur für technische Entwickler
Dies ist der umgekehrte Fehler des ersten Irrtums. Manche Teams überlassen BPMN-Diagramme vollständig den Entwicklern und beziehen die Business-Stakeholder, die den Prozess verantworten, nie ein. Das Ergebnis sind Diagramme voller Teilprozesse, Call Activities, Kompensationsereignisse und Nachrichtenkorrelationen, die technisch korrekt und für die Personen, die die Prozesslogik validieren müssen, völlig unlesbar sind.
Die Ebene für Geschäftsabläufe und die Ebene für technische Implementierung sind bei BPMN bewusst voneinander trennbar. Die Notation unterstützt dies ausdrücklich durch eingeklappte Teilprozesse, Call Activities und Konventionen für Detailstufen, mit denen ein Diagramm einem Business-Stakeholder eine Sache und einem technischen Entwickler, der dieselbe Spezifikation liest, eine andere Detailstufe zeigen kann.
Wenn Geschäftsanwender von BPMN-Diagrammen ausgeschlossen werden, werden die Prozessmodelle nicht mehr von den Menschen validiert, die den Prozess tatsächlich kennen. Die technische Darstellung entwickelt sich in eine Richtung weiter, während die geschäftliche Realität in eine andere abdriftet. Das ist dann kein technisches Problem mehr.
BPMN-Diagramme müssen komplex sein, um wertvoll zu sein
Dieser Irrtum ist im Support besonders frustrierend, weil die Teams, die ihm verfallen, meist die gewissenhaftesten sind. Sie haben die Notation gelernt, wenden sie sorgfältig an und enden mit einem Diagramm, das jeden Ausnahmepfad, jedes Datenobjekt und jede Annotation dokumentiert – und das niemand liest.
Das Best-Practice-Signal von Praktikern, die komplexe Prozesse professionell modellieren, lautet: Ein BPMN-Diagramm auf eine einzelne Seite zu beschränken, schafft häufig mehr Wert als eine vollständige Abdeckung. Ein Diagramm, das während einer Stakeholder-Prüfung auf einen Bildschirm passt, wird in dieser Prüfung genutzt. Ein Diagramm, das Scrollen erfordert, wird geschlossen. Die Abfolge der Geschäftsaktivitäten, die Verzweigungslogik der Gateways und der Sequenzfluss zwischen den Schritten sollten ohne Navigation sichtbar sein. Wenn das nicht der Fall ist, dient das Diagramm seiner Zielgruppe nicht mehr.
Datenobjekte, Annotationselemente und Teilprozessdetails können in unterstützenden Diagrammen untergebracht werden. Der Hauptablauf sollte die einfachste korrekte Darstellung des Prozesses sein, nicht die vollständigste.
Das ist kein Designkompromiss. Das ist eine BPMN-Best-Practice.
📊 In der Praxis:
Eine praktische Prüfung vor Ihrer nächsten Stakeholder-Review: Wenn Sie nicht den gesamten BPMN-Hauptablauf in weniger als drei Minuten durchgehen können, ohne Symbole erklären zu müssen, dient das Diagramm eher dem Autor als dem Publikum. Versuchen Sie, jeden Teilprozess auf eine einzelne Box einzuklappen, und prüfen Sie, ob der Hauptablauf weiterhin die richtige Geschichte erzählt. Wenn ja, können die Details an anderer Stelle stehen.
