Swimlane-Diagramm: Definition, Anleitung & Praxisbeispiel

Das Swimlane-Diagramm (auch funktionsübergreifendes Flussdiagramm, Rummler-Brache-Diagramm oder Cross-Functional Flowchart) ist eine Prozessvisualisierungstechnik, die Arbeitsschritte in horizontalen oder vertikalen Bahnen — den sogenannten Lanes — anordnet. Jede Bahn repräsentiert eine Abteilung, Rolle oder ein System. Das Ergebnis: Du siehst nicht nur, welche Schritte ein Prozess durchläuft, sondern auch, wer welchen Schritt verantwortet — und wo die Übergaben zwischen den Beteiligten stattfinden.

Die Methode geht auf Geary Rummler und Alan Brache zurück, die sie 1990 in ihrem Standardwerk Improving Performance: How to Manage the White Space on the Organization Chart einführten [1]. Ihre zentrale Erkenntnis: Die meisten Prozessfehler entstehen nicht innerhalb einer Abteilung, sondern an den Übergabepunkten zwischen Abteilungen — im sogenannten „White Space” des Organigramms. Rummler schätzte, dass bis zu 80 % aller Prozessprobleme auf diese Schnittstellen zurückzuführen sind [1]. Das Swimlane-Diagramm macht genau diese Schnittstellen sichtbar.

Suchst du im deutschsprachigen Netz nach „Swimlane-Diagramm”, findest du hauptsächlich Tool-Tutorials (Lucidchart, Creately, draw.io) mit generischen Ablaufbeispielen. Kein Ergebnis erklärt Rummlers „White Space”-Einsicht, die den eigentlichen Wert der Methode begründet. Keines vergleicht Swimlane-Diagramme systematisch mit Service Blueprints oder BPMN. Und keines zeigt ein konkretes Praxisbeispiel aus dem Dienstleistungsbereich — etwa einer Schadenbearbeitung, die vier Abteilungen durchläuft.

Dieser Leitfaden schließt diese Lücken.

Definition und Herkunft

Was ist ein Swimlane-Diagramm?

Ein Swimlane-Diagramm ist ein erweitertes Flussdiagramm, das Prozessschritte in parallelen Bahnen (Lanes) anordnet. Die Bahnen können horizontal oder vertikal verlaufen — die Wahl ist rein konventionell, wobei horizontale Bahnen im europäischen Raum verbreiteter sind.

Die Grundidee: Ein klassisches Flussdiagramm zeigt dir die Reihenfolge der Prozessschritte — aber nicht, wer sie ausführt. Wenn du wissen willst, warum ein Prozess stockt, reicht die Reihenfolge nicht aus. Du musst sehen, wo die Verantwortung von einer Person zur nächsten übergeht. Genau das leistet das Swimlane-Diagramm.

Rummler und Brache: Der White Space

Geary Rummler war Organisationsberater und Performance-Experte, der sich sein gesamtes Berufsleben mit einer Frage beschäftigte: Warum liefern Organisationen schlechtere Ergebnisse als die Summe ihrer Teile erwarten ließe? Seine Antwort, gemeinsam mit Alan Brache in Improving Performance (1990) formuliert: Weil niemand den „White Space” zwischen den Kästchen im Organigramm managt [1].

Organigramme zeigen Abteilungen als Kästchen und Hierarchien als Linien. Aber die tatsächliche Wertschöpfung verläuft horizontal — quer durch die Kästchen, von Abteilung zu Abteilung. Ein Kundenauftrag durchläuft Vertrieb, Auftragserfassung, Produktion, Logistik, Fakturierung. An jedem Übergang — jedem „White Space” — können Informationen verloren gehen, Prioritäten sich verschieben, Verantwortlichkeiten unklar sein.

Rummler und Brache entwickelten das Swimlane-Diagramm als Werkzeug, um diese horizontalen Prozesse sichtbar zu machen. Ihre Erkenntnis: Wenn du einen Prozess verbessern willst, optimiere zuerst die Übergaben — nicht die einzelnen Schritte. Ein perfekt ausgeführter Schritt in der Sachbearbeitung nützt nichts, wenn die Übergabe an die Qualitätsprüfung drei Tage dauert, weil niemand definiert hat, wie, wann und in welchem Format die Information weitergegeben wird.

Weiterentwicklung und Standards

Das Konzept wurde in mehrere formale Notationen integriert:

• BPMN 2.0 (Business Process Model and Notation, OMG 2011): Verwendet Pools und Lanes als Kernelemente zur Darstellung von Verantwortlichkeiten [2].
• UML-Aktivitätsdiagramme: Nutzen Activity Partitions als Swimlane-Äquivalent [3].
• Sharp & McDermott (2009): Formalisierten die Notation in Workflow Modeling mit klaren Regeln für Symbolik und Übergabedarstellung [4].

Heute ist das Swimlane-Diagramm die verbreitetste Form der funktionsübergreifenden Prozessvisualisierung — unterstützt von praktisch jedem Diagramm-Tool (Visio, Lucidchart, Miro, draw.io) und in ISO- sowie BPMN-Standards verankert.

Die 6 Grundelemente

Ein Swimlane-Diagramm besteht aus sechs Grundelementen. Wenn du diese verstehst, kannst du jeden Prozess abbilden.

Element	Symbol	Funktion
Lane (Bahn)	Horizontaler oder vertikaler Streifen	Repräsentiert eine Abteilung, Rolle oder ein System
Pool	Rahmen um mehrere Lanes	Gruppiert Lanes zu einer Organisation oder einem Prozessbereich
Aktivität	Abgerundetes Rechteck	Ein einzelner Prozessschritt
Entscheidung	Raute	Verzweigungspunkt mit Ja/Nein- oder Mehrfachauswahl
Übergabe	Pfeil, der eine Lane-Grenze kreuzt	Informations- oder Verantwortungsübergang zwischen Beteiligten
Start/Ende	Kreis (Start) / Doppelkreis (Ende)	Markiert Prozessbeginn und -abschluss

Die wichtigste Erkenntnis: Das wertvollste Element ist die Übergabe — der Pfeil, der eine Lane-Grenze überquert. Jeder dieser Pfeile ist ein potenzieller Fehlerpunkt. Rummlers Faustregel: Zähle die Lane-Grenzüberquerungen in deinem Diagramm — die Anzahl korreliert mit der Fehleranfälligkeit des Prozesses [1].

Wann ein Swimlane-Diagramm einsetzen — und wann nicht

Ideale Einsatzszenarien

Setze ein Swimlane-Diagramm ein, wenn:

• Du einen abteilungsübergreifenden Prozess visualisieren willst — mit 2 bis 8 beteiligten Rollen oder Abteilungen
• Du Übergabeprobleme diagnostizieren willst — Verzögerungen, Informationsverluste, unklare Verantwortlichkeiten
• Du eine Ist-Analyse durchführst, bevor du einen Prozess redesignst
• Du einen Soll-Prozess dokumentieren willst, der für alle Beteiligten verständlich sein muss — Swimlane-Diagramme sind auch für Nicht-Techniker lesbar
• Du Onboarding-Material für neue Mitarbeiter erstellst, die verstehen müssen, wie ein Prozess durch mehrere Abteilungen läuft
• Du Compliance-Anforderungen dokumentieren musst — wer hat welchen Schritt zu verantworten?

Wann ein anderes Werkzeug besser passt

Situation	Bessere Alternative	Warum
Du willst die Kundenperspektive abbilden (Touchpoints, Emotionen, Pain Points)	Customer Journey Map	Swimlane-Diagramme sind prozesszentriert, nicht kundenzentriert
Du willst Frontstage und Backstage eines Service unterscheiden	Service Blueprint	Service Blueprints haben eine „Line of Visibility”, die Swimlanes fehlt
Du brauchst eine maschinenlesbare Prozessdefinition für Workflow-Engines	BPMN 2.0	BPMN hat formale Semantik, die Software interpretieren kann
Du willst Verschwendung und Durchlaufzeiten in einem Fertigungsprozess identifizieren	Wertstromanalyse	Wertstromanalysen quantifizieren Zeiten und Bestände pro Schritt
Dein Prozess hat mehr als 8 Lanes	Prozesshierarchie (Teilprozesse)	Ab 8+ Lanes wird das Diagramm unlesbar — teile den Prozess auf
Du willst Prozessdaten analysieren, nicht visualisieren	Process Mining	Process Mining rekonstruiert den tatsächlichen Prozessverlauf aus Logdaten

Schritt-für-Schritt: Ein Swimlane-Diagramm erstellen

Schritt 1: Prozessumfang definieren

Bevor du zeichnest, kläre drei Fragen:

1. Wo beginnt der Prozess? (Auslösendes Ereignis, z. B. „Kunde reicht Schadensmeldung ein”)
2. Wo endet der Prozess? (Abschlussereignis, z. B. „Auszahlung erfolgt oder Ablehnung zugestellt”)
3. Welche Ebene? (Gesamtprozess oder Teilprozess?)

Tipp: Formuliere den Prozessumfang als „Von X bis Y”-Satz. Wenn der Satz länger als ein Satz wird, ist der Umfang wahrscheinlich zu groß.

Schritt 2: Beteiligte identifizieren

Liste alle Rollen, Abteilungen oder Systeme auf, die am Prozess beteiligt sind. Jede Beteiligte bekommt eine eigene Lane.

Drei Regeln für gute Lane-Definitionen:

1. Rolle, nicht Person: „Sachbearbeiter Schaden”, nicht „Frau Müller”
2. Konsistente Granularität: Entweder alle Lanes auf Abteilungsebene (Vertrieb, Schaden, Finanzen) oder alle auf Rollenebene — nicht mischen
3. Maximal 6-8 Lanes: Mehr wird unlesbar. Wenn du 12 Beteiligte hast, gruppiere verwandte Rollen

Schritt 3: Prozessschritte sammeln

Nutze eine der folgenden Techniken:

• Prozessbegehung (Gemba Walk): Begleite den Prozess physisch und dokumentiere jeden Schritt
• Stakeholder-Interviews: Befrage Vertreter jeder Lane, was sie tun, von wem sie Input erhalten und an wen sie Output weitergeben
• Workshop: Bringe alle Beteiligten zusammen und sammle Schritte auf Haftnotizen — eine Farbe pro Lane

Tipp: Formuliere jeden Schritt als Verb + Objekt: „Schadensmeldung prüfen”, „Gutachter beauftragen”, „Auszahlung freigeben”. Vermeide Substantivierungen wie „Prüfung der Schadensmeldung” — sie verschleiern, wer handelt.

Schritt 4: Schritte in Lanes einsortieren

Ordne jeden Schritt der verantwortlichen Lane zu. Die zeitliche Reihenfolge verläuft von links nach rechts (bei horizontalen Lanes) oder von oben nach unten (bei vertikalen).

Kritische Frage bei jedem Schritt: „Wer führt diesen Schritt aus — und ist das dieselbe Person, die ihn verantworten sollte?” Wenn Ausführung und Verantwortung auseinanderfallen, hast du eine potenzielle Schwachstelle identifiziert.

Schritt 5: Übergaben und Entscheidungen einzeichnen

Verbinde die Schritte mit Pfeilen. Achte besonders auf:

• Lane-Grenzüberquerungen: Jeder Pfeil, der eine Lane-Grenze kreuzt, ist eine Übergabe. Beschrifte ihn: Was wird übergeben? In welchem Format? Innerhalb welcher Frist?
• Entscheidungsrauten: Jede Verzweigung braucht eine klare Bedingung. Nicht: „Prüfung okay?” Sondern: „Schadenshöhe > 5.000 €?”
• Parallele Pfade: Wenn zwei Schritte gleichzeitig stattfinden können, zeichne sie nebeneinander, nicht nacheinander

Schritt 6: Validieren

Gehe das fertige Diagramm mit Vertretern jeder Lane durch. Stelle drei Fragen:

1. „Fehlt ein Schritt, den du regelmäßig ausführst?”
2. „Gibt es Schritte, die in der Praxis anders ablaufen als hier dargestellt?”
3. „Wo wartest du am häufigsten auf Input von einer anderen Abteilung?”

Die dritte Frage identifiziert die kritischen Übergaben — die Stellen, an denen der Prozess in der Realität am häufigsten stockt.

Schritt 7: Schwachstellen markieren

Markiere im fertigen Diagramm:

• Rote Übergaben: Übergaben mit bekannten Problemen (Verzögerungen, Informationsverluste, Rückfragen)
• Redundante Schritte: Aktivitäten, die in mehreren Lanes dupliziert werden
• Entscheidungen ohne klare Kriterien: Rauten, bei denen die Bedingung nicht eindeutig ist

Diese Markierungen sind der direkte Input für die Prozessverbesserung.

Praxisbeispiel: Schadenbearbeitung einer Kfz-Versicherung

Ein mittelgroßer Kfz-Versicherer stellt fest, dass die durchschnittliche Bearbeitungszeit für Schadenmeldungen 14 Tage beträgt — der Branchendurchschnitt liegt bei 8 Tagen. Der Prozessmanager erstellt ein Swimlane-Diagramm mit vier Lanes.

Die vier Lanes

Lane	Rolle	Verantwortung
1	Kunde	Meldet Schaden, reicht Dokumente ein, erhält Ergebnis
2	Sachbearbeitung Erstaufnahme	Nimmt Meldung entgegen, prüft Vollständigkeit, ordnet zu
3	Sachbearbeitung Schaden	Bewertet Schaden, beauftragt Gutachter, entscheidet
4	Finanzen	Gibt Auszahlung frei, veranlasst Überweisung

Der Ist-Prozess (vereinfacht)

1. Kunde → reicht Schadensmeldung online ein
2. Erstaufnahme → prüft Vollständigkeit (Ergebnis: 34 % der Meldungen unvollständig → Rückfrage an Kunde)
3. Übergabe an Schaden → per E-Mail mit angehängtem PDF
4. Schaden → bewertet Schadenshöhe
5. Schaden → Entscheidung: Gutachter nötig? (bei > 3.000 €: ja)
6. Schaden → beauftragt externen Gutachter (Wartezeit: Ø 5 Tage)
7. Übergabe an Finanzen → per internes Ticketsystem
8. Finanzen → prüft Budgetdeckung, gibt frei
9. Übergabe an Kunde → Bescheid per Post

Was das Diagramm aufdeckt

Das Swimlane-Diagramm macht drei Probleme sichtbar, die in der bisherigen Prozessbeschreibung (einer reinen Textanleitung) verborgen waren:

1. Medienbruch bei Übergabe 3: Die Übergabe von Erstaufnahme an Schaden erfolgt per E-Mail mit PDF. Es gibt kein definiertes Format, keine Checkliste, keine automatische Zuordnung. Folge: Sachbearbeiter in der Schadenbearbeitung müssen die Akte manuell anlegen — ein vermeidbarer Schritt, der durchschnittlich 45 Minuten pro Fall kostet.

2. Informationsschleife bei unvollständigen Meldungen: 34 % der Meldungen gehen als unvollständig zurück an den Kunden. Im Diagramm ist sichtbar, dass diese Schleife den Prozess um 3-5 Tage verlängert — weil der Kunde nicht sofort antwortet und die Erstaufnahme den Fall in der Zwischenzeit „parkt”.

3. Wartezeit beim Gutachter: Der 5-tägige Warteblock ist im Diagramm als leere Fläche in der Lane „Schaden” sichtbar — ein visuelles Signal, das in einer Textbeschreibung unsichtbar bleibt.

Der Soll-Prozess

Nach der Analyse implementiert der Versicherer drei Maßnahmen:

• Online-Formular mit Pflichtfeldern → Unvollständigkeitsquote sinkt von 34 % auf 8 %
• Automatische Fallübergabe via Kernsystem statt E-Mail → Übergabezeit von 45 Min. auf 0
• Gutachter-Netzwerk mit SLA → Wartezeit von 5 auf 2 Tage

Ergebnis: Durchschnittliche Bearbeitungszeit sinkt von 14 auf 7 Tage.

5 häufige Fehler

Fehler 1: Zu viele Lanes

Ab 8 Lanes wird ein Swimlane-Diagramm unlesbar. Wenn dein Prozess 12 Beteiligte hat, ist das kein Zeichen für ein komplexes Diagramm — es ist ein Zeichen dafür, dass du den Prozess in Teilprozesse aufteilen solltest. Sharp und McDermott empfehlen maximal 5-7 Lanes pro Diagramm [4].

Fehler 2: Fehlende Übergabebeschriftung

Ein Pfeil, der eine Lane-Grenze kreuzt, ohne beschriftet zu sein, ist wertlos. Er zeigt, dass eine Übergabe stattfindet, aber nicht was übergeben wird, in welchem Format und innerhalb welcher Frist. Unbeschriftete Übergaben sind die häufigste Ursache dafür, dass Swimlane-Diagramme in der Schublade enden.

Fehler 3: Vermischung von Ist und Soll

Erstelle immer zuerst den Ist-Prozess, dann den Soll-Prozess — in getrennten Diagrammen. Teams, die beide gleichzeitig zeichnen, produzieren einen idealisierten Prozess, der mit der Realität wenig zu tun hat. Die Diskrepanz zwischen Ist und Soll ist der eigentliche analytische Wert.

Fehler 4: Inkonsistente Granularität

Wenn Lane 1 einen einzelnen Schritt enthält („Antrag einreichen”) und Lane 2 zehn Schritte hat, stimmt die Granularität nicht. Jede Lane sollte ein vergleichbares Detaillevel aufweisen. Faustregel: Wenn ein Schritt mehr als einen Arbeitstag repräsentiert, ist er zu grob und sollte in Teilschritte zerlegt werden.

Fehler 5: Kein Validierungsschritt

Ein Swimlane-Diagramm, das nur von einer Person erstellt und nie mit den Prozessbeteiligten validiert wurde, ist eine Hypothese — keine Prozessdokumentation. Die Validierungsrunde (Schritt 6 der Anleitung) ist kein optionaler Zusatz, sondern der Schritt, der das Diagramm von einer Annahme in eine geteilte Realität verwandelt.

Vergleich mit verwandten Methoden

Kriterium	Swimlane-Diagramm	Service Blueprint	BPMN 2.0	Wertstromanalyse
Perspektive	Prozess (funktionsübergreifend)	Service (Kunde + Anbieter)	Prozess (formal)	Wertfluss (Lean)
Lanes/Bahnen	Abteilungen/Rollen	Frontstage, Backstage, Support	Pools + Lanes	Keine (linearer Fluss)
Line of Visibility	Nein	Ja (Kernkonzept)	Nein	Nein
Zeitdaten	Optional	Optional	Optional	Kernbestandteil (Takt, Durchlaufzeit)
Maschinenlesbar	Nein	Nein	Ja (XML-basiert)	Nein
Zielgruppe	Prozessmanager, Business Analysten	Service Designer, UX-Teams	IT, Prozessautomatisierung	Lean-/Operations-Teams
Lernkurve	Niedrig (30 Min.)	Mittel (1-2 Std.)	Hoch (Tage)	Mittel (Halbtag)
Stärke	Übergaben sichtbar machen	Kundenerlebnis + interne Prozesse verbinden	Automatisierbar, standardisiert	Verschwendung quantifizieren
Schwäche	Keine Kundenperspektive, keine Zeitdaten	Nicht für IT-Automatisierung	Zu komplex für nicht-technische Stakeholder	Nur für Fertigungs-/Logistikprozesse

Wann welches Werkzeug?

• Swimlane-Diagramm: Du willst verstehen, wer was tut und wo die Übergaben stocken — ohne Spezialsoftware, ohne Schulung, verständlich für alle Beteiligten
• Service Blueprint: Du willst den Zusammenhang zwischen Kundenerlebnis und internen Prozessen darstellen — Frontstage und Backstage
• BPMN: Du willst den Prozess automatisieren oder in einer Workflow-Engine abbilden
• Wertstromanalyse: Du willst Durchlaufzeiten, Bestände und Verschwendung quantifizieren

Unsere Perspektive

Das Swimlane-Diagramm ist kein Innovations-Tool — es ist ein Diagnose-Tool. Sein Wert liegt nicht darin, neue Prozesse zu erfinden, sondern bestehende Prozesse so darzustellen, dass ihre Schwachstellen sichtbar werden. Und die Schwachstellen liegen fast immer an den gleichen Stellen: an den Übergaben.

Rummlers „White Space”-Einsicht ist nach über 30 Jahren aktueller denn je. In einer Welt, in der Organisationen immer stärker in Silos arbeiten — trotz aller agilen Rahmenwerke — bleibt die Fähigkeit, horizontale Prozesse sichtbar zu machen, eine Kernkompetenz.

In unserer Praxis beobachten wir drei Muster:

1. Teams unterschätzen die Anzahl der Übergaben. Wenn wir Prozessbeteiligte fragen, wie viele Übergaben ihr Kernprozess hat, schätzen sie typischerweise 3-4. Das Swimlane-Diagramm zeigt regelmäßig 8-12. Die Diskrepanz zwischen Wahrnehmung und Realität ist der analytische Wert der Methode.

2. Die wertvollsten Erkenntnisse kommen aus Schritt 6 (Validierung). Nicht das Zeichnen des Diagramms produziert Einsichten, sondern das Gespräch über das Diagramm. Wenn Sachbearbeitung und Finanzen zum ersten Mal gemeinsam auf denselben Prozess schauen, werden Annahmen sichtbar, die jahrelang ungeprüft geblieben sind.

3. Die größte Gefahr ist die Optimierung der falschen Ebene. Teams neigen dazu, einzelne Aktivitäten innerhalb einer Lane zu optimieren, statt die Übergaben zwischen Lanes zu verbessern. Ein Sachbearbeiter, der 20 % schneller arbeitet, kompensiert keine Übergabe, die drei Tage dauert. Das Swimlane-Diagramm hilft, den Fokus auf die richtigen Hebel zu lenken.

FAQ

Was ist ein Swimlane-Diagramm einfach erklärt?

Ein Swimlane-Diagramm ist ein Flussdiagramm mit parallelen Bahnen. Jede Bahn gehört einer Abteilung oder Rolle. Die Bahnen zeigen, wer welchen Schritt ausführt und wo Aufgaben von einer Abteilung zur nächsten übergehen.

Woher kommt der Name „Swimlane”?

Die parallelen Bahnen erinnern an die Bahnen in einem Schwimmbad — daher der englische Name „Swimlane” (Schwimmbahn). Im Deutschen wird auch „Funktionsband” oder „Cross-Functional Flowchart” verwendet.

Wie viele Swimlanes sollte ein Diagramm maximal haben?

Sharp und McDermott (2009) empfehlen 5-7 Lanes [4]. Ab 8 Lanes wird das Diagramm unübersichtlich. Wenn du mehr Beteiligte hast, teile den Prozess in Teilprozesse auf.

Was ist der Unterschied zwischen einem Swimlane-Diagramm und einem Service Blueprint?

Ein Swimlane-Diagramm zeigt, wer welchen Prozessschritt ausführt. Ein Service Blueprint teilt den Prozess zusätzlich in Frontstage (vom Kunden sichtbar) und Backstage (intern) auf und enthält eine „Line of Visibility”. Service Blueprints sind kundenzentriert, Swimlane-Diagramme prozesszentriert.

Welches Tool eignet sich für Swimlane-Diagramme?

Für einfache Diagramme reichen Post-its auf einem Whiteboard. Für digitale Diagramme eignen sich Lucidchart, Miro, draw.io (kostenlos), Microsoft Visio oder Figma. Für formale BPMN-Diagramme mit Swimlanes: Camunda Modeler oder Signavio.

Kann ich Swimlane-Diagramme in BPMN 2.0 überführen?

Ja. Die BPMN-2.0-Notation enthält Pools und Lanes als Kernelemente [2]. Ein Swimlane-Diagramm lässt sich in BPMN übersetzen, indem du Pools für Organisationen und Lanes für Rollen definierst. Der umgekehrte Weg — BPMN zu Swimlane — vereinfacht das Diagramm für nicht-technische Stakeholder.

Forschungsmethodik

Dieser Artikel synthetisiert Erkenntnisse aus Rummlers und Braches Standardwerk zur Prozessoptimierung (1990), dem BPMN-2.0-Standard der Object Management Group (2011), Dumas’ et al. akademischem Lehrbuch zur Geschäftsprozessmodellierung (2018), Sharp und McDermotts praxisorientiertem Leitfaden (2009) sowie Madisons Einführung in Prozess-Mapping (2005). Die Quellen decken theoretische Grundlagen, formale Standards und praktische Anwendung ab.

Limitationen: Die Angabe, dass 80 % der Prozessfehler an abteilungsübergreifenden Schnittstellen entstehen, basiert auf Rummlers Beratungserfahrung, nicht auf einer kontrollierten Studie. Das Praxisbeispiel (Kfz-Versicherung Schadenbearbeitung) ist illustrativ konstruiert. Die Effektivitätsangaben (Reduktion von 14 auf 7 Tage) sind typische Größenordnungen aus der Prozessoptimierung, keine dokumentierten Einzelfallstudien.

Offenlegung

SI Labs bietet Beratungsleistungen im Bereich Service Innovation an und setzt Swimlane-Diagramme als Analysewerkzeug in der Prozessanalyse des Integrierten Service Entstehungs Prozess (iSEP) ein. Diese Praxiserfahrung informiert die Einordnung der Methode in diesem Artikel. Leser sollten sich der möglichen Perspektivenverzerrung bewusst sein.

Quellenverzeichnis

1. Rummler, G. A. & Brache, A. P. (1990). Improving Performance: How to Manage the White Space on the Organization Chart. San Francisco: Jossey-Bass. — ★★★★★ Das Standardwerk, das Swimlane-Diagramme einführte. Pflichtlektüre für Prozessmanager.
2. Object Management Group (2011). Business Process Model and Notation (BPMN) Version 2.0. OMG Standard. — ★★★★☆ Der formale Standard, der Swimlanes (Pools/Lanes) als BPMN-Kernelement definiert.
3. Dumas, M., La Rosa, M., Mendling, J. & Reijers, H. A. (2018). Fundamentals of Business Process Management. 2. Aufl. Berlin: Springer. — ★★★★☆ Akademisches Lehrbuch mit umfassender Behandlung von Prozessvisualisierung.
4. Sharp, A. & McDermott, P. (2009). Workflow Modeling: Tools for Process Improvement and Application Development. 2. Aufl. Boston: Artech House. — ★★★★☆ Praxisorientierte Notation und Regeln für Swimlane-Diagramme.
5. Madison, D. (2005). Process Mapping, Process Improvement, and Process Management. Chico: Paton Professional. — ★★★☆☆ Praktische Einführung mit vielen Diagrammbeispielen.