Manche Abläufe sind ein Fliessband: Ein Auslöser kommt herein, durchläuft eine feste Folge von Stationen und verlässt den Prozess als fertiges Ergebnis. Bestellung annehmen, Bonität prüfen, Ware versenden, Rechnung stellen. Die Reihenfolge steht vorab fest, Abweichungen sind Ausnahmen, die man als eigene Pfade modelliert. Für solche Abläufe ist BPMN gemacht — und BPMN ist darin exzellent.
Andere Abläufe sind kein Fliessband. Eine Sachbearbeiterin, die einen komplexen Schadenfall bearbeitet, folgt keiner vorab festgelegten Stationenfolge. Sie prüft, holt Gutachten ein, fragt nach, entscheidet — in einer Reihenfolge, die sich erst aus dem Fall selbst ergibt. Wer versucht, das in ein BPMN-Fliessband zu pressen, produziert entweder ein Diagramm, das die Realität verfehlt, oder ein Gateway-Dickicht, das niemand mehr liest. Für genau diese Art von Arbeit gibt es eine zweite Notation: CMMN.
Zwei Leitfragen, zwei Notationen
Der Unterschied lässt sich auf eine einzige Frage zuspitzen, die jede der beiden Notationen beantwortet.
BPMN — Business Process Model and Notation, seit 2013 in der Fassung 2.0.2 ein Standard der Object Management Group — beantwortet die Frage: In welcher Reihenfolge? Ein BPMN-Diagramm legt einen Kontrollfluss fest. Sequenzflüsse verbinden Aktivitäten, Gateways verzweigen und führen zusammen, und der Weg vom Startereignis zum Endzustand ist im Modell vorgezeichnet. Das Modell schreibt vor, was als Nächstes kommt.
CMMN — Case Management Model and Notation, seit 2016 in der Fassung 1.1 ein Standard derselben Organisation — beantwortet eine andere Frage: Was ist jetzt erlaubt und sinnvoll? Ein CMMN-Modell legt keinen Pfad fest, sondern einen Handlungsraum. Es beschreibt, welche Aktivitäten in einem Fall grundsätzlich verfügbar sind, welche davon verpflichtend sind, unter welchen Bedingungen etwas freigeschaltet oder gesperrt wird und woran man erkennt, dass ein Zwischenziel erreicht ist. Welche der erlaubten Handlungen der Bearbeiter tatsächlich wählt und in welcher Reihenfolge, entscheidet er zur Laufzeit — im Rahmen der Regeln.
Eine Metapher bringt es auf den Punkt: BPMN ist ein Gleis, CMMN ist ein Spielfeld mit Regeln. Auf dem Gleis gibt es genau eine Richtung; Weichen sind vorgesehen, aber der Zug bleibt auf den Schienen. Auf dem Spielfeld darf sich der Spieler frei bewegen — die Regeln sagen, was erlaubt ist und wann das Spiel gewonnen ist, nicht, welchen Laufweg er nehmen muss.
Warum Wissensarbeit kein Gleis verträgt
Der Grund, warum diese zweite Notation überhaupt gebraucht wird, hat einen Namen und eine Geschichte. Bereits 1959 prägte Peter F. Drucker in Landmarks of Tomorrow den Begriff des „knowledge worker“ — des Wissensarbeiters, dessen Produktivität nicht daran hängt, eine vorgegebene Handbewegung schneller auszuführen, sondern daran, aus Wissen und Urteilsvermögen die jeweils richtige Handlung abzuleiten.
Genau hier liegt die Grenze des Fliessbands. Die Arbeit eines Wissensarbeiters folgt keiner starren Reihenfolge, weil die Reihenfolge selbst Teil dessen ist, was er entscheidet. Ein Anwalt, der einen Fall aufbaut, eine Ärztin, die eine Diagnose stellt, ein Kreditanalyst, der einen unüblichen Antrag prüft: Sie alle arbeiten fallgetrieben, nicht ablaufgetrieben. Der Versuch, jede denkbare Reihenfolge in BPMN vorab zu verdrahten, endet in einem Modell, das mehr Ausnahmen als Regel enthält — unlesbar und trotzdem unvollständig.
Für diese Klasse von Arbeit entstand eine eigene Disziplin, das Adaptive Case Management, prominent umrissen im Sammelband Mastering the Unpredictable (herausgegeben von Keith Swenson, 2010). Sein Untertitel ist Programm: Es geht um die Frage, wie Wissensarbeiter das Unvorhersehbare bewältigen — durch Modelle, die den Rahmen setzen, statt den Weg vorzuschreiben. CMMN ist die Notation, die diese Denkweise standardisiert.
BPMN und CMMN im direkten Vergleich
Die folgende Tabelle stellt die beiden Notationen nebeneinander — nicht als Rangliste, sondern als Entscheidungshilfe.
| Aspekt | BPMN 2.0 | CMMN 1.1 |
|---|---|---|
| Leitfrage | In welcher Reihenfolge? | Was ist jetzt erlaubt und sinnvoll? |
| Metapher | Gleis: eine vorgezeichnete Richtung | Spielfeld mit Regeln: freie Bewegung im Rahmen |
| Steuerprinzip | Vorgegebener Kontrollfluss (Sequenzflüsse) | Möglicher Handlungsraum (Bedingungen, Freischaltungen) |
| Wer bestimmt die Reihenfolge? | Das Modell, vorab | Der Bearbeiter, zur Laufzeit |
| Typische Einsatzfälle | Bestellabwicklung, Onboarding, wiederkehrende Freigaben | Schadenbearbeitung, Ermittlungen, Diagnostik, Beratung |
| Kernelemente | Aktivitäten, Sequenzflüsse, Gateways, Ereignisse, Pools/Lanes | Stages, Human/Process Tasks, Sentries, Meilensteine, Ereignis-Listener |
| Charakter | Ablaufgetrieben, vorhersehbar | Fallgetrieben, unvorhersehbar |
Ein Blick auf die Kernelemente zeigt den Denkunterschied. In BPMN ist der Sequenzfluss das prägende Element — der Pfeil, der A mit B verbindet und sagt „danach“. In CMMN gibt es keinen vorgeschriebenen Pfeil zwischen Aufgaben. Stattdessen steuern Sentries — bewachte Ein- und Ausgänge — wann eine Aktivität verfügbar wird oder ein Abschnitt endet; Meilensteine markieren erreichte Zwischenziele; Stages bündeln zusammengehörige Aufgaben; und Ereignis-Listener reagieren auf Zeitpunkte oder Nutzerentscheidungen. Das Modell beschreibt Verfügbarkeit und Bedingung, nicht Abfolge.
Ein Beispiel: dieselbe Domäne, zwei Charaktere
Nehmen wir eine Versicherung. Zwei Abläufe, beide real, beide legitim — und doch verlangen sie verschiedene Notationen.
Der Fliessband-Teil — BPMN. Die Erstaufnahme einer Schadenmeldung ist ein vorhersehbarer Ablauf: Meldung entgegennehmen, Vollständigkeit prüfen, Fall anlegen, an die Sachbearbeitung übergeben. Feste Reihenfolge, klare Endzustände.
(Schematische Skizze — vereinfachte Illustration, kein vollständig normkonformes BPMN.)
Der Spielfeld-Teil — CMMN. Sobald der Fall in der Sachbearbeitung liegt, endet die Vorhersehbarkeit. Die Sachbearbeiterin kann ein Gutachten beauftragen, muss die Deckung prüfen, darf bei Verdacht die Betrugsprüfung anstossen, und der Fall gilt erst als entscheidungsreif, wenn bestimmte Bedingungen erfüllt sind. Keine dieser Handlungen hat eine feste Position in einer Reihenfolge — welche sie wählt und wann, ergibt sich aus dem Fall. In CMMN heisst das: eine Stage „Schaden bearbeiten“ mit mehreren Human Tasks, einige verpflichtend, einige durch Sentries freigeschaltet, ein Meilenstein „entscheidungsreif“ als Zwischenziel. Ein BPMN-Diagramm desselben Sachverhalts müsste jede Reihenfolge als eigenen Pfad zeichnen — und würde an seiner eigenen Kombinatorik ersticken.
Die Pointe: Es ist ein Geschäftsvorfall, aber er hat zwei Charaktere. Der Anfang ist ein Gleis, die Mitte ist ein Spielfeld. Eine ehrliche Modellierung braucht beide Notationen — und einen sauberen Übergang zwischen ihnen.
MESTRO: die Notation ableiten, nicht wählen lassen
An diesem Punkt entscheidet sich in der Praxis viel — und hier liegt eine Designentscheidung von MESTRO, die den Unterschied zwischen den Notationen ernst nimmt, statt ihn dem Anwender aufzubürden.
In vielen Werkzeugen ist die Notation ein manueller Schalter: Der Modellierer legt zu Beginn fest „das wird ein BPMN-Prozess“ oder „das wird ein CMMN-Fall“ — und trifft damit eine Entscheidung, für die er das Wissen aus diesem Artikel bereits braucht. Wer den Charakterunterschied nicht kennt, wählt falsch und merkt es erst, wenn das Diagramm unlesbar wird.
MESTRO leitet die Notation aus dem Prozesscharakter ab, statt sie abzufragen. Beschreibt ein Ablauf eine vorgegebene Reihenfolge, entsteht BPMN; beschreibt er einen Handlungsraum mit fallgetriebener Freiheit, entsteht CMMN. Die Frage „Gleis oder Spielfeld?“ beantwortet nicht ein Dropdown, sondern die Analyse des Ablaufs selbst. Beide Notationen sind dabei erstklassig und gleichwertig umgesetzt: MESTRO erzeugt und editiert BPMN und CMMN nativ — einschliesslich der CMMN-Feinheiten, an denen viele Werkzeuge scheitern: Stages, Sentries, Meilensteine und Ereignis-Listener. CMMN ist kein nachträglich angeflanschter Zweitmodus, sondern gleichberechtigte Sprache.
Entscheidend für die gemischte Realität aus dem Versicherungsbeispiel ist der Übergang: In MESTRO kann ein BPMN-Prozess in einen CMMN-Fall hineinzoomen und umgekehrt. Die Erstaufnahme bleibt ein sauberes BPMN-Gleis; die Aktivität „Schaden bearbeiten“ öffnet sich beim Hineinzoomen als CMMN-Spielfeld — genau dort, wo der Charakter des Ablaufs kippt. So muss niemand einen von Natur aus gemischten Vorgang in eine einzige Notation zwängen.
Und weil die Wahl der Notation eine fachliche Entscheidung mit Folgen ist, bleibt der Mensch in der Schleife: MESTRO arbeitet zunächst auf einem Work-Pad, einer Arbeitsfläche, deren Ergebnis erst durch bewusste Übernahme zum verbindlichen Modell wird — kein stilles Überschreiben. Der Output ist in beiden Fällen Standard: BPMN 2.0 beziehungsweise CMMN 1.1, ohne proprietäre Erweiterungen, die nur MESTRO selbst wieder lesen könnte.
Fazit
Die häufigste Modellierungssünde ist nicht ein falsch gesetztes Gateway — sie ist eine falsch gewählte Notation. Wer einen fallgetriebenen Ablauf in ein BPMN-Fliessband presst, kämpft von der ersten Aktivität an gegen die Natur des Prozesses. BPMN und CMMN sind keine konkurrierenden Standards, zwischen denen man sich für immer entscheiden müsste, sondern zwei Werkzeuge für zwei Fragen: „In welcher Reihenfolge?“ und „Was ist jetzt erlaubt und sinnvoll?“. Beide sind OMG-Standards, beide sind ausgereift, und die reifste Modellierungspraxis ist die, die je Ablauf das passende wählt — und Mischformen zulässt, weil die Wirklichkeit selten reinrassig ist. Nicht jeder Ablauf ist ein Fliessband. Man sollte auch nicht so tun.
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/
- Object Management Group: Case Management Model and Notation (CMMN) Version 1.1, 2016. https://www.omg.org/spec/CMMN/1.1/
- K. Swenson (Hg.): Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done, Meghan-Kiffer Press, 2010.
- P. F. Drucker: Landmarks of Tomorrow, Harper & Brothers, 1959 (prägt den Begriff „knowledge worker“).
- M. Dumas, M. La Rosa, J. Mendling, H. A. Reijers: Fundamentals of Business Process Management, 2. Auflage, Springer, 2018.
