BPMN Events einfach erklärt: Start, Ende & Zwischenereignisse (Message, Timer, Error)

Wenn wir uns ein typisches BPMN-Diagramm ansehen, wird unser Blick oft von den großen Rechtecken dominiert – den Aktivitäten. Das ist verständlich, denn dort findet die eigentliche Wertschöpfung statt, dort wird gearbeitet. Doch ein Prozess besteht nicht nur aus bloßer Arbeit. Er ist eingebettet in eine Welt voller externer Einflüsse, zeitlicher Fristen und unvorhergesehener Störungen.

Genau an dieser Stelle kommen die Events (Ereignisse) ins Spiel. Um sie korrekt einzusetzen, müssen wir zunächst eine fundamentale Unterscheidung treffen, die in der BPMN-Spezifikation verankert ist: Der Unterschied zwischen "Arbeit" und "Ereignis".

Was ist der Unterschied zwischen einer Aktivität und einem Event?

Eine Aktivität (dargestellt als abgerundetes Rechteck) repräsentiert Arbeit, die verrichtet wird. Sie hat eine Dauer. Ein Sachbearbeiter braucht Zeit, um einen Antrag zu prüfen; ein Server braucht Millisekunden, um Daten zu speichern. Solange der Token in einer Aktivität liegt, ist der Prozess in einem Zustand des "Tuns".

Ein Event (dargestellt als Kreis) hingegen verbraucht keine Zeit. Es ist ein infinitesimal kleiner Moment im Prozessablauf. Die Spezifikation definiert ein Event schlicht als "etwas, das passiert" (something that happens). Es ist der Moment, in dem eine E-Mail im Posteingang aufschlägt, der Moment, in dem eine Frist abläuft, oder der Moment, in dem ein Fehler auftritt.

Man kann sich den Prozess wie eine Reise mit dem Auto vorstellen:

• Die Aktivitäten sind die Fahrtabschnitte auf der Autobahn. Hier bewegst du dich, hier verstreicht Zeit, hier kommst du voran.
  
  

• Die Events sind die Verkehrsschilder und Signale. Das grüne Licht an der Ampel (Start), das Aufleuchten der Tankanzeige (Zwischenereignis) oder das Erreichen des Ziels (Ende). Sie unterbrechen die Fahrt nicht um der Fahrt willen, sondern sie steuern den Verlauf.

Warum sind Events so wichtig?

Ohne Events wäre ein Prozessmodell starr und linear. Es würde implizieren, dass wir einfach stumpf von A nach B arbeiten, ohne dass die Außenwelt uns beeinflusst. Events erlauben es uns, Reaktivität zu modellieren. Sie geben dem Prozess die Fähigkeit, auf seine Umwelt zu hören und entsprechend zu handeln. Sie definieren den Puls des Prozesses: Wann darf er starten? Worauf muss er warten? Und wann genau ist er eigentlich fertig?

Indem wir Events nutzen, machen wir aus einer statischen Arbeitsanweisung ein dynamisches Verhaltensmodell, das auch beschreibt: "Was passiert eigentlich, wenn nicht alles nach Plan läuft?".

Damit du ein BPMN-Event in einem Diagramm richtig interpretieren oder selbst korrekt einsetzen kannst, musst du lernen, das Symbol fast wie ein kleines Piktogramm zu lesen. Ein einziges grafisches Element verrät dir nämlich drei entscheidende Informationen auf einmal: An welcher Stelle im Prozess stehen wir? Was genau passiert hier? Und welche Rolle spielt das Event im Ablauf?

Schauen wir uns diese drei Dimensionen genauer an.

1. Die Position: Wo stehen wir?

Der erste Blick sollte immer auf den Rand des Kreises fallen. Die Dicke und Art der Linie verrät dir sofort, wo im zeitlichen Ablauf des Prozesses wir uns befinden.

Ein Start-Ereignis erkennst du an einem dünnen, einfachen Rand. Es markiert den Anfang der Geschichte und hat logischerweise niemals einen eingehenden Pfeil, sondern nur einen ausgehenden, der den Prozess ins Rollen bringt.

Das Gegenstück dazu ist das End-Ereignis, das durch einen dicken, fetten Rand markiert wird. Hier ist der Pfad zu Ende, weshalb es zwar einen Eingang, aber keinen Ausgang hat.

Alles, was dazwischen passiert, sind Zwischen-Ereignisse (Intermediate Events). Sie zeichnen sich durch einen doppelten Rand aus und können den Prozessfluss an jeder beliebigen Stelle beeinflussen.

2. Der Typ: Was passiert eigentlich?

Wenn du weißt, wo das Event steht, schaust du ins Innere des Kreises. Das Symbol (Icon) dort erklärt dir die Art des Ereignisses – den sogenannten "Trigger" oder das "Resultat".

Ein Briefumschlag ist wohl das bekannteste Symbol: Er steht für Kommunikation, also den Empfang oder Versand einer Nachricht. Eine Uhr symbolisiert Zeit, sei es ein fixer Zeitpunkt oder eine Wartefrist. Ein Blitz warnt vor einem Fehler oder einer Störung. Wenn der Kreis leer ist, handelt es sich um ein generisches Ereignis ohne spezifischen technischen Auslöser – das nutzen wir oft für manuelle Starts oder einfache Endpunkte.

3. Das Verhalten: Catching vs. Throwing

Dies ist das technisch wichtigste Konzept, das viele Einsteiger anfangs übersehen. Ein Event ist nämlich niemals neutral. Es ist entweder passiv (es wartet) oder aktiv (es handelt). In der Fachsprache nennen wir das "Catching" (Fangen) und "Throwing" (Werfen).

Stell dir ein Catching Event wie einen Torwart vor, der bereitsteht und wartet. Der Prozess kommt an dieser Stelle an und bleibt stehen. Er kann erst weitermachen, wenn der Auslöser von außen "gefangen" wurde – etwa, wenn die erwartete E-Mail im Posteingang landet oder der Timer abgelaufen ist. Du erkennst diese wartenden Events daran, dass das Icon im Inneren weiß (ungefüllt) ist.

Ein Throwing Event hingegen ist wie ein Werfer. Wenn der Prozess diesen Punkt erreicht, wird aktiv ein Ergebnis "geworfen". Das System sendet eine E-Mail raus oder meldet einen Fehler. Der Prozess wartet hier nicht, sondern feuert das Ergebnis ab und läuft sofort weiter oder endet. Diese aktiven Events erkennst du am schwarzen (gefüllten) Icon.

Diese Unterscheidung ist essenziell: Start-Events sind immer "Catching" (sie warten auf den Startschuss), End-Events sind immer "Throwing" (sie liefern ein Ergebnis). Nur die Zwischen-Ereignisse sind die wahren Verwandlungskünstler – sie können, je nach Bedarf, warten oder werfen.

Jeder Prozess muss irgendwo beginnen. In BPMN markiert das Start-Ereignis (Start Event) genau diesen Punkt. Technisch gesehen wird in dem Moment, in dem dieses Ereignis eintritt, eine neue Prozessinstanz erzeugt und der erste Token auf die Reise geschickt .

Eine eiserne Regel, die du dir merken musst: Start-Ereignisse sind immer "Catching" (Fangend). Sie können nicht aktiv etwas tun, sondern warten passiv darauf, dass ein Auslöser (Trigger) eintritt, um den Prozess zu starten .

Schauen wir uns die drei Varianten an, die du im Alltag fast immer brauchst.

1. Das unbestimmte Start-Ereignis (None Start Event)

Dieses Symbol ist ein einfacher Kreis ohne Icon im Inneren. Es ist der "Joker" unter den Start-Events. Wir nutzen es immer dann, wenn der Auslöser technisch nicht spezifiziert ist oder wenn der Prozess manuell von einem Menschen gestartet wird .

Wenn du beispielsweise einen Prozess modellierst, der beginnt, indem ein Mitarbeiter morgens eine Akte aus dem Schrank nimmt und anfängt zu arbeiten, ist das ein None Start Event. Es gibt keinen automatischen Trigger aus der IT, sondern eine menschliche Entscheidung.

Profi-Tipp: Es gibt einen Ort, an dem du zwingend dieses Ereignis nutzen musst: im Subprozess. Ein eingebetteter Subprozess darf niemals durch eine Nachricht oder einen Timer gestartet werden, sondern immer nur durch den eingehenden Sequenzfluss des übergeordneten Prozesses. Deshalb ist hier das leere Start-Event Pflicht .

2. Das Nachrichten-Start-Ereignis (Message Start Event)

Sobald dein Prozess durch Kommunikation von außen angestoßen wird, nutzt du den Kreis mit dem Briefumschlag. Typische Beispiele sind der Eingang einer Kundenbestellung per E-Mail, ein Anruf im Service-Center oder ein elektronischer Datensatz, der über eine Schnittstelle (API) hereinkommt.

Dieses Ereignis ist besonders wichtig für die Abgrenzung deines Prozesses. Es signalisiert: "Wir warten hier auf jemanden außerhalb unseres Einflussbereichs (z. B. den Kunden), der uns den Ball zuwirft." Jedes Mal, wenn eine solche Nachricht eintrifft, wird eine brandneue Instanz des Prozesses gestartet .

Nach "Method & Style" solltest du dieses Event immer mit dem Namen der Nachricht beschriften, die empfangen wird (z. B. "Bestellung empfangen"), und idealerweise den eingehenden Nachrichtenfluss aus dem Pool des Absenders (z. B. "Kunde") einzeichnen, um den Kontext klarzustellen .

3. Das Zeit-Start-Ereignis (Timer Start Event)

Wenn dein Prozess nicht auf Menschen oder Nachrichten wartet, sondern auf die Uhr schaut, nutzt du den Kreis mit dem Uhr-Symbol.

Das Timer-Start-Ereignis wird für zeitgesteuerte Prozesse verwendet. Das kann ein fixer Zeitpunkt sein ("Jeden Montag um 8:00 Uhr") oder ein wiederkehrender Zyklus ("Jeden ersten des Monats"). Der Prozess startet in diesem Fall vollautomatisch, ohne dass ein Mensch eingreifen muss. Ein klassisches Beispiel ist der monatliche Rechnungslauf oder das tägliche Backup .

Jede Reise hat ein Ende, und in BPMN wird dieses durch das End-Ereignis (End Event) markiert. Du erkennst es sofort an dem dicken, fetten Rand des Kreises . Technisch gesehen passiert hier etwas Entscheidendes: Der Prozess-Token, der durch dein Modell gewandert ist, kommt an und wird "konsumiert". Er verschwindet. Wenn alle Tokens im Prozess vernichtet sind, ist die Prozessinstanz beendet.

Während Start-Ereignisse immer passiv waren (sie warten), sind End-Ereignisse immer aktiv. Sie sind "Throwing" (Werfend). Das bedeutet, sie markieren nicht nur das Ende, sondern sie senden oft ein Ergebnis in die Welt hinaus – sei es eine Nachricht an den Kunden oder ein Signal an das System.

Schauen wir uns die drei Typen an, die du für saubere Modelle beherrschen musst.

1. Das einfache End-Ereignis (None End Event)

Dieses Symbol ist ein dicker Kreis ohne Inhalt. Es ist der Standard, wenn der Prozess einfach "vorbei" ist, ohne dass noch eine spezielle Nachricht gesendet oder ein Fehler geworfen werden muss.

Es gibt hier eine technische Besonderheit, die oft übersehen wird: Wenn du in deinem Prozess parallele Pfade hast (z. B. nach einem AND-Split), beendet dieses Ereignis nur den einen Pfad, auf dem der Token gerade angekommen ist. Andere Pfade, die noch aktiv sind, laufen weiter. Erst wenn alle Pfade in ein End-Ereignis gelaufen sind, ist der gesamte Prozess fertig.

Deshalb benötigst du vor einem None End Event eigentlich kein zusammenführendes Gateway – das Ereignis selbst fungiert als impliziter Sammelpunkt .

2. Das Nachrichten-End-Ereignis (Message End Event)

Wenn dein Prozess nicht stillschweigend enden soll, sondern mit einer Kommunikation abschließt, nutzt du den Kreis mit dem ausgefüllten Briefumschlag.

Das ist der Klassiker für das Ende einer Dienstleistung: Du hast die Bestellung bearbeitet, das Paket gepackt und übergibst es dem Versand. Der Prozess endet, indem du dem Kunden eine "Versandbestätigung" sendest. Technisch gesehen wirft dieses Event eine Nachricht an einen externen Teilnehmer (z. B. den Kunden-Pool).

Nach "Method & Style" ist es Best Practice, hier immer einen ausgehenden Nachrichtenfluss zum Empfänger zu zeichnen, damit sofort klar ist, wer die Info bekommt .

3. Das Abbruch-End-Ereignis (Terminate End Event)

Dieses Symbol – ein dicker Kreis mit einem schwarzen Punkt darin – ist der "Not-Aus-Schalter" deines Prozesses.

Normalerweise wartet ein Prozess geduldig, bis alle parallelen Pfade abgearbeitet sind. Das Terminate-Event ignoriert diese Höflichkeit. Sobald ein Token dieses Ereignis erreicht, werden alle Aktivitäten im Prozess sofort und gnadenlos abgebrochen. Alle anderen Tokens, die vielleicht noch irgendwo auf parallelen Pfaden unterwegs sind, werden vernichtet .

Du nutzt dieses Event typischerweise für gravierende Fehlerpfade. Stell dir vor, du prüfst parallel die Bonität und die Verfügbarkeit der Ware. Wenn die Bonität negativ ist, macht es keinen Sinn, weiter nach der Ware zu suchen. Das Terminate-Event beendet hier den gesamten Vorgang sofort ("Auftrag abgelehnt") und spart so Ressourcen.

Profi-Tipp: Endzustände sauber trennen

Ein häufiger Fehler von Anfängern ist es, alle Pfade – egal ob Erfolg oder Misserfolg – in ein und dasselbe End-Ereignis zu führen, das nur "Ende" heißt. Das ist zwar erlaubt, aber inhaltlich schwach.

Nach "Method & Style" solltest du für jeden unterschiedlichen Ausgang des Prozesses ein eigenes End-Ereignis modellieren. Nenne eines "Rechnung bezahlt" (Erfolg) und ein anderes "Mahnung gesendet" (Misserfolg). Das macht dein Diagramm viel aussagekräftiger, weil man sofort sieht: Dieser Prozess kann auf zwei Arten enden .

Wir haben gelernt, dass der Start immer passiv (wartend) und das Ende immer aktiv (werfend) ist. Was passiert aber in der Mitte?

Hier kommen die Zwischen-Ereignisse (Intermediate Events) ins Spiel. Sie sind die flexibelsten Elemente in deinem Baukasten, denn sie können beide Rollen einnehmen. Du erkennst sie immer an ihrem doppelten Kreisrand.

Ein Zwischen-Ereignis tritt, wie der Name sagt, zwischen dem Start und dem Ende auf1. Es unterbricht oder beeinflusst den normalen Fluss der Aktivitäten. Um sie richtig einzusetzen, musst du unterscheiden, ob das Ereignis als Teil des normalen Ablaufs (im Sequenzfluss) steht oder ob es an eine Aufgabe angeheftet ist (Boundary Event – dazu kommen wir im nächsten Abschnitt).

Schauen wir uns die Ereignisse im normalen Fluss an. Hier entscheidet die Füllung des Icons über das Verhalten des Prozesses:

1. Catching (Fangen): Der Wartezustand

Wenn du ein Zwischen-Ereignis mit einem weißen (ungefüllten) Icon in deinen Sequenzfluss einbaust, fungiert es als Stoppschild. Der Prozess-Token kommt an dieser Stelle an und bleibt stehen. Er wartet.

Der Prozess kann erst dann fortgesetzt werden, wenn der Auslöser des Ereignisses eintrifft. Ein typisches Beispiel ist das Timer Zwischen-Ereignis: Der Prozess wartet an dieser Stelle, bis eine bestimmte Zeit (z. B. "5 Tage") vergangen ist. Erst dann darf der Token weiter zur nächsten Aktivität wandern.

Ein anderes Beispiel ist das Nachrichten-Zwischen-Ereignis: Wir haben ein Angebot versendet und warten nun an dieser Stelle explizit auf den Eingang der Antwort, bevor wir weitermachen.

2. Throwing (Werfen): Der aktive Impuls

Ganz anders verhält es sich, wenn das Icon im Inneren schwarz (gefüllt) ist. Ein solches "Throwing Intermediate Event" ist ein aktiver Schritt. Wenn der Token dieses Ereignis erreicht, wartet er nicht. Stattdessen feuert er sofort ein Signal ab – er "wirft" das Ergebnis – und läuft ohne Verzögerung weiter zur nächsten Aufgabe.

In der Praxis verhalten sich diese werfenden Ereignisse fast wie eine Aktivität. Ein "Message Throw Event" ist beispielsweise funktional fast identisch mit einem "Send Task" (Senden-Aufgabe).

Es wird genutzt, um den Status des Prozesses nach außen zu kommunizieren, etwa "Zwischenbescheid gesendet", ohne dass dafür eine komplexe Aufgabe modelliert werden muss.

3. Das Unbestimmte Zwischen-Ereignis (None Intermediate Event)

Manchmal möchtest du im Prozessverlauf einfach einen Meilenstein markieren, ohne dass eine technische Aktion (Warten oder Senden) passiert. Dafür gibt es das None Intermediate Event (Doppelkreis ohne Icon).

Es hat keinen Auslöser und keine technische Funktion, außer dem Leser zu zeigen: "Hier haben wir einen bestimmten Status erreicht" (z. B. "Phase 1 abgeschlossen"). Der Token läuft hier einfach hindurch, als wäre das Ereignis gar nicht da.

Bisher haben wir uns Ereignisse im normalen Sequenzfluss angesehen. Aber was passiert, wenn ein Ereignis eintritt, während wir gerade mitten in einer Aufgabe stecken?

Stell dir vor, du bist gerade dabei, eine Bestellung zu verpacken (Aktivität "Ware verpacken"). Plötzlich klingelt das Telefon und der Kunde storniert. Oder er ruft an und ändert nur die Lieferadresse. Wie modellieren wir das? Wir können das Ereignis nicht vor oder nach die Aufgabe setzen, denn es passiert währenddessen.

Die Lösung ist das Boundary Event (Grenz-Ereignis). Du heftest den Kreis direkt an den Rand der Aktivität. Das signalisiert: "Solange diese Aufgabe läuft, höre ich auf dieses Signal."

Es gibt zwei Varianten, die du unterscheiden musst:

1. Interrupting (Unterbrechend)

Das unterbrechende Grenz-Ereignis hat einen durchgezogenen doppelten Rand. Wenn es eintritt, wird die aktuelle Aufgabe sofort abgebrochen. Der Token verlässt die Aktivität nicht über den normalen Ausgang, sondern springt über das Grenz-Ereignis auf einen Sonderpfad.

Beispiel: Während "Ware verpacken" trifft die Nachricht "Stornierung" ein. Wir hören sofort auf zu packen (Abbruch) und leiten den Prozess in den Pfad "Stornierung bearbeiten".

2. Non-Interrupting (Nicht-Unterbrechend)

Das nicht-unterbrechende Grenz-Ereignis hat einen gestrichelten doppelten Rand. Wenn es eintritt, läuft die eigentliche Aufgabe ganz normal weiter.

Zusätzlich wird aber ein neuer Token erzeugt, der den Sonderpfad startet. Wir machen also zwei Dinge gleichzeitig.

Beispiel: Während "Ware verpacken" trifft die Nachricht "Adressänderung" ein. Wir packen weiter (der Prozess wird nicht gestoppt), aber gleichzeitig starten wir den Task "Versandlabel aktualisieren".

Der BPMN-Standard kennt Dutzende von Event-Typen (Signal, Eskalation, Kompensation etc.). Aber für 90 % deiner täglichen Arbeit reichen drei Typen aus. Wenn du diese beherrschst, bist du bestens gerüstet.

1. Timer (Zeit)

Das Uhr-Symbol. Es ist der Meister der Zeitsteuerung.

• Als Start-Event: Löst Prozesse periodisch aus (z.B. "Jeden Montag").

• Als Zwischen-Ereignis: Dient als Wartezeit (z.B. "5 Tage warten").

• Als Grenz-Ereignis: Fungiert als Frist oder Timeout. Wenn die Aufgabe "Rechnung prüfen" zu lange dauert, feuert der Timer am Rand und eskaliert den Vorgang an den Chef .

2. Message (Nachricht)

Der Briefumschlag. Er regelt die Kommunikation mit der Außenwelt.

Wichtig: Eine "Message" in BPMN ist immer eine Kommunikation zwischen zwei unterschiedlichen Pools (z.B. Kunde und Firma). Innerhalb eines Pools nutzen wir keine Message Events, sondern Sequenzflüsse .

3. Error (Fehler)

Der Blitz. Er ist der Spezialist für technische oder fachliche Probleme.

Ein Error-Event wird fast immer als Grenz-Ereignis genutzt. Wenn in einem Subprozess etwas schiefgeht, "wirft" das Ende-Event einen Fehler, und das Grenz-Ereignis am Rand des Subprozesses "fängt" ihn auf, um eine Lösung einzuleiten .

Damit dein Diagramm nicht nur technisch korrekt, sondern auch verständlich ist, gibt es klare Regeln für die Beschriftung.

Ein Event ist kein Tun, sondern ein Zustand.

• Falsch: "Rechnung senden" (Das klingt nach einer Aktivität).

• Richtig: "Rechnung gesendet" (Zustand erreicht).

Nutze immer die Formel Objekt + Zustand (Partizip Perfekt).

• Statt "E-Mail empfangen" schreibe "E-Mail empfangen".

• Statt "5 Tage warten" schreibe "5 Tage vergangen".

Das macht beim Lesen sofort klar: Hier wird nicht gearbeitet, hier ist ein Meilenstein erreicht .

Events sind das Salz in der Suppe deiner Prozessmodelle. Sie verwandeln eine starre Aufgabenliste in einen lebendigen Ablauf, der auf Zeit, Nachrichten und Fehler reagieren kann.

Hier ist dein Merkzettel für die Praxis: