Prozessmodelle verfeinern – kein Problem?
BPMN - Business & IT? October 22nd. 2008, 11:41am
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.
Doch 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.
Jetzt 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…
2008-10-24 at 3.05 pm
Das ist das harte Brot der Prozessmodellierung. In der Tat braucht man u. U. ganz verschiedene Modelle für unterschiedliche Zwecke. Es wäre natürlich ganz schön, wenn man ein Tool hätte, mit dem man unterschiedliche Prozessdarstellungen aus einem integrierten Modell erzeugen lassen könnte. Also z. B. einmal die Postsortierung als eigener Prozess, der andere Prozesse anstößt (als Grundlage für die Implementierung), das andere Mal als Teil der Auftragsbearbeitung, um den gesamten Ablauf Ende-zu-Ende verstehen zu können. Andererseits brächte das noch einmal eine Menge zusätzliche Komplexität in die Modellierung.
Das erste Beispiel lädt natürlich dazu ein, über die Hierarchisierung von Ereignissen nachzudenken. Dies wird ja gegenwärtig von der BPMN nicht angeboten. Man könnte in dem “groben” Modell auch komplett auf die Ereignisse verzichten, dann wäre das genauere Modell wieder eine richtige Detaillierung des groben.
Modelle der oberen Hierarchie-Ebenen lassen sich streng genommen sowieso nicht mit BPMN darstellen, da die Verbindungen zwischen High-Level-Aktivitäten wie “Auftragsbearbeitung” und “Produkterstellung” keineswegs simple Sequenzflüsse im Sinne der BPMN sind. Es handelt sich vielmehr um grobe Angaben bzgl. vorherrschender Flussrichtung. Bei detaillierter Betrachtung wird die Verbindung aus zahlreichen unterschiedlichen Sequenzflüssen mit Rückflüssen usw. bestehen. Auf höheren Ebenen würde ich daher eher Wertschöpfungsketten-Diagramme verwenden, und nur auf den ein bis zwei untersten Ebenen tatsächlich BPMN.
Auf jeden Fall muss man sich von der Vorstellung verabschieden, eine komplett durchgängige und konsistente Prozessmodellstruktur über alle Unternehmensebenen zu erreichen. Von daher haben die Ersteller “inkonsistenter” EPK-Modelle schon recht, wenn sie einen pragmatischen Weg gewählt haben und die Modelle ihren Zweck erfüllen. Will man einen Prozess automatisieren, so muss natürlich eine genauere Beschreibung erstellt werden. Wenn es gelingt, hierbei zumindest die Traceability von “ungenauem” Fachmodell zum ausführbaren Modell zu erhalten, ist schon viel gewonnen.
Wie steht bei White/Miers? “All models are wrong, some are useful”.
2008-10-25 at 12.28 am
Hmh, ich glaube “All models are wrong” bezieht sich eher auf den Perfektionismus mancher Modellierer, alle Details der Realität abbilden zu wollen, als auf die Modell-Konsistenz (ich kenne den Spruch mit “All models are incomplete…”) Aber wie auch immer, ich kann Ihre Argumente sicher nachvollziehen.
Wo ich aber drauf beharre: Es ist keine gute Unterstützung für den “BPM-Kreislauf”, wenn in der fachlichen Modellierung Prozessmodelle entstehen, die in der technischen Modellierung in einer ganz anderen Struktur umgesetzt werden müssen. Weder für die Implementierungsphase, noch für die Phase der Kennzahlenmessung und -aggregation (Controlling), und ganz besonders nicht für die fachlich/technische Administration im laufenden Betrieb (<= Incidident Management, SOA Governance, aber auch KVP usw.). Ich will mich aber noch nicht von der Idee der durchgängigen Modellierung verabschieden, denn ich sehe in der Praxis immer wieder punktuelle Lösungen, die ich bislang "nur" noch nicht in ein generisches Gesamtkonzept zusammenpuzzeln konnte. Es bringt jedenfalls gar nichts, wenn eine Methode oder ein Tool zwar alle Phasen des Kreislaufs abbildet, aber die Übergänge zwischen den Phasen nicht intelligent unterstützt. Das ist keine Durchgängigkeit. Zum Thema "Hierarchisierung von Ereignissen": Habe ich auch schon überlegt, klappt aber eigentlich nicht (auch in diesem Beispiel), weil an zwei Ereignissen zusätzliche Prozessschritte hängen (und theoretisch unendlich viele). Da könnte man die Differenzierung zwischen Ereignis und Aktivität auch gleich vergessen (muss zugeben, dass ich das beim Send/Receive ohnehin problematisch finde). Ereignisse weglassen ist auch keine Lösung, wenn man das Thema "Prozesse schneiden" ernst nimmt. Dann ist das eine der Bestelleingang im Ganzen, das andere die Prüfung der Bestellung. Das Startereignis des Betelleingangs kann nicht einfach in der Prüfung ausmodelliert werden, das wäre inhaltlich falsch und in komplexeren Modellen auch praktisch ein Problem. Das WKD, Prozesslandkarten etc. fehlen, ist wirklich ein Defizit von BPMN - Da merkt man m.E., dass die Erfinder aus der IT kommen und nicht aus dem Business. Hier muss man sich leider auf proprietäre Lösungen zurückziehen. Zu Ihrer ersten Anregung: Ich glaube, dass wir genauso ein Tooling sehr gut gebrauchen könnten, auch wenn das die Modellierung evtl. zuerst noch anspruchssvoller macht. Aber die Leute müssen endlich verstehen, dass Prozessmodellierung keine "Fleißarbeit" ist, für die man sich mal eben einen "Werksstudenten" holt, sondern eine analytisch extrem anspruchsvolle Geschichte, bei der man sich auch nicht mit "Ist mir zu technisch" aus der Verantwortung stehlen darf.