Die Fluss-Objekte sind die Hauptdarsteller auf deiner Bühne. Sie sind die Elemente, die den eigentlichen Ablauf definieren. Ohne sie gibt es keine Handlung. Wir unterscheiden hier drei Typen, die du rein optisch sofort auseinanderhalten kannst: Kreise, Rechtecke und Rauten.

Ereignisse werden immer als Kreise dargestellt. Sie symbolisieren, dass im Verlauf eines Prozesses "etwas geschieht". Das kann der Eingang einer Bestellung sein, das Verstreichen einer Frist oder einfach der Startschuss für die Arbeit. Man unterscheidet sie nach ihrer Position im Prozess:

• Ein Start-Ereignis (dünner Rand) löst den Prozess aus.
  
  

• Ein Zwischen-Ereignis (doppelter Rand) tritt auf, während der Prozess bereits läuft – etwa wenn wir auf eine Rückmeldung warten.
  
  

• Das End-Ereignis (dicker Rand) markiert schließlich das Resultat, beispielsweise dass der Auftrag abgeschlossen oder storniert wurde.

Die eigentliche Arbeit findet in den Aktivitäten statt, die als abgerundete Rechtecke dargestellt werden. Hier wird Wert geschöpft.

Wenn die Aufgabe nicht weiter unterteilt werden kann, sprechen wir von einem Task (Aufgabe). Das ist der kleinste Arbeitsschritt, wie "Rechnung prüfen" oder "E-Mail senden".

Wird die Arbeit jedoch komplexer, nutzen wir einen Subprozess. Er kapselt mehrere Schritte in einem einzigen Symbol, um das Diagramm lesbar zu halten. Du erkennst ihn oft an einem kleinen Plus-Zeichen am unteren Rand.

Die Rauten im Diagramm sind die Gateways. Hier entsteht oft ein Missverständnis: Ein Gateway trifft selbst keine Entscheidungen. Die Entscheidung – also die inhaltliche Prüfung – findet in der Aktivität davor statt. Das Gateway fungiert eher als Verkehrspolizist: Es prüft die Datenlage und lenkt den Prozessfluss in die entsprechende Richtung.

Das Exklusive Gateway (XOR), oft leer oder mit einem "X" dargestellt, lässt nur genau einen Weg zu: Entweder wird der Antrag genehmigt oder abgelehnt.

Müssen mehrere Dinge gleichzeitig passieren, nutzt du das Parallele Gateway (AND) mit einem Plus-Zeichen. Es aktiviert alle ausgehenden Pfade simultan.

Daneben gibt es noch das Inklusive Gateway (OR) für "einen oder mehrere Wege" und komplexe Typen für Spezialfälle (Event-based-Gateway und komplexes Gateway).

Die besten Objekte nützen nichts, wenn sie isoliert im Raum stehen. Erst die Verbindungslinien geben dem Prozess seine Struktur und Logik. Hier musst du genau hinsehen, denn die Art der Linie ändert die Bedeutung drastisch.

Der Sequenzfluss ist eine durchgezogene Linie mit einer gefüllten Pfeilspitze. Er ist das Rückgrat deines Modells und zeigt strikt die zeitliche Reihenfolge an: "Erst Schritt A, dann Schritt B". Eine goldene Regel, die du dir sofort merken solltest: Ein Sequenzfluss darf niemals die Grenzen eines Pools verlassen.

Wenn du nämlich kommunizieren willst – etwa zwischen deiner Firma und einem Kunden – nutzt du den Nachrichtenfluss. Dieser wird als gestrichelte Linie mit einem offenen Pfeil dargestellt. Er sagt nicht "jetzt bist du dran mit arbeiten", sondern "hier fließt eine Information oder ein Dokument an einen externen Partner".

Zuletzt gibt es die Assoziation, eine gepunktete Linie. Sie steuert nicht den Ablauf, sondern verknüpft Informationen (wie Dokumente oder Notizen) mit den Objekten im Fluss.

BPMN nutzt das visuelle Konzept von "Schwimmbahnen", um klarzustellen, wer für welchen Schritt verantwortlich ist.

Das größte Gefäß ist der Pool. Er repräsentiert einen Teilnehmer in einer Zusammenarbeit, meistens eine ganze Organisation (z.B. "Lieferant") oder eine spezifische Prozess-Instanz. Alles, was innerhalb der Grenzen eines Pools passiert, unterliegt der Kontrolle dieses Teilnehmers. Ein Pool kann "White Box" sein (man sieht die internen Prozesse) oder "Black Box" (leer), wenn uns die internen Abläufe des Partners, wie etwa beim Kunden, nicht bekannt sind.

Innerhalb eines Pools sorgen Lanes für weitere Ordnung. Sie unterteilen die Organisation in konkrete Zuständigkeitsbereiche wie Abteilungen ("Buchhaltung"), Rollen ("Manager") oder Systeme. Wenn ein Task in der Lane "Vertrieb" liegt, ist ohne weitere Worte klar, wer diesen Schritt ausführen muss.

Manchmal reicht der reine Ablauf von Tätigkeiten nicht aus, um das volle Bild zu vermitteln. Du willst vielleicht zeigen, welches Dokument bearbeitet wird oder eine zusätzliche Erklärung anfügen, ohne die technische Logik des Prozesses zu verändern.

Hier kommen Datenobjekte ins Spiel. Sie sehen aus wie ein Blatt Papier mit Eselsohr und zeigen an, welche Informationen in eine Aktivität hineingehen (Input) oder als Ergebnis herauskommen (Output). Das ist besonders wichtig, wenn Prozesse später technisch umgesetzt werden sollen. Für Daten, die dauerhaft gespeichert werden (wie in einer Datenbank), gibt es das Symbol des Datenspeichers (Data Store).

Zusätzlich kannst du Anmerkungen (Text Annotations) nutzen. Das ist dein "Notizzettel" im Diagramm, der mit einer eckigen Klammer an ein Objekt geheftet wird. Oder du nutzt Gruppen, um visuell zu zeigen, dass bestimmte Elemente logisch zusammengehören, etwa für eine Analyse oder Dokumentation. Wichtig ist hierbei: Artefakte beeinflussen niemals den technischen Lauf des Prozesses, sie sind reine Zusatzinformationen.

Wenn du ein BPMN-Modell betrachtest, siehst du erst einmal nur ein statisches Bild. Doch ein Prozess ist Bewegung. Um zu verstehen, wie dein Modell technisch funktioniert – und um logische Fehler zu vermeiden – musst du lernen, den Token zu sehen.

Der Token ist ein theoretisches Konzept, das als Hilfsmittel dient, um das Verhalten eines Prozesses während der Ausführung zu definieren. Stell ihn dir wie einen kleinen Ball oder eine farbige Kugel vor, die durch die Leitungen (Sequenzflüsse) deines Diagramms läuft.

Wie der Token wandert

Die Reise des Tokens folgt festen physikalischen Gesetzen der BPMN-Welt:

• Die Geburt: Wenn ein Prozess startet (z. B. durch ein Start-Ereignis), wird ein Token erzeugt.

• Die Reise: Der Token wandert entlang der Sequenzflüsse zu den Aktivitäten, Gateways und Ereignissen.

• Der Stopp: Erreicht der Token eine Aktivität (z. B. einen User Task), bleibt er dort liegen, bis die Arbeit erledigt ist. Erst dann darf er weiterziehen.

• Das Ende: Erreicht der Token ein End-Ereignis, wird er "konsumiert" – also vernichtet. Wenn alle Tokens im Prozess vernichtet sind, ist die Prozessinstanz beendet.

Wichtig: Ein Token bewegt sich niemals über einen Nachrichtenfluss (die gestrichelte Linie), sondern immer nur innerhalb eines Pools über die Sequenzflüsse.

Die Magie an den Gateways

Das Token-Konzept hilft dir enorm, wenn es um Verzweigungen geht. Hier passieren Dinge, die Anfänger oft übersehen:

• Am Exklusiven Gateway (XOR): Der Token kommt an, prüft die Bedingung und biegt entweder links oder rechts ab. Er bleibt ein einziger Token.

• Am Parallelen Gateway (AND - Split): Hier geschieht etwas Besonderes. Wenn ein Token in ein paralleles Gateway läuft, wird er vervielfältigt. Aus einem Token werden zwei (oder mehr), die nun gleichzeitig durch die verschiedenen Pfade laufen.

• Am Parallelen Gateway (AND - Join): Wenn die Pfade wieder zusammenlaufen, wartet das Gateway. Der erste Token, der ankommt, muss warten, bis auch der zweite Token aus dem anderen Pfad da ist. Erst wenn alle erwarteten Tokens eingetroffen sind, verschmelzen sie wieder zu einem einzigen Token, der weiterlaufen darf.

Wenn du dieses Prinzip verinnerlichst, vermeidest du den häufigsten Fehler in der Modellierung: Deadlocks. Das passiert, wenn ein paralleles Gateway auf einen Token wartet, der niemals ankommt, weil er an einer anderen Stelle im Prozess falsch abgebogen ist.

Jetzt, wo du die Symbole und das Token-Konzept kennst, könntest du theoretisch loslegen und Prozesse zeichnen. Doch Vorsicht: Nur weil ein Satz grammatikalisch korrekt ist, ergibt er noch lange keinen Sinn. Genau so ist es in BPMN. Du kannst ein Modell bauen, das technisch völlig "valide" ist (also keine Regeln der Spezifikation verletzt), das aber trotzdem niemand versteht – oder schlimmer noch, das falsch verstanden wird.

Hier kommt der Ansatz von Method & Style ins Spiel. Es geht nicht nur darum, irgendein Diagramm zu erstellen, sondern ein Modell, das die Prozesslogik allein durch das Diagramm eindeutig und vollständig kommuniziert .

Das oberste Ziel von gutem Stil ist simpel: Ein BPMN-Diagramm muss für sich selbst sprechen. Wenn du deinem Diagramm ein fünfseitiges Word-Dokument beilegen musst, um zu erklären, was die Pfeile bedeuten, hast du das Ziel verfehlt.

Der Leser – egal ob aus der Fachabteilung oder der IT – muss auf einen Blick erkennen können:

• Wie startet der Prozess?

• Was passiert im Normalfall (Happy Path)?

• Was sind die Ausnahmen und wie endet der Prozess (Erfolg oder Misserfolg)?

Nach dem "Method and Style"-Ansatz sollte die Prozesslogik vollständig aus dem Diagramm ablesbar sein, ohne dass man "raten" muss, was der Modellierer gemeint hat

Ein häufiges Problem bei schlechten Modellen ist die Beschriftung. Ein Rechteck, in dem nur "Rechnung" steht, ist mehrdeutig. Ist das Erstellen der Rechnung gemeint? Das Prüfen? Oder der Versand?

Um Klarheit zu schaffen, nutzen Profis feste Konventionen für die Beschriftung :

• Aktivitäten (Activities) werden immer nach dem Prinzip Verb + Substantiv benannt. Schreibe also nicht "Bonitätsprüfung", sondern "Bonität prüfen". Das signalisiert Handlung.
  
  

• Ereignisse (Events) beschreiben einen Zustand. Nutze hier Objekt + Zustand (Partizip). Schreibe "Rechnung beglichen" oder "Auftrag storniert".
  
  

• Gateways stellen oft eine Ja/Nein-Frage. Beschrifte das Gateway mit der Frage (z.B. "Ware verfügbar?") und die ausgehenden Pfade mit den Antworten ("Ja" / "Nein").

Ein weiteres Merkmal von professionellem Stil ist der Umgang mit dem Ende eines Prozesses. Anfänger lassen oft alle Pfade in einem einzigen End-Ereignis zusammenlaufen, beschriftet mit "Ende".

Das ist zwar laut Standard erlaubt, aber inhaltlich schwach. Ein Prozess hat oft unterschiedliche Ausgänge: Er kann erfolgreich sein oder scheitern. Ein guter Modellierer trennt diese Endzustände (End States) . Wenn du beispielsweise einen Bestellprozess hast, solltest du zwei separate End-Events modellieren: Eines für "Bestellung erfolgreich versendet" und eines für "Bestellung abgelehnt". Das macht sofort sichtbar, dass der Prozess auch scheitern kann und zwingt dich dazu, den Fehlerpfad sauber zu modellieren.

Auch die Symmetrie spielt eine Rolle. Wenn du einen Pfad mit einem Gateway aufsplittest, solltest du ihn oft (nicht immer) strukturiert wieder zusammenführen. Das macht das Modell für das menschliche Auge leichter lesbar und logisch nachvollziehbar.

So wie du in Word eine Rechtschreibprüfung hast, kannst du BPMN-Modelle validieren. Die meisten Tools prüfen nur die Syntax (z.B. "Ist der Pfeil richtig angeschlossen?").

Wenn du nach "Method & Style" arbeitest, prüfst du aber auch den Stil. Du schaust, ob Labels vorhanden sind, ob Gateways beschriftet sind und ob Eltern- und Kind-Prozesse (bei Subprozessen) logisch zusammenpassen . Das hebt deine Arbeit von bloßer "Malerei" auf das Niveau professioneller Prozessarchitektur.

Einer der häufigsten Fehler, den Einsteiger machen, ist der Versuch, sofort alle 100+ Symbole zu nutzen. Das Ergebnis sind oft überladene "Wandtapeten", die kein Manager mehr lesen will.

Die Lösung dafür ist ein Stufenmodell. In der Praxis – und auch im offiziellen BPMN-Standard – unterscheiden wir drei Ebenen der Modellierung (sogenannte "Conformance Subclasses"). Je nachdem, wen du adressierst, nutzt du eine andere Detailtiefe.

Dies ist die "Vogelperspektive". Hier geht es um reine Dokumentation und Kommunikation mit dem Management oder fachfremden Kollegen. Das Ziel ist es, den Prozess grob zu verstehen, ohne sich in technischen Details zu verlieren.

Auf diesem Level nutzt du nur eine sehr begrenzte Palette an Symbolen (die sogenannte "Level 1 Palette"), die fast jedem intuitiv verständlich sind. Das sind im Wesentlichen die Symbole, die du auch aus klassischen Flussdiagrammen kennst:

• Einfache Start- und End-Ereignisse.

• Normale Tasks (Aufgaben).

• Pools und Lanes für die Verantwortlichkeiten.

• Gateways für einfache Entscheidungen.

Ein Level-1-Modell ignoriert oft komplexe Ausnahmebehandlungen. Es zeigt den "Happy Path" – also wie der Prozess idealerweise läuft.

Jetzt zoomen wir hinein. Dies ist die Ebene für Prozessanalysten und Requirements Engineers. Hier reicht es nicht mehr zu wissen, dass "etwas schiefgehen kann". Wir müssen präzise definieren, was genau passiert und wie wir darauf reagieren .

Level 2 nutzt die erweiterte Palette. Hier kommen die spezialisierten Ereignisse ins Spiel, die BPMN so mächtig machen:

• Was passiert, wenn der Kunde nach 14 Tagen nicht zahlt? (Timer Event).

• Wie reagieren wir auf einen Systemfehler? (Error Event).

• Wie gehen wir mit einer Stornierung um, während die Ware schon gepackt wird? (Message Event an der Aktivitätsgrenze).

Das Ziel von Level 2 ist es, alle logischen Pfade – auch die Ausnahmen – so exakt zu beschreiben, dass ein IT-Entwickler sie ohne Rückfragen implementieren könnte. Es ist der detaillierte Bauplan für die Software.

Hier verlassen wir die reine Zeichnung. Ein Modell auf Level 3 ist technischer Programmcode, der nur zufällig wie ein Bild aussieht. Solche Modelle werden direkt auf einer Process Engine (wie Camunda oder Signavio) ausgeführt .

Das Besondere: Die meisten Informationen auf diesem Level sind im Diagramm selbst gar nicht sichtbar. Sie stecken "unter der Haube" in den Eigenschaften der Elemente (im XML-Code):

• Genaue Datentypen und Variablen.

• Technische Ausdrücke für Gateway-Entscheidungen (z.B. Java Unified Expression Language).

• Schnittstellen-Definitionen für Service Tasks.

Für dich als Prozessdesigner ist wichtig zu wissen: Ein Modell kann visuell auf Level 2 perfekt sein (Analytisch), aber trotzdem nicht auf Level 3 funktionieren, weil technische Attribute fehlen. Level 3 ist die Domäne der IT-Entwicklung.

Wenn du bis hierhin gelesen hast, juckt es dich sicher in den Fingern, loszulegen. Vielleicht hast du schon PowerPoint oder Visio geöffnet. Mein dringender Rat als Experte: Tu es nicht. Zumindest nicht mit den Standard-Schablonen.

Warum? Weil BPMN mehr ist als nur "Kästchen malen". Wie wir gelernt haben, steckt hinter jedem Symbol eine präzise Bedeutung und – ab Level 2 und 3 – auch technischer Code (XML). Ein reines Zeichenprogramm weiß nicht, dass ein Sequenzfluss keine Pool-Grenzen überschreiten darf. Ein echtes BPMN-Tool schon .

Ein professionelles Tool unterstützt dich aktiv beim Modellieren. Es fungiert wie eine Rechtschreibprüfung in Word: Es warnt dich, wenn du gegen die Regeln des Standards verstößt (Validierung). Außerdem muss es in der Lage sein, dein Diagramm als standardisierte .bpmn-Datei (XML) zu speichern, damit du es später in anderen Systemen weiterverwenden kannst .

Wir unterscheiden grob zwei Kategorien:

• Reine Modellierungstools: Diese sind schlank und fokussieren sich darauf, schnell gute Diagramme zu erstellen.

• BPM-Suites (BPMS): Diese sind mächtige Plattformen, die nicht nur das Modellieren erlauben, sondern den Prozess auch technisch ausführen (Process Engine) und überwachen.

Es gibt viele Tools auf dem Markt, aber eines hat sich besonders bewährt, weil es die Brücke zwischen Business und IT extrem gut schlägt: Der Camunda Modeler.

Warum ich dieses Tool empfehle?

• Standardtreue: Es hält sich strikt an den BPMN 2.0 Standard.
  
  

• Flexibilität: Du kannst damit sowohl einfache fachliche Modelle (Level 1) zeichnen als auch tief in die technischen Attribute (Level 3) einsteigen, um Prozesse ausführbar zu machen .
  
  

• Simplicity: Die Benutzeroberfläche ist aufgeräumt und lenkt nicht vom Wesentlichen ab.

Natürlich gibt es je nach Unternehmensgröße und Zielsetzung auch andere starke Alternativen (wie Signavio für kollaboratives Prozessmanagement oder Bizagi).

Glückwunsch! Wenn du bis hierhin gelesen hast, weißt du jetzt mehr über Prozessmodellierung als 90% der Leute, die in Büros "Kästchen malen". Du kennst die Vokabeln (Elemente), die Grammatik (Regeln) und sogar den guten Stil (Method & Style).