Die fünf Leben eines Prozesses

Ein Kreditantrag wird eingereicht, geprüft, genehmigt, ausbezahlt. Klingt nach einem Vorgang — ist aber ein Prozess, der in seinem Bestehen mehrere Male neu geboren wird. Zuerst existiert er nur als vage Vorstellung im Kopf einer Fachabteilung. Dann als Kästchen-Skizze auf einem Whiteboard. Später als sauberes Modell in einer Notation, danach als lauffähiger Code in einer Process Engine, schliesslich als Datenspur, die zeigt, wo die Realität vom Modell abweicht. Jedes dieser Stadien ist ein eigenes Leben desselben Prozesses — mit eigenen Werkzeugen, eigenen Menschen und, in den meisten Organisationen, eigenen Dateien, die nichts voneinander wissen.

Genau diese Stadien hat die akademische BPM-Disziplin längst benannt. Sie nennt sie nicht «Leben», sondern schlicht: den BPM-Lebenszyklus. Und die spannende Frage ist nicht, ob es diese Etappen gibt — die gibt es überall. Die Frage ist, was an den Übergängen zwischen ihnen passiert.

Der Lebenszyklus ist kein Marketingbegriff

Wer den BPM-Lebenszyklus für eine Beraterfolie hält, hat das Standardwerk der Disziplin nicht aufgeschlagen. Dumas, La Rosa, Mendling und Reijers beschreiben in Fundamentals of Business Process Management einen Zyklus aus klar benannten Phasen: Prozess-Identifikation, Process Discovery (die Ist-Aufnahme), Prozessanalyse, Prozess-Redesign, Implementierung und schliesslich Monitoring und Controlling — von wo aus die Schleife zur nächsten Runde zurückführt.

Das ist keine willkürliche Einteilung. Sie folgt einer Logik: Man kann einen Prozess nicht verbessern, den man nicht analysiert hat; man kann ihn nicht analysieren, den man nicht sichtbar gemacht hat; und man weiss erst nach der Ausführung, ob die Verbesserung überhaupt gegriffen hat. Der Zyklus schliesst sich, weil die letzte Phase — das Beobachten der laufenden Realität — die Rohdaten für die erste Phase der nächsten Runde liefert.

Für diese datengetriebene Rückkopplung liefert van der Aalst in Process Mining: Data Science in Action das methodische Fundament: Aus den Ereignisprotokollen laufender Systeme lässt sich der tatsächlich gelebte Prozess rekonstruieren — nicht der, den jemand gezeichnet hat, sondern der, den die Organisation wirklich ausführt. Damit wird aus dem «Monitoring» am Ende des Zyklus keine subjektive Einschätzung, sondern eine Messung.

Kurz: Der Lebenszyklus ist etabliert, gut begründet und alt genug, um kein Trend zu sein. Wenn ein Werkzeug ihn abbildet, erfindet es nichts — es macht etwas explizit, das ohnehin geschieht.

Fünf Phasen, ein bekanntes Muster

MESTRO ist ein KI-nativer Orchestrator, der diesen Lebenszyklus in fünf Phasen giesst: Analyse, Design, Instrumentierung, Test & Fix, Optimierung. Man muss diese fünf nicht auswendig lernen, um zu erkennen, dass es sich um denselben Zyklus handelt, nur mit einer stärkeren Betonung der ausführbaren Umsetzung. Die Zuordnung ist bewusst grobkörnig — es geht um das Muster, nicht um eine Eins-zu-eins-Landkarte:

MESTRO-Phase	Entspricht im Lebenszyklus (Dumas et al.)	Kernfrage
Analyse	Identifikation + Discovery + Analyse	Welche Prozesse gibt es, und wie sehen sie grob aus?
Design	Redesign / Modellierung	Wie sieht der Soll-Prozess präzise aus?
Instrumentierung	Implementierung	Wie wird das Modell ausführbar?
Test & Fix	Teil der Implementierung / Qualitätssicherung	Tut der ausführbare Prozess, was er soll?
Optimierung	Monitoring & Controlling → zurück zur Analyse	Wo weicht die Realität ab, und was verbessern wir als Nächstes?

Zwei Dinge fallen auf. Erstens: Die Instrumentierung — der Schritt vom Modell zum lauffähigen Code — bekommt bei MESTRO eine eigene, prominente Phase. Das ist der Punkt, an dem im klassischen Zyklus die grösste Bruchstelle sitzt, weil hier die Zuständigkeit vom Fachbereich zur IT wechselt. Zweitens: Die Optimierung ist kein Endpunkt, sondern eine Rückkopplung. Sie führt zurück zur Analyse — genau die Schleife, die Dumas et al. beschreiben.

Schematisch sieht der Fluss so aus:

Die gepunktete Linie von der Optimierung zurück zur Analyse ist der eigentliche Punkt. Ohne sie hat man fünf Projekte hintereinander. Mit ihr hat man einen Lebenszyklus.

Der Gewinn liegt nicht in den Phasen — sondern zwischen ihnen

Hier kommt die These, die diesen Artikel trägt: Die einzelnen Etappen sind kein Wettbewerbsvorteil. Analyse-Workshops macht jede Beratung, Modellieren kann jedes BPMN-Tool, ausführen jede Process Engine, testen jedes QA-Team. Wer glaubt, der Fortschritt läge darin, eine dieser Etappen etwas schneller oder etwas hübscher zu machen, optimiert die falsche Stelle.

Der Schaden entsteht an den Brüchen. Betrachten wir den typischen Weg eines Prozesses durch eine Organisation ohne durchgängige Artefakte:

Ein Analyst hält im Workshop eine Prozesslandkarte in einer Präsentation fest. Ein Modellierer übersetzt sie — von Hand, nach bestem Verständnis — in ein BPMN-Diagramm in einem Modellierungstool. Ein Entwickler liest das Diagramm, versteht drei Details anders als gemeint, und baut daraus ausführbaren Code in einer Engine. Ein Tester schreibt seine Testfälle gegen die Spezifikation, die inzwischen zwei Wochen alt ist. Und wenn im Betrieb eine Kennzahl aus dem Ruder läuft, sitzt der Optimierer vor einem Dashboard, das mit keinem der vorherigen Artefakte verknüpft ist.

An jeder dieser vier Übergabestellen passiert dasselbe: Ein Mensch übersetzt eine Wahrheit über den Prozess von einem Format in ein anderes. Und jede Übersetzung ist eine Gelegenheit, dass die Wahrheit auseinanderdriftet. Nach wenigen Runden existieren nicht mehr fünf Sichten auf einen Prozess, sondern fünf verschiedene Prozesse, die alle denselben Namen tragen. Welcher davon gilt? Meistens keiner — und niemand weiss es.

Konkret: Der Modellierer fügt eine Eskalationsschleife hinzu, weil die Fachabteilung sie im Nachgang erwähnt hat. Er sagt es dem Entwickler nicht, weil der Entwickler in einem anderen Team, einem anderen Tool und einem anderen Sprint arbeitet. Der ausgeführte Prozess kennt die Schleife nie. Der Test prüft sie folglich auch nicht. Und wenn im Betrieb Anträge unbemerkt liegenbleiben, sucht man den Fehler im Code — obwohl er in der Lücke zwischen Diagramm und Code sitzt.

Die Lösung ist unspektakulär und genau deshalb wirksam: Alle Phasen arbeiten auf denselben Artefakten. Wenn das Modell, das der Modellierer bearbeitet, dasselbe Artefakt ist, aus dem der ausführbare Prozess erzeugt wird, dann kann die Eskalationsschleife nicht «vergessen» werden — sie ist entweder im gemeinsamen Modell oder gar nicht da. Die Wahrheit über den Prozess kann nicht auseinanderdriften, weil es nur eine gibt.

Wie MESTRO die Brüche schliesst

Und damit zu dem einen Ort, an dem sich das oben Gesagte konkret nachvollziehen lässt. MESTRO ist als ein durchgängiger Fluss über die fünf Phasen gebaut, nicht als fünf Tools mit Import-Export-Adaptern dazwischen. Drei Konstruktionsentscheide machen das aus:

Der «Überbau» in der Analyse. MESTRO nimmt unscharfe Inputs — Gesprächsnotizen, halbe Ideen, bestehende Dokumente — und verdichtet sie zu einer strukturierten Prozesslandkarte: End-to-End-Prozesse mit jeweils fünf bis zehn Hauptaktivitäten. Dieser «Überbau» ist nicht Wegwerf-Material für den Workshop, sondern das Gerüst, auf dem alle folgenden Phasen aufsetzen. Der Sprung von der Landkarte zum Detailmodell ist keine Neuübersetzung, sondern eine Verfeinerung desselben Artefakts.

«Das Modell ist die Quelle» in der Instrumentierung. Der ausführbare Code für die Engine (Flowable) wird aus dem Modell erzeugt — das Modell ist die Quelle der Wahrheit, nicht ein unverbindlicher Vorschlag, den ein Entwickler danach frei interpretiert. Damit verschwindet genau die Bruchstelle, an der im obigen Beispiel die Eskalationsschleife verlorenging. Was im Modell steht, kommt in die Ausführung; was nicht drinsteht, existiert nicht.

Native BPMN- und CMMN-Modellierung, Method-&-Style-konform. Ob ein Prozess strukturiert und vorhersehbar ist (BPMN) oder fallgetrieben und situativ (CMMN), wird von MESTRO aus dem Charakter des Prozesses abgeleitet, nicht als manueller Schalter aufgezwungen. Erzeugt werden Standard-BPMN und -CMMN — keine proprietäre Insellösung, die den nächsten Bruch bloss verschiebt.

Wichtig — und das ist kein Detail: Die KI schreibt ihre Vorschläge in ein Work-Pad, nicht direkt ins kanonische Diagramm. Die Übernahme ist eine bewusste menschliche Handlung. Das ist die Human-in-the-Loop-Absicherung gegen die naheliegende Sorge, ein durchgängiger Fluss werde zum unkontrollierten Automaten. Der Fluss ist durchgängig; die Kontrolle bleibt beim Menschen. Governance-Belange und IKS-Kontrollen hängen dabei an den einzelnen Aktivitäten, und die gemeinsame Versionierung sorgt dafür, dass jede Runde des Zyklus nachvollziehbar bleibt.

Man kann das ausdrücklich für übertrieben halten, wenn ein Prozess nur einmal gezeichnet und nie wieder angefasst wird. Aber solche Prozesse sind selten — und meist die unwichtigen. Für alles, was wirklich läuft und sich weiterentwickelt, entscheidet die Durchgängigkeit über die Qualität mehr als jede einzelne Phase.

Fazit

Ein Prozess lebt in Etappen — das ist keine These, sondern Lehrbuchwissen: Dumas et al. beschreiben den BPM-Lebenszyklus von der Identifikation über Analyse und Redesign bis zu Implementierung und Monitoring, und van der Aalst zeigt, wie sich die Rückkopplung aus laufenden Daten datengetrieben schliessen lässt. MESTROs fünf Phasen sind eine Ausprägung genau dieses Zyklus.

Der Fortschritt liegt aber nicht in einer besseren Analyse oder einem schöneren Editor. Er liegt darin, die Übersetzungsstellen zwischen den Phasen zu tilgen. Solange jede Etappe ihr eigenes Artefakt pflegt, driftet die Wahrheit über den Prozess bei jeder Übergabe ein Stück weiter auseinander — bis niemand mehr sagen kann, welche Version gilt. Wenn alle Phasen auf denselben Artefakten arbeiten, ist diese Frage gegenstandslos: Es gibt nur eine Wahrheit, und sie kann sich nicht spalten.

Fünf Leben, ein Prozess. Das gelingt nur, wenn zwischen den Leben nichts verlorengeht.

Quellen & Weiterlesen

• M. Dumas, M. La Rosa, J. Mendling, H. A. Reijers: Fundamentals of Business Process Management, 2. Auflage, Springer, 2018.
• W. M. P. van der Aalst: Process Mining: Data Science in Action, 2. Auflage, Springer, 2016.
• Object Management Group: Business Process Model and Notation (BPMN) Version 2.0.2, 2013. https://www.omg.org/spec/BPMN/2.0.2/