Best Practice: BPMN Modellierungsbeispiel mit Gateways
Viele Weg führen nach Rom. Die einen sind länger, die anderen kürzer. Die einen schneller, die anderen langsamer.
In diesem Fall ist das Ergebnis übersichtlicher, weil am Ende weniger grafische Elemente genutzt werden. Ich möchte dieses Mal ein Beispiel vorstellen, bei dem das digitale Denken zu sequentiellen Entscheidungen zu einzelnen Frage hin zu einer gleichzeitigen Entscheidung aller Fragen kommt. Mit digital meine ich die typische “0″ und “1″ stehend für wahr oder falsch, wie sie in unseren Computergehirnen erfolgen. Im den folgenden Bild sind es die Punkte im Prozessdiagramm, in denen exklusive Gateways mit nur 2 Ausgängen enthalten sind:
Die Modellierung in diesem Fall hat eine wichtige Spielregel in Hinsicht auf die Möglichkeiten des SAPERION Workflow berücksichtig: das UND und ODER Gateway muss im Gegensatz zum XOR Gateway immer im Pärchen auftreten, so dass die parallel ablaufenden Zweige entsprechend aufgelöst werden können.
Eine Alternative der Modellierung nutzt ein ODER Gateway-Pärchen, so dass die Anzahl der Gateways am Anfang und Ende von vier auf eins reduziert werden kann. Damit wird das Modell übersichtlicher, da es nun insgesamt zehn Gateways weniger zu betrachten gibt:
Die Bedingungen für die Entscheidung, welcher Zweig durchlaufen wird, stehen sprachlich auf den ausgehenden Sequenzflüssen des ODER-Split-Gateways. Die Formeln, die die Process Engine auswertet, sind als Attribute zusätzlich enthalten, in der Grafik nur nicht visualisiert.
—-
Und dann noch etwas für die SAPERION Workflow Community. In der Grafik oben sieht man auf dem von den Benutzer-Tasks ausgehenden Sequenzflüssen zu den Nachfolgenden Nachrichtenzwischenereignissen den Text “z.K. Verteiler”. Dieser Text steht auch im Attribut “Protokolleintrag” und steht damit automatisch dem Anwender als weitere Information, in diesem folgenden Anwendungsfall als Kontext (Spalte in der Aufgabeliste) zur Verfügung:
Und wenn das Nachrichtenereignis im Sinne einer zur Kenntnisnahme quittiert wurde (Kontextmenü “löschen”), dann steht in der Prozesshistorie ein entsprechender Eintrag:
Die Historie zeigt den Durchlauf zu dem oben gezeigten Prozessdiagramm. Es wurde nicht zitlich sortiert, daher bitte auf die Zeiten achten. Die Einträge sind wie folgt zu lesen:
Eingang bedeutet, dass die Aufgabe oder Nachricht beim Anwender eingegangen ist und Ausgang, dass sie verlassen wurde und es im Prozess weiterging. In jeder Zeile des Prozesses hat der Empfänger eine Aktion auf der entsprechenden Aufgabe ausgeführt.
1 Comment »
RSS feed for comments on this post. TrackBack URL





Hallo Bernhard,
wie immer wird Aristoteles Recht haben: die Wahrheit liegt meist in der Mitte.
Ja, obiges Beispiel mag von ungeübteren leichter gelesen werden, schreckt aber auch genauso ab, da der erste Eindruck groß wirkt. Vielleicht sollte man Tools entwickeln, die ein Umschalten der Sichten ermöglicht :-)
LG Martin