Ein BPMN-Prozessdiagramm beschreibt Arbeit mit Business Process Model and Notation (BPMN), einer standardisierten Sprache für Aktivitäten, Ereignisse, Entscheidungen und Kommunikation. Bei einer Teamprüfung ist ihr Wert die Präzision. Ein gemeinsames Modell ermöglicht es den Beteiligten, einen bestimmten Übergang zu hinterfragen, statt über vage Aussagen wie „Freigaben dauern lange“ zu streiten.
Dieser Artikel verwendet kleine beschreibende Beispiele zur Diskussion. Sie sind keine ausführbaren Prozessmodelle. Verwenden Sie ein BPMN-fähiges Modellierungswerkzeug, um das tatsächliche Diagramm zu erstellen und zu validieren. NextRetro unterstützt Retrospektivengespräche und Nachverfolgung; es ist weder BPMN-Editor noch Prozessmaschine.
Die Notation verstehen, bevor Sie das Bild interpretieren
Die OMG-BPMN-2.0.2-Spezifikation ist die maßgebliche Referenz. Die folgende Einführung beschränkt sich bewusst auf die in unserem Beispiel verwendeten Begriffe; BPMN bietet mehr Details, als diese Einführung abdeckt.
| Element | Bedeutung in diesem Beispiel |
|---|---|
| Pool | Ein Beteiligter an einer Zusammenarbeit |
| Lane | Ein Abschnitt innerhalb eines Prozesses, hier zur Darstellung von Zuständigkeit |
| Aufgabe | Eine Aktivität, etwa eine Anfrage prüfen |
| Start- oder Endereignis | Beginn oder Ende des modellierten Prozesspfads |
| Gateway | Ein Kontrollpunkt zum Verzweigen oder Zusammenführen von Pfaden |
| Sequenzfluss | Reihenfolge der Arbeit innerhalb eines Prozesses; er überschreitet keine Pool-Grenze |
| Nachrichtenfluss | Kommunikation zwischen getrennten Beteiligten, dargestellt als separate Pools |
Ein Sequenzfluss darf Lanes innerhalb desselben Pools überschreiten. Verwenden Sie keinen Nachrichtenfluss zwischen zwei Lanes dieses Pools, nur weil verschiedene Teams die Arbeit erledigen. Lanes und unabhängige Beteiligte sind nicht austauschbar.
Ausführliche Symbole und Verhaltensregeln stehen in der normativen Spezifikation. Ein Modell, das Automatisierung steuern soll, muss strenger validiert werden als eine Workshop-Skizze.
Beispiel 1: eine interne Zugriffsanfrage
Stellen Sie sich eine hypothetische Organisation vor, die prüft, wie Mitarbeitende Zugriff auf ein Berichtssystem beantragen. Modellieren Sie die Organisation als einen Pool mit Lanes für den Service Desk und die Zugriffsverwaltung. Die anfragende Person kann separat dargestellt werden, wenn die gewählte Kollaborationsansicht sie als weiteren Beteiligten behandelt; wählen und dokumentieren Sie die Grenze einheitlich.
Für den Prozess der Organisation sieht ein einfacher Ablauf so aus:
- Eine Anfrage trifft ein und startet den Prozess.
- Der Service Desk prüft, ob die erforderlichen Informationen vorhanden sind.
- Eine exklusive Entscheidung verzweigt in vollständige und unvollständige Anfragen.
- Unvollständige Anfragen gehen im Rahmen der definierten Interaktion zur Klärung zurück.
- Vollständige Anfragen werden zur Prüfung der Zugriffsberechtigung weitergeleitet.
- Genehmigte Anfragen erhalten Zugriff; abgelehnte Anfragen erhalten eine Erklärung.
- Der Prozess endet mit dem passend dokumentierten Ergebnis.
Beschriften Sie Entscheidungspfade mit Bedingungen wie „erforderliche Angaben vollständig“ und „Angaben fehlen“. „Ja“ und „Nein“ lassen sich schwer interpretieren, wenn das Diagramm ohne seine ursprüngliche Frage geteilt wird.
Dies ist eine Beschreibung, die modelliert werden soll, keine Behauptung, dass diese Schritte die Sicherheitsrichtlinien einer bestimmten Organisation erfüllen. Anforderungen zur Zugriffsgenehmigung und Evidenz müssen aus den genehmigten Kontrollen der jeweiligen Organisation stammen.
Beispiel 2: Ein Lieferant wirkt am Prozess mit
Stellen Sie sich nun vor, ein separater Lieferant muss nach der Genehmigung durch die Organisation ein lizenziertes Konto aktivieren. Stellen Sie den Lieferanten als weiteren Pool dar. Die Aktivierungsanfrage der Organisation und die Bestätigung des Lieferanten sind Kommunikation zwischen Beteiligten und werden daher als Nachrichtenflüsse modelliert.
Zeichnen Sie keinen Sequenzpfeil von einer internen Aufgabe direkt zu einer Lieferantenaufgabe. Das würde die interne Reihenfolge des Prozesses eines Beteiligten mit Kommunikation über eine Grenze hinweg verwechseln.
Der interne Lieferantenprozess kann verborgen bleiben, wenn er außerhalb des Prüfungsumfangs liegt. Das Team muss wissen, welche Nachricht die Interaktion startet und welche Antwort erwartet wird, ohne so zu tun, als kenne es die interne Arbeitsweise des Lieferanten.
Nun wird eine nützliche Prüffrage sichtbar: Was passiert, wenn keine Bestätigung eintrifft? Definieren Sie die gewünschte Behandlung der Ausnahme, bevor Sie dem formalen Modell einen Timer oder ein anderes Ereignis hinzufügen. Ein Timeout-Label allein legt nicht fest, wer nachfasst oder welche Entscheidung diese Person treffen kann.
Fälle durch das Modell verfolgen, bevor Sie es ändern
Wählen Sie drei reale, angemessen bereinigte Fälle: einen normalen Abschluss, eine Anfrage mit Klärungsbedarf und eine Ausnahme. Vertrauliche personenbezogene Angaben bleiben im genehmigten Fallsystem; verwenden Sie im Workshop Verweise oder Zusammenfassungen.
Bitten Sie für jeden Fall die Personen, die die Arbeit erledigt haben, den Pfad nachzuverfolgen. Wo kam die Arbeit tatsächlich zum Stillstand? Welche Information fehlte? Welche Beteiligten glaubten, eine andere Person sei für den nächsten Schritt zuständig? Halten Sie Unterschiede zwischen dokumentiertem Prozess und beobachteter Praxis fest.
Bearbeiten Sie das Modell nicht stillschweigend zu einem idealen zukünftigen Prozess um. Kennzeichnen Sie den aktuellen Ablauf und die vorgeschlagene Änderung getrennt. Sonst könnte das Team ein ausgefeiltes Diagramm mitnehmen, das die untersuchten Fälle nicht mehr erklärt.
Ein Prozessmodell ist eine Hypothese über den Arbeitsfluss. Zeitstempel und Fallverläufe helfen dabei, sie zu prüfen. Weder das Diagramm noch die Erinnerung einer beteiligten Person ist für sich genommen ein vollständiger Beleg.
Eine ausgearbeitete Verbesserungsentscheidung
In diesem hypothetischen Beispiel untersucht das Team zwölf Anfragen. Die Zahl dient der Veranschaulichung und ist weder ein Richtwert noch ein Kundenergebnis von NextRetro. Mehrere Anfragen warteten zwischen der Informationsprüfung und der Zugriffsfreigabe, weil bei der Übergabe die entscheidungsbefugte Person nicht genannt wurde.
Der erste Vorschlag lautet, jede Genehmigung zu automatisieren. Das Modell zeigt, warum dies verfrüht ist: Das Team hat noch nicht vereinbart, welche Anfragen welche Genehmigung brauchen. Eine undefinierte Entscheidung zu automatisieren könnte unvollständige Arbeit beschleunigen, ohne die Zuständigkeit zu klären.
Das Team wählt ein kleineres Experiment. Bei den nächsten zehn geeigneten Anfragen benennt der Service Desk vor der Übergabe die zuständige Person für die Genehmigung. Die Wartezeit auf die Klärung der Zuständigkeit wird getrennt von der Zeit für die Genehmigung erfasst.
Die Schutzvorgabe bleibt der unveränderte Zugriffsschutz. Eine schnellere Bearbeitung rechtfertigt nicht, die Genehmigung zu überspringen. Bei der nächsten Prüfung untersucht das Team, ob Verzögerungen durch fehlende Zuständigkeiten abgenommen haben und ob die zusätzliche Vorbereitung einen neuen Engpass geschaffen hat.
So verbindet sich das Prozessdiagramm mit einer beobachtbaren Änderung, statt die Fertigstellung des Diagramms als Verbesserung zu behandeln.
Ein Prüfblatt neben dem Diagramm verwenden
Halten Sie für jedes vermutete Problem diese Felder fest:
Ort: Welche Aufgabe, Entscheidung oder Übergabe ist betroffen?
Beobachteter Fall: Welches Beispiel zeigt die Schwierigkeit?
Erwarteter Auslöser: Was sollte den nächsten Schritt starten?
Tatsächliches Hindernis: Was hat ihn verhindert?
Vorgeschlagene Änderung: Was ist bei den nächsten geeigneten Fällen anders?
Einschränkung: Welche Kontrolle oder Qualitätsanforderung muss erhalten bleiben?
Prüfevidenz: Was prüft das Team und wann?
Wählen Sie ein Retrospektiven-Format, das den Beteiligten Zeit lässt, das Modell vor der Priorisierung von Änderungen zu hinterfragen. Nutzen Sie anschließend den Leitfaden für Maßnahmen, damit das ausgewählte Experiment nach dem Meeting sichtbar bleibt.
Häufig gestellte Fragen
Sind Pools und Lanes in BPMN dasselbe?
Nein. Ein Pool stellt einen Beteiligten an einer Zusammenarbeit dar. Eine Lane unterteilt einen Prozess. Ein Sequenzfluss darf Lanes innerhalb eines Pools überschreiten; Kommunikation zwischen getrennten Pools von Beteiligten erfolgt als Nachrichtenfluss.
Ist jedes Prozessflussdiagramm ein BPMN-Diagramm?
Nein. Ein allgemeines Flussdiagramm kann informelle Symbole und Konventionen nutzen. Bezeichnen Sie ein Modell nur dann als BPMN, wenn es den einschlägigen Regeln der Notation folgt, und validieren Sie es angemessen, wenn es Automatisierung steuern soll.
Kann NextRetro ausführbare BPMN-Modelle erstellen?
NextRetro ist weder BPMN-Modellierungswerkzeug noch Prozessmaschine. Bewahren Sie das maßgebliche Modell in einem passenden Editor auf und verwenden Sie ein Retrospektiven-Board, um beobachtete Probleme, konkurrierende Erklärungen und vereinbarte Verbesserungsexperimente zu besprechen.