So, unser kleines Spielchen ist beendet. Es galt, die zahlreichen Fehler zu finden, die in dem nebenstehenden BPMN-Diagramm enthalten sind. Herzlichen Dank für die rege Teilnahme! Wie versprochen werden die Verfasser der besten Beiträge in die Hall of Fame der Modellierung aufgenommen. Hierfür gibt es nächste Woche noch einen eigenen Beitrag, in dem diese ausgewiesenen BPMN-Modellierungsexperten vorgestellt werden. Es wurden auch zwei verbesserte Diagramme eingereicht, die ebenfalls nächste Woche präsentiert werden sollen.
Heute erst einmal die – hoffentlich – komplette Fehlerliste. Das Diagramm ist mit einem Koordinatensystem hinterlegt. Zu jedem Fehler wird das Planquadrat angegeben, damit man ihn leichter findet. Zunächst eimal geht es um die Gesamtstruktur des Modells, anschließend bewegen wir uns von links unten entlang dem Sequenz- und Nachrichtenfluss.
- Spalte A: Die Aufteilung des Diagramms in Pools und Bahnen ist inhaltlich höchst fragwürdig. Dass sich der Einkauf (typischerweise eine Organisationseinheit des bestellenden Unternehmens) zusammen mit dem Lieferanten in einem gemeinsamen Pool „Beschaffung“ befindet, würde bedeuten, dass sie über einen gemeinsamen, zentral gesteuerten Prozess verfügen. Einkauf und Lieferant müssten in getrennten Pools sein.
- A6: Wenn es ein Start-Ereignis in einem Prozess gibt, darf es nicht gleichzeitig eine Aktivität ohne Start-Ereignis geben. Es fehlt also ein Start-Ereignis vor „Einsatzbedarf erfassen“. Wobei zwei unbestimmte Start-Ereignisse auch nicht so richtig empfehlenswert sind. Besser wäre ein Start-Ereignis mit einem folgenden exklusiven Gateway, der zwischen Neubedarf und Ersatzbedarf unterscheidet.
- B6: „Ersatzbedarf erfasst“ ist vom Namen her keine Aktivität, sondern ein Ereignis. Dieses müsste hier aber nicht gesondert modelliert werden.
- C6: Der parallele Gateway ist inhaltlich falsch, da es sich bei „Neubedarf erfassen“ und „Ersatzbedarf erfassen“ wohl eher um alternative Aktivitäten handelt. Ob es sich auch um einen syntaktischen Fehler handelt, kann wegen des Fehlers in A6 nicht ganz eindeutig entschieden werden. Würde man nämlich einfach das Start-Ereignis in A5 weglassen, so würden die beiden Aktivitäten „Neubedarf erfassen“ und „Ersatzbedarf erfassen“ tatsächlich parallel ausgeführt. Das wäre zwar unsinnig, aber syntaktisch richtig. Würde man stattdessen – wie oben empfohlen – ein Startereignis mit exklusivem Gateway verwenden, so wäre der parallele Gateway auch syntaktisch falsch.
- C5: Der Kasten mit der Punkt-Strich-Begrenzung ist eine Gruppierung, kein Unterprozess. Eine Gruppierung ist eine rein optische Zusammenfassung, ein Sequenzfluss kann nicht an einer Gruppierung enden. Entsprechend ist das Start-Ereignis in D6 auch unsinnig. Richtig wären der Sequenz-Fluss und das Start-Ereignis, wenn man einen Unterprozess anstelle einer Gruppierung modelliert hätte. Dieser hat einen durchgezogenen Rand.
- D6/D5: Der Nachrichtenfluss verläuft innerhalb eines Pools, dies ist nicht möglich.
- E4: Ein Gateway enthält in der BPMN keinen Text. Der Text „Über Beschaffungsantrag entscheiden“ beschreibt eine Tätigkeit. Ein Gateway stellt aber keine Tätigkeit dar, sondern reine Logik. „Über Beschaffungsantrag entscheiden“ müsste als Aktivität modelliert werden.
- E4/F4: Der Gateway enthält zwei Standard (Default)-Ausgänge. Es darf aber nur einen geben.
- F4: Der Sequenz-Fluss endet in einem Zwischen-Ereignis. Dies ist nicht möglich, es müsste ein End-Ereignis verwendet werden.
- E4: Der Sequenz-Fluss überquert Pool-Grenzen. Dies ist nicht möglich, zwischen Pools können nur Nachrichten-Flüsse verlaufen.
- F3-A2: Bei der gepunkteten Linie handelt es sich um keinen Fluss, sondern um eine Assoziation. Diese wird verwendet, um die Erzeugung von Daten-Objekten zu modellieren, kann aber nicht zwischen Aktivitäten und Ereignissen verlaufen.
- A2: Es gibt kein Nachrichten-sendendes Start-Ereignis (mit dem ausgefüllten Briefumschlag).
- B2: Bei einem Gateway wird keine Bedingungsraute an den ausgehenden Sequenz-Flüssen dargestellt. Diese wird nur bei Sequenz-Flüssen verwendet, die aus einer Aktivität herausgehen.
- B1: Ein Sequenz-Fluss kann keine Unterprozess-Grenzen überqueren.
- C1: Hier ist inhaltlich Unsinniges modelliert: Dre Tage nach der Nachbestellung wird der Wareneingang erfasst – ob die Ware nun da ist, oder nicht…
- C1: Aus einem Zwischen-Ereignis dürfen keine zwei Sequenz-Flüsse herausgehen.
- D1: Noch ein inhaltliches Problem: Auf die Nachfrage beim Hersteller folgt nichts mehr, weder erneute Nachfragen, noch ein Wareneingang.
- E1: Der Unterprozess hat keinen ausgehenden Sequenz-Fluss zum weiteren Ablauf. Dies ist inhaltlich nicht sinnvoll. Außerdem müsste zumindest ein End-Ereignis folgen. Da in dem Prozess noch weitere End-Ereignisse verwendet werden, kann der Unterprozess kein implizites End-Ereignis haben.
- F2: Ein paralleler Gateway kann keinen Standard (Default)-Ausgang haben, da ja alle Ausgänge parallel mit Marken belegt werden.
- E2: Ebenso ist es sinnlos, an einem Sequenz-Fluss, der aus einem parallelen Gateway herausgeht, eine Bedingung anzugeben.
- F1: An den aus dem inklusiven Gateway herausgehenden Sequenz-Flüssen sind keine Bedingungen angegeben. Streng genommen ist das aber kein Fehler, da die Bedingungen nicht unbedingt im Diagramm dargestellt werden müssen. Sie könnten auch in Attributen der Sequenz-Flüsse hinterlegt sein. Da hier aber nur die Grafik vorliegt, wäre dies recht nutzlos.
- G2: Der parallele Gateway ist falsch. Da die oberen beiden Sequenz-Flüsse einem inklusiven Gateway entstammen, ist nicht sichergestellt, dass immer Marken über alle drei Sequenz-Flüsse eingehen. Es entsteht eine Blockade.
- H3-H6: Hier ist wieder ein Sequenz-Fluss über Pool-Grenzen hinweg gezeichnet, was nicht erlaubt ist.
- H6: Das Zwischenereignis ist nicht mit dem vorangehenden Prozess im Pool verbunden. Außerdem hat es keinen ausgehenden Sequenz-Fluss.
Ein weiteres Problem, das bemängelt wurde, war die fehlende Markierung des Unterprozesses (mittels eines kleinen Kästchens mit einem Minus), der in B1 beginnt. Allerdings schreibt die BPMN-Spezifikation eine solche Markierung eines aufgeklappten Unterprozesses nicht vor.
Auch der fehlende Name des Unterprozesses wurde als Schönheitsfehler benannt.
Ich denke, das waren alle. Gratuliere, es wurden von den Teilnehmern praktisch alle Fehler gefunden. Zwei haben mir parallel zum Spiel weitgehend komplette Fehlerlisten geschickt.
Im nächsten Beitrag werden die Vorschläge für verbesserte Diagramme vorgestellt.
Eine kleine Berichtigung zum Fehler in E4: Text innerhalb eines Gateway-Symbols scheint doch möglich zu sein, jedenfalls wird diese Darstellung an einigen Stellen in der BPMN-Spezifikation benutzt.
Das ist aber unabhängig von der Tatsache, dass hier inhaltlich eine Aktivität verwendet werden müsste.
Allein die Komplexität des Diagramms die Vielfältigkeit seiner Interpretation, die Unfähigkeit Prozesse in dieser Form weder zu analysieren noch auszuführen, zeigt was für ein gedanklicher Kurzschluss hinter Flussdiagrammen steckt.
BPMN definiert nicht das einzig notwendige DIE ZIELE! Weiters gibt es keine Definition von Daten, die Rollen, die Regeln, die Dokumenteninhalte und deren Datenvernetzung, ist nicht direkt in Prozesse übersetzbar, wenn überhaupt dann in so etwas wie BPEL mit Java, und ist damit reine Programmierarbeit.
Nur eine freie Kollaboration mit den fachlichen Prozesselementen die durch die Benutzerrollen und wenige Geschäftsregeln geordnet wird ist überhaupt sinnvoll und wirtschaftlich ausführbar.
Wann hört denn diese illusionäre BPM Wahn endlich auf???
In der Tat enthalten BPMN-Diagramme mit ihrem Fokus auf den Kontrollfluss nur einen kleinen Ausschnitt aller relevanten Sachverhalte, wie Ziele, Organisation, Daten, Regeln usw. Für eine Modellierung auf fachlicher Ebene wird zudem nur ein relativ kleiner Ausschnitt aus der BPMN benötigt.
Die spezielleren Konstrukte sind eher im Rahmen einer Workflow-Spezifikation einsetzbar, wobei auch hier wiederum Rollen, Daten, User Interface etc. zu ergänzen sind.
Die derzeit häufig anzutreffende ausschließliche Konzentration auf die reine Kontrollflussmodellierung ist wesentlich zu kurz gegriffen.