Die Business Process Modeling Notation (BPMN) setzt sich immer weiter als Standardnotation für die Prozessmodellierung durch. Es müsste also schon eine ganze Reihe von BPMN-Modellierern geben. Für sie gibt es heute einen kleinen Wettbewerb.
Die Aufgabe: Finden Sie im folgenden BPMN-Diagramm möglichst viele Fehler!
Gesucht sind insbesondere Verstöße gegen die BPMN-Spezfikation, aber auch offensichtliche inhaltliche Fehler (wie z. B. wenn ein Brief erst verschickt und dann erst geschrieben wird …). Die Sinnhaftigkeit des Prozesses an sich steht weniger im Fokus, Sie können sich aber auch gerne darüber auslassen. Massgeblich ist die derzeit gültige Version 1.1, wie sie in der OMG-Spezifikation (http://www.omg.org/spec/BPMN/1.1/) definiert ist.
Verwenden Sie die Kommentarfunktion zu diesem Beitrag, um die gefundenen Fehler kund zu tun. Damit man die fehlerhaften Stellen leichter findet, ist das Diagramm mit einem Koordinatennetz überzogen. Sie sollten also jeweils angeben, in welchem Planquadrat sich der jeweilige Fehler befindet (z. B. D2).
Gewinner ist derjenige, der den letzten vorher nicht gemeldeten Fehler findet. Wer also einen Fehler meldet, der bisher noch nicht gemeldet wurde, führt damit automatisch in dem Spiel. Am besten, Sie melden also immer nur einen der von Ihnen gefundenen Fehler. Dann können Sie die folgenden Einsender wieder übertrumpfen. Der Gewinner erhält einen Ehrenplatz in der „Hall of Famous Modelers“ auf diesem Blog.
Ein weiterer Ehrenplatz ist übrigens für denjenigen reserviert, der das beste korrigierte Diagramm einsendet (am besten per Mail)!
Haben Sie Zweifel daran, dass es sich bei einem gemeldeten Fehler um einen Fehler handelt, tun Sie dies bitte ebenso kund – am besten mit einem Verweis auf die betreffende Stelle in der Spezifikation, an der das Thema geregelt ist. In Zweifelsfällen wird das Thema ausdiskutiert, und nur wenn das auch nichts bringt, entscheidet der Blog-Betreiber …
Und nun viel Spaß bei der Fehlersuche!
Nachbemerkung: Das Spiel ist zwischenzeitlich beendet. Die Auflösung finden Sie hier:
Liste aller Fehler
Verbesserte Diagramme
Und damit nochmal klar wird, wie es geht, hier gleich der erste Fehler:
In F4 befindet sich ein Zwischen-Ereignis (Intermediate Event) ohne ausgehenden Sequenzfluss. Dies ist nicht erlaubt.
Damit führe ich das Spiel momentan selbst an. Also melden Sie fleißig weitere Fehler!
In A6 befindet sich eine Funktion, die von keinem Ereignis ausgelöst wird. Soweit ich weiß ist dies solange zulässig, wie es kein anderes Startereignis im Prozess gibt. Stimmt das?
Stimmt. Da es eine Startereignis gibt, ist das in der Tat ein Fehler.
Ein korrigiertes BPD habe ich soeben per Email an Sie geschickt. Es bleibt die Hoffnung in der ”Hall of Famous Modelers” Erwähnung zu finden… 😉
Zusätzlich würde ich gerne noch auf ein Whitepaper hinweisen, welches die Unterschiede zwischen BPMN 1.0 zu 1.1 thematisiert und in diesem Zusammenhang unter Umständen hilfreich sein kann: http://www.inubit.com/bpmn
In B1 bzw. C1 fließt der conditional flow direkt in den Subprozess ein. Hier sollte ein Startereignis für den Subprozess vorhanden sein.
Beste Grüße
Einen will ich auch nennen:
In C6 haben wir ein AND Gateway, das ist syntaktisch zwar korrekt, aber inhaltlich (höchstwahrscheinlich) nicht so gewollt. Ein XOR Gateway dürfte angebrachter sein.
Wenn das nicht zählt, ein Syntaxfehler: Der Message Flow in D5 ist innerhalb eines Pools und deshalb dort falsch.
F3: Die Kommunikation zwischen Fachabteilung und Beschaffung sollte über einen MessageFlow stattfinden.
Prima, alles eindeutige Fehler.
Der Fehler in C6 ergibt sich zunächst inhaltlich, man wird entweder einen Ersatzbedarf oder einen Neubedarf melden, aber nicht beides.
Die syntaktische Korrektheit lässt sich wegen des Fehler in A6 nicht eindeutig entscheiden. Hätte man in A6 nämlich auch ein Startereignis verwendet, dann würde dies den Prozess alleine starten, ohne dass das Startereignis in A5 ebenfalls ausgelöst wird. Dann wäre das parallele Gateway auch syntaktisch falsch.
Hätte man den Fehler in A6 hingegen dadurch gelöst, dass man auch auf das Ereignis in A5 verzichtet hätte, dann würden hingegen beim Start des Prozesses alle Tasks ohne eingehenden Sequenz-Fluss gleichzeitig gestartet, dann wäre das parallele Gateway zumindest syntaktisch korrekt (auch wenn die Parallelität inhaltlich immer noch Quatsch ist).
Vielen Dank auch für das korrigierte Diagramm. Ich denke, wir warten noch ein wenig mit der Veröffentlichung, denn es gibt noch viele weitere Fehler. Vielleicht gibt es ja auch noch andere Vorschläge für ein korrigiertes Diagramm.
Im Moment führt Florian L. Also, suchen Sie weiter!
Na gut, dann will ich auch mal:
– Das Gateway in B2 hat zwei ausgehende Seq-Flows, der obere darf keinen Conditional-Marker haben denn an Gateways wird nur der Default-Marker dargestellt.
Gruß
Frank
Vielen Dank an Frank T. Er hatte ursprünglich gleich mehrere Fehler gemeldet, mich dann aber – um anderen den Spaß nicht zu verderben – gebeten, den Kommentar zu löschen. Ich habe jetzt einfach mal den ersten Fehler stehen lassen. Ich hoffe, das ist so okay.
Damit ist Frank jetzt vorne.
Der intermediate timer event in C1 darf nicht 2 ausgehende sequence flows haben. Der sequence flow sollte vielmehr in einen XOR gateway gehen…etc.
Stichwort: Default flow
In E2 hat der parallel gateway einen solchen, was aber keinen Sinn macht. Und in E4 hat der XOR gateway 2 solche default flows, was auch nicht sein kann.
Auch erscheint die Modellierung in A6-B6 zweifelhaft. Wozu ausser ‚Einsatzbedarf erfassen‘ noch ‚Einsatzbedarf erfasst‘? Soll da ein Event mittels einer Aktivität abgebildet werden?
Das korrigierte Bild ging per Email raus; ich hoffe, es ist fehlerfrei 😉
Neben den bereits erwähnten Fehlern sind mir noch schätzungsweise 9-10 (vermeintliche) Fehler aufgefallen.
Nr.1: in H6 sollte ein Endereignis (kein Zwischenereignis) stehen.
Wie lange geht eigentlich der Wettbewerb?
Ich möchte nicht noch einen Fehler lieferen, sondern gerne noch einmal die Aussage in 8 aufgreifen. Die Frage der syntaktischen Korrektheit ist etwas, was aus meiner Sicht oft zu kurz kommt. Es ist aus meiner Sicht schade, dass hier die Toolhersteller nicht mehr Unterstützung bieten. Was ich häufiger schon gesehen habe ist, dass Sub-Prozesse modelliert wurden, in denen eine klare Ja/Nein Entscheidung getroffen wird. D.h. das Diagramm im Sub-Prozess endet mit zwei unterschiedlichen Ereignissen. Im zugehörigen übergeordneten Diagramm geht jedoch nur ein direkter Kontrollfluss weiter. Hier würde ich nach dem Sub-Prozess einen Gateway erwarten, da die unterschiedlichen Ereigisse aus dem Sub-Prozess auch unterschiedlich behandelt werden.
Mich würde interessieren, was Sie dazu meinen, dass solche syntaktischen Probleme stärker kontrolliert würden. Mit so einer Prüfung würde sicher auch auf einige der bereits gefundenen Fehler aufmerksam gemacht (z.B. Kontrollfluss über Pools hinweg, Message Fluss in Lanes, …).
Ja, das wäre mit Sicherheit sinnvoll, dass Modellierungstools syntaktische Fehler vermeiden helfen. Grafik-orientierte Tools wie Visio sind dazu nicht in der Lage, und auch Modellierungswerkzeuge, die viele Notationen unterstützen, wie etwa ARIS, bieten meist keine direkte Unterstützung bei der Einhaltung spezifischer BPMN-Syntax-Regeln. Man könnte diese ggf. mit speziellen Skripten überprüfen, die man über ein Modell darüber laufen lässt.
Am Weitesten geht die Unterstützung meines Erachtens bei BPMS-Modellierungskomponenten, die eng mit der Process Engine gekoppelt sind. Diese helfen Prozesse so zu modellieren, dass sie durch die spezifische Engine ausgeführt werden können. Die überprüften Regeln stimmen dabei aber nicht unbedingt exakt mit der BPMN-Spezifikation überein. So kann die Engine bestimmte Modellierungsmuster erwarten oder Dinge ausschließen, die gemäß Spezifikation möglich wären. So verhindert etwa Intalio, dass man eine Schleife mit Hilfe eines zurückgeführten Sequenzflusses modelliert, man muss zwingend einen Unterprozess vom Typ Schleife verwenden.
Hinzu kommt, dass die BPMN-Spezifikation nicht alles regelt, was vielleicht sinnvoll wäre. Gerade zu dem genannten Beispiel mit den alternativen End-Ereignissen in einem Sub-Prozess, die anschließend durch ein exklusives Gateway zu unterschiedlichen Pfaden führen sollten, habe ich in der Spezifikation beispielsweise nichts gefunden.
Will man die Einhaltung einer solchen – sicherlich sinnvolle – Regel sicherstellen, so muss das betreffende Tool die Möglichkeit bieten, Überprüfungen für die Einhaltung individueller Modellierungskonventionen zu definieren. Wobei etwa die Überprüfung der o.g. Regel nicht ganz trivial ist, so dass man hierfür eine Programmierschnittstelle benötigt. Oder vielleicht könnte man eine Regel-Engine einsetzen.
Die anderen genannten Beispiele wie Sequenzflüsse über Pools hinweg u.ä. könnten aber durch ein Modellierungstool von vornherein überprüft werden.
Wer kennt Tools, die eine gute BPMN-Syntaxüberprüfung anbieten – und vielleicht auch noch individuelle Modellierungsregeln überprüfen können?
@Thomas N:
„Nr.1: in H6 sollte ein Endereignis (kein Zwischenereignis) stehen.“
Das Ereignis in H6 ist in der Tat ganz schlimm, es ist auch nicht mit dem restlichen Prozess im gleichen Pool verbunden.
Würde es sich bei dem eingehenden Fluss von der der Aktivität „Versenden“ um einen Nachrichten-Fluss handeln (da ein Pool-übergreifender Sequenz-Fluss nicht erlaubt ist), dürfte es sich nicht um ein End-Ereignis handeln, da ein solches keine Nachricht empfangen kann. Stattdessen müsste auf das Zwischenereignis, das einen eingehenden Sequenz-Fluss aus dem gleichen Pool haben müsste, ein ausgehender Sequenz-Fluss mit einem End-Ereignis folgen.
Noch einer:
Der punktierte Kasten im unteren Pool soll wahrscheinlich einen Sub-Prozess beschreiben?
Er hat allerdings das optische Erscheinungsbild eines Groupings (welches zwar ein gültiges BPMN Artefakt ist, allerdings keinen eingehenden Sequence-Flow haben darf)
Gruß
Frank
Ja genau, eine Gruppierung ist eine rein optische Umrandung eines Modellausschnitts. Der Sequenz-Fluss kann daher nicht zur Gruppierung führen.
Das Spielchen läuft jetzt seit gut zwei Wochen. Ich denke, wir schließen es Ende dieser Woche ab. Sagen wir mal, Freitag 24 Uhr.
Anschließend stelle ich nochmal alle gefundenen Fehler zusammen. Weiterhin werden die eingesandten verbesserten Diagramme veröffentlicht.
Und es wird verkündet, wer in die Hall of Fame einzieht!
Hatten wir schon A2? Mitten im Prozess ein Start-Event, auch noch durch einen Message Flow initiiert
Leider komme ich heute erst dazu, Spiel und Zuschriften zu lesen. Etwas erstaunt: es gibt ein sehr gutes Werkzeug zur Modellierung, das ich seit 2006 verwende und das meine Anfängerfehler jedenfalls alle gefunden hat und die BPMN Version 1.1 wohl vollständig abbildet. Es bietet außerdem Checks für die Erzeugung von Files für BPEL und XPDL. „Process Modeler 5“ von http://www.itp-commerce.com in Bern. Das Werkzeug bietet auch optionale Referenzprozesse (ITIL, BASEL2). Falsch ist, daß nur die mit einer Execution Engine verbundenen Werkzeuge Checks anbieten – man sollte das auch getrennt halten, denn die Ausführung benötigt eigene Prüfungen. Für den PM5 als Modellierungswerkzeug gibt es optionale Anpassungen an BizTalk und Oracle, es gab eine an Carnot.
Ein Problem bleibt: das äußerst geringe Interesse an BPMN in Deutschland – das ist in den USA, England und Japan (!) anders.
Mit freundlichem Gruß
Rüdiger Molle
Es wäre sicherlich interessant, das fehlerhafte Modell einmal mit Process Modeler oder einem anderen Tool zu überprüfen. Wahrscheinlich würde man einen großen Teil der Fehler gar nicht erst begehen können, weil direkt bei der Eingabe eine Syntax-Überprüfung stattfindet.