BPMN 2.0 – Symbole & Begriffe

Ein Start-Event markiert den Auslöser und den Beginn eines Prozesses in BPMN 2.0. Es wird als dünner Kreis dargestellt und besitzt keinen eingehenden Sequenzfluss. Jeder Prozesspfad beginnt an genau einem Start-Event; Varianten wie das Nachrichten-, Zeit- oder Signal-Start-Event geben den konkreten Auslöser an. Das Start-Event beschreibt, dass und wodurch ein Prozess beginnt – nicht, was fachlich zu tun ist.

Ein End-Event markiert das Ende eines Prozesspfads in BPMN 2.0 und wird als Kreis mit dicker Linie dargestellt. Es besitzt keinen ausgehenden Sequenzfluss. Ein Prozess kann mehrere End-Events haben; Varianten wie das Nachrichten-, Fehler- oder Terminierungs-End-Event geben an, was beim Ende ausgelöst wird. Das End-Event zeigt, dass ein Pfad endet, und optional mit welchem Ergebnis.

Ein Zwischenereignis tritt während des Prozessverlaufs ein – zwischen Start und Ende – und wird als Kreis mit doppelter Linie dargestellt. Es kann eintretend (catching) auf ein Ereignis warten oder werfend (throwing) eines auslösen. Am Rand einer Aktivität platziert (Boundary Event) unterbricht es diese oder reagiert begleitend. Es strukturiert den Ablauf anhand von Ereignissen, ohne selbst eine Aufgabe zu sein.

Ein Nachrichten-Event sendet oder empfängt eine Nachricht zwischen Prozessbeteiligten (Pools) und trägt ein Briefumschlag-Symbol. Als eintretendes Event wartet es auf den Eingang einer Nachricht, als werfendes versendet es eine. Es ist der typische Auslöser für Kommunikation über Prozessgrenzen hinweg. Es modelliert, was ausgetauscht wird, nicht den technischen Transportweg.

Ein Timer-Event reagiert auf einen Zeitpunkt, eine Dauer oder einen Zyklus und trägt ein Uhr-Symbol. Als Start-Event startet es einen Prozess zeitgesteuert, als Zwischen- oder Boundary-Event verzögert es oder löst nach Ablauf einer Frist aus. Es ist immer eintretend (catching). Es beschreibt die zeitliche Bedingung, unter der der Prozess fortfährt.

Ein Fehler-Event signalisiert einen fachlichen Fehler (Error) und trägt ein Zickzack-Symbol. Als werfendes End-Event beendet es einen Teilprozess mit Fehler; als eintretendes Boundary-Event am Rand einer Aktivität fängt es den Fehler und leitet in einen Ausnahmepfad. Fehler-Events unterbrechen die normale Ausführung immer. Sie trennen den Gutfall vom Fehlerfall.

Ein Signal-Event sendet oder empfängt ein Signal und trägt ein Dreieck-Symbol. Anders als die gerichtete Nachricht wird ein Signal broadcastartig ausgestrahlt und kann von beliebig vielen Empfängern aufgefangen werden. Es eignet sich zur Koordination mehrerer Prozesse auf ein gemeinsames Ereignis. Es modelliert eine 1:n-Benachrichtigung ohne festen Adressaten.

Ein Bedingungs-Event (Conditional) löst aus, sobald eine definierte Bedingung wahr wird, und trägt ein Listen-Symbol. Als Start-Event startet es den Prozess bei Eintreten der Bedingung, als Zwischen- oder Boundary-Event wartet es darauf. Es ist immer eintretend. Es beschreibt eine datengetriebene Auslösebedingung, nicht die Prüfung selbst.

Ein Eskalations-Event meldet eine Eskalation an eine übergeordnete Ebene und trägt ein nach oben offenes Pfeil-Symbol. Anders als der Fehler muss eine Eskalation den (Teil-)Prozess nicht zwingend abbrechen – ein nicht-unterbrechendes Boundary-Event lässt die Aktivität weiterlaufen. Es modelliert das Hochreichen einer Situation zur Entscheidung oder Information.

Ein Kompensations-Event stößt die Rückabwicklung bereits abgeschlossener Aktivitäten an und trägt ein Rücklauf-Symbol (zwei Dreiecke). Es gleicht nach einem Abbruch die bisherigen Wirkungen aus – etwa eine Buchung zu stornieren. Kompensation greift nur auf erfolgreich beendete Aktivitäten. Es beschreibt das Zurücknehmen von Ergebnissen, nicht das normale Weitergehen.

Ein Abbruch-Event (Cancel) gehört zu einer Transaktion und trägt ein Kreuz-Symbol. Als werfendes End-Event bricht es die Transaktion ab, als Boundary-Event fängt es den Abbruch und löst die Kompensation der Transaktion aus. Es ist ausschließlich im Kontext von Transaktions-Subprozessen gültig. Es signalisiert, dass eine zusammenhängende Einheit nicht gültig abgeschlossen werden konnte.

Ein Link-Event verbindet zwei Stellen desselben Prozesses, ohne eine durchgezogene Sequenzfluss-Linie zu zeichnen, und trägt ein Pfeil-Symbol. Ein werfendes Link-Event (Quelle) und ein gleichnamiges eintretendes (Ziel) bilden ein Paar. Es hält große oder über Seiten verteilte Diagramme lesbar. Es ist eine reine Darstellungs-Brücke, kein fachliches Ereignis.

Ein Terminierungs-Event (Terminate) beendet sofort den gesamten Prozess bzw. Teilprozess und trägt einen ausgefüllten Kreis. Anders als das normale End-Event stoppt es auch alle noch laufenden parallelen Pfade – ohne Kompensation. Es ist immer ein werfendes End-Event. Es erzwingt das harte, vollständige Ende einer Prozessinstanz.

Ein User Task ist eine Aktivität, die ein Mensch mit Unterstützung eines IT-Systems erledigt – etwa eine Freigabe in einem Workflow-Tool. In BPMN 2.0 wird er als abgerundetes Rechteck mit einem Personen-Symbol oben links dargestellt. Er grenzt sich vom vollautomatischen Service Task und vom rein manuellen Manual Task (ohne System) ab. Der User Task sagt aus, wer (eine Person) die Aufgabe womit (systemgestützt) ausführt.

Ein Service Task ist eine Aktivität, die automatisch durch ein System oder einen Dienst ausgeführt wird – ohne menschliches Zutun – und trägt ein Zahnrad-Symbol. Typische Beispiele sind ein Webservice-Aufruf oder eine automatische Berechnung. Er grenzt sich vom User Task (Mensch mit System) und vom Script Task (engine-interne Skriptausführung) ab. Er sagt aus, dass die Aufgabe vollautomatisch erledigt wird.

Ein Script Task wird von der Process Engine durch Ausführung eines hinterlegten Skripts erledigt und trägt ein Dokument-Symbol. Das Skript (z. B. in Groovy oder JavaScript) läuft direkt in der Engine, ohne externen Dienst. Er unterscheidet sich vom Service Task, der einen externen Dienst aufruft. Er beschreibt eine engine-interne automatische Verarbeitung.

Ein Manual Task ist eine Aufgabe, die ein Mensch ohne Unterstützung eines IT-Systems ausführt – etwa ein Paket physisch verpacken – und trägt ein Hand-Symbol. Die Process Engine steuert oder überwacht ihn nicht. Er grenzt sich vom User Task ab, der systemgestützt erfolgt. Er dokumentiert rein manuelle, nicht automatisierbare Tätigkeiten.

Ein Business Rule Task ruft eine Geschäftsregel oder Entscheidungslogik auf – häufig eine DMN-Entscheidungstabelle – und trägt ein Tabellen-Symbol. Er liefert aus Eingabedaten ein regelbasiertes Ergebnis zurück, etwa eine Bonitätseinstufung. So bleibt die Entscheidungslogik vom Prozessfluss getrennt und zentral pflegbar. Er steht für die Auswertung von Regeln, nicht für deren Umsetzung.

Ein Sende-Task (Send Task) versendet eine Nachricht an einen anderen Prozessbeteiligten und trägt ein ausgefülltes Briefumschlag-Symbol. Er gilt als abgeschlossen, sobald die Nachricht gesendet wurde. Funktional ähnelt er dem werfenden Nachrichten-Zwischenereignis, ist aber eine vollwertige Aktivität. Er beschreibt das aktive Versenden einer Nachricht als Arbeitsschritt.

Ein Empfangs-Task (Receive Task) wartet auf den Eingang einer Nachricht und trägt ein offenes Briefumschlag-Symbol. Erst mit Eintreffen der Nachricht gilt er als abgeschlossen und der Prozess läuft weiter. Er entspricht fachlich dem eintretenden Nachrichten-Zwischenereignis. Er modelliert das aktive Warten auf und Entgegennehmen einer Nachricht.

Ein Subprozess fasst mehrere Aktivitäten zu einem übergeordneten Schritt zusammen und wird als abgerundetes Rechteck mit einem [+]-Zeichen dargestellt (eingeklappt). Aufgeklappt zeigt er seinen inneren Ablauf im selben Diagramm. Er strukturiert komplexe Prozesse hierarchisch und erhöht die Lesbarkeit. Er bündelt Detail, ohne den Hauptfluss zu überladen.

Ein Ereignis-Subprozess (Event Sub-Process) liegt innerhalb eines Prozesses und wird durch ein Start-Event ausgelöst – dargestellt als gepunktet umrandetes Rechteck. Er hat keinen eingehenden Sequenzfluss und startet nur, wenn sein auslösendes Ereignis eintritt (z. B. ein Fehler oder Timer). Je nach Start-Event unterbricht er den umgebenden Prozess oder läuft parallel. Er kapselt ereignisgetriebene Ausnahme- oder Begleitlogik.

Eine Aufruf-Aktivität (Call Activity) ruft einen global definierten, wiederverwendbaren Prozess auf und wird mit dickem Rand dargestellt. Anders als der eingebettete Subprozess verweist sie auf eine externe, an mehreren Stellen nutzbare Prozessdefinition. Das vermeidet Redundanz und hält gemeinsame Abläufe zentral. Sie steht für Wiederverwendung eines eigenständigen Prozesses.

Eine Transaktion ist ein spezieller Subprozess mit doppelter Umrandung, dessen Aktivitäten nur gemeinsam gültig abgeschlossen werden (alles-oder-nichts). Scheitert sie, wird über ein Abbruch-Event die Kompensation der bereits erledigten Schritte ausgelöst. Typisch für Buchungs- oder Zahlungsvorgänge mit Rücknahmebedarf. Sie bündelt Schritte zu einer konsistenten Einheit.

Die Schleife (Loop) ist eine Aktivitäts-Markierung (Rücklaufpfeil unten) und bedeutet, dass eine Aktivität wiederholt ausgeführt wird, solange eine Bedingung gilt. Die Wiederholungen laufen nacheinander. Sie unterscheidet sich von der Mehrfachinstanz, die eine Aktivität je Datenobjekt vervielfacht. Sie beschreibt das wiederholte Durchlaufen desselben Schritts.

Die Mehrfachinstanz (Multi-Instance) ist eine Aktivitäts-Markierung (drei Striche) und bedeutet, dass eine Aktivität mehrfach ausgeführt wird – je Element einer Menge, etwa je Bestellposition. Die Instanzen laufen parallel (drei senkrechte Striche) oder sequenziell (drei waagerechte). Sie grenzt sich von der bedingungsgesteuerten Schleife ab. Sie steht für n-fache Ausführung über eine Datenmenge.

Ein Ad-hoc-Subprozess (Tilde-Symbol ~) enthält Aktivitäten ohne festgelegte Reihenfolge, die je nach Situation einmal, mehrfach oder gar nicht ausgeführt werden. Die Beteiligten entscheiden zur Laufzeit über den Ablauf. Typisch für wissensintensive, schwer vorab strukturierbare Arbeit. Er modelliert unstrukturierte Tätigkeiten innerhalb eines Prozesses.

Das exklusive Gateway (XOR) verzweigt einen Prozess in mehrere, sich gegenseitig ausschließende Pfade – abhängig von einer Bedingung wird genau ein Pfad gewählt. Dargestellt wird es als Raute, optional mit einem „X" in der Mitte. Als zusammenführendes Gateway wartet es nicht, sondern leitet jeden eintreffenden Pfad einzeln weiter. Es modelliert eine Entweder-oder-Entscheidung – im Gegensatz zum parallelen (AND) und zum inklusiven (OR) Gateway.

Das parallele Gateway (AND) trennt den Fluss in mehrere Pfade, die gleichzeitig ausgeführt werden, und wird als Raute mit Plus-Zeichen dargestellt. Als zusammenführendes Gateway wartet es, bis alle eingehenden Pfade angekommen sind (Synchronisation). Bedingungen spielen keine Rolle – es werden immer alle Pfade aktiviert. Es modelliert echte Nebenläufigkeit.

Das inklusive Gateway (OR) aktiviert einen oder mehrere Pfade, deren Bedingung zutrifft, und wird als Raute mit Kreis dargestellt. Beim Zusammenführen wartet es auf genau jene Pfade, die zuvor aktiviert wurden. Es verbindet die Flexibilität des XOR mit der Parallelität des AND. Es modelliert eine Und/Oder-Verzweigung.

Das ereignisbasierte Gateway entscheidet den weiteren Weg nicht anhand von Daten, sondern danach, welches Ereignis zuerst eintritt – dargestellt als Raute mit Fünfeck im Kreis. Nach dem Gateway folgen mehrere Ereignisse (z. B. Nachricht oder Timer); der zuerst eintretende Pfad gewinnt. Typisch für „Antwort oder Timeout". Es modelliert eine ereignisgetriebene Entscheidung.

Das komplexe Gateway steuert Verzweigung oder Zusammenführung über eine frei formulierte Bedingung, die sich mit XOR, AND und OR nicht ausdrücken lässt – dargestellt als Raute mit Stern. Beispiel: „weiter, sobald 2 von 3 Pfaden eingetroffen sind". Wegen der schwer lesbaren Semantik sollte es sparsam eingesetzt werden. Es ist der Sonderfall für komplexe Synchronisationsregeln.

Ein Pool repräsentiert einen eigenständigen Prozessbeteiligten – ein Unternehmen, eine Organisation oder eine Rolle – und bildet den äußeren Rahmen eines Prozesses. Zwischen Pools wird ausschließlich über Nachrichtenflüsse kommuniziert, nicht über Sequenzflüsse. Ein Diagramm kann mehrere Pools enthalten (Kollaboration). Der Pool beantwortet die Frage wer den Prozess ausführt.

Eine Lane (Bahn) ist eine Unterteilung innerhalb eines Pools und ordnet Aktivitäten einer Rolle, Abteilung oder einem System zu. Sequenzflüsse dürfen Lanes überqueren – anders als Pool-Grenzen. Lanes gliedern die Verantwortlichkeiten innerhalb eines Beteiligten. Sie beantworten die Frage, wer im Beteiligten welchen Schritt verantwortet.

Ein Black-Box-Pool ist ein Pool ohne sichtbaren inneren Ablauf – meist ein externer Partner, dessen interne Schritte unbekannt oder irrelevant sind. Mit ihm wird nur über Nachrichtenflüsse kommuniziert. Er hält das Diagramm auf die eigene Prozesssicht fokussiert. Er steht für einen Beteiligten, dessen Innenleben bewusst verborgen bleibt.

Ein Datenobjekt (Data Object) stellt Informationen dar, die eine Aktivität benötigt oder erzeugt – etwa ein Dokument oder einen Datensatz – und wird als Blatt mit umgeknickter Ecke gezeichnet. Es ist über Assoziationen mit Aktivitäten verbunden und beeinflusst den Sequenzfluss nicht. Ein Zustand (z. B. „genehmigt") kann ergänzt werden. Es zeigt, womit im Prozess gearbeitet wird.

Ein Datenspeicher (Data Store) steht für eine dauerhafte Ablage, aus der gelesen oder in die geschrieben wird – etwa eine Datenbank oder ein Archiv – dargestellt als Zylinder. Anders als das flüchtige Datenobjekt überdauert er die einzelne Prozessinstanz. Er wird über Assoziationen mit Aktivitäten verbunden. Er zeigt den persistenten Datenbestand des Prozesses.

Eine Dateneingabe (Data Input) ist eine Information, die ein Prozess oder eine Aktivität zu Beginn benötigt, dargestellt als Datenobjekt mit offenem (nicht gefülltem) Pfeil. Sie beschreibt die erwarteten Eingangsdaten auf Prozessebene. Gemeinsam mit der Datenausgabe dokumentiert sie die Datenschnittstelle. Sie zeigt, was hineingegeben werden muss.

Eine Datenausgabe (Data Output) ist eine Information, die ein Prozess oder eine Aktivität als Ergebnis liefert, dargestellt als Datenobjekt mit ausgefülltem Pfeil. Sie beschreibt die produzierten Ausgangsdaten auf Prozessebene. Zusammen mit der Dateneingabe bildet sie die Datenschnittstelle. Sie zeigt, was herauskommt.

Eine Nachricht (Message) ist der Inhalt, der zwischen zwei Prozessbeteiligten über einen Nachrichtenfluss ausgetauscht wird – dargestellt als Briefumschlag. Ein unausgefüllter Umschlag steht für eine empfangene, ein ausgefüllter für eine gesendete Nachricht. Sie fließt stets zwischen Pools, nie innerhalb eines Pools. Sie zeigt, welche Information die Grenze überquert.

Ein Sequenzfluss (Sequence Flow) verbindet Elemente innerhalb eines Pools und legt die Reihenfolge der Ausführung fest – dargestellt als durchgezogener Pfeil mit gefüllter Spitze. Er darf keine Pool-Grenze überschreiten. Er ist das Rückgrat des Kontrollflusses. Er zeigt, in welcher Reihenfolge die Schritte ablaufen.

Ein Nachrichtenfluss (Message Flow) stellt den Nachrichtenaustausch zwischen zwei Pools dar – dargestellt als gestrichelte Linie mit offenem Kreis am Start und offener Pfeilspitze. Er verbindet nie Elemente innerhalb desselben Pools. Er macht die Kommunikation über Organisationsgrenzen sichtbar. Er zeigt, wer wem was schickt.

Eine Assoziation (Association) verknüpft Artefakte wie Datenobjekte oder Textannotationen mit Flussobjekten – dargestellt als gepunktete Linie. Sie überträgt keine Steuerung und beeinflusst den Ablauf nicht. Mit Pfeilspitze zeigt sie die Richtung eines Datenflusses an. Sie dient der Zuordnung von Zusatzinformationen.

Ein Standardfluss (Default Flow) ist der ausgehende Pfad eines Gateways oder einer Aktivität, der genommen wird, wenn keine andere Bedingung zutrifft – markiert durch einen kleinen Querstrich am Linienanfang. Er stellt sicher, dass immer ein Weg offen bleibt. Typisch als „sonst"-Zweig eines XOR-Gateways. Er ist die Rückfalloption einer Verzweigung.

Ein bedingter Sequenzfluss (Conditional Flow) trägt eine Bedingung, die erfüllt sein muss, damit der Pfad genommen wird – markiert durch eine kleine Raute am Linienanfang. Er geht direkt von einer Aktivität aus (nicht von einem Gateway). Nur bei wahrer Bedingung wird er aktiviert. Er verlagert eine einfache Entscheidung direkt an die Flusslinie.

Eine Gruppe (Group) umrahmt zusammengehörige Elemente mit einer gestrichelten, abgerundeten Linie – rein visuell zur Hervorhebung. Sie kann Pool- und Lane-Grenzen überspannen und beeinflusst den Ablauf nicht. Häufig markiert sie eine Phase oder einen thematischen Block. Sie dient allein der optischen Zusammenfassung.

Eine Textannotation (Text Annotation) fügt einem Diagramm erläuternden Klartext hinzu – dargestellt als offene eckige Klammer mit Text. Sie wird über eine Assoziation mit dem erklärten Element verbunden und hat keine Auswirkung auf die Ausführung. Sie erhöht die Verständlichkeit für Leser. Sie ist ein reiner Kommentar im Modell.