Malen kann jeder. Orchestrieren nicht.

Ein sauber gezeichnetes BPMN-Diagramm fühlt sich wie ein Ergebnis an. Man hat einen Workshop hinter sich, die Kästchen sitzen, die Pfeile stimmen, die Rauten verzweigen sich logisch — und am Ende steht ein Bild, das aussieht, als wäre der Prozess damit erledigt. Diese Empfindung ist verständlich, aber sie führt in die Irre. Die eigentliche Frage stellt sich erst danach: Was passiert mit diesem Bild, wenn der Workshop vorbei ist? Wird daraus ausführbare Software? Bleibt es aktuell, wenn sich der Prozess ändert? Weiss in zwölf Monaten noch jemand, ob das, was auf dem Papier steht, mit dem übereinstimmt, was im Betrieb tatsächlich geschieht?

Genau an diesen Fragen entscheidet sich, ob ein Diagramm Wert stiftet oder nur Aufwand war. Und genau hier trennen sich zwei Sichtweisen auf Prozessmanagement: die eine sieht das Modell als Ziel, die andere als einen Zwischenstand in einem längeren Lauf. Dieser Artikel argumentiert für die zweite — und zeigt, warum das keine Geschmacksfrage ist, sondern in der Definition der Disziplin selbst angelegt.

BPM ist ein Kreislauf, kein Kunstwerk

Wer Business Process Management ernst nimmt, kommt an einer unbequemen Tatsache nicht vorbei: Die Disziplin definiert sich selbst nicht über das Modellieren, sondern über einen Lebenszyklus. In Fundamentals of Business Process Management beschreiben Marlon Dumas, Marcello La Rosa, Jan Mendling und Hajo Reijers BPM als einen fortlaufenden Zyklus aus mehreren Phasen — von der Identifikation und Erhebung eines Prozesses über seine Analyse und Neugestaltung bis zur Umsetzung und zum laufenden Monitoring, das wiederum zurück in die nächste Runde führt. Das Modellieren ist in dieser Darstellung eine einzige Etappe unter mehreren, kein Endpunkt.

Das ist keine akademische Spitzfindigkeit. Es hat eine praktische Konsequenz: Der Nutzen eines Prozessmodells realisiert sich fast vollständig ausserhalb des Modellierens. Ein Diagramm, das niemand umsetzt, prüft oder verbessert, hat seinen Zweck nicht erfüllt — es hat ihn nur illustriert. Der Wert entsteht in der Bewegung durch die Phasen, nicht im Verweilen auf einer davon.

(Schematische Skizze des Lebenszyklus: Der Prozess wird verstanden, modelliert, umgesetzt, geprüft und verbessert — und die Optimierung speist die nächste Analyse. Die Darstellung ist vereinfacht und illustriert das Prinzip, nicht eine bestimmte Werkzeug- oder Normvorgabe.)

Die meisten Werkzeuge am Markt decken von diesem Kreislauf genau eine Etappe ab: das Design. Sie sind exzellente Zeichenprogramme. Sie helfen, Kästchen und Pfeile normkonform anzuordnen — und hören dort auf, wo die Definition der Disziplin gerade erst in Fahrt kommt.

Wo die Wahrheit verloren geht

Der teuerste Ort in einem Prozessvorhaben ist selten eine einzelne Phase. Es sind die Übergänge dazwischen. Zwischen Analyse und Design, zwischen Design und Umsetzung, zwischen Umsetzung und Betrieb liegen Werkzeugbrüche — jedes Mal wird Information von Hand in ein neues Format übertragen, neu interpretiert, teilweise verloren. An jeder dieser Nahtstellen kann die Beschreibung des Prozesses von seiner Realität abdriften.

Dass diese Kluft real und zentral ist, hat kaum jemand deutlicher gezeigt als Wil van der Aalst. Sein Forschungsprogramm Process Mining setzt genau dort an: an der Differenz zwischen dem Prozess, wie er dokumentiert wurde, und dem Prozess, wie er in den Ereignisdaten der Systeme tatsächlich abläuft. In Process Mining: Data Science in Action macht van der Aalst das Abgleichen von Modell und Wirklichkeit — die sogenannte Conformance-Prüfung — zu einer eigenen Disziplin. Dass es einen ganzen Forschungszweig braucht, um herauszufinden, ob ein Modell noch mit der Realität übereinstimmt, ist der beste Beleg dafür, dass diese Übereinstimmung eben nicht selbstverständlich ist. Modelle driften. Nicht aus Böswilligkeit, sondern weil die Werkzeugkette sie von der Realität trennt, sobald sie einmal gezeichnet sind.

Ein Diagramm, das isoliert in einem Dateiablagesystem liegt, ohne Verbindung zur Umsetzung und ohne Rückkopplung aus dem Betrieb, ist gegen diese Drift schutzlos. Es war im Moment seiner Entstehung vielleicht korrekt. Aber es hat keinen Mechanismus, korrekt zu bleiben. Das ist der eigentliche Grund, warum eine BPMN-Datei schon nach einem halben Jahr so oft nur noch entfernt mit dem gelebten Prozess zu tun hat: nicht, weil sie schlecht gezeichnet war, sondern weil sie allein war.

Ein offener Standard ist die Voraussetzung, nicht die Lösung

An dieser Stelle lohnt eine Klarstellung, denn sie wird oft verwechselt. Dass BPMN ein offener Standard ist, ist ein grosser Vorteil — aber er löst das Lebenszyklus-Problem nicht von selbst. BPMN 2.0 ist eine Spezifikation der Object Management Group und zusätzlich als ISO/IEC 19510 normiert. Das bedeutet: Ein BPMN-Modell ist maschinenlesbares, herstellerübergreifendes XML, kein proprietäres Bildformat, das an ein einzelnes Programm gefesselt ist. Man kann es weiterreichen, versionieren, in andere Werkzeuge überführen, ausführen.

Der Standard schafft damit die Möglichkeit, ein Modell über die Phasen hinweg durchzureichen. Er stellt sie aber nicht her. Er definiert, wie ein gültiges Diagramm aussieht — nicht, wie es von der Analyse ins Design, vom Design in die Umsetzung und von dort in den Test wandert, ohne dass an jeder Grenze ein Mensch Information von Hand kopiert und dabei verliert. Die Norm ist die Fahrbahn. Sie ist noch nicht die Fahrt.

Ein Dirigent, kein Instrument

Ein Orchester besteht aus vielen Instrumenten. Jedes für sich kann brillant sein; erst der Dirigent macht daraus ein zusammenhängendes Stück. Diese Metapher steckt bewusst im Namen MESTRO — denn die These lautet: Das Problem im Prozessmanagement ist selten ein fehlendes Instrument. Zeichenwerkzeuge gibt es reichlich, und viele sind ausgezeichnet. Was fehlt, ist die Führung über den ganzen Lauf hinweg.

MESTRO ist deshalb kein weiteres Zeichenprogramm, sondern ein Orchestrator über fünf Phasen: Analyse, Design, Umsetzung, Test & Fix und Optimierung. Der entscheidende Beitrag liegt nicht darin, in einer dieser Phasen besonders laut zu spielen, sondern darin, die Übergänge zu schliessen, an denen sonst die Wahrheit über den Prozess verloren geht.

Konkret heisst das:

In der Analyse verdichtet MESTRO unscharfe Inputs zu einer strukturierten Prozesslandkarte — End-to-End-Prozesse, die jeweils in typischerweise fünf bis zehn Hauptaktivitäten gegliedert sind. Dieser „Überbau“ ist die Voraussetzung für den richtigen Zuschnitt und die richtige Granularität der späteren Modelle; ohne ihn beginnt das Design im Blindflug.
Im Design entsteht daraus ein präzises Modell — und zwar in Standard-BPMN 2.0 oder CMMN 1.1, je nachdem, was der Charakter des Prozesses verlangt. Es bleibt ein offenes, herstellerübergreifendes Format; niemand wird in ein proprietäres Silo gesperrt.
In der Umsetzung wird das Modell zur Quelle für ausführbaren Code einer Process-Engine. Das Diagramm ist nicht länger eine Beschreibung neben dem System, sondern der Ursprung des Systems.
In Test & Fix wird der Prozess szenariobasiert geprüft, bevor er produktiv geht — mit Anbindung an etablierte Werkzeuge der Testverwaltung.
In der Optimierung schliesst sich der Kreis zurück zur Analyse, und der nächste Durchlauf beginnt auf besserer Grundlage.

Der springende Punkt ist die durchgehende Kette. Weil dasselbe Modell durch alle Phasen getragen wird, statt an jeder Grenze neu abgeschrieben zu werden, verschwinden die Werkzeugbrüche, in denen die Drift entsteht. Das Diagramm ist dabei jederzeit nur ein Zwischenstand — ein wichtiger, aber eben einer unter mehreren Zuständen desselben Prozesses.

Ein zweiter Aspekt gehört ehrlicherweise dazu: MESTRO ist KI-nativ gebaut, aber die KI ersetzt nicht das menschliche Urteil. Sie schreibt ihre Vorschläge in einen Arbeitsbereich, ein „Work-Pad“; die Übernahme ins kanonische Diagramm bleibt eine bewusste menschliche Handlung, kein stilles Überschreiben. Der Mensch bleibt Autor und Entscheider; die Maschine trägt die Konsistenz durch den Lebenszyklus und nimmt die Fleissarbeit ab. Das ist der Unterschied zwischen Automatisierung als Verstärker und Automatisierung als Blackbox.

Diese Ambition, einzelne Automatisierungsinseln zu einem durchgängigen Ganzen zu verbinden, hat auch die Analystenwelt benannt — Gartner spricht in diesem Zusammenhang von „Hyperautomation“. Der Begriff meint im Kern genau das: nicht eine weitere isolierte Insel, sondern die orchestrierte Verbindung vieler Fähigkeiten über den gesamten Ablauf. Ein Orchestrator über den Prozess-Lebenszyklus ist die konsequente Antwort auf diese Idee.

Fazit

Malen — im Sinne von normkonforme Kästchen und Pfeile setzen — beherrscht heute jedes ernstzunehmende Werkzeug. Das ist gut, aber es ist nicht das Schwierige. Das Schwierige ist, ein Modell über den ganzen Lebenszyklus hinweg wahr zu halten: es umzusetzen, zu prüfen, zu verbessern und dabei die Übereinstimmung mit der Realität nicht zu verlieren. Die Definition von BPM als Kreislauf und die gesamte Forschung zur Kluft zwischen Modell und Wirklichkeit zeigen dasselbe: Der Wert liegt in der Bewegung durch die Phasen, nicht im schönen Standbild einer einzelnen.

Ein Zeichenprogramm hört auf, wo die Wertschöpfung beginnt. Ein Orchestrator setzt genau dort an. Das Modell ist nicht das Ergebnis, sondern der Taktstock — und der Prozess spielt danach. Wer mehr darüber wissen will, warum diese fünf Phasen zusammengehören, findet in „Die fünf Leben eines Prozesses“ die Fortsetzung des Gedankens; warum der Kreis sich nie ganz schliesst, vertieft „Kein Prozess ist je fertig“.

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/
ISO/IEC 19510:2013. https://www.iso.org/standard/62652.html