BPMN-3.26.0: BPMN Elemente einschränken

Der BPMN 2.0 Standard bietet durch eine große Menge an verfügbaren Prozesselementen eine Vielzahl an Möglichkeiten zur Prozessmodellierung. Für neue, aber auch für geübte Leser:innen und Nutzer:innen kann dies manchmal zu mehr Fragezeichen als Klarheit führen und so dem Ziel von BPMN entgegenstehen: Intuitive Prozessmodellierung ohne große Einstiegshürden von hoher Qualität. Des Weiteren streben Organisationen, Bereiche oder Teams oftmals einen möglichst einheitlichen Modellierungs-Stil an. So sollen zum Beispiel gewisse BPMN Elemente nicht genutzt werden, da sie möglicherweise in dem gegebenen Kontext die Lesbarkeit und Verständlichkeit des Modells mindern. Das Release 3.26.0 des BPMN Modeler Enterprise Server setzt genau hier an: Es ist nun möglich, auf Bereichsebene einzelne BPMN Elemente oder ganze Gruppen von Elementen auszuschalten. Diese stehen dann beim Modellieren nicht zur Verfügung.

Anwendungsbeispiel: Stolperfalle Bedingter Fluss

Ein alltäglich in Modellen genutzter Aspekt des BPMN Standards ist die Möglichkeit, Prozessabläufe zu modellieren, die unter gewissen Bedingungen durchlaufen werden. In der folgenden Abbildung sehen wir so eine Bedingung. Nachdem in der rot gefärbten Aktivität eine Rechnung erstellt wurde, muss sie an den Empfänger gesendet werden. Der obere Fluss drückt hierbei aus, dass der Kunde Empfänger ist während der untere Fluss durchlaufen wird, falls die Versicherung Empfänger ist.

In der Abbildung wurde beim Modellieren auf das BPMN Element „Bedingter Fluss" zurückgegriffen. Flusselemente zur Fallunterscheidung zu nutzen und nicht Gateways scheint zunächst eine gute Idee zu sein, da das Modell klein und vermeintlich leicht verständlich bleibt. Tatsächlich birgt der bedingte Fluss ein paar Stolperfallen, die wir anhand von drei Fragen illustrieren wollen.

Können sowohl Kunde als auch Versicherung die Rechnung erhalten?

Die Erfahrung zeigt, dass der bedingte Fluss oftmals als exklusiv gelesen wird. Tatsächlich aber ist er gleichbedeutend mit einem OR-Split. Sind also beide Bedingungen erfüllt, so werden auch beide Flusselemente durchlaufen. In unserem Beispiel ist aber gemeint, dass entweder der Kunde oder aber die Versicherung die Rechnung erhält. Da sich die Bedingungen nicht offensichtlich ausschließen ist es also empfehlenswert, hier auf ein XOR-Gateway zurückzugreifen.

Was passiert, wenn wir zwischen den Versicherungspartnern unterscheiden müssen?

Gerne würden wir dann zunächst entscheiden, ob Kunde oder Versicherung Empfänger ist, um in einem nächsten Schritt weitere Bedingungen zu prüfen um zwischen Versicherungspartnern zu unterscheiden. Flusselemente unterstützen aber keine kaskadierenden Bedingungen. Auch deshalb sollten wir also an dieser Stelle auf ein Gateway zurückgreifen.

Wie werden die nächsten Schritte durchlaufen?

Nehmen wir an, es gibt mehrere Empfänger:innen und nach dem Versand der Rechnung folgt eine weitere Aktivität. Als Ergebnis der vorangegangenen Modellierung wird diese Aktivität mehrmals und eventuell asynchron ausgeführt, da beide Sequenzen getrennt voneinander in die Aktivität fließen. Dieses Problem ergibt sich aus dem Zusammenführen von Flusselementen direkt in eine Aktivität. Dies ist nämlich äquivalent zu einem XOR-Join. Eine Synchronisation und eine Verschmelzung der eintreffenden Tokens wie beim OR-Join ist mit Flusselementen nicht möglich.

Nach gemeinsamer Überlegung entscheidet sich das Team, welches an diesem und weiteren Modellen in einem Confluence-Bereich arbeitet, also dafür, in Zukunft auf bedingte Flüsse zu verzichten und auf Gateways zurückzugreifen. Dies kann nun direkt im BPMN Modeler Enterprise umgesetzt werden.

Die Lösung

In den Bereichseinstellungen zum BPMN Modeler, welche zum Beispiel über die Seitenleiste des entsprechenden Bereichs erreicht werden kann, findet sich nun der Reiter "BPMN Elemente".

Hier lassen sich einzelne BPMN Elemente sowie ganze Gruppen von Elementen aus- und wieder einstellen. Diese stehen dann in dem entsprechenden Bereich im BPMN Modeler nicht mehr zur Verfügung. Der Bereichsadministrator unseres Beispielteams schaltet nun also den bedingten Fluss aus und speichert.

Zurück im BPMN Modeler lässt sich der Effekt sofort erkennen: Das BPMN Elemente "Bedingter Fluss" ist nicht mehr verfügbar.

Die Modelliererin des vorliegenden Diagrammes entscheidet sich also den Prozess mittels Gateways darzustellen. Die Vereinbarung, die das Team getroffen hat, wurde einfach und effektiv umgesetzt.

Ihre Modellierungs-Etiquette

Probieren Sie es selber aus und schalten Sie ungewünschte BPMN Elemente beim Modellieren direkt in Confluence einfach aus: Mit dem BPMN Modeler Enterprise.

Sie nutzen den BPMN Modeler Enterprise noch nicht und haben Fragen? Melden Sie sich gerne bei uns!