Auf der Suche nach dem korrekten BPMN-Diagramm

Bei dem vor einiger Zeit vorgestellten, fehlerhaften BPMN-Diagramm waren die Leser nicht nur aufgerufen, möglichst viele Fehler zu finden, sondern auch selbst ein verbessertes BPMN-Modell einzusenden. Drei Lösungsvorschläge sind eingegangen, die hier vorgestellt werden. Herzlichen Dank an Torben Schreiter (Vorschlag Nr. 1), Thomas Niebisch (Vorschlag Nr. 2) und Tobias Heubeck (Vorschlag Nr. 3)! Ausgehend von diesen drei Vorschlägen habe ich auch selbst einen Lösungsvorschlag erarbeitet, den ich auch noch etwas genauer erläutern möchte.

Hier erst einmal die drei eingereichten Vorschläge:

 Lösungsvorschlag Nr. 1:

BPMN-Suchbild Lösungsvorschlag 1

Lösungsvorschlag Nr. 2:

BPMN-Suchbild Lösungsvorschlag 2

Lösungsvorschlag Nr. 3:

BPMN-Suchbild Lösungsvorschlag Nr. 3

Die Vorschläge weisen durchaus einige Unterschiede auf – obwohl alle drei Modellierer offensichtlich einige Erfahrung mit der BPMN besitzen. Woran liegt dies? Ich denke, es sind wohl folgende drei Faktoren:

  • Zum einen sind in der BPMN so einige Feinheiten versteckt, weshalb manche Fragen erst bei genauem Durchlesen der Spezifikation genau geklärt werden können. Z. T. weisen auch verschiedene Modellierungstools einige Besonderheiten in ihrer Umsetzung der BPMN auf. Dieser Faktor trug in diesem Fall allerdings nur zu einem geringen Teil zu den beobachteten Unterschieden bei.
  • Zum Zweiten legt die BPMN zwar die Notation und ihre Bedeutung fest, liefert aber keine Modellierungskonventionen mit. Es gibt z. B. keine Empfehlung ob und wie eine Weiterleitung eines Antrags in einem Unternehmen modelliert werden soll. Solche Regeln muss jedes Modellierungsteam selbst aufstellen.
  • Zum Dritten gab es keine Erläuterungen und Zusatzinformationen zu dem Diagramm. Es musste also jeder Modellierer interpretieren, wie bestimmte fehlerhafte Teile des Diagramms eigentlich gemeint waren. Insbesondere Lösungsvorschlag Nr. 3 enthält einige inhaltliche Erweiterungsmöglichkeiten des Prozesses. Es zeigt sich wieder einmal, wie wichtig es ist, nicht nur Diagramme zu erstellen, sondern auch Beschreibungen zu den einzelnen Aktivitäten sowie Definitionen der verwendeten Begriffe.

Im Folgenden ein konsolidierter Vorschlag, den ich auch noch ein wenig erläutern werde (vgl. hierzu auch die Beschreibung der Fehler des ursprünglichen Diagramms):

BPMN-Suchbild Lösungsvorschlag Nr. 4

Zunächst die Pools und Bahnen: Da der Einkauf nicht zum Lieferanten gehört, kann man für ihn entweder in einen eigenen Pool modellieren (Vorschlag 1), oder man nimmt ihn mit in den Pool der Fachabteilung auf (Vorschlag 3). Version 1.1 der BPMN bietet die Möglichkeit verschachtelter Bahnen, die genutzt wurde, um die Fachabteilung zu untergliedern, die  gemeinsam mit dem Einkauf in einen Pool „Kunden“ gesetzt wurde.

Der Prozess beginnt links unten. Bei Vorschlag 1 ist die Darstellung vertikal gekippt, so dass man den Prozess entsprechend der gewohnten Leserichtung von links oben nach rechts unten verfolgen kann. Das ist eine gute Idee. Ich habe lediglich deswegen darauf verzichtet, weil der Vergleich mit dem ursprünglichen Modell einfacher ist.

Der Prozess wird durch Start-Ereignis „Bedarf aufgetreten“ ausgelöst. Anschließend verzweigt ein exklusiver Gateway zur Erfassung von Neubedarf bzw. zur Erfassung von Ersatzbedarf. In Vorschlag 1 wurden zwei unterschiedlich benannten Start-Ereignisse verwendet. Das ist prinzipiell möglich, kann aber bei der Verwendung einer Process Engine die Problematik aufwerfen, wie bei der Instanziierung des Prozesses das zutreffende Start-Ereignis identifiziert wird.

Ein leeres Rautensymbol für einen Gateway ist übrigens gleichbedeutend mit dem „X“ in der Raute, beide stehen für einen exklusiven Gateway („XOR“).

Anschließend wird der Antrag an den Abteilungsleiter gesendet. Hier stellt sich die Frage, ob das Weiterleiten und Empfangen expliziert modelliert werden soll. Das ist normalerweise nur sinnvoll, wenn diese Aktivitäten eine besondere Bedeutung haben und genauer untersucht werden sollen. Ansonsten blähen sie ein Modell unnötig auf. Daher wurde hier darauf verzichtet. Die Entscheidung über den Antrag wurde in allen Lösungsvorschlägen durch eine eigene Aktivität mit folgendem exklusiven Gateway modelliert. In jedem Fall führt die Ablehnung des Antrags zu einem End-Ereignis.

Wird der Antrag genehmigt, gibt der Einkauf die Bestellung auf. Der Bestellungsversand wird über einen Nachrichtenfluss modelliert. Dieser löst beim Lieferanten ein Nachrichten-empfangendes Start-Ereignis aus, worauf er prüft, ob das Produkt auf Lager ist. Ist es auf Lager wird es ausgelagert, ansonsten wird der Unterprozess ausgeführt. Selbstverständlich könnte man – wie in Vorschlag 2 und 3 – auch auf die Verwendung eines Unterprozesses verzichten und den Inhalt direkt in den Hauptprozess mit aufnehmen können.

Im Unterprozess wird das Produkt beim Hersteller nachbestellt. Geht die Ware ein, wird der Wareneingang erfasst. Ist nach drei Tagen noch keine Ware eingegangen, so wird beim Hersteller nachgefragt. Anschließend wird wieder auf den Wareneingang gewartet, ggf. nach drei Tagen erneut nachgefragt usw. Inhaltlich kann man sich an dieser Stelle die Frage stellen, was passiert, wenn der Hersteller trotz mehrfacher Nachfrage nicht liefert. Um ganz vollständig zu sein, müsste auch die Reaktion auf diesen Fall modelliert werden, worauf an dieser Stelle aber verzichtet wird.

Die Nachbestell-Thematik hat jeder Modellierer anders gelöst, wobei die Version mit dem zeitlichen Zwischenereignis am Rande der Aktivität „Produkt bei Hersteller nachbestellen“ in Vorschlag 2 nicht ganz optimal erscheint. Ein solches Ereignis am Rande einer Aktivität unterbricht eine Aktivität, in diesem Fall nach drei Tagen. Das würde bedeuten, dass die Aktivität „Produkt bei Hersteller nachbestellen“ auch das Warten auf das Eintreffen der Ware beinhaltet, was man intuitiv eher nicht vermuten würde.

In Vorschlag 3 wird nach dem Nachbestellen der Prozess bis zum Eintreffen des Zwischen-Ereignisses „Nach 3 Tagen“ unterbrochen, d. h. es wird einfach drei Tage gewartet, anschließend wird geprüft, ob die Ware eingetroffen ist. Allerdings bedeutet dies, dass ein früheres Eintreffen der Ware nicht direkt verarbeitet werden kann, weil man ja erst einmal abwartet, bis drei Tage vergangen sind.

Dieses Beispiel ist eigentlich ideal für den Einsatz des ereignis-basierten exklusiven Gateways, wie er in Vorschlag 1 verwendet wird. Hierbei wird darauf gewartet, welches Ereignis zuerst eintrifft: Der Ablauf von drei Tagen (in diesem Fall wird beim Hersteller nachgefragt und anschließend wiederum auf das erste eintreffende Ereignis gewartet), oder das Eintreffen der Ware, worauf der Wareneingang erfasst wird. Dieser Vorschlag wurde daher in das konsolidierte Modell übernommen, wobei das der BPMN 1.0 entstammende Symbol durch das geänderte Symbol der BPMN 1.1 ersetzt wurde.

Im Anschluss an den Unterprozess folgt ein Sequenz-Fluss zu einem exklusiven Gateway, der die alternativen Pfade über den Unterprozess bzw. über die Aktivität „Auslagern“ zusammenführt. Die Logik bzgl. der folgenden Aktivitäten wurde in den Vorschlägen unterschiedlich umgesetzt, was wohl hauptsächlich darauf zurückzuführen ist, dass aus dem Ursprungsdiagramm nicht eindeutig hervorging, was genau gemeint war. Im Folgenden wird davon ausgegangen, dass die Ware immer verpackt werden muss (es wurde in dem fehlerhaften Diagramm ja auch ein paralleler Gateway verwendet), das Versichern des Pakets bzw. das Bestellen eines Kuriers hingegen nur bei Bedarf erfolgen. Über den parallelen Gateway werden zwei parallele Sequenz-Flüsse gestartet: Einmal zur Aktivität „Verpacken“, das andere Mal zu einem inklusiven Gateway. Je nach Wunsch wird das Paket versichert und/oder ein Kurier bestellt. Es gibt aber auch die Möglichkeit, dass keines von beiden gewünscht wird. Hierfür dient der dritte, als Standard (Default) gekennzeichnete Sequenz-Fluss. Alle Sequenz-Flüsse werden über den folgenden inklusiven Gateway zusammengeführt, der immer auf so viele eingehende Aktivierungen wartet, wie erzeugt wurden.

Lösungsvorschlag 1 enthält eine interessante Alternative zur Modellierung der Verzweigungen: Anstatt zwei Gateways und einen leeren Standard-Sequenz-Fluss zu verwenden, wird dort einfach ein inklusiver Gateway gewählt, und als Bedingung beim Fluss zum Verpacken die Bedingung „Immer“ angegeben. Damit ist intuitiv klar, dass das Verpacken in jedem Fall durchgeführt wird, jede der beiden anderen Aktivitäten hingegen nur, wenn die zugehörige Bedingung zutrifft. Diese Variante hat den Vorteil, dass sie sehr übersichtlich und leicht verständlich ist.

Schließlich erfolgt das Versenden der Ware, bevor der Prozess auf Lieferanten-Seite durch das End-Ereignis abgeschlossen wird. Von dieser Aktivität geht ein Nachrichtenfluss zum Kunden. Dessen Prozess hat nach dem Aufgeben der Bestellung auf das Zwischen-Ereignis „Ware eingegangen“ gewartet. Ist es eingetroffen, so folgt das End-Ereignis „Beschaffung erfolgt“, womit auch der Kunden-seitige Prozess beendet ist.

Falls jetzt noch Fehler oder Unschönheiten enthalten sind, freue ich mich wieder über jeden Kommentar.

Und im nächsten Beitrag werden die Modellierer näher vorgestellt, die an dem Spiel teilgenommen und sich für die „Hall of Famous Modelers“ qualifiziert haben. Ich habe sie einmal über ihre Erfahrungen mit der BPMN befragt.

8 Gedanken zu „Auf der Suche nach dem korrekten BPMN-Diagramm“

  1. Ich finde das Fehlersuchspiel nach wie vor sehr interessant. Schade, dass sich nicht noch mehr Modellierer beteiligt haben!

    Zwei wirklich kleine Anmerkungen zum vorgestellten konsolidierten Diagramm hätte ich jedoch noch. Beide drehen sich um den Default Flow, der einmal im oberen und einmal im unteren Pool verwendet wurde.

    Beim unteren Default Flow macht es eigentlich keinen Sinn, noch zusätzlich eine Beschreibung an die Kante zu kleben („genehmigt“). Wenn ich mich nicht ganz irre, steht sogar irgendwo in der Spec, dass ein Default Flow keine Condition Expression haben kann.

    Zum oberen Default Flow am Inklusiv-OR-Gateway: Es gibt eine widersprüchliche Definition in der BPMN Spec bezüglich der Verwendbarkeit des Default Flows an Gateways. An einer Stelle heißt es:

    „A Sequence Flow that has an Exclusive Data-Based Gateway or an activity as its source can also be defined with a
    condition expression of Default.“

    An einer anderen:

    „For Data-Based Exclusive Decisions or
    Inclusive Decisions, one type of flow is
    the Default condition flow…“

    Das ist eine der vielen Stellen in der Spezifikation, die sehr fuzzy ist. Ich würde mich nicht aus dem Fenster lehnen und Default Flow für Inklusiv-OR-Gateways verbieten, weil es aus meiner Sicht durchaus Sinn machen kann. Dennoch könnte man die Spec so verstehen, wenn man wollte… 😉

    Gruß,
    Torben

  2. Das „genehmigt“ an dem Default-Fluss ist tatsächlich ein wenig überflüssig. Zwar könnte man argumentieren, dass es sich bei dem angezeigten Text nur um ein Label handelt (das laut Spezifikation alle möglichen Inhalte enthalten darf) und nicht um die Condition Expression (z. B. wird im Intalio Modeler die Condition Expression als Attribut angegeben, für die Grafik lässt sich aber ein beliebiger Text angeben), andererseits ist es tatsächlich nicht nötig. Eigentlich könnte man das „genehmigt“ oder die Default-Markierung weglassen.

    Beim zweiten Punkt ist die Spezifikation in der Tat inkonsistent. Auf S. 81 der Spezifikation ist explizit ein Beispiel eines inklusiven Gateways mit Default-Fluss abgebildet. Zudem kann man bei Flüssen aus Aktivitäten neben bedingten Flüssen ebenfalls einen Default-Fluss markieren. Und da dies laut Spezifikation äquivalent zur Verwendung eines inklusiven Gateways ist, ist es eigentlich nur folgerichtig, den Default auch beim inklusiven Gateway zu verwenden.

  3. Die verschiedenen vorgestellten Lösungen fand ich sehr interessant. Zur „Musterlösung“ hätte ich noch eine Anmerkung. Mir gefällt der Oder-Gateway nach der Aktivität „Verpacken“ nicht so richtig. Da der Fluss vor der Aktivitä durch ein AND Gateway in zwei parallele Pfade aufgespaltet wurde, bin ich der Meinung, dass zum Zusammenführen auch wieder ein AND-Gateway verwendet werden sollte. Der ODER-Gateway kann doch strenggenommen nur die Information aus den Pfaden nach dem ersten ODER Gateway haben und somit würde die Aktivität „Versenden“ zweimal ausgeführt, ausser man setzt die Kenntnis nichtlokaler Gegebenheiten im ODER Gateway voraus. Dies ist in meinen Augen im Lösungsbeispiel 1 besser gelöst.
    Viele Grüsse,
    Klaus

  4. Das würde bedeuten, man würde mit dem inklusiven Gateway nur die drei obersten Sequenz-Flüsse zusammenführen, um sie anschließend mittels eines weiteren parallelen Gateways mit dem unteren Sequenz-Fluss von „Verpacken“ zu vereinigen. Das wäre auf jeden Fall richtig und würde die Logik der öffnenden Gateways symmetrisch wiederspiegeln.

    Einmal unabhängig davon, welches die schönere und elegantere Lösung ist (da hat Lösungsbeispiel 1 wahrscheinlich die besten Karten): Ist die Zusammenführung nur durch einen einzelnen inklusiven Gateway möglich?

    Das setzt natürlich Voraus, dass der inklusive Gateway nichtlokales Wissen besitzt. Allerdings muss er dieses sowieso besitzen, denn auch wenn alle Pfade aus einem einzigen öffnenden inklusiven Gateway stammen, muss es ja wissen, welche dieser Pfade aktiviert wurde.

    Man könnte natürlich öffnenden und schließenden inklusiven Gateway als zusammengehöriges Paar betrachten, die voneinander wissen. Allerdings gibt es in der Spezifikation nirgends die Forderung, dass die Gateways paarweise verwendet werden müssen. Man kann beispielsweise auch Pfade, die durch bedingte Sequenz-Flüsse aus Aktivitäten entstanden sind, mit einem inklusiven Gateway zusammenführen.

    Auf S. 82 der Spezifikation heißt es: „Process flow SHALL continue when the signals (Tokens) arrive from all of the incoming Sequence Flow that
    are expecting a signal based on the upstream structure of the Process (e.g., an upstream Inclusive Decision).“ Der inklusive Gateway muss also in der Tat wissen, was im Laufe des Prozesses bereits passiert ist. Ein öffnendes inklusives Gateway wird nur als Beispiel genannt.

    Die vorgeschlagene Lösung sollte daher m. E. zumindest korrekt sein, wenn auch vielleicht nicht so schön wie andere Möglichkeiten.

  5. Aus meiner Sicht ist die Gateway-Konstruktion der „Musterlösung“ syntaktisch schon korrekt. Das OR-Gateway führt sämtliche zuvor aktivierten Stränge zusammen. Dabei ist es prinzipiell egal, durch welches oder wieviele Gateways diese aktiviert wurden…

    Dennoch schließe ich mich den bisherigen Kommentaren an, denn wirklich auf den ersten Blick verständlich ist diese Lösung nicht. Für weniger versierte BPMN-Anwender drängen sich so (unnötigerweise) neue Fragen auf.

    Die Frage ist immer, für wen man eigentlich modelliert. Oft muss man davon ausgehen, dass der Hauptadressat der Diagramme wenig bis keine Ahnung von BPMN hat. So weh es tut, ist unter Umständen bereits ein Event-based Gateway schwerer zu vermitteln als man denkt…

  6. Muss man in einem BPMN Diagramm nicht immer alle öffnenden (z. B.) parallelen Gateways auch wieder schließen, weil das Netz sonst nicht sound ist? Vgl. paralleles Gateway vor Aktivität „Verpacken“ beim „Lieferant“-Pool.

  7. Nicht unbedingt. Zum Beispiel können parallele Pfade auch jeweils in separaten Endereignissen enden.
    Im vorliegenden Beispiel führt der schließende inklusive Gateway den parallelen Pfad mit den anderen zusammen.

Kommentare sind geschlossen.