End-Ereignis
BPMNAuch: End Event , Endsymbol
BPMN-Element, das den Abschluss eines Prozesses kennzeichnet. Grafisch ein Kreis mit dicker Linie. Jeder Prozess muss mindestens ein End-Ereignis besitzen. End-Ereignisse können das Ergebnis konkretisieren: Message, Error, Escalation, Cancel, Compensation, Signal oder Terminate.
Das End-Ereignis markiert den Abschluss eines Prozesspfads. Wie das Start-Ereignis ist es in BPMN 2.0 obligatorisch: Jeder Prozess muss in mindestens einem End-Ereignis enden. Mehrere End-Ereignisse pro Prozess sind erlaubt und sinnvoll, wenn ein Prozess unterschiedliche Ausgänge hat (etwa: positiv abgeschlossen, abgelehnt, abgebrochen).
Visuell unterscheidet sich das End-Ereignis vom Start-Ereignis durch eine dickere Randlinie (Strichstärke 3 in der OMG-Spezifikation). Diese visuelle Konvention erlaubt Lesenden, Start und Ende auf einen Blick zu unterscheiden.
Wichtige Varianten:
- None End Event (leerer Kreis): Standard-Abschluss ohne spezifisches Ergebnis
- Message End Event (Briefumschlag, gefüllt): Versand einer Nachricht beim Beenden
- Error End Event (Blitz, gefüllt): Prozess bricht mit Fehler ab, der ggf. von einem übergeordneten Prozess gefangen wird
- Terminate End Event (gefüllter Kreis): Beendet den gesamten Prozess unmittelbar, auch parallele Pfade
Das Terminate End Event ist besonders nützlich bei Notfall-Abbrüchen, etwa Storno einer Bestellung mit laufender Zahlungsabwicklung.
Wie beschriftet man ein End-Ereignis richtig?
Ein End-Ereignis beschreibt das Ergebnis, mit dem der Prozess endet, nicht die letzte Tätigkeit. Bewährt haben sich Beschriftungen im Partizip wie „Auftrag abgeschlossen“ oder „Anfrage abgelehnt“. Sie machen auf einen Blick lesbar, welche Zustände ein Prozess hinterlassen kann. End-Ereignisse sind werfend: Sie lösen bei Bedarf selbst etwas aus, etwa das Versenden einer Nachricht (Weske 2024, S. 223).
Der Unterschied zum Start-Ereignis liegt nur in der Strichstärke, deshalb ist die Beschriftung umso wichtiger. In Modellen mit mehreren Ausgängen sollte jedes End-Ereignis einen eigenen, eindeutigen Namen tragen, damit Kennzahlen wie „Anteil abgelehnter Anfragen“ später direkt am Modell ablesbar sind.
Ein Ende oder mehrere Enden?
Die sieben Modellierungsrichtlinien empfehlen ein einziges End-Ereignis, weil die Zahl der Start- und End-Ereignisse messbar mit der Fehlerwahrscheinlichkeit zusammenhängt (Mendling et al. 2010). Trotzdem sind mehrere Enden legitim, wenn sie fachlich verschiedene Ergebnisse darstellen.
Eine einfache Faustregel hilft bei der Entscheidung: Würde ein Prozessverantwortlicher die Ausgänge getrennt zählen wollen, verdienen sie getrennte End-Ereignisse. Werden alle Pfade nach derselben Aufgabe wieder zusammengeführt, genügt ein Ende. Was vermieden werden sollte, sind parallele Pfade, die in getrennten Enden auslaufen, obwohl sie zusammengehören; hier gehört zuvor ein zusammenführendes Gateway ins Modell.
Welche Fehler passieren beim End-Ereignis am häufigsten?
Der häufigste Fehler ist das fehlende Ende: Ein Pfad läuft nach dem letzten Gateway einfach aus. Der zweite ist ein End-Ereignis, das als Aufgabe beschriftet ist. Der dritte betrifft parallele Pfade: Endet einer davon in einem normalen End-Ereignis, laufen die anderen weiter, was oft nicht beabsichtigt ist. Gadatsch nennt Start- und End-Ereignisse deshalb Pflichtelemente jedes Prozessmodells, Zwischenereignisse dagegen optional (Gadatsch 2025, S. 165).
Häufige Fragen zu End-Ereignis
- Wann braucht ein Prozess mehrere End-Ereignisse?
- Wenn er fachlich unterschiedlich enden kann, etwa mit Freigabe oder Ablehnung. Beide Ausgänge bekommen ein eigenes, beschriftetes End-Ereignis. Führen alle Pfade zum selben Ergebnis, reicht ein einziges.
- Was unterscheidet das Terminate-End-Ereignis vom normalen Ende?
- Ein normales End-Ereignis beendet nur den Pfad, auf dem es liegt; parallele Pfade laufen weiter. Das Terminate-Ereignis beendet sofort den gesamten Prozess, auch alle anderen laufenden Pfade.
Quellen
- Gadatsch, A. (2025): Grundkurs Geschäftsprozess-Management, 11. Aufl., Springer Vieweg, S. 166
- OMG (2011): Business Process Model and Notation (BPMN) Specification, Version 2.0, S. 245 ff.
- Weske, M. (2024): Business Process Management. Concepts, Languages, Architectures, 4. Aufl., Springer, S. 223
- Mendling, J. / Reijers, H. A. / van der Aalst, W. M. P. (2010): Seven Process Modeling Guidelines (7PMG), Information and Software Technology 52(2)
Autor: Jordanis Kleinöder Stafidis, Gründer und Geschäftsführer der Procevia GmbH · Aktualisiert am
Siehe auch: Ereignis , Start-Ereignis , Zwischenereignis , BPMN