BPMN Markdown: echtes BPMN 2.0 als Text — für Git, Docs und KI

Lesetipp: Zuerst die Direktiven, dann die Pools — jeder Pool ist ein eigener Teilnehmer (eigene „Schwimmbahn“).

@title und @direction LR steuern Überschrift und Leserichtung. Zwei pool-Blöcke modellieren getrennte Organisationen: der Kunde löst aus, der Shop erfüllt. Der Nachrichtenfluss -..-> verbindet Aufgaben über Pool-Grenzen hinweg (BPMN: Message Flow). Im Shop entscheidet ein XOR-Gateway <Lager?> — bei „nein“ endet der Prozess mit einem Fehler-Ende (end:error), damit im Diagramm sichtbar wird, dass etwas schiefgelaufen ist.

@title "Zwei Pools"
@direction LR

pool "Kunde"
  (start) --> [Bestellen]:user
  [Bestellen] -..-> [Packen]

pool "Shop"
  [Packen] --> <Lager?>
  <Lager?> -->|ja| (end)
  <Lager?> -->|nein| (end:error)

Kunde bestellt, der Shop packt und prüft das Lager.

So erkennst du auf einen Blick: Zusammenarbeit zwischen zwei Rollen, asynchrone Übergabe per Nachricht und eine klare Entscheidung mit zwei möglichen Ausgängen.

Links siehst du die Schreibweisen für viele Ereignistypen — als Nachschlagewerk. Rechts ein Mini-Prozess mit Message-Start.

In BPMN unterscheidet man z. B. normale Start- und Endereignisse, Zwischenereignisse (Timer, Nachricht, …) und Ereignisse, die etwas „werfen“. Das Diagramm zeigt: Team A arbeitet sequentiell, bis eine Nachricht nötig ist; Team B startet seinen Teil mit einem Message-Start, sobald die Nachricht eintrifft, und antwortet wieder per Nachrichtenfluss. So wird sichtbar, dass der Ablauf über Organisationen hinweg koordiniert wird — nicht nur mit einem Pfeil „irgendwohin“.

// Start
(start) (start:message) (start:timer) (start:signal) (start:conditional)
(start:escalation) (start:error) (start:multiple) (start:parallel)

// Ende
(end) (end:message) (end:error) (end:terminate) (end:signal) (end:escalation)
(end:compensation) (end:cancel) (end:multiple)

// Zwischen (Catch)
(timer) (message) (signal) (conditional) (escalation) (compensation)
(link) (link:Weiter) (multiple) (parallel)

// Werfen (Throw)
(throw:message) (throw:signal) (throw:escalation) (throw:compensation)
(throw:link:Weiter) (throw:multiple) (throw:parallel)

// Benannte Message-Korrelation
(message:AuftragBestaetigt) (throw:message:AuftragBestaetigt)
(start:message:AuftragEingang) (end:message:Abschluss)

// Aliase
(start) as begin "Eingang"
(timer) as w48h "48h"

Nachricht von A nach B und zurück zur Prüfung in A.

Praktisch: Rückfragen, Genehmigungen oder Lieferungen modellieren, bei denen eine andere Abteilung oder ein externer Partner erst reagieren muss, bevor es weitergeht.

Nach dem Doppelpunkt wählst du den BPMN-Task-Typ: :user (menschlich), :service (System), :send (Nachricht raus) und viele weitere — siehe linke Spalte.

Im rechten Diagramm sind absichtlich nur drei Schritte: so erkennst du die unterschiedlichen Symbole im SVG (z. B. kleines Personen-Icon bei User-Tasks, Dreieck bei Send). In echten Prozessen würdest du längere Ketten bauen; hier geht es nur darum, die Zuordnung „Textzeile → BPMN-Notation“ zu üben.

[Generische Aufgabe]
[Prüfen]:user [API]:service [Skript]:script
[Senden]:send [Empfangen]:receive [Empfang mit Ref]:receive:NachrichtX
[Manuell]:manual [Regel]:rule

// Multi-Instance & Schleife
[Parallel-Batch]:service:parallel
[Der Reihe nach]:user:sequential
[Wiederholen bis OK]:service:loop

// Alias
[Genehmigen]:user as approve

Erfassen → API → Mail: eine Zeile, drei Task-Arten.

So dokumentierst du klar: wer eingibt, wo automatisiert wird und wo eine Nachricht den Prozess verlässt — hilfreich für Reviews mit Fachbereich und IT.

Ein Boundary-Event hängt an der Kante einer Task — z. B. ein Timer, der „nebenher“ feuert, ohne die Hauptbedeutung der Task zu ändern.

~(timer) bindet den Timer an [Warten]. Mit as t gibst du diesem Grenzereignis einen Namen und kannst von dort aus weiterfließen: z. B. Eskalation oder Erinnerung. Der Hauptpfad [Warten] --> [Weiter] bleibt der Normalfall; der Timer-Zweig beschreibt, was passiert, wenn die Wartezeit überschritten wird. So bleiben Ausnahmen im Modell sichtbar, ohne den glücklichen Pfad zu überladen.

[Warten]:user~(timer) as t
[Warten] --> [Weiter]:service
t --> [Erinnern]:send
[Erinnern] --> (end)
[Weiter] --> (end)

Timer löst „Erinnern“ aus; „Weiter“ ist der reguläre Abschluss der Wartezeit.

Typische Fälle: SLA, Fristen oder „wenn bis Dienstag keine Antwort, dann Erinnerung“ — genau das verbinden viele Teams mit BPMN-Grenzereignissen.

Gateways steuern Verzweigung und Zusammenführung: XOR (entweder/oder), AND (parallel), OR (eine oder mehrere Pfade), … — die Schreibweise steht links.

Das rechte Diagramm zeigt nur ein exklusives Gateway (XOR): genau eine ausgehende Bedingung trifft zu — hier „ja“ oder „nein“. So modellierst du Freigaben, Freigaben mit Ablehnung oder einfache Entscheidungsbäume, ohne das Diagramm mit Parallelität zu vermischen. Komplexere Muster (parallel arbeitende Teams, inklusive ODER) baust du später mit den anderen Gateway-Typen aus der linken Referenz.

<Exklusiv?>          // XOR
<+Parallel>          // AND
<o Inklusiv?>        // OR
<* Ereignis-Gateway?> // ereignisbasiert
<# Komplex?>         // Complex

Genehmigt? — ja führt zu Ausführen, nein zu Ablehnen; beide Zweige enden explizit.

Leserinnen und Leser sehen sofort: es gibt keinen „stillen“ dritten Weg — die Entscheidung ist abgeschlossen und nachvollziehbar.

--> ist der normale Sequenzfluss innerhalb eines Pools. -..-> ist der Nachrichtenfluss zwischen Teilnehmern (Pools).

Das unterscheidet BPMN von reinen Flussdiagrammen: Kommunikation zwischen Organisationen oder Systemen wird explizit gezeichnet, nicht als normaler Pfeil „durch die Wand“. Pool A startet mit einer Sende-Task und erreicht damit Pool B; dort wird geprüft und mit einem XOR beendet. So siehst du Verantwortung und Schnittstelle in einem Bild.

pool "A"
  (start) --> [Senden]:send -..-> [Prüfen]
pool "B"
  [Prüfen] --> <OK?>
  <OK?> -->|ja| (end)
  <OK?> -->|nein| (end)

A sendet, B prüft und beendet mit Ja oder Nein.

Gute Dokumentation für Schnittstellen zwischen Teams: wer triggert, wer reagiert, und wo die Entscheidung fällt.

Ein Pool fasst einen Teilnehmer zusammen; Lanes unterteilen ihn in Rollen oder Abteilungen (horizontal oder vertikal — hier im Code nebeneinander).

Das Beispiel zeigt einen typischen Support: Front nimmt an, Technik löst — dieselbe Vorgangsnummer wandert über die Lane-Grenze. So erkennt man Verantwortung innerhalb eines Unternehmens, ohne für jede Rolle einen eigenen Pool anzulegen (das wäre eher für strikt getrennte Organisationen).

pool "Support"
  lane "Front"
    (start) --> [Annehmen]:user
  lane "Technik"
    [Annehmen] --> [Lösen]:service --> (end)

Ein Pool, zwei Lanes: Annahme und Lösung im selben Prozess.

Für Leser ohne BPMN-Vorkenntnis: oben/unten oder links/rechts im Bild sind die Rollen — der Fluss zeigt die Übergabe der Arbeit.

Ein Subprozess kapselt mehrere Schritte in einem Rahmen; [[Name]] ist eine Call Activity (wiederverwendbarer Unterprozess andernorts definiert).

Oben siehst du den Inhalt des erweiterten Subprozesses „Zahlung“ (Autorisierung, Entscheidung, ggf. Fehlerende). Unten der Hauptfluss: der Prozess startet, durchläuft den Subprozess zahlung (Referenz auf den Namen), ruft die Call Activity „Freigabe holen“ auf und schließt mit Buchen ab. So trennst du Detaillogik von übergeordneter Steuerung — Standard in größeren BPMN-Modellen.

subprocess "Zahlung"
  (start) --> [Autorisieren]:service --> <OK?>
  <OK?> -->|ja| (end)
  <OK?> -->|nein| (end:error)
end

(start) --> zahlung --> [[Freigabe holen]]
[[Freigabe holen]] --> [Buchen]:service --> (end)

Zahlung im Kasten, danach Freigabe holen, dann buchen.

Das Muster eignet sich überall, wo ein technischer Teilschritt (Zahlung, Prüfung) vor einer fachlichen Freigabe und einer Buchung kommt.

Assoziationen mit --- zeigen: welche Daten zu einer Aktivität gehören — z. B. ein Dokument {PDF} oder ein System-Speicher {{Konto}}.

Datenobjekte (Dokument, Datensatz) und Datenspeicher (persistente Quelle wie eine Datenbank-Tabelle) sind in BPMN eigene Symbole. Sie helfen beim Verständnis, was fließt, nicht nur wer was tut. Im Diagramm siehst du die Verknüpfung neben den Tasks; das reicht oft schon für Architektur- und Fachreviews.

(start) --> [Rechnung]:service --- {PDF}
[Rechnung] --> [Buchung]:service --- {{Konto}}
[Buchung] --> (end)

PDF entsteht bei der Rechnung; die Buchung hängt am Konto-Speicher.

Praktisch für Onboarding: neue Mitarbeitende sehen, welche Artefakte und Systeme zu welchem Schritt gehören.

Mit as vergibst du Aliase — kurze Namen für Elemente, die du später nochmal ansprechen willst, ohne lange Task- oder Gateway-Texte zu wiederholen.

Hier bedeuten l die Lager-Task und g das Gateway. Die Zeile l --> g verbindet sie explizit (nützlich, wenn dazwischen andere Syntax oder Umbrüche stehen). Anschließend verzweigt g zu Versand oder Nachbestellen. Aliase machen große Modelle lesbarer und sind in Textform besonders angenehm — vergleichbar mit Variablen im Code.

(start) --> [Lager]:service as l
[Lager] --> <Genug?> as g
l --> g
g -->|ja| [Versand]:user
g -->|nein| [Nachbestellen]:manual

Lager prüfen, dann je nach Bestand versenden oder nachbestellen.

Das Muster überträgst du auf komplexere Graphen: einmal benennen, oft referenzieren — weniger Tippfehler, klarere Diffs in Git.