Einführung
Business Process Model and Notation (BPMN) wird häufig fälschlicherweise als ein einziges Diagrammierungsstandard verstanden. In Wirklichkeit ist BPMN ist eine vielschichtige Modellierungssprache, die denselben Geschäftsprozess durch unterschiedliche Blickwinkel darstellen kann – von hochstrategischen Übersichten bis hin zu detaillierten technischen Ausführungsspezifikationen. Die wahre Stärke von BPMN liegt nicht darin, ein perfektes Diagramm zu erstellen, sondern die passende Perspektive für die beabsichtigte Zielgruppe und den Zweck auszuwählen.
Dieser Leitfaden untersucht den Incident-Management-Prozesseines Softwareherstellers, um diese Vielseitigkeit zu veranschaulichen. Basierend auf Abschnitt 6 des Ausgangsmaterials untersuchen wir, wie ein einzelnes Szenario – ein VIP-Kunde meldet einen Produktfehler – in drei verschiedenen Phasen modelliert werden kann. Indem wir von abstrakter Abgrenzung über detaillierte Zusammenarbeit bis hin zur systemgesteuerten Automatisierung fortschreiten, zeigt diese Fallstudie, wie BPMN die Abstimmung zwischen geschäftlichen Stakeholdern und IT-Implementierungsteams erleichtert.
Phase 1: Hochstufenübersicht (Abgrenzung und Abstraktion)
Die erste Modellierungsphase dient dazu, den Geltungsbereich festzulegen und sicherzustellen, dass alle Stakeholder ein gemeinsames Verständnis des „Happy Path” haben. Diese Sichtweise ist absichtlich vereinfacht, um vorzeitige Komplexität zu vermeiden.
Das Szenario
Ein VIP-Kunde meldet ein Produktproblem einem Account Manager. Der Prozess folgt einer linearen Eskalationskette:
-
Der Account Manager versucht, das Problem zu lösen.
-
Falls es nicht gelöst wird, eskaliert es an den Support der 1. Ebene.
-
Die 1. Ebene kann an den Support der 2. Ebene eskalieren.
-
Die 2. Ebene kann einen Softwareentwickler konsultieren.
-
Die Lösung fließt zurück zum Account Manager, der sie dem Kunden erklärt.
Wichtige BPMN-Konzepte
-
Single-Pool-Modellierung: Diese Version verwendet einen einzigen Pool mit mehreren Spalten. Dieser Ansatz „blendet” explizite Kommunikationsprotokolle effektiv aus. Er geht davon aus, dass Teilnehmer auf irgendeine Weise kommunizieren, ohne die spezifischen Nachrichtenflüsse zu modellieren, wodurch das Diagramm sauber bleibt und sich auf die Sequenz konzentriert, nicht auf die Interaktion.
-
Abstrakte Aufgaben: Aufgaben werden absichtlich untypisiert (abstrakt) gelassen. In dieser Phase liegen nicht genügend Informationen vor, um zu bestimmen, ob eine Aufgabe manuell, automatisiert oder ein Serviceaufruf ist. Eine vorzeitige Typisierung kann den Designraum einschränken; Abstraktion erhält die Flexibilität während der Abgrenzungsphase.
Hauptanwendungsfall: Abstimmung der Stakeholder, Prozessabgrenzung und Zusammenfassungen für die Geschäftsführung.
Phase 2: Detaillierte Zusammenarbeit und Choreografie
Sobald der hochstufige Ablauf vereinbart wurde, entwickelt sich das Modell weiter, um die Realität menschlicher Interaktion und abteilungsübergreifender Übergänge abzubilden. Diese Phase unterscheidet zwischen interner Orchestrierung und externen Kommunikationsverträgen.
Das Szenario
Granulare Details werden hinzugefügt, um die tatsächlichen Abläufe widerzuspiegeln. Der Dialog zwischen dem Account Manager und dem Kunden wird explizit modelliert, um Problemdefinitionen zu klären. Zusätzlich fügt der Agent der zweiten Ebene, falls eine Behebung nicht sofort möglich ist, eine Anforderung für eine neue Funktion in den Product Backlog ein und führt damit einen parallelen Workflow-Zweig ein.
Wichtige BPMN-Konzepte
-
Kollaborationsdiagramm (Multi-Pool): Das Modell wechselt von einem einzelnen Pool zu mehreren Pools. Dies visualisiert das „Ping-Pong-Spiel” von Nachrichten zwischen unabhängigen Teilnehmern (Account Manager, Support-Agents, Entwickler). Nachrichtenflüsse überschreiten nun Pool-Grenzen, wodurch Übergaben und Abhängigkeiten explizit werden.
-
Manuelle Aufgaben: Im Gegensatz zu Phase 1 sind die Aufgaben nun explizit als „Manuell” gekennzeichnet. Dies zeigt einen vollständig von Menschen gesteuerten Prozess ohne aktuelle Automatisierung und liefert eine genaue „As-Is”-Grundlage.
-
Choreographiediagramm: Dies bietet eine alternative, kommunikationszentrierte Sichtweise. Die Choreographie verbirgt die interne Logik (wie das Aktualisieren eines Backlogs oder Denkzeiten) und zeigt nur den Nachrichtenaustausch zwischen den Teilnehmern. Sie definiert den Interaktionsvertrag und nicht die interne Verarbeitung.
-
Gemeinsames semantisches Modell: Entscheidend ist, dass das Kollaborations- und das Choreographiediagramm keine separaten Prozesse darstellen; sie repräsentieren exakt dasselbe zugrundeliegende semantische Modell, das durch verschiedene Filter betrachtet wird. Änderungen in einem sollten logischerweise auch im anderen widergespiegelt werden.
Hauptanwendungsfall: Dokumentation von Mensch-zu-Mensch-Interaktionen, Definition von Schnittstellenverträgen und Analyse von Kommunikationsengpässen.
Phase 3: Menschengesteuerte vs. Systemgesteuerte Abläufe
Die letzte Phase schließt die Lücke zwischen Geschäftsprozessdesign und IT-Implementierung. Sie identifiziert, welche Elemente menschzentriert bleiben und welche von einer Prozess-Engine orchestriert werden können, um eine echte Business-IT-Ausrichtung zu erreichen.
Das Szenario
Um die Effizienz zu maximieren, wird der Prozess hybridisiert. Der Account Manager und der Entwickler bleiben „menschengesteuert” und kommunizieren per E-Mail oder face-to-face. Die Workflows der Support-Agents werden jedoch nun von einem “Störungsticketsystem verwaltet, das als zentrale Prozess-Engine fungiert.
Wichtige BPMN-Konzepte
-
Dedizierter Prozess-Engine-Pool: Das Störungsticketsystem wird in einem eigenen, distincten Pool modelliert. Dies zeigt explizit die Rolle des Systems beim Parsen eingehender E-Mails, beim Zuweisen von Benutzeraufgaben an Agents und beim Aufruf von Service-Funktionen an die Product-Backlog-API.
-
Ausführungsdetails: Dieses Modell geht über die Dokumentation hinaus zur Spezifikation. Es kann mit technischen Metadaten angereichert werden (z. B. XML-Serialisierungsschemata, API-Endpunkte, Variablenzuordnungen), die für eine Prozess-Engine erforderlich sind, um den Workflow auszuführen. Für Business-Teilnehmer, die keine technischen Implementierungsdetails sehen müssen, können dennoch einfachere, abstrahierte Ansichten dieses ausführbaren Modells generiert werden.
Hauptanwendungsfall: Technische Spezifikation für Automatisierung, Konfiguration der Prozess-Engine und Definition der Grenze zwischen menschlichen und systemseitigen Verantwortlichkeiten.
Zusammenfassung der BPMN-Perspektiven im Incident-Management
Die folgende Tabelle fasst die Schlüsselkonzepte über die drei Phasen hinweg zusammen und dient als schnelle Referenz zur Auswahl des geeigneten Modellierungsansatzes.
| BPMN-Perspektive | Hauptanwendungsfall | Wichtige Notation/Element |
|---|---|---|
| Hochlevelig | Eingrenzung und grundlegendes Verständnis des Ablaufs. | Einzelner Pool, Bahnen, abstrakte Aufgaben. |
| Zusammenarbeit | Modellierung der Interaktion zwischen Menschen / Ist-Zustand. | Mehrere Pools, Nachrichtenflüsse, manuelle Aufgaben. |
| Choreografie | Hervorhebung von Kommunikationsverträgen zwischen Partnern. | Choreografie-Aufgaben (zeigt zwei Teilnehmer). |
| Systemgesteuert | Technische Spezifikation für Automatisierung. | Service-Aufgaben, Prozess-Engine-Pool, Benutzer-Aufgaben-Zuweisungen. |
Fazit
Die Fallstudie zum Incident-Management zeigt, dass effektive BPMN-Modellierungeine Übung im Perspektivenmanagement ist. Ein einzelner Geschäftsprozess erfordert mehrere Darstellungen, um unterschiedliche Bedürfnisse zu erfüllen: abstrakte Modelle zur Eingrenzung, kollaborative Modelle zum Verständnis der menschlichen Interaktion, Choreografien zur Definition von Verträgen und systemgesteuerte Modelle zur Automatisierung. Der Versuch, all diese Aspekte in ein einziges Diagramm zu zwingen, führt unweigerlich entweder zu überwältigender Komplexität oder zu gefährlicher Vereinfachung.
Für Praktiker, die diesen mehrperspektivischen Ansatz umsetzen möchten, ist eine robuste Werkzeugunterstützung unerlässlich. Visual Paradigm ist besonders gut für diese Methodik geeignet, da es das gesamte Spektrum an BPMN-Diagrammtypen—von hochleveligen Orchestrierungen bis hin zu ausführbaren Choreografien—in einem einheitlichen Repository. Die Fähigkeit, ein gemeinsames semantisches Modell zu pflegen, stellt sicher, dass Aktualisierungen in der systemgesteuerten Ansicht automatisch in die Perspektiven für Zusammenarbeit und Choreografie übernommen werden und so die Konsistenz zwischen Geschäfts- und IT-Bereichen erhalten bleibt. Durch die Nutzung solcher Tools in Kombination mit dem in diesem Leitfaden beschriebenen phasenweisen Modellierungsansatz können Organisationen BPMN von einer statischen Dokumentationsübung in eine dynamische Brücke zwischen Geschäftsstrategie und technischer Umsetzung verwandeln.
