In der heutigen Geschäftswelt ist es von entscheidender Bedeutung, Geschäftsprozesse effektiv und effizient zu gestalten und kontinuierlich zu verbessern. Um dieses Ziel zu erreichen, nutzen Unternehmen oft Modellierungssprachen wie die Business Process Model and Notation (BPMN). BPMN ist eine standardisierte und visuelle Sprache, die es ermöglicht, Geschäftsprozesse zu dokumentieren und zu kommunizieren.
Eine der mächtigsten Funktionen in der BPMN ist die Verwendung von Signalereignissen. Signalereignisse dienen dazu, außerplanmäßige Ereignisse in einem Geschäftsprozess zu erkennen und entsprechend zu reagieren. Sie können als “Weckruf” betrachtet werden, der einen Prozessschritt ausführt, wenn ein bestimmtes Ereignis eintritt. Diese Signalereignisse eröffnen Unternehmen neue Möglichkeiten, ihre Prozesse zu optimieren und auf unvorhergesehene Situationen zu reagieren.
In diesem Blogbeitrag werde ich mich eingehend mit Signalereignissen in der BPMN beschäftigen und ihre verschiedenen Anwendungsmöglichkeiten erkunden. Ich möchte untersuchen, wie Signalereignisse in der Praxis eingesetzt werden können, um komplexe Workflows zu steuern und auf Ereignisse zu reagieren, die den normalen Fluss eines Prozesses unterbrechen.
Inhaltsverzeichnis
- Signal-Endereignis
- Signal-Startereignis
- Signal-Zwischenereignis
- Angeheftete Signal-Zwischenereignisse und die Kombination mit ereignisbasierten Unterprozessen
- Fazit
Signalereignisse gibt es in allen Varianten, die die BPMN anbietet: als Start-, Zwischen- und Endereignis. Signalereignisse werden in der BPMN grundsätzlich verwendet, um die Kommunikation zwischen Prozessen oder innerhalb von Prozessen zu ermöglichen, indem sie den Austausch von Informationen oder Signalen zwischen den beteiligten Elementen ermöglichen. Sie dienen dazu, den Prozessfluss abhängig von (meist) externen Signalen zu steuern und ermöglichen eine flexible Reaktion. Die Besonderheit des Signalereignisses besteht darin, dass zwischen Sender und Empfänger keine direkte Verbindung besteht. Jede Stelle im Prozess oder auch in einem anderen Prozess kann das Signal auffangen. Damit wird eine lose Kopplung im Sinne eines publish-subscribe-Musters realisiert.
Die wenigsten Anwender der BPMN möchten wirklich die offizielle Spezifikation der BPMN studieren. Diese ist unter https://www.omg.org/spec/BPMN kostenfrei verfügbar. Diese „Spec“ ist vorrangig für Werkzeughersteller wichtig, die sich an dem offiziellen Standard orientieren sollten. Wenn wir gleichwohl einen kurzen Blick in das Dokument werfen, finden wir auf S. 261f einen tabellarischen Überblick über alle Ereignisse, die die BPMN anbietet. Nicht alle sind im Alltag eines Modellierenden wichtig. Wie Abbildung 1 zeigt, gibt es das Signalereignis, wie sonst nur noch zwei andere Ereignisse, in allen möglichen Varianten:
Die Anwendung der sogenannten Ereignis-Unterprozesse (Event Sub-Processes) thematisieren wir in diesem Beitrag nur kurz. Ereignis-Unterprozesse erleichtern typischerweise die Modellierung, in dem der typische Ablauf (happy path) insofern entschlackt wird, als dass die Reaktion auf Fehler- und Ausnahmefälle separat als Unterprozess dargestellt werden kann. Alternativ können angeheftete (Zwischen-)Ereignisse (Boundary Events) genutzt werden.
1. Signal-Endereignis
Am Anfang steht das Ende, zumindest in diesem Blogbeitrag: Beginnen wir mit dem Signal-Endereignis. Ein Endereignis stellt das fachliche Ergebnis eines Geschäftsprozesses dar und sollte daher auch eine passende Benennung haben.
Abbildung 2 zeigt ein vereinfachtes Prozessmodell, das mit dem Bedarf zur Besetzung einer freien Position im Unternehmen beginnt. Auf die Platzierung einer Stellenanzeige erfolgt die Auswahl der geeigneten Person. Das Ergebnis des Prozesses mit einem betriebswirtschaftlichen Wert ist die Einstellung eines neuen Mitarbeiters.
Für die Einstellung eines Mitarbeitenden und dem praktischen Arbeitsbeginn sind üblicherweise weitere Aspekte zu erledigen, wie beispielsweise die Bereitstellung der Zugänge zu den IT-Systemen des Unternehmens oder die Beschaffung der Geschäftsausstattung (Notebook etc.).
Daher wird im Beispiel ein Signalendereignis verwendet: Das Symbol für das Signal, ein Dreieck, ist dabei ausgefüllt dargestellt. Ausgefüllte Elemente bedeuten in der BPMN generell ein Senden, bzw. das Werfen eines Ereignisses. Auf dieses Werfen kann dann an anderer Stelle reagiert werden.
2. Signal-Startereignis
Im Beispiel können also andere, sich fachlich anschließende Geschäftsprozesse, mit einem korrespondierenden Startereignis ausgestattet werden. Erweitern wir das fachliche Szenario: Wenn eine neue Mitarbeiterin eingestellt wurde, wird die IT-Abteilung informiert, die sich dann um die Einrichtung der Benutzerzugänge (E-Mail, SAP-System, etc.) kümmert und die Neueingestellte über die relevanten IT-Richtlinien informiert. Außerdem wird sich die Fachabteilung in einem separaten Prozess um das Büro und die Geschäftsausstattung kümmern.
Für beide bzw. beliebig viele Prozesse, die über eine Neueinstellung informiert werden, wird ein Signalstartereignis eingerichtet. Abbildung 3 zeigt vereinfachte Prozesse. Das nicht-ausgefüllte Signal-Symbol (Dreieck) bedeutet, dass es ein empfangendes Ereignis ist. Die Verbindung zum Signal werfenden, oder im Sinne einer Signalpistole abfeuernden Prozesses wird über die identische Benennung des Ereignisses hergestellt, das den Start des Signalstartereignisses auslöst.
3. Signal-Zwischenereignis
Ein Signalereignis kann auch innerhalb eines Prozesses verwendet werden. Abbildung 4 zeigt ein Beispiel, in dem verschiedene Signalereignisse kombiniert werden. Die Farbgebung der Ereignisse zeigt die Zusammenhänge zwischen werfendem und den auffangenden Ereignissen; ansonsten hat die Farbgebung in der BPMN keine semantische Bedeutung. Es wird deutlich, dass eine ggf. mehrfache Interaktion zwischen den Prozessinstanzen möglich ist.
Nachdem ein Bewerber ausgewählt wurde (grünes, werfendes Signalzwischenereignis), startet der neue Prozess – in der Abbildung unten dargestellt. Sofern schlussendlich die Vertragsverhandlung scheitert, wird der Prozess mit einem entsprechenden Signalendereignis „Vertragsverhandlung gescheitert“ beendet. Der im oberen Bereich dargestellte Prozess wartet mithilfe eines ereignisgesteuerten Gateways auf ein Signal. Im Falle einer gescheiterten Vertragsverhandlung muss ein Bewerbender ausgewählt werden, mit dem erneute Vertragsverhandlungen aufgenommen werden. Verläuft die Vertragsverhandlung positiv, so wird dies über das werfende Signalzwischenereignis „Einstellung positiv verlaufen“ zurückgemeldet und die Bewerberauswahl erfolgreich abgeschlossen. Zusätzlich und guter Modellierungsstil ist es außerdem, ein ereignisgesteuertes Gateway in Verbindung mit einem Zeitzwischenereignis zu verwenden, um ein „Steckenbleiben“ beim Prozessablauf zu verhindern.
4. Angeheftete Signal-Zwischenereignisse und die Kombination mit ereignisbasierten Unterprozessen
Für fortgeschrittene Modellierende möchte ich noch weiteres Beispiel für den Einsatz von Signal-Ereignisse darstellen. Abbildung 5 zeigt einen Geschäftsprozess, der immer dann ausgeführt wird, wenn ein Projekt durchgeführt werden soll und ein Projektauftrag vorliegt. Nach der Initialisierung des Projektes wird fortlaufend und „parallel“ das Projekt selbst bearbeitet und ergänzend ein Projektcontrolling durchgeführt. Sobald die eigentliche Projektarbeit beendet ist, wird ein Signal „Projektarbeit beendet“ geworfen. Dieses wird im angehefteten, abbrechenden Zwischenereignis bei der Aktivität „Projektcontrolling durchführen“ aufgefangen. Außerdem wird das Signal „Projektarbeit beendet“ von einem sogenannten ereignis-basierten Unterprozess aufgefangen. Diese soll sich vereinfacht um die organisationsinterne Vermarktung der Projektergebnisse kümmern.
5. Fazit
Wie im Blogbeitrag zu sehen ist, sind die Anwendungsmöglichkeiten des Signalereignisses vielfältig. Es ermöglicht eine lose Kopplung verschiedener Prozesse oder Prozessbestandteile in einer schlanken und eleganten Form. Dem Einsteiger in die BPMN-Modellierung empfehle ich, sich zunächst die Möglichkeiten der Start- und Endereignisse zu konzentrieren und nach und nach das weitere Spektrum zu erkunden. Wie immer in der Modellierung kommt es aber nicht darauf an, möglichst viele verschiedene BPMN-Elemente zu nutzen. Vielmehr sollte die Lesbarkeit und Verständlichkeit oberste Priorität haben.
Möchten Sie mehr zum Thema Benennung von Prozessen erfahren? Dann lesen Sie auch den Blogbeitrag “Wie Aktivitäten in BPMN richtig benannt werden”.
Bitte beachten Sie:
Die oben aufgeführten Signalereignisse finden Sie nicht alle in Ihrem roXtra – doch das bedeutet nicht, dass Sie dort diese Prozesse nicht abbilden können! Wie so oft gilt auch hier: Viele Wege führen nach Rom. Bei Fragen zur Prozessmodellierung in Ihrem roXtra wenden Sie sich bitte an den Support von Roxtra: Kontaktieren Sie uns per Email an service@roxtra.com oder telefonisch unter +49 (0)7161 50570-0.
