Die Geschichte
Ein Schaden, drei Menschen, eine Entscheidung.
Der Prozess beginnt, wenn ein Kunde einen Schaden an seinem Auto meldet. Die Sachbearbeitung registriert den Schaden im Schadensystem und fragt beim Kunden nach, was fehlt: Fotos, der Polizeibericht, falls es einen gibt, der Kostenvoranschlag der Werkstatt. Erst wenn die Unterlagen da sind, prüft der Underwriter die Deckung: Ist der Schaden durch die Police gedeckt, so wie sie am Schadentag galt?
Diese Prüfung ist der Kontrollschritt des Modells. Sie ist blau gezeichnet, weil sie der eine Punkt ist, an dem die Organisation entschieden hat, dass eine qualifizierte Person hinsehen muss, bevor Geld fließt. Alles davor ist Aufnahme; alles danach hängt vom Ergebnis ab.
Das Gateway stellt eine einzige Frage: gedeckt oder nicht. Wenn ja, gibt die Sachbearbeitung die Auszahlung im Schadensystem frei, und der Kunde erhält das Geld. Wenn nein, schreibt der Underwriter eine Ablehnung mit Begründung, und der Kunde erhält diese. Zwei Endereignisse, beide in der Lane des Kunden, denn der Prozess endet, wenn der Kunde eine Antwort hat, nicht wenn die Akte geschlossen ist.
Dies ist ein fiktives Beispielmodell. Es ist bewusst kleiner als ein echter Schadenprozess, der Betrugsprüfungen, Werkstattnetze, Reserven und Rückversicherung enthielte. Das Beispiel soll zeigen, wie sich drei Rollen, eine Entscheidung und eine Kontrolle in BPMN lesen.
Das Diagramm
Das Modell als BPMN 2.0.
Lesen Sie es von links nach rechts. Jedes waagerechte Band ist eine Lane, eine pro Rolle. Der dünne Kreis ist der Start, die dicken Kreise sind die Enden, die Raute mit dem Kreuz ist das exklusive Gateway, und die blaue Aufgabe ist der Kontrollschritt. Die kleinen Großbuchstaben unter einer Aufgabe nennen das System, das dieser Schritt nutzt.
Verwendete Elemente
Was im Modell steckt, und warum.
Jedes Element im Diagramm beantwortet eine Frage, die im Workshop jemand stellen würde: Wer macht das, was passiert wenn, welches System, und wann sind wir fertig.
Lanes: Kunde, Sachbearbeitung, Underwriter
Drei Rollen, drei Bänder. Der Kunde hat eine eigene Lane, weil er in diesem Prozess echte Arbeit leistet: den Schaden melden und Unterlagen einreichen. Jede Übergabe ist eine Linie, die eine Lane-Grenze kreuzt.
Gateway: Gedeckt?
Ein exklusives Gateway, mit einem Kreuz markiert. Genau einer der beiden ausgehenden Pfade wird genommen. Die Frage steht neben der Raute, die Antworten ja und nein stehen an den ausgehenden Flüssen.
Kontrollschritt: Deckung prüfen
Die blaue Aufgabe. In der .bpmn-Datei trägt der Schritt die Dokumentation „Kontrollschritt“, damit ein BPMN-Werkzeug, und später ein KI-Agent, ihn von gewöhnlicher Arbeit unterscheiden kann. Er nutzt die Policenakte als Referenz.
Systeme: Schadensystem, Policenakte
Schaden registrieren und Auszahlung freigeben berühren beide das Schadensystem; die Deckungsprüfung liest die Policenakte. Der Systemname unter der Aufgabe genügt, um zu sehen, welche Schritte betroffen wären, wenn sich eines der Systeme ändert.
Endereignisse: Auszahlung erhalten, Ablehnung erhalten
Zwei Enden, beide beim Kunden. Das Ende aus Sicht des Kunden zu benennen hält das Modell ehrlich: Der Schaden ist nicht erledigt, wenn die Sachbearbeitung die Akte schließt, sondern wenn der Kunde das Geld oder die Begründung hat.
Wo der Prozess wartet
Worauf Sie in einem Schadenmodell achten sollten.
Schon ein so kleines Modell zeigt die Stellen, an denen echte Schadenprozesse Tage verlieren. Es sind alles Übergaben über eine Lane-Grenze.
Warten auf Unterlagen
Der Schritt Unterlagen einreichen liegt in der Lane des Kunden. Die Organisation kann ihn nicht direkt beschleunigen; sie kann nur in einer Nachricht klar sagen, was gebraucht wird, und erinnern.
Die Schlange vor dem Underwriter
Deckung prüfen ist ein Kontrollschritt einer knapperen Rolle. Davor stauen sich die Schäden. Im Workshop ist das die Stelle, an der meist jemand sagt: „Da bleibt es immer liegen.“
Zwei Systeme, ein Schaden
Schadensystem und Policenakte sind getrennt. Wenn die Deckungsprüfung bedeutet, Dinge von Hand nachzuschlagen, zeigt es das Modell: zwei verschiedene Systemnamen an zwei benachbarten Schritten.
Die Ablehnung mit Begründung
Eine Ablehnung ist Schreibarbeit, kein Klick. Modelle, die sie als einzelnen Pfeil zu einem Endereignis zeichnen, verbergen den Aufwand und die Beschwerden, die auf eine dünne Begründung folgen.
Datei anfordern
Das Modell als .bpmn-Datei.
Die Datei ist ein fiktives Beispielmodell in BPMN 2.0 XML. Sie öffnet sich in Standard-BPMN-Werkzeugen wie Camunda Modeler, Signavio oder ADONIS, mit Lanes, Gateway, Kontrollschritt und dem Layout des Diagramms. Sie wird auf Anfrage per E-Mail versandt; von dieser Seite wird nichts heruntergeladen.
Die Symbole im Detail: der BPMN-Leitfaden. Dieselbe Prozessfamilie mit mehr Rollen: Policen-Onboarding. Wie ein solches Diagramm aus einem Gespräch entsteht: So funktioniert patchley.