BPMN (Business Process Model and Notation) ist die Standardsprache, um Geschäftsprozesse zu zeichnen: eine Sammlung von Symbolen, die Fachbereich und IT gleich lesen und die in Version 2.0 eine Engine ausführen kann. Ein BPMN-Diagramm lesen und schreiben zu können ist die zentrale Kompetenz aller, die mit Prozessen arbeiten – und die Gateways zu beherrschen ist das, was eine hübsche Zeichnung von einem Prozess unterscheidet, der funktioniert.
Dieser Leitfaden geht die BPMN-Symbole nach Familien gruppiert durch, mit einem SVG für jedes, erklärt die vier Gateways und den klassischen Fehler, der eine Blockade verursacht, und endet mit einem vollständigen BPMN-Diagramm zur Rechnungsfreigabe. Er ist die praktische Ergänzung zu unserem Leitfaden Was ist BPM?.
BPMN steht für Business Process Model and Notation: Modell und Notation für Geschäftsprozesse. Es ist der internationale Standard, um grafisch darzustellen, wie ein Prozess funktioniert, gepflegt von der Object Management Group (OMG) und als Norm ISO/IEC 19510 veröffentlicht. Ziel ist, dass dasselbe Diagramm von drei Zielgruppen verstanden wird, die normalerweise unterschiedliche Sprachen sprechen: dem Business-Analysten, der den Prozess kennt, der Führungskraft, die ihn freigibt, und dem technischen Team, das ihn umsetzt.
Der große Unterschied zwischen BPMN und einem einfachen Flussdiagramm ist die präzise Semantik. In einem Flussdiagramm bedeutet eine Raute „eine Entscheidung" und jeder Autor zeichnet sie auf seine Weise. In BPMN ist eine Raute mit einem X darin ein exklusives Gateway mit einem auf den Millimeter definierten Verhalten, das sich von der Raute mit einem +-Zeichen (parallel) unterscheidet. Diese Präzision ist es, die ein BPMN-2.0-Diagramm ausführbar macht: eine Prozess-Engine interpretiert es direkt und verwandelt es in eine echte Anwendung, ohne dass jemand es in Code „übersetzen" und dabei Nuancen verlieren muss.
Es lohnt sich, BPMN in die größere Disziplin einzuordnen, der es dient. BPMN ist die Notation, die in der Modellierungsphase des BPM-Lebenszyklus verwendet wird; wenn Sie das vollständige Bild möchten – was Prozessmanagement ist, wie es sich von einem Workflow oder von RPA unterscheidet und wie es eingeführt wird – beginnen Sie mit dem Pillar-Leitfaden Was ist BPM?.
In einem Satz: BPMN verhält sich zu Prozessen wie die Notenlinien zur Musik. Eine gemeinsame Sprache, die jeder lesen und eine Maschine ausführen kann. Dieser Leitfaden bringt Ihnen bei, sie zu lesen und gut zu schreiben.
BPMN 2.0 definiert Dutzende von Symbolen, aber Sie müssen nicht alle auswendig lernen. Vier Familien decken die überwiegende Mehrheit der Geschäftsdiagramme ab: Ereignisse, Aktivitäten, Gateways und Sequenzflüsse. Darum herum vervollständigen zwei organisierende Elemente – Lanes (Verantwortung) und Artefakte (Anmerkungen und Datenobjekte) – das Bild.
Kreise. Etwas, das geschieht: es startet, unterbricht oder beendet den Prozess.
Abgerundete Rechtecke. Die Arbeit: Aufgaben und Teilprozesse.
Rauten. Entscheidungen: der Ablauf verzweigt sich oder wird synchronisiert.
Pfeile. Die Reihenfolge: sie verbinden die Elemente in einer Sequenz.
Ein Pool repräsentiert einen Teilnehmer (eine Organisation oder ein System); darin teilen die Lanes (Swimlanes) die Arbeit nach Rolle oder Abteilung auf. Sie ordnen jede Aktivität einem klaren Verantwortlichen zu. Wir behandeln dies im Detail in Abschnitt 6.
Sie verändern den Ablauf nicht, sie dokumentieren ihn: Datenobjekte (ein Dokument, das in eine Aufgabe ein- oder austritt), Textanmerkungen (Hinweise für den Leser) und Gruppen (Kästen, die visuell zusammenfassen). Nützlich, damit sich das Diagramm von selbst liest.
Ein Ereignis ist etwas, das während des Prozesses geschieht. Es wird immer als Kreis gezeichnet, und die Stärke der Linie zeigt seine Position im Ablauf an: das Startereignis hat eine dünne Linie, das Zwischenereignis ist ein Doppelkreis und das Endereignis hat eine dicke Linie. Allein diese Regel erlaubt es Ihnen schon, auf einen Blick zu erkennen, wo ein Prozess ein- und austritt.
Zusätzlich gibt ein Symbol im Kreis den Typ des Ereignisses an: ein Briefumschlag ist ein Nachrichtenereignis (etwas trifft ein oder wird gesendet), eine Uhr ist ein Timer (eine Frist läuft ab), ein Blitz ist ein Fehler und ein Dreieck ist ein Signal (ein Broadcast, den mehrere Prozesse gleichzeitig hören können).
Der Prozess startet, wenn etwas von außen eintrifft: eine E-Mail, ein abgesendetes Webformular, eine empfangene Rechnung. Es ist der häufigste Auslöser in Geschäftsprozessen.
Es lässt den Ablauf warten („warte 3 Tage") oder, am Rand einer Aufgabe angehängt, unterbricht es sie, wenn die Frist abläuft. Es ist die Grundlage automatischer SLA-Eskalationen.
Es fängt einen Fehler einer Aufgabe oder eines Teilprozesses ab und leitet den Ablauf über einen Zweig zur Fehlerbehandlung um, ohne die Ausführung zu unterbrechen.
Es schließt einen Pfad des Prozesses ab. Ein Diagramm kann mehrere Endereignisse haben (freigegeben, abgelehnt, storniert): das ist kein Fehler, sondern Best Practice, um Ergebnisse zu unterscheiden.
Eine Aktivität ist die Arbeit, die erledigt wird, und sie wird als Rechteck mit abgerundeten Ecken gezeichnet. Was einen Aufgabentyp vom anderen unterscheidet, ist ein kleines Symbol in der oberen linken Ecke: eine Person für die Benutzeraufgabe, Zahnräder für die Service-Aufgabe, eine Hand für die manuelle Aufgabe, eine Schriftrolle für die Skript-Aufgabe und eine Tabelle für die Geschäftsregel-Aufgabe (Business Rule).
Wenn eine Aktivität ihrerseits einen weiteren Prozess umschließt, ist es ein Teilprozess (mit einem +-Zeichen am unteren Rand, das anzeigt, dass er sich aufklappen lässt) oder eine Call Activity (dicke Linie), die einen separat definierten, wiederverwendbaren Prozess aufruft. Und die Marker am Sockel der Aufgabe zeigen Wiederholung an: eine Schleife (↻) oder drei Balken für Multi-Instanz (dieselbe Aufgabe für mehrere Elemente gleichzeitig, z. B. „Angebot bei 3 Lieferanten anfragen").
Ein für die Ausführung wichtiges Detail: der Aufgabentyp ist nicht dekorativ. In einer BPMN-Engine erzeugt eine Benutzeraufgabe einen Eintrag im Postkorb einer Person; eine Service-Aufgabe löst einen Aufruf an ein System oder eine API aus; eine Regel-Aufgabe wertet eine Entscheidungstabelle aus. Deshalb ist es das korrekte Modellieren des Typs jeder Aufgabe, das das Diagramm direkt ausführbar macht. Eine Service-Aufgabe kann durch Code, durch einen RPA-Bot oder durch einen gesteuerten KI-Agenten erledigt werden – das Diagramm ändert sich nicht.
Die Gateways sind das Herzstück der Logik eines Prozesses und der Teil, der die meisten Zweifel aufwirft. Sie werden immer als Raute gezeichnet, und ein inneres Symbol definiert ihr Verhalten. Vier davon müssen Sie beherrschen. Die Merkregel: ein divergierendes Gateway öffnet Pfade und ein konvergierendes führt sie wieder zusammen; beim Zusammenführen den falschen Typ zu verwenden ist die Hauptursache für Prozesse, die sich blockieren.
Der Ablauf nimmt einen einzigen Pfad, den ersten, dessen Bedingung wahr ist. Es ist das „if/else" des Prozesses. Beispiel: „Übersteigt der Betrag 5.000 €?" → Ja geht zur Freigabe durch den Leiter; Nein wird direkt verbucht. Nur einer der beiden Zweige wird ausgeführt.
Es aktiviert alle Pfade gleichzeitig, ohne Bedingungen. Beispiel: beim Einstellen einer Person werden parallel die IT-Ausstattung vorbereitet, die Person in der Lohnabrechnung angelegt und die Zutrittskarte beantragt. Die parallele Konvergenz wartet, bis alle fertig sind, bevor es weitergeht.
Es aktiviert alle Pfade, deren Bedingung erfüllt ist, von einem bis allen. Beispiel: eine Reklamation kann je nach Fall eine rechtliche Prüfung, eine technische Prüfung oder beides erfordern. Die inklusive Konvergenz wartet nur auf die Zweige, die tatsächlich ausgelöst wurden.
Den Weg entscheidet keine Datenbedingung, sondern welches Ereignis zuerst eintritt. Beispiel: nach dem Versand eines Angebots wartet der Prozess: trifft die Zusage des Kunden ein, geht es zur Fakturierung; läuft die Frist von 15 Tagen ab (Timer), geht es zur Vertriebsnachverfolgung.
Der häufigste Fehler beim Modellieren von BPMN: den Ablauf mit einem exklusiven Gateway zu öffnen (bei dem nur ein Zweig ausgelöst wird) und ihn dann mit einem parallelen Gateway zur Zusammenführung schließen zu wollen. Das parallele wartet, bis alle Zweige eintreffen – aber da das exklusive nur einen aktiviert hat, treffen die anderen nie ein. Der Prozess wartet für immer: das ist ein Deadlock (Blockade).
Die Regel, um es zu vermeiden: schließen Sie mit demselben Typ, mit dem Sie geöffnet haben. Was in einem exklusiven divergierte, wird in einem exklusiven wieder zusammengeführt; Paralleles in Parallelem; Inklusives in Inklusivem. Das Öffnen mit dem Schließen abzustimmen beseitigt die überwiegende Mehrheit der Blockaden.
Ein BPMN-Diagramm zeigt nicht nur, was passiert, sondern wer es tut. Dafür gibt es die Lanes (Swimlanes). Stellen Sie sich ein Schwimmbecken von oben vor: das große Rechteck ist der Pool (der vollständige Teilnehmer, z. B. „Unser Unternehmen") und die horizontalen Streifen darin sind die Lanes, eine je Rolle oder Abteilung: Finanzen, HR, das System. Jede Aufgabe wird in der Lane des Verantwortlichen gezeichnet, der sie ausführt – so wissen Sie, wenn Sie vertikal lesen, wem jeder Schritt gehört.
Die entscheidende Unterscheidung ist, wann man eine Lane und wann einen separaten Pool verwendet:
Wenn alle Teilnehmer zur selben Organisation gehören und den Prozess teilen. Die Aufgaben werden mit Sequenzflüssen (durchgezogene Pfeile) verbunden, die von einer Lane in eine andere wechseln. Beispiel: Finanzen und das ERP-System im Rechnungsprozess.
Wenn eine andere Organisation beteiligt ist (ein Kunde, ein Lieferant, eine Behörde), deren internen Prozess Sie weder steuern noch sehen. Pools werden nicht mit Sequenzflüssen verbunden, sondern mit Nachrichtenflüssen (gestrichelte Pfeile): sie tauschen nur Kommunikation aus.
Diese Regel vermeidet einen häufigen Fehler: den Kunden als eine weitere Lane in den eigenen Pool zu setzen. Sie orchestrieren die internen Aufgaben des Kunden nicht – Sie senden und empfangen nur Nachrichten von ihm. Ihn als separaten Pool zu modellieren macht die Verantwortungsgrenze klar und das Diagramm ehrlich darüber, was Sie tatsächlich steuern.
Fügen wir alles in einem realen Diagramm zusammen. Wir modellieren die Freigabe einer Rechnung mit einem Pool aus zwei Lanes – Finanzen (die Menschen) und System (die automatischen Schritte) – einem Nachrichten-Startereignis, einer OCR-Service-Aufgabe, einem exklusiven Gateway, das nach dem Betrag entscheidet, einer Benutzeraufgabe zur Freigabe, der Erfassung im ERP und einem Endereignis.
Lesen Sie es entlang der Pfeile: die Rechnung trifft ein und startet den Prozess in der Lane System; die OCR-Service-Aufgabe extrahiert Betrag, Lieferant und Fälligkeit; das exklusive Gateway betrachtet den Betrag. Die unter 5.000 € benötigen keine Person und gehen direkt ins ERP; die darüber gehen in die Lane Finanzen, wo eine Person freigibt, bevor das System sie erfasst. Ein einziges Endereignis markiert „verbucht".
Beachten Sie, was das Diagramm ohne eine einzige Zeile Prosa explizit macht: welche Schritte automatisch und welche menschlich sind (die Lanes), wo die Entscheidung liegt und nach welchem Kriterium (das Gateway und seine Beschriftung) und wann eine Person eingreift (nur oberhalb des Schwellwerts). Das ist die Stärke von BPMN: es dokumentiert, kommuniziert und – in BPMN 2.0 – wird ausgeführt, alles mit derselben Zeichnung. Genau diese Art von Prozess finden Sie aktivierungsbereit im Katalog der BPM-Vorlagen.
Hier liegt der Unterschied, der den Markt verändert hat. In der Welt der klassischen Flussdiagramme war die Zeichnung Dokumentation: jemand gab sie frei, und dann „übersetzte" sie ein Team in Code. Bei dieser Übersetzung gingen Nuancen verloren, es wurden Abweichungen eingeführt und sechs Monate später stimmten Diagramm und Realität nicht mehr überein.
Mit BPMN 2.0 auf einer Prozess-Engine gibt es keine Übersetzung: das Diagramm ist das Programm. Die Engine liest das XML des Modells (BPMN 2.0 definiert ein standardisiertes Austauschformat) und führt es so aus, wie es ist. Wenn der Ablauf eine Benutzeraufgabe erreicht, erstellt die Engine den Eintrag im Postkorb der Person; bei einer Service-Aufgabe ruft sie das System auf; bei einem Gateway wertet sie die Bedingung aus und wählt den Zweig. Was der Fachbereich validiert hat, ist buchstäblich das, was in Produktion läuft.
Auf einer Low-Code-BPM-Plattform geht dies einen Schritt weiter: neben dem Diagramm entwerfen Sie die Formulare, die Regeln und die Integrationen visuell, ohne zu programmieren. Die Phasen Modellieren und Ausführen des BPM-Lebenszyklus fallen in eine zusammen. Deshalb misst sich der erste produktive Prozess in Wochen, nicht in Monaten.
Wenn Sie sehen möchten, wie ein ausführbarer BPMN-Prozess von Anfang bis Ende aufgebaut wird, werfen Sie einen Blick auf die Low-Code-BPM-Plattform von Dokuflex; und für den vollständigen Kontext der Disziplin den Leitfaden Was ist BPM?.
Ein technisch korrektes BPMN-Diagramm kann trotzdem unlesbar sein. Diese einfachen Konventionen machen den Unterschied zwischen einem Modell, das sich von selbst erklärt, und einem, das einer Erklärung bedarf:
„Rechnung freigeben", „Im ERP erfassen", „Kunde benachrichtigen". Nicht „Rechnung" oder „Verwaltung": eine Aufgabe ist eine Handlung. Ereignisse hingegen werden als Substantiv oder Zustand benannt („Rechnung empfangen", „Vertrag unterzeichnet").
Zeichnen Sie den Hauptablauf in einer geraden horizontalen Linie und lassen Sie Ausnahmen und Ablehnungen nach oben oder unten abzweigen. Der Leser sollte den Normalfall mühelos verfolgen und die Abweichungen als Zweige erkennen können.
Sich kreuzende Pfeile sind das visuelle Zeichen eines unordentlichen Diagramms. Ordnen Sie die Position der Aufgaben neu an, bis sich die Flüsse nicht überlappen; fast immer ist das möglich.
Wenn ein Prozess zu groß wird, lässt er sich nicht mehr lesen. Kapseln Sie Blöcke in Teilprozesse, die sich aufklappen lassen: das Diagramm der ersten Ebene erzählt die Geschichte, und jeder Teilprozess liefert das Detail an den, der es braucht.
Was ein exklusives öffnet, schließt ein exklusives; Paralleles ein paralleles. Es ist die Regel, die die Deadlocks aus Abschnitt 5 vermeidet. Und beschriften Sie immer die Zweige eines exklusiven (Ja/Nein, <5.000/>5.000).
Ein Prozess entwickelt sich weiter. Speichern Sie Versionen des Modells und halten Sie in der Engine die alte Version für laufende Vorgänge und die neue für die beginnenden parallel verfügbar. Das Ändern des Diagramms sollte nicht zerstören, was bereits in Gang ist.
Und ein grundlegenderer Fehler jenseits der Notation: modellieren Sie nicht den Prozess, den Sie gerne hätten, sondern den, den Sie haben – einschließlich seiner realen Ausnahmen – und verbessern Sie ihn dann. Ein idealisiertes Diagramm, das die schwierigen Fälle ignoriert, zerbricht am ersten Tag in der Produktion.
BPMN steht für Business Process Model and Notation (Modell und Notation für Geschäftsprozesse). Es ist der internationale Standard, gepflegt von der Object Management Group (OMG) und als Norm ISO/IEC 19510 veröffentlicht, der eine grafische Sprache definiert, um Prozesse so darzustellen, dass jede Person sie versteht und – in BPMN 2.0 – eine Engine sie ausführen kann.
Nein. Ein klassisches Flussdiagramm ist informell: jeder Autor verwendet die Symbole auf seine Weise und es ist nicht ausführbar. BPMN 2.0 ist ein Standard mit präziser Semantik: jedes Symbol hat eine definierte Bedeutung (Ereignisse vom Typ Nachricht oder Timer, exklusive oder parallele Gateways, Lanes pro Verantwortlichem) und eine BPM-Engine kann das Diagramm interpretieren und in Produktion bringen, ohne es neu zu interpretieren.
Das inklusive Gateway (Raute mit einem Kreis darin, das Symbol O). Es aktiviert alle Pfade, deren Bedingung wahr ist, von einem bis allen gleichzeitig. Wenn nur eine Bedingung erfüllt sein kann, nutzen Sie das exklusive (X); wenn Sie immer alle Pfade parallel, ohne Bedingung starten möchten, nutzen Sie das parallele (+). Denken Sie daran, eine inklusive Verzweigung mit einem weiteren inklusiven Gateway zur Zusammenführung zu schließen, damit korrekt synchronisiert wird.
Zum Zeichnen genügt jeder Editor, der den Standard unterstützt (auch kostenlose Editoren auf Basis von bpmn.io). Der Wert von BPMN 2.0 liegt jedoch darin, dass das Diagramm ausführbar ist: Auf einer Low-Code-BPM-Plattform wird genau das Diagramm, das Sie mit dem Fachbereich validieren, zur echten Anwendung – mit Formularen, Regeln und Integrationen, ohne es in einem anderen Werkzeug neu zu zeichnen.
Ja. Eine Aufgabe in einem BPMN-Prozess kann von einer Person, einem Service, einem RPA-Bot oder einem KI-Agenten ausgeführt werden. Den KI-Schritt als Service-Task im Diagramm zu modellieren erhält die Nachvollziehbarkeit: das nachfolgende Gateway entscheidet je nach Ergebnis oder Vertrauensniveau, und der Ablauf eskaliert zu einer Benutzeraufgabe, wenn die KI den Schwellwert nicht erreicht (Human-in-the-Loop).
Obwohl BPMN 2.0 Dutzende Symbole definiert, decken vier Gruppen 90 % der realen Diagramme ab: Ereignisse (Start, Zwischen, Ende), Aktivitäten (Aufgaben und Teilprozesse), Gateways (exklusiv, parallel, inklusiv und ereignisbasiert) und Sequenzflüsse, organisiert in Lanes. Mit dieser Teilmenge lassen sich nahezu alle Geschäftsprozesse modellieren.
Bringen Sie den Prozess mit, den Sie bereits gezeichnet haben – Rechnungen, Urlaub, Onboarding – und wir zeigen Ihnen dasselbe BPMN-Diagramm in einer 30-minütigen Demo auf Dokuflex laufen. Unverbindlich und mit Ihrem Fall, nicht mit einem Laborbeispiel.