BPMN Pools & Lanes: Organisation und Zuständigkeiten richtig modellieren

Stell dir vor, du planst einen Prozess für die Auftragsabwicklung. Du zeichnest sauber auf, was passiert: Bestellung annehmen, Ware prüfen, Rechnung schreiben, Paket versenden. Der Ablauf ist logisch. Aber eine entscheidende Frage bleibt offen: Wer macht das eigentlich?

Ein Prozessmodell ohne klare Zuständigkeiten ist oft nur eine theoretische Übung. In klassischen Flussdiagrammen (Flowcharts) sehen wir häufig das Problem, dass Verantwortlichkeiten wild gemischt werden oder nur implizit bekannt sind. Der Betrachter muss raten: "Macht das jetzt der Vertrieb oder schon die Buchhaltung?"

Genau hier bringt BPMN 2.0 Ordnung ins Chaos. Mit dem visuellen Konzept der Swimlanes (Schwimmbahnen) schaffen wir eine klare Struktur. Wir teilen das Diagramm in horizontale oder vertikale Bereiche auf, die wie Bahnen in einem Schwimmbecken aussehen. Jede Bahn repräsentiert eine bestimmte Zuständigkeit – sei es eine ganze Firma, eine Abteilung oder eine spezifische Rolle.

Indem wir Aktivitäten in diese Bahnen legen, beantworten wir die Frage nach dem "Wer" visuell und eindeutig, ohne auch nur ein Wort schreiben zu müssen. In diesem Artikel lernst du, wie du Pools und Lanes richtig einsetzt, um deine Prozesse nicht nur logisch, sondern auch organisatorisch glasklar zu gestalten.

Beginnen wir mit dem größten Element: dem Pool. In der BPMN-Logik ist der Pool der Container, der einen kompletten Prozess umschließt. Er repräsentiert einen Teilnehmer (Participant) an einer Kollaboration1. Das kann eine ganze Organisation sein (z. B. "Lieferant"), eine spezifische Unternehmenseinheit (z. B. "Klinikum Nord") oder eine abstrakte Rolle (z. B. "Kunde").

Das Wichtigste, was du über den Pool wissen musst, ist seine Funktion als Grenze. Alles, was innerhalb eines Pools passiert, unterliegt der Kontrolle dieses Teilnehmers. Hier gelten die internen Regeln, hier fließt die Arbeit von Schritt zu Schritt.

Die Goldene Regel: Der Sequenzfluss bleibt drinnen

Es gibt eine technische Regel, die du niemals brechen darfst, wenn du valide Modelle bauen willst: Ein Sequenzfluss (die durchgezogene Linie) darf niemals die Grenzen eines Pools verlassen.

Warum ist das so? Der Sequenzfluss steht für "Befehlsgewalt". Wenn du einen Pfeil von Task A zu Task B zeichnest, sagst du: "Nach A muss sofort B gemacht werden." Das funktioniert innerhalb deiner eigenen Firma wunderbar. Aber du kannst deinem Kunden oder Lieferanten nicht befehlen, was er als Nächstes zu tun hat. Du hast keine Kontrolle über seinen internen Prozess. Deshalb endet der Sequenzfluss immer an der Pool-Wand. Wenn du mit jemandem außerhalb deines Pools interagieren willst, musst du kommunizieren (Nachrichtenfluss), nicht anordnen .

White Box vs. Black Box: Wie viel zeigen wir?

Nicht jeder Pool muss mit Leben gefüllt sein. Wir unterscheiden in der Praxis zwei Darstellungsformen, je nachdem, wie viel wir über den Teilnehmer wissen oder preisgeben wollen.

Der White Box Pool ist der Standard für deine eigenen Prozesse. Er ist "gefüllt". Du siehst das Start-Ereignis, die Aktivitäten, die Gateways und das Ende. Du machst die interne Logik transparent ("White Box"). Das ist der Pool, den du für deine Abteilung oder dein Team modellierst .

Der Black Box Pool hingegen ist leer. Er ist oft einfach zugeklappt dargestellt. Das nutzen wir für externe Teilnehmer wie Kunden oder Lieferanten. Warum? Weil wir deren interne Abläufe oft gar nicht kennen – oder sie für unser Modell schlicht irrelevant sind. Uns interessiert nicht, welche internen Genehmigungsschritte der Kunde durchläuft, bevor er bestellt. Uns interessiert nur, dass er bestellt. Der Black Box Pool zeigt also nur die Schnittstelle nach außen: Was geht rein (Nachricht), was kommt raus?

Wenn der Pool das "Haus" ist, in dem der Prozess wohnt, dann sind die Lanes (Bahnen) die einzelnen Zimmer. Sie unterteilen den Pool in kleinere Bereiche, um Verantwortlichkeiten klarer zu machen.

Du kennst das Prinzip sicher aus klassischen Schwimmbahnen-Diagrammen: Jede Rolle oder Abteilung bekommt eine eigene Zeile. In BPMN 2.0 funktioniert das genauso, aber mit einer wichtigen Einschränkung: Lanes existieren nur innerhalb eines Pools . Sie können nicht alleine im leeren Raum schweben (auch wenn manche Tools das technisch zulassen, ist es semantisch falsch).

Wofür nutzen wir Lanes?

Lanes beantworten die Frage: "Wer in unserer Organisation macht diesen Schritt?"

Sie repräsentieren meistens:

• Abteilungen (z. B. Vertrieb, Buchhaltung, Lager).

• Rollen (z. B. Manager, Sachbearbeiter).

• Systeme (z. B. ERP-System, CRM), wenn man zeigen will, dass ein Schritt vollautomatisch läuft .

Die technische Besonderheit

Hier kommt ein Detail, das viele Einsteiger überrascht: Für die Process Engine (die Software, die den Prozess ausführt) sind Lanes fast völlig egal. Der Sequenzfluss ignoriert die Lane-Grenzen. Der Token springt fröhlich von der Lane "Vertrieb" in die Lane "Lager" und zurück, ohne dass technisch etwas Besonderes passiert .

Lanes sind also primär ein visuelles Hilfsmittel für den menschlichen Betrachter. Sie helfen uns, den Prozess zu lesen und sofort zu sehen: "Aha, ab hier übernimmt die Buchhaltung."

Verschachtelte Lanes (Nested Lanes)

Du kannst Lanes auch verschachteln. Stell dir vor, du hast eine große Lane "Finanzabteilung". Darin könntest du zwei Unter-Lanes (Sub-Lanes) für "Kreditorenbuchhaltung" und "Debitorenbuchhaltung" erstellen. Das sorgt für eine saubere Hierarchie, sollte aber sparsam eingesetzt werden, damit das Diagramm nicht zu unruhig wird .

Jetzt stehen wir vor der Gretchenfrage, an der selbst erfahrene Modellierer oft straucheln: Wann mache ich eine neue Lane auf und wann brauche ich zwingend einen neuen Pool?

Die Entscheidung hängt nicht davon ab, wie unterschiedlich die Aufgaben sind, sondern wer die Prozesshoheit hat. Um das richtig zu entscheiden, musst du zwischen Orchestrierung (intern) und Kollaboration (extern) unterscheiden.

Fall 1: Eine Firma, ein Ziel (Lane)

Solange sich der Prozess innerhalb einer einzigen Organisation oder unter einer gemeinsamen Führung bewegt, nutzen wir einen einzigen Pool und unterteilen ihn mit Lanes.

Stell dir vor, der Vertrieb übergibt einen Auftrag an das Lager. Das sind zwar unterschiedliche Abteilungen, vielleicht sogar in verschiedenen Gebäuden. Aber sie spielen im selben Team. Der Vertrieb kann dem Lager (durch das Prozessdesign der Firma) diktieren: "Wenn ich den Auftrag freigebe, musst du ihn verpacken." Da hier eine direkte Befehlskette – oder technisch gesprochen: eine Orchestrierung – möglich ist, bleibt der Sequenzfluss erhalten. Wir ziehen einfach eine durchgezogene Linie über die Lane-Grenze hinweg.

Fall 2: Getrennte Welten (Pool)

Sobald du die Grenzen deiner eigenen Organisation verlässt, ändert sich die Spielregel drastisch. Wenn deine Firma mit einem Kunden oder einem externen Lieferanten interagiert, hast du keine Prozesshoheit mehr.

Du kannst deinem Kunden nicht befehlen, die Rechnung zu bezahlen. Du kannst ihm nur die Rechnung schicken (Nachricht) und hoffen, dass er zahlt. Sein Prozess ("Rechnung prüfen und bezahlen") ist völlig unabhängig von deinem Prozess ("Rechnung stellen und Geldeingang prüfen"). Ihr arbeitet nicht im selben Team, ihr verhandelt miteinander.

In diesem Fall musst du zwei separate Pools verwenden: Einen für deine Firma, einen für den Kunden. Da der Sequenzfluss niemals die Pool-Grenze überschreiten darf, verbindest du die beiden Welten ausschließlich über Nachrichtenflüsse (gestrichelte Linien). Das nennen wir Kollaboration.

Die Faustregel für die Praxis

Wenn du unsicher bist, stell dir folgende Frage: "Könnte ein einzelner Prozessmanager den Ablauf für beide Parteien verbindlich festlegen?"

• Lautet die Antwort Ja (z. B. Vertrieb & Produktion), dann gehören sie in einen Pool (verschiedene Lanes).

• Lautet die Antwort Nein (z. B. Wir & Kunde), dann gehören sie in getrennte Pools.

Nachdem du nun weißt, ob du einen neuen Pool oder nur eine neue Lane brauchst, müssen wir klären, wie du die Aktivitäten miteinander verbindest. Denn in BPMN ist Pfeil nicht gleich Pfeil. Die Art der Verbindungslinie erzählt dem Leser eine wichtige Geschichte darüber, wie eng die Zusammenarbeit ist.

Orchestrierung: Der Taktstock (Sequenzfluss)

Innerhalb eines Pools – egal über wie viele Lanes hinweg – sprechen wir von Orchestrierung. Das Bild dahinter ist ein Dirigent, der einem Orchester den Takt vorgibt. Er hat die volle Kontrolle. Wenn die Geigen aufhören, müssen die Trompeten einsetzen.

Dafür nutzt du den Sequenzfluss (Sequence Flow). Das ist die durchgezogene Linie mit der gefüllten Pfeilspitze. Sie repräsentiert den Fluss der Kontrolle. Sie sagt: "Wenn Schritt A fertig ist, geht die Verantwortung direkt und ohne Diskussion an Schritt B über." Da du innerhalb deiner Firma (eines Pools) diese Durchgriffsmacht hast, verbindest du auch Aktivitäten in unterschiedlichen Lanes (z. B. vom Vertrieb zur Buchhaltung) immer mit dieser durchgezogenen Linie.

Kollaboration: Der Handschlag (Nachrichtenfluss)

Sobald wir die Grenze des Pools überschreiten, endet unsere Macht. Wir können dem externen Partner nicht den Takt vorgeben. Wir können nicht "orchestrieren", wir können nur kollaborieren.

Dafür nutzt du den Nachrichtenfluss (Message Flow). Das ist die gestrichelte Linie mit dem offenen Kreis am Start und der leeren Pfeilspitze am Ende. Sie transportiert keine Kontrolle, sondern nur Information. Sie sagt: "Ich bin fertig und sende dir hiermit eine Nachricht (z. B. eine Bestellung)." Ob und wann der Partner darauf reagiert, liegt nicht in unserer Hand.

Die eiserne Regel der Grenzen

Aus diesem Unterschied leitet sich die wichtigste Syntax-Regel für Pools ab, die du dir merken musst:

1. Ein Sequenzfluss (durchgezogen) darf niemals eine Pool-Grenze überschreiten. Du kannst keine Kontrolle an eine andere Firma übergeben. Der Prozessfluss bleibt immer "im Haus".

3. Ein Nachrichtenfluss (gestrichelt) darf niemals zwei Aktivitäten innerhalb desselben Pools verbinden. Du schickst dir selbst keine Briefe, du arbeitest einfach weiter.

Wenn du also siehst, wie ein durchgezogener Pfeil von "Unser Vertrieb" zu "Kunde" geht, weißt du sofort: Das ist ein Syntax-Fehler. Hier wurde versucht, den Kunden zu steuern, was in der Realität nicht funktioniert.

Motiv: Eine Grafik, die beide Szenarien zeigt.

• Szenario A (Richtig): Ein Pfeil innerhalb des Pools (durchgezogen) und ein Pfeil zwischen zwei Pools (gestrichelt).

• Szenario B (Falsch): Ein durchgezogener Pfeil, der die Poolgrenze durchbricht (mit einem roten X markiert).

  Unterschrift: Durchgezogene Linien bleiben drinnen, gestrichelte Linien gehen raus.

Ein BPMN-Diagramm kann technisch vollkommen korrekt sein – keine Syntaxfehler, alle Pfeile richtig verbunden – und trotzdem nutzlos, weil niemand es versteht. Damit deine Modelle nicht nur valide, sondern auch wertvoll sind, solltest du bei Pools und Lanes ein paar eiserne Stilregeln beachten.

Das richtige Labeling: Prozess vs. Organisation

Ein häufiger Anfängerfehler ist die Benennung des Haupt-Pools. Viele schreiben einfach den Namen der Firma hinein, z. B. "Muster GmbH". Das ist zwar nicht falsch, aber verschenkter Platz. Da der Pool (im White Box Szenario) den Container für genau einen spezifischen Prozess darstellt, empfiehlt Bruce Silver, den Pool nach dem Prozess selbst zu benennen, z. B. "Auftragsabwicklung" oder "Reklamationsmanagement".

Die Organisationseinheiten packst du stattdessen in die Lanes. So hast du eine saubere Trennung: Der Pool sagt, was wir tun (den Prozess), und die Lanes sagen, wer es tut (die Abteilungen).

Bei externen Black Box Pools (z. B. "Kunde") hingegen reicht der Name der Rolle völlig aus, da wir den internen Prozess dort ja nicht sehen.

Keine Namen, keine Politik

Vermeide es unbedingt, Lanes nach konkreten Personen ("Peter Müller") oder extrem spezifischen, volatilen Abteilungskürzeln ("Abt. 42b - Nord") zu benennen. Prozessmodelle sollen langlebig sein. Wenn Peter in Rente geht oder die Abteilung umbenannt wird, ist dein Modell sofort veraltet.

Nutze stattdessen funktionale Rollen wie "Sachbearbeiter", "Manager" oder "Systemadministrator". Diese Rollen bleiben meist bestehen, auch wenn sich das Organigramm ändert. Das macht deine Modelle robust gegen die nächste Umstrukturierung.

Wohin mit dem Nachrichtenfluss?

Ein feines Detail für Profis betrifft das Andocken von Nachrichtenflüssen an Black Box Pools. Wenn du einen leeren Pool für den "Kunden" hast, wohin zeichnest du den Pfeil deiner E-Mail?

Da der Pool leer ist, gibt es darin keine Aktivität, auf die du zielen kannst. Deshalb dockst du den Nachrichtenfluss direkt an den Rand des Pools an. Das bedeutet: "Die Nachricht geht an die Organisation Kunde".

Andersherum gilt: Wenn die Nachricht vom Kunden kommt, startet der Pfeil ebenfalls am Rand des Kunden-Pools und landet auf deinem spezifischen "Message Catch Event" oder "Receive Task". So bleibt die Schnittstelle sauber definiert, ohne dass wir so tun, als wüssten wir, was beim Kunden intern passiert.

Pools und Lanes sind weit mehr als nur grafische Ordnungslinien. Sie bilden das organisatorische Skelett deines Prozessmodells. Sie verwandeln eine bloße Abfolge von Tätigkeiten ("Was passiert?") in einen klaren Verantwortungsbereich ("Wer macht es?").

Wenn du aus diesem Artikel nur eine einzige Sache mitnimmst, dann bitte diese: Respektiere die Grenze. Die dicke Linie eines Pools ist wie eine Firmenmauer. Innerhalb dieser Mauer (in den Lanes) kannst du befehlen und steuern (Sequenzfluss). Aber sobald du über die Mauer hinweg mit einem Kunden oder Partner sprichst (Pool-Grenze), musst du höflich bitten und informieren (Nachrichtenfluss).

Wer diesen Unterschied verstanden hat, vermeidet 90 % der logischen Fehler in BPMN-Diagrammen.

Hier ist deine Entscheidungshilfe für die tägliche Arbeit: