Fragen Sie einen Prozessverantwortlichen kurz vor dem Go-live, ob sein Prozess funktioniert, und Sie hören mit hoher Wahrscheinlichkeit einen bestimmten Satz: «Das müsste funktionieren.» Es ist ein freundlicher Satz, ein zuversichtlicher Satz — und es ist der teuerste Satz im ganzen Prozessmanagement. Denn «müsste» ist kein Beweis. Es ist eine Hoffnung, die sich meist am glatten Normalfall gebildet hat, während die eigentlichen Probleme woanders lauern: an den Rändern.
Der Antrag kommt unvollständig herein. Die Frist ist abgelaufen, bevor die Genehmigung eintrifft. Ein Kunde storniert, während die Rechnung schon unterwegs ist. Zwei Wege laufen zusammen und keiner hat daran gedacht, dass der eine noch offen sein könnte, wenn der andere endet. Prozesse scheitern fast nie dort, wo alle hinschauen — sie scheitern an den Sonderfällen und Ausnahmen, die im Workshop niemand laut ausgesprochen hat. Wer «müsste funktionieren» sagt, meint fast immer den Happy Path. Die teure Wahrheit steckt in allem, was daneben passiert.
Die gute Nachricht: Man muss nicht hoffen. Man kann beweisen. Und zwar auf zwei komplementären Wegen, die sich nicht ersetzen, sondern ergänzen.
Zwei Arten von Beweis: Verifikation und Test
Software-Ingenieure kennen die Unterscheidung seit Jahrzehnten, in der Prozesswelt wird sie oft vergessen. Es gibt zwei grundverschiedene Fragen an ein Modell:
- Ist der Prozess in sich schlüssig? Das ist eine strukturelle Frage — sie hat mit der Logik des Modells zu tun, nicht mit einem konkreten Fall. Antwort liefert die Verifikation.
- Tut der Prozess bei diesem konkreten Fall das Erwartete? Das ist eine inhaltliche Frage — sie prüft ein bestimmtes Szenario gegen ein erwartetes Ergebnis. Antwort liefert der Test.
Beide Fragen sind wichtig, und keine beantwortet die andere. Ein Prozess kann formal makellos sein und trotzdem das fachlich Falsche tun. Und ein Prozess kann in einem einzelnen Testszenario grün leuchten und trotzdem eine strukturelle Falle enthalten, die erst der 200. Fall auslöst.
Verifikation: die Theorie der sauberen Enden
Die formale Prozess-Verifikation ist keine Erfindung der letzten Jahre. Ihre theoretische Grundlage geht auf die Arbeit von Wil van der Aalst zurück, der 1997 in der Petri-Netz-Forschung für sogenannte Workflow-Netze die Eigenschaft Soundness definiert hat (van der Aalst, 1997). Vereinfacht besagt Soundness: Von jedem erreichbaren Zustand aus lässt sich der definierte Endzustand erreichen; wenn dieser Endzustand erreicht ist, ist kein anderer Teil des Prozesses mehr aktiv; und es gibt keine Aktivität, die grundsätzlich nie ausgeführt werden kann.
In der Alltagssprache heisst das dreierlei:
1. Kein Deadlock. Der Prozess bleibt nirgends stecken, wo er ewig auf etwas wartet, das nie kommt. 2. Keine verwaisten Token. Wenn der Prozess «fertig» meldet, läuft nicht heimlich noch ein vergessener Zweig weiter. 3. Jeder Fall erreicht ein sauberes Ende. Es gibt keine toten Aktivitäten und keine Sackgassen ohne Ausgang.
Dumas, La Rosa, Mendling und Reijers behandeln diese Verhaltenskorrektheit in ihrem Standardwerk Fundamentals of Business Process Management als eigene Qualitätsdimension neben der reinen syntaktischen Korrektheit (Dumas et al., 2018). Der Punkt ist subtil, aber entscheidend: Ein Modell kann jede Regel der BPMN-Notation befolgen — sauber gezeichnet, valides XML nach der Spezifikation der Object Management Group (OMG, 2013) — und trotzdem einen Deadlock enthalten. Syntax garantiert keine Schlüssigkeit. Genau das prüft die Verifikation, ohne einen einzigen Testfall zu brauchen.
Test: das erwartete Ergebnis zählt
Verifikation sagt Ihnen, dass der Prozess niemals steckenbleibt. Sie sagt Ihnen nicht, dass er beim Szenario «Antrag über 50’000 Franken» korrekt in die Vier-Augen-Genehmigung verzweigt. Das ist eine fachliche Aussage, und fachliche Aussagen prüft man wie in der Softwareentwicklung: mit konkreten Szenarien und einem vorher festgelegten erwarteten Ergebnis.
Ein Testszenario ist nichts anderes als: Gegeben diese Eingaben und diese Umstände — welchen Weg soll der Prozess nehmen, und in welchem Zustand soll er enden? Man definiert das Erwartete vorher, spielt das Szenario durch und vergleicht. Grün oder rot. Kein «müsste».
Die Ränder sind der eigentliche Prüfstand
Der Wert des Testens entsteht nicht aus dem Happy Path — den prüft man in fünf Minuten und er geht fast immer durch. Der Wert entsteht aus der disziplinierten Frage: Was kann alles schiefgehen? Und daraus, dass man für jede dieser Antworten ein erwartetes Ergebnis festhält, bevor man den Prozess produktiv schaltet.
Nehmen wir einen schlichten Freigabeprozess für einen Antrag. Der Happy Path ist trivial. Interessant wird es an den Rändern:
| Szenario | Erwartetes Ergebnis | Status |
|---|---|---|
| Vollständiger Antrag, Betrag unter Limit | Automatisch freigegeben, Ende «Genehmigt» | 🟢 |
| Vollständiger Antrag, Betrag über Limit | Vier-Augen-Genehmigung, dann Ende «Genehmigt» | 🟢 |
| Unvollständiger Antrag | Rückweisung an Antragsteller, Ende «Nachbesserung» | 🔴 |
| Frist läuft während der Prüfung ab | Eskalation an Vorgesetzten, Ende «Eskaliert» | 🟢 |
| Antrag wird während der Prüfung zurückgezogen | Sauberer Abbruch, Ende «Zurückgezogen» | 🔴 |
Zwei rote Zeilen — und beide betreffen keinen exotischen Sonderfall, sondern Alltag. Der unvollständige Antrag hat keinen sauberen Rückweg, weil im Modell die entsprechende Kante fehlt. Und der Rückzug während der Prüfung? Ein klassischer Kandidat für ein verwaistes Token: Der Prüfzweig läuft weiter, obwohl der Fall längst beendet sein sollte. Genau die Sorte Fehler, die im Betrieb Wochen später als «komischer Geisterfall» im Support landet — und die man hier, vor dem Go-live, für ein paar Minuten Nachdenken einfängt.
Schematisch sind es die markierten Ausnahmepfade, nicht die Hauptlinie, die den Ausschlag geben:
Die durchgezogene Linie ist der Happy Path. Die gestrichelten Kanten sind die Ränder — und dort entscheidet sich, ob der Prozess im Ernstfall trägt oder kippt.
Warum «erst beweisen» vor dem Go-live gehört
Der Zeitpunkt ist nicht Nebensache, er ist der ganze Punkt. Ein Fehler, den man im Modell findet, kostet eine Korrektur am Modell. Derselbe Fehler, im produktiven Betrieb entdeckt, kostet einen Support-Fall, eine Notfall-Analyse, eine Hotfix-Freigabe, womöglich einen falsch bearbeiteten Kundenvorgang — und Vertrauen. Die Kurve ist bekannt: Je später der Fund, desto teurer die Behebung. Beweisen heisst deshalb vor allem: früh beweisen, solange Fehler noch billig sind.
Und «beweisen» meint beides zusammen. Verifikation fängt die strukturellen Fallen, die kein noch so gründlicher Tester manuell durchdenken würde. Testen fängt die fachlichen Fehler, die kein Verifikationsalgorithmus kennen kann, weil sie von Ihrer Domäne abhängen. Erst die Kombination ergibt einen Prozess, dem man glauben darf — nicht weil er «müsste», sondern weil man es geprüft hat.
Test & Fix in MESTRO: den Prozess selbst prüfen, nicht ein Abbild
Hier setzt die Test-&-Fix-Phase von MESTRO an. Bevor ein Prozess produktiv geht, wird er gegen konkrete Szenarien geprüft — Normalfall, Sonderfälle, Ausnahmen — jeweils mit einem erwarteten Ergebnis, gegen das MESTRO das tatsächliche Verhalten vergleicht. Aus der Tabelle weiter oben wird kein Papier, sondern eine ausführbare Prüfung: grün oder rot, Szenario für Szenario.
Der entscheidende Unterschied liegt darin, was geprüft wird. In der klassischen Welt testet man ein System, das aus dem Modell irgendwann einmal abgeleitet wurde — man prüft also ein Abbild und hofft, dass es dem Modell noch entspricht. In MESTRO ist das Modell die Quelle der Umsetzung (siehe «Von der Serviette zum laufenden Prozess»). Man testet damit den Prozess selbst, nicht seinen Schatten. Was grün leuchtet, leuchtet für die Realität, die produktiv geht.
Findet ein Szenario einen Fehler, führt der Weg zurück ins Modell — dort, wo die Ursache sitzt, nicht in einer nachgelagerten Codeschicht. Korrigieren, erneut prüfen, bis alle Szenarien tragen: die Test-↔-Fix-Schleife, im selben Werkzeug, ohne Werkzeugbruch zwischen Finden und Beheben. Dass die Design-Phase Method-&-Style-konforme Modelle mit expliziten Endzuständen liefert, ist dabei kein kosmetisches Detail, sondern die Voraussetzung fürs Testen: Nur wenn klar definiert ist, wo ein Fall sauber enden soll, kann man überhaupt prüfen, ob er dort ankommt (siehe «Schöne Diagramme sind kein Luxus»).
Und weil Prüfung selten in einem Werkzeug allein lebt, sind die Testfälle exportierbar — etwa als Test-Issues nach Xray/JIRA. So wandert die szenariobasierte Absicherung in die bestehende QA-Landschaft, statt neben ihr ein Inseldasein zu führen. MESTRO erzeugt dabei durchgehend Standard-BPMN und -CMMN; die Beweise hängen nicht an einem proprietären Format.
Fazit
«Müsste funktionieren» ist keine Aussage über einen Prozess, sondern über die Hoffnung seines Autors. Ersetzen lässt sie sich durch etwas Belastbareres: durch Verifikation, die strukturell garantiert, dass der Prozess nirgends steckenbleibt und jeder Fall ein sauberes Ende findet — und durch Tests, die szenariobasiert nachweisen, dass er auch das fachlich Richtige tut, gerade an den Rändern, wo Prozesse tatsächlich scheitern. Beides gehört vor den Go-live, wo Fehler noch billig sind. Erst beweisen, dann glauben — und weil in MESTRO das Modell die Quelle ist, prüft man den Prozess selbst, nicht ein Abbild von ihm.
Quellen & Weiterlesen
- W. M. P. van der Aalst: Verification of Workflow Nets. In: Application and Theory of Petri Nets 1997, LNCS 1248, Springer, 1997 (Soundness-Eigenschaft).
- M. Dumas, M. La Rosa, J. Mendling, H. A. Reijers: Fundamentals of Business Process Management, 2. Auflage, Springer, 2018.
- Object Management Group: Business Process Model and Notation (BPMN) Version 2.0.2, 2013. https://www.omg.org/spec/BPMN/2.0.2/
