Der Moment im Workshop ist fast immer derselbe. Auf dem Whiteboard steht der Prozess, so wie ihn niemand vorher gesehen hat: Kästchen, Pfeile, drei Rückfragen, ein Kaffeefleck. Alle im Raum nicken. Für diese halbe Stunde stimmt das Bild an der Wand mit der gemeinsamen Vorstellung überein, wie die Arbeit laufen soll. Dann wird abfotografiert, der Raum geleert — und die eigentliche Reise beginnt. Jemand tippt die Skizze in ein Modellierungswerkzeug ab. Ein anderer nimmt dieses Modell und baut daraus eine Präsentation für das Management. Wieder jemand anders setzt am Ende in einem dritten Tool die Umsetzung um. Drei Übergaben, drei Werkzeuge, drei Interpretationen desselben Prozesses.
Und mit jeder Übergabe geht ein Stück Wahrheit verloren. Das ist kein Vorwurf an die Beteiligten — es ist die zwangsläufige Folge davon, dass die Skizze, das Modell und das laufende System in getrennten Welten leben und über Menschen synchronisiert werden müssen. Dieser Artikel handelt von diesen Werkzeugbrüchen, von der Lücke, die sie öffnen, und von einer Idee, die sie schliesst: das Modell nicht als Dokumentation neben dem System zu behandeln, sondern als dessen Quelle.
Die Werkzeugbrüche zwischen Idee und System
Machen wir die typische Kette explizit. Am Anfang steht eine Idee — als Skizze auf der Serviette, als Whiteboard-Foto, als PDF eines Soll-Prozesses aus einem Beraterbericht oder schlicht als Absatz Fliesstext in einem Ticket. Das ist Rohmaterial: reich an Kontext, arm an Präzision.
Der erste Bruch: Jemand überträgt dieses Rohmaterial in ein Modellierungswerkzeug. Dabei wird interpretiert. Was auf dem Whiteboard eine flüchtige Verzweigung war, muss jetzt eine benannte Gateway-Entscheidung werden. Der zweite Bruch: Das Modell dient der Kommunikation, aber die Umsetzung passiert woanders — in einer Process-Engine, in Code, in einem Low-Code-Baukasten. Wer dort baut, liest das Modell noch einmal und übersetzt es in etwas Ausführbares. Der dritte Bruch schleicht sich später ein: Das System läuft, es wird angepasst, gepatcht, erweitert — und niemand pflegt das Modell nach. Es veraltet still.
Jeder dieser Pfeile ist eine manuelle Übersetzung zwischen zwei Repräsentationen desselben Prozesses. Und jede Übersetzung ist eine Gelegenheit, etwas fallen zu lassen: eine Ausnahme, eine Zuständigkeit, eine Bedingung, die im Original noch da war. Am Ende existieren mehrere Versionen der Wahrheit nebeneinander — die im Kopf der Fachabteilung, die im Modell, die im laufenden System — und keine stimmt vollständig mit der anderen überein.
Die Modell-Realität-Lücke
Diese Diskrepanz hat einen Namen und eine ganze Forschungsdisziplin, die sie sichtbar macht. Wilfried van der Aalst beschreibt in Process Mining: Data Science in Action genau den Graben zwischen dem, was ein Prozessmodell behauptet, und dem, was die Ereignisdaten eines laufenden Systems tatsächlich zeigen. Process Mining rekonstruiert Prozesse aus den Spuren, die sie in IT-Systemen hinterlassen — und deckt dabei regelmässig auf, dass der real ausgeführte Prozess vom dokumentierten abweicht. Genau das ist die Modell-Realität-Lücke: Das schöne Diagramm an der Wand und das, was das System wirklich tut, sind zwei verschiedene Dinge.
Für die Praxis ist das teuer. Ein Modell, dem man nicht trauen kann, ist schlimmer als kein Modell — es erzeugt falsche Sicherheit. Compliance-Prüfungen stützen sich auf Diagramme, die den Ist-Zustand nicht mehr abbilden. Neue Mitarbeitende lernen einen Prozess, der so nicht mehr läuft. Verbesserungsinitiativen optimieren an einer Landkarte, die das Gelände nicht mehr trifft.
Der Kern des Problems: Solange das Modell nur Dokumentation neben dem System ist, gibt es keinen Mechanismus, der es zwingt, mit der Realität übereinzustimmen. Es kann driften, ohne dass etwas kaputtgeht. Genau diese fehlende Kopplung ist der Hebel.
Das Modell als Quelle, nicht als Beiwerk
Die Gegenbewegung heisst modellgetriebene Umsetzung: Das Prozessmodell ist nicht die Beschreibung des Systems, es ist das System — oder zumindest die Quelle, aus der das ausführbare Verhalten unmittelbar entsteht.
Der entscheidende Punkt ist, dass BPMN von Anfang an dafür gebaut wurde. Die Business Process Model and Notation (BPMN) Version 2.0.2 der Object Management Group ist keine reine Zeichennotation. Sie definiert eine Ausführungssemantik und ein Serialisierungsformat, sodass ein Modell nicht nur für Menschen lesbar, sondern für Maschinen ausführbar ist. Ein BPMN-2.0-Diagramm hat eine präzise, standardisierte XML-Repräsentation — und eine Process-Engine kann diese direkt interpretieren.
Genau hier setzen Engines wie das Open-Source-Flowable an. Flowable führt BPMN-Prozesse direkt aus: Das Modell wird nicht von Hand in Code übersetzt, es wird deployed und läuft. Ändert man den Prozess, ändert man das Modell — und die geänderte Ausführung folgt daraus, nicht aus einer separaten, nachgepflegten Codebasis. Damit verschwindet der zweite und dritte Werkzeugbruch von oben: Es gibt kein Nebeneinander von Modell und Umsetzung mehr, das auseinanderdriften könnte, weil beide dasselbe Artefakt sind.
Dumas, La Rosa, Mendling und Reijers ordnen diesen Schritt in den Fundamentals of Business Process Management in den grösseren Kreislauf ein: Prozesse werden erhoben, modelliert, umgesetzt, überwacht und verbessert — als kontinuierlicher Lebenszyklus, nicht als einmaliges Dokumentationsprojekt. Model-driven Execution ist das Scharnier, das die Umsetzungsphase mit dem Modell verzahnt, statt sie davon zu entkoppeln. (Wer den Lebenszyklus-Gedanken vertiefen will, findet ihn im Beitrag «Die fünf Leben eines Prozesses».)
Bleibt der erste Bruch: der Weg von der rohen Idee zum präzisen, ausführungsfähigen Modell. Der ist am schwersten zu automatisieren, weil hier interpretiert werden muss — und genau hier hat sich in den letzten Jahren am meisten bewegt.
Ein durchgängiger Fluss: ein Beispiel
Nehmen wir einen konkreten, kleinen Prozess — die Genehmigung einer Spesenabrechnung, wie er auf einem Whiteboard entstehen könnte:
«Mitarbeiter reicht Spesen ein. Vorgesetzter prüft. Bis 500 Franken geht’s direkt durch, darüber muss die Finanzabteilung nochmal drauf. Am Ende Auszahlung.»
Das ist Fliesstext mit einer eingebauten Verzweigung. Als präzises Modell gedacht, wird daraus:
Der Weg vom Absatz zum Diagramm ist die Modellierungsarbeit: aus «bis 500 Franken direkt» wird eine benannte Gateway-Bedingung, aus «prüft» werden zwei getrennte User-Tasks mit klaren Zuständigkeiten. Ist dieses Modell einmal als sauberes BPMN 2.0 formuliert, ist der Rest kein neuer Interpretationsschritt mehr, sondern eine Ableitung: Die Gateway-Bedingung wird zur ausführbaren Verzweigung, die Tasks werden zu Arbeitskörben in der Engine, der Sequenzfluss zur Prozessinstanz. Dieselbe Struktur, die im Workshop verständlich war, trägt bis in die Ausführung — vorausgesetzt, sie muss unterwegs nicht dreimal neu abgetippt werden.
Wo MESTRO ansetzt
Genau diesen durchgängigen Fluss macht MESTRO zum Produkt. MESTRO ist ein KI-nativer Orchestrator für den BPM-Lebenszyklus, und seine Aufgabe ist es, die Werkzeugbrüche zwischen Idee und laufendem System einzuebnen — ohne sie zu verstecken.
Am Anfang steht das Rohmaterial in der Form, in der es real anfällt. MESTRO versteht Bilder und PDF: Eine abfotografierte Whiteboard-Skizze oder ein PDF eines Soll-Prozesses wird zu einem BPMN-Modell — als Ausgangspunkt zum Weiterbearbeiten, nicht als fertiges Endprodukt. Auch eine reine Textbeschreibung genügt. Der erste, sonst so verlustreiche Werkzeugbruch — Skizze abtippen — wird damit zu einem Startpunkt, an dem der Mensch weiterbaut, statt bei null zu beginnen. (Wie eine KI überhaupt dazu kommt, BPMN «zu sprechen», ist Thema des Beitrags «Die KI, die BPMN spricht».)
In der Design-Phase entsteht daraus ein präzises Modell — BPMN und CMMN nativ, Method-&-Style-konform, also nicht nur syntaktisch korrekt, sondern lesbar und regelkonform. In der Instrumentierung schliesslich wird aus diesem Modell ausführbarer Code für eine Process-Engine (Flowable). Das ist der entscheidende Halbsatz: Das Modell ist die Quelle, nicht Dokumentation neben dem System. Was ausgeführt wird, stammt aus dem, was modelliert wurde — die Modell-Realität-Lücke bekommt keinen Ort mehr, an dem sie entstehen könnte.
Wichtig ist dabei, was MESTRO nicht tut: Es überspringt den Menschen nicht. Jeder Schritt und jede Übernahme ist bewusst. Zwischen dem, was die KI vorschlägt, und dem, was in den kanonischen Prozess übernommen wird, liegt ein Work-Pad als Skizzenraum und ein expliziter Promote-Schritt. Die KI schlägt vor, der Mensch entscheidet, was Wahrheit wird — ein Prinzip, das der Beitrag «Die KI schlägt vor. Du entscheidest.» genauer ausleuchtet. Und weil MESTRO durchgängig Standard-BPMN-2.0 und CMMN-1.1 erzeugt, entsteht kein proprietäres Format, das den nächsten Werkzeugbruch nur verschiebt.
MESTRO ist hier ein Beispiel für den Ansatz, nicht sein Alleinvertreter. Der eigentliche Punkt ist der Ansatz selbst: Skizze, Modell und Ausführung auf ein einziges, standardkonformes Artefakt zu reduzieren, das der Mensch an bewussten Punkten kontrolliert.
Fazit
Die Reise von der Serviette zum laufenden Prozess führt klassisch über drei Werkzeuge und drei Übergaben — und an jeder Übergabe verliert der Prozess ein Stück Wahrheit. Das Ergebnis ist die Modell-Realität-Lücke: dokumentierte und tatsächlich laufende Prozesse, die auseinanderdriften, ohne dass jemand es merkt. Process Mining hat diese Lücke sichtbar gemacht; sie zu schliessen ist eine Frage der Architektur, nicht der Disziplin.
Der tragfähige Ausweg ist model-driven: Das Modell ist nicht Beiwerk, sondern Quelle. BPMN 2.0 ist genau dafür gebaut, Engines wie Flowable führen es direkt aus, und der Lebenszyklus-Gedanke verzahnt Umsetzung und Modell statt sie zu trennen. Bleibt der schwierigste erste Schritt — von der rohen Idee zum präzisen Modell. Dass KI diesen Schritt heute übernehmen kann und der Mensch dabei die Kontrolle über jede Übernahme behält, ist das, was den durchgängigen Fluss praktikabel macht. Nicht das Modell abtippen, sondern es als Wahrheit behandeln, aus der das System entsteht: Das ist der Unterschied zwischen einem Diagramm an der Wand und einem laufenden Prozess.
Quellen & Weiterlesen
- Object Management Group: Business Process Model and Notation (BPMN) Version 2.0.2, 2013. https://www.omg.org/spec/BPMN/2.0.2/
- W. M. P. van der Aalst: Process Mining: Data Science in Action, 2. Auflage, Springer, 2016.
- Flowable — Open-Source-BPM/Process-Engine. https://www.flowable.com/open-source
- M. Dumas, M. La Rosa, J. Mendling, H. A. Reijers: Fundamentals of Business Process Management, 2. Auflage, Springer, 2018.
