Verfeinerung von Prozessmodellen
Damit die Prozesslandschaft eines Unternehmens in beherrschbaren Modellen abgebildet werden kann, werden diese gern mit einer “Hierarchie” ausgestattet: Weiter oben befinden sich die Hauptprozesse (auch Oberprozesse o.ä. genannt), und die darin enthaltenen Teilprozesse werden dann in den unteren Ebenen verfeinert modelliert.
Dieser Ansatz wird auch gern propagiert, wenn es um die Überführung fachlicher Prozessmodelle in technische Prozessmodelle geht, die im Idealfall durch eine Process Engine ausgeführt werden können.
Dummerweise klappt das häufig nicht – eine Erkenntnis, die anscheinend in der akademischen Welt längst angekommen ist, von Praktikern aber sehr häufig noch nicht verstanden wird. Vielleicht helfen zwei einfache Beispiele.


1. Beispiel: Derselbe Prozess, unterschiedliche Präzisierungen
“Wenn eine Bestellung reinkommt, wird diese geprüft, und der Auftrag wird bestätigt” – Aus dieser kurzen und wunderbar einfachen Beschreibung ergibt sich ein ebenso einfaches Prozessmodell. Und im Rahmen einer High-Level-Betrachtung ist es auch völlig unerheblich, auf welchen Wegen eine Bestellung eingehen kann. Ebenso ist es nicht weiter wichtig, dass ein Auftrag prinzipiell auch abgelehnt werden kann, oder dass die Bestellprüfung fehlschagen oder zuviel Zeit in Anspruch nehmen kann. Es geht lediglich um eine grobe Vorstellung des regulären Ablaufs. Das und nichts weiter ist für ein schnelles Prozessverständnis, wie es z.B. das Top-Management benötigt, relevant.

Bestelleingang - grob und feinDoch mitunter will man tiefer bohren – der neue Prozessmanager, wenn es ihn denn gibt (!), braucht Details über die Abläufe, evtl. soll eine genaue Dokumentation zur Qualitätssicherung stattfinden. Möglicherweise sollen auch Medienbrüche identifiziert werden, um Maßnahmen zur Prozessverbesserung einzuleiten – hier ist nebenbei bemerkt von Execution noch überhaupt keine Rede. Kurzum: Eine genauere Betrachtung desselben Prozesses ist erforderlich. Hier geht es also überhaupt nicht darum, die Aktivität (egal ob Task oder Unterprozess) “Bestellung prüfen” zu verfeinern, sondern um haargenau den selben Prozess, der zuvor nur grob betrachtet, modelliert und präsentiert wurde. Noch ein Hinweis zum dargestellten Beispiel: Das Pattern mit den unterschiedlichen Startereignissen ist derzeit umstritten, aber dazu kommt noch ein eigener Post.

2. Beispiel: Strukturunterschiede zwischen “Was” und “Wie”
Für das Business wird der Bestellprozess durch den Eingang einer Bestellung gestartet. Man empfängt also die Nachricht, und los geht’s. Das passende Prozessmodell in BPMN enthält ein eintretendes Startereignis, das die Instanziierung des Prozesses auslöst. Das würde einem Anruf durch den Kunden entsprechen, der augeblicklich vom Call-Center-Agent angenommen würde. Es entspricht jedoch definitiv nicht dem Vorgang, der mit dem Eingang der Bestellung per Post oder Email verbunden ist: Dass jemand prüft, ob neue Post eingegangen ist, die Bestellungen aussortiert und für jede gefundene Bestellung den Bestellprozess auslöst.

Fachliche Sicht versus Technische SichtJetzt sagen manche Leute: “Aber genau diese hässlichen Details sollen doch das Business auch gar nicht interessieren. Die Bestellung löst den Prozess aus – wie diese empfangen wird, darum soll sich die IT kümmern” Meine polemische Meinung dazu: Wer so denkt, braucht sich über “Business-IT-Alignment” gar nicht erst auszulassen. An der technischen Implementierung eines scheinbar banalen Sachverhaltes hängen mitunter schwerwiegende Konsequenzen für das Business – das sich am Ende wieder wundert, warum zwar alles so läuft, wie es definiert wurde, jedoch nicht wirklich so, wie es da Business gerne hätte. Vielleicht muss also nicht unbedingt die konsumierende Fachabteilung die technische Umsetzung des Prozesses verstehen, aber in groben Zügen zumindest der Process Analyst, der häufig auch die Anforderungserhebung, Realisierungsprojektleitung usw. übernimmt und rechtzeitig erkennen muss, welche fachlichen Auswirkungen eine bestimmte Realisierungsform haben kann. Die dargestellte Problematik hängt im Übrigen auch gar nicht am Thema IT-Realisierung – der Bestelleingang per Post erfordert mitunter genau denselben Vorgang “Post abholen und sortieren”.

Die Schwierigkeit besteht jetzt darin, diesen zunächst scheinbar vorgelagerten, tatsächlich aber quer zum betrachteten Prozess “Bestelleingang” verlaufenden, separaten Prozess so in das Gesamtmodell zu integrieren, das seine Rolle im “Bestelleingang” insgesamt verständlich und konsistent berücksichtigt wird – z.B. auch für die Ermittlung der Prozesszeit und -kosten. Mit einer simplen “Verfeinerung” funktioniert das nicht – wer hier eine elegante Lösung kennt, möge sie mir schicken (man könnte hier vielleicht über “Querschnitts-Queues” nachdenken, aber das muss dann auch für fachliche Modelle funktionieren – und für das Business verständlich sein).

“Hauptsache, der Betrachter versteht es” – Ein Schuss ins eigene Knie

Es existieren noch viele weitere Verfeinerungsszenarien, bei denen die in der BPMN-Spec definierte Konstruktion von Ober- und Unterprozessen nicht ohne Weiteres angewandt werden kann. Und ich glaube auch nicht, dass sie überhaupt dafür gedacht ist (oder doch?). Das Problem ist eben nur, dass die vielen neuen BPMN-Aspiranten, die aus dem Business kommen, dies zunächst immer versuchen, weil sie das früher, z.B. mit EPKs, auch so gemacht haben. Aber mein Eindruck ist auch, dass mit EPK und ähnlichen Notationen in der Vergangenheit ganz überwiegend extrem inkonsistente Prozessmodelle erzeugt wurden – nach dem Motto: “Hauptsache, der Betrachter versteht es.”
Diese Haltung ist natürlich ein kompletter Show-Stopper, wenn man den berühmt-berüchtigten BPM-LifeCycle (Modellierung, Implementierung, Controlling) effektiv durchlaufen möchte. Denn bei diesem Wischi-Waschi-Ansatz muss in der Implementierungsphase das fachliche Modell weggeworfen und technisch sauber komplett neu modelliert werden – Missverständnisse sind vorprogrammiert.

BPMN ist ja nicht schon deshalb die “gemeinsame Sprache für Business und IT”, weil in der Konzeptionsphase dieselben grafischen Shapes wie in der Implementierungsphase benutzt werden können.

Was tun?

Ich habe keine Lösung. Ich bin schon froh, wenn ich überhaupt das Problem halbwegs eingrenzen kann – dieser Post ist auch nur einer erster Versuch in diese Richtung. Wenn ich das richtig verstehe, wird in der akademischen Welt über dieses Problem schon seit längerer Zeit diskutiert, und es werden Lösungsansätze erforscht. Aber wie gehen wir kurzfristig in der Praxis vor, speziell bezogen auf BPMN?

Sinnvollerweise pragmatisch – Ein Beispiel: Man könnte einfach für jeden Prozess einen Ordner definieren. Darin legt man ein Diagramm desselben Prozesses mehrfach, aber mit jeweils unterschiedlicher Präzision ab. Das würde das erste Beispiel in diesem Post abfangen. Man könnte das ganze auch mit einem besseren Tooling ausstatten, bei dem man je nach Level unterschiedliche Sichten auf den Prozess erhält. Wenn dann die Objekte im Diagramm nicht nur grafisch, sondern auch logisch durch das Tool verwaltet werden, muss man auch nicht jedes Diagramm einzeln anpassen, nur weil sich die Bezeichnung für einen Task o.ä. geändert hat.
Eine standardisierte Lösung wäre natürlich schöner, aber was der Standard offen lässt, muss eben proprietär gefüllt werden (sonst könnten sich die Hersteller ja gar nicht mehr differenzieren).

Es läuft zunächst also auf BPMN-basierte Modellierungskonventionen verschiedenster Art hinaus, die verbal definiert oder in Tools gegossen werden können. Wir wollen versuchen, hier Vorschläge zu erarbeiten. Denn letztendlich ist ein funktionierendes Ebenenkonzept ein wichtiger Baustein in einer Gesamtlösung, die eine Nutzung der BPMN als gemeinsame Sprache von Business und IT tatsächlich ermöglicht. Die Vorgaben in der Spec scheinen mir im heutigen Stand dafür nicht ausreichend zu sein.

stay tuned…