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:

Lösungsvorschlag Nr. 2:

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):

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.