Über die BPMN wird im kommunalen Umfeld in letzter Zeit viel gesprochen. Manches davon stimmt sogar, vieles aber auch nicht. Um der Wahrheit auf den Grund zu gehen, gibt es aber nicht nur einen Lichtblick, es gibt einen strahlenden Sonnenschein der Erleuchtung: Die Spezifikation der BPMN. Die von der Object Management Group herausgegebene Spezifikation der BPMN – und nur sie – definiert Syntax und Semantik der BPMN! Wozu dann noch ein Wissen und Werkzeug Prinzip? Antworten gibt dieser Artikel.
Ich habe im letzten Artikel bereits erwähnt, dass die BPMN sehr komplex sein kann und eine umfangreiche Symbolpalette mitbringt. Als wäre das nicht schon genug, lässt der strahlende Sonnenschein der Erleuchtung (die Spezifikation) auch noch die Möglichkeit, den gleichen Sachverhalt auf unterschiedliche Art und Weise zu modellieren. Um den Einstieg in die BPMN zu erleichtern und gleiche Sachverhalte möglichst gleich zu modellieren, habe ich das Wissen und Werkzeug Prinzip entwickelt.
Der Grundsatz: Artikel 1 des Wissen und Werkzeug Prinzips
Die Spezifikation der BPMN ist unantastbar! Ich gebe zu: Es ist etwas hochtrabend und überspitzt formuliert, aber als Grundsatz gilt: Alle Regeln halten sich streng an die Spezifikation. Nach dem Wissen und Werkzeug Prinzip erstellte Prozessmodelle sind demnach 100% mit der Spezifikation konform! Daraus ergibt sich, dass die Bedeutung der Symbole nicht angetastet wird. Ich beschränke lediglich den Umfang der Symbole und mache einen Vorschlag, wie bestimmte Sachverhalte modelliert werden sollten.
Zwei Level der Modellierung
Was die Einschränkung der Symbolpalette betrifft, streiche ich natürlich keine Symbole. Vielmehr führe ich zwei Level der Modellierung ein. Das Basis-Level, mit allen Symbolen, die für eine fachliche Modellierung benötig werden, und das Experten-Level, das alle zur Verfügung stehenden Symbole beinhaltet. Die BPMN selbst sieht eine Dreiteilung in eine beschreibende Ebene (Descriptive), eine analytische (Analytic) und eine ausführbare Ebene (Common Executable) vor. Hierbei wird aber eine stark technische Sicht eingenommen und die Einteilung richtet sich hauptsächlich an Softwarehersteller. Mir war es wichtig ein Prinzip zu schaffen, mit dem sowohl in der Organisation, in der Fachabteilung als auch in der IT Modelle erstellt werden können, die leicht zu erstellen und für alle verständlich sind. Dazu musste ich einen Ausgleich zwischen Komplexität, Präzision und Verständnis des Modells finden. Ob mir dies gelungen ist, beurteilen Sie am besten selbst.
Die Münze
Die formale Korrektheit eines BPMN-Diagramms lässt sich am besten mit Hilfe einer Münze (im Englischen: Token) überprüfen. Stellen Sie sich vor, jede Prozessinstanz (z. B. ein Antrag) erzeugt eine Münze, die durch den Prozess wandert. Sequenzflüsse, Verzweigungen, Ereignisse etc. sagen der Münze was sie zu tun hat und wie sie weiter-wandert. In Seminaren mache ich eine Übung, in der ich die Teilnehmenden mit einer Münze Modellierungsfehler im Prozess suchen lasse. Der Erkenntnisgewinn dieser einfachen Methode ist nicht zu unterschätzen. Die Spezifikation selbst, wie auch der überwiegende Teil der BPMN-Literatur, verwendet dieses Verfahren. Die genaue Funktionsweise erläutere ich am folgenden Beispiel.
Beispiel Exklusive-Verzweigung
Damit sich jeder vorstellen kann, was ich meine, wenn ich sage, dass der gleiche Sachverhalt auf unterschiedliche Weise modelliert werden kann, möchte ich ein Beispiel anführen. So lässt sich eine Exklusive-Verzweigung auf folgende Arten darstellen.
Wobei hier schon der Teufel im Detail steckt. Im vorliegenden Beispiel haben alle drei Modelle tatsächlich die gleiche Bedeutung, da sich die Bedingungen ausschließen, was sie beim linken und mittigen Beispiel auch müssen, sonst läge ein Modellierungsfehler vor. Die bedingten Sequenzflüsse (rechts) könnten allerdings auch für die Modellierung einer Inklusiven-Verzweigung stehen. Ein Detail, das sich nicht intuitiv erschließt, weshalb bedingte Sequenzflüsse im Wissen und Werkzeug Prinzip keine Verwendung finden. Das linke und mittige Beispiel unterscheiden sich aber tatsächlich nur in der Darstellung, da die BPMN zwei Symbole für die Exklusive-Verzweigung kennt.
Was würde die Münze hier tun? Trifft die Münze auf eine Exklusive-Verzweigung (links + Mitte), so muss sie sich für genau einen Weg entscheiden. Könnte Sie sich für zwei Wege gleichzeitig entscheiden (z. B. Beträge überschneiden sich), läge ein Modellierungsfehler vor. Im rechten Beispiel wäre eine Überschneidung aus formaler Sicht allerdings kein Modellierungsfehler. Die Münze würde sich teilen und beide Wege gehen. Solche Feinheiten sind eher etwas für Modellierungsexperten und führen im Alltag in der Zusammenarbeit mit den Fachämtern nur zu Verwirrung. Ein simples Beispiel für die Sinnhaftigkeit einer Konvention wie sie das Wissen und Werkzeug Prinzip darstellt.
Ausblick auf die Reihe zur BPMN
Damit ist der Grundstein gelegt. Alle Vorgaben und Empfehlungen meines Prinzips entsprechen der Spezifikation der BPMN. Zudem führe ich zwei Level der Modellierung mit unterschiedlichen Symbolumfängen ein, damit auf dem Basis-Level eine einfache, verständliche und leicht zu erlernende fachliche Modellierung möglich ist und dem Experten auf dem Experten-Level alle Möglichkeiten der BPMN zur Verfügung stehen.
Im weiteren Verlauf der Reihe werde ich zunächst den grundsätzlichen Aufbau der BPMN erläutern, um im Anschluss die Symbolpalette des Basislevels vorzustellen. Dabei werde ich die Bedeutung und den korrekten Einsatz jedes einzelnen Symbols erläutern und mit Beispielen unterfüttern.
Sollten Sie es jetzt nicht mehr erwarten können, die Symbolpalette des Basis-Levels kennen lernen zu wollen, so empfehle ich das Abonnement meines Newsletters. Auf der Bestätigungsseite ist ein Link hinterlegt. Sollten Sie schon Abonnent sein, so finden Sie den Link im aktuellen Newsletter.
