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 ein Spielfeld braucht
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.
Die Entscheidung fällt zuoberst
Die praktisch wichtigste Frage kommt vor der Wahl der Notation — und sie betrifft nicht die einzelne Aktivität, sondern den End-to-End-Prozess: Ist der ganze Vorgang ein Fliessband oder ein Spielfeld? Diese eine Entscheidung legt den Rahmen fest, in dem alles Weitere steht.
Ist der End-to-End-Prozess ein Fliessband, dann ist er ein BPMN-Prozess — von vorn bis hinten, in einem einzigen Kontext. Bestellung annehmen, Bonität prüfen, Ware versenden, Rechnung stellen: Es gibt keinen Fall, keinen Handlungsraum und keinen Grund für eine zweite Notation. Das ist der Normalfall in Beschaffung, Logistik und Abwicklung — und dort ist «Methode & Stil» die ganze Antwort.
Ist der End-to-End-Prozess ein Spielfeld, kehrt sich das Verhältnis um. Ein Schadenfall ist von der Meldung bis zur Auszahlung ein Fall: Was als Nächstes zulässig ist, ergibt sich aus seinem Status und aus Regeln, nicht aus einer vorgezeichneten Reihenfolge. Die Sachbearbeiterin muss die Deckung prüfen, kann ein Gutachten beauftragen, darf bei Verdacht die Betrugsprüfung anstossen; entscheidungsreif wird der Fall erst, wenn bestimmte Bedingungen erfüllt sind. In CMMN heisst das: eine Stage mit mehreren Human Tasks, einige verpflichtend, einige durch Sentries freigeschaltet, ein Meilenstein „entscheidungsreif“ als Zwischenziel.
Der Fall als Klammer: Was zulässig ist, entscheiden Status und Regeln — nicht eine Reihenfolge. Die Erstaufnahme, das Gutachten, die Betrugsprüfung und die Auszahlung sind Process Tasks: Sie rufen eigenständige BPMN-Prozesse auf. Gezeichnet aus dem CMMN-1.1-Modell.
Und genau hier ruft der Fall strukturierte Abläufe auf. Die Erstaufnahme einer Schadenmeldung ist ein Fliessband: Meldung erfassen, Vollständigkeit prüfen, Fall anlegen, übergeben. Für die Auszahlung gilt dasselbe. Beide sind vorhersehbar, beide haben eine feste Reihenfolge und klare Endzustände — beide gehören als eigener BPMN-Prozess modelliert und werden aus dem Fall heraus aufgerufen, sobald dessen Status und Regeln es zulassen. Der Fall bleibt die Klammer; das Fliessband ist ein Werkzeug, das er benutzt.
Einer der gerufenen Abläufe: die Erstaufnahme. Ein sauberes Gleis mit eigenem Anfang und Ende — aufgerufen aus dem Fall, nicht ihn umschliessend. (Schematische Skizze, kein vollständig normkonformes BPMN.)
Die Pointe: Die Klammer ist der Fall, nicht der Ablauf. Wer zuerst das Fliessband zeichnet und den Fall darin unterbringen will, hat die Ebenen vertauscht — und merkt es spätestens dort, wo die Erstaufnahme ein Endereignis braucht, das in Wahrheit gar kein Ende ist, sondern nur ein Statuswechsel im Fall.
Und die Regel? Die gehört in keines von beiden
Im Fall steht eine Aufgabe, die anders ist als die übrigen: Betrugsverdacht ermitteln. Sie erledigt keine Arbeit — sie stellt eine Frage und bekommt eine Antwort. In CMMN heisst das ein Decision Task, und das Tabellensymbol in seiner Ecke sagt, wohin er sich wendet.
Der bequeme Weg wäre ein anderer gewesen. Man hätte die Regel in den Wächter schreiben können, der die Aufgabe freischaltet: „wenn Schaden über 50 000 und Vertrag jünger als drei Monate“. Das funktioniert — und kostet drei Dinge. Die Regel ist unsichtbar: Sie steht in einer Bedingung, die nur sieht, wer das Modell öffnet. Sie ist nicht prüfbar: Es gibt keine Stelle, an der ein Fachbereich nachlesen könnte, was gilt. Und sie verändert das Prozessmodell, sobald sich ein Schwellwert ändert. Schwellwerte ändern sich.
Bevor eine Entscheidung getroffen werden kann, muss feststehen, woraus sie gespeist wird. Diese Ebene heisst in DMN das Anforderungsdiagramm — es benennt die Eingaben und was am Ende herauskommt, ohne schon zu sagen, wie gerechnet wird:
Drei Eingaben, eine Entscheidung, drei mögliche Antworten. Bei einer einstufigen Entscheidung wie dieser geht man in der Umsetzung oft direkt zur Tabelle — methodisch gehört dieser Schritt aber davor, denn er zwingt dazu, die Eingaben zu benennen.
Deshalb wandert sie hinaus — in eine Entscheidungstabelle:
Die Entscheidung „Betrugsverdacht“: vier Eingaben, fünf Regeln, eine Antwort. Der Fall ruft sie auf und reagiert auf das Ergebnis.
Zwei Dinge daran verdienen Aufmerksamkeit. Das F oben links ist die Trefferregel. Sie beantwortet, was gilt, wenn mehrere Zeilen zutreffen — und das ist hier der Normalfall: Ein Schaden von 60 000 auf einem zwei Monate alten Vertrag, mit drei Vorschäden, gemeldet nach 40 Tagen, erfüllt alle fünf Zeilen. F heisst: Die erste von oben gewinnt, also „hoch“. Damit trägt die Reihenfolge Bedeutung — wer zwei Zeilen vertauscht, ändert das Verhalten, ohne dass es jemand sieht. Die Vorgabe der Spezifikation wäre U: Dann dürfte höchstens eine Zeile zutreffen, und die Tabelle bräuchte statt fünf rund ein Dutzend überschneidungsfreie Zeilen.
Die letzte Zeile ist die Auffangzeile. Ohne sie liefe die Entscheidung für den Normalfall ins Leere — und der Normalfall ist der häufigste. Eine Entscheidungstabelle ohne Auffangzeile ist der stille Klassiker unter den Fehlern.
Der Fall reagiert dann auf das Ergebnis, nicht auf eine Vermutung: „Ermittlung einleiten“ öffnet sich, wenn der Verdacht hoch ist. Was zu tun ist, bleibt im Fall. Was gilt, steht in der Tabelle. Ändert sich der Schwellwert, ändert sich eine Zelle — und kein Prozessmodell.
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 ist dabei die Ebene, nicht die einzelne Aktivität. MESTRO bestimmt den Charakter des End-to-End-Prozesses und leitet daraus den Kontext ab: Ein Fliessband wird ein BPMN-Kontext, ein Spielfeld ein CMMN-Fall. Und weil ein Fall in aller Regel strukturierte Abläufe braucht, ruft er sie auf — jeder gerufene Ablauf ein sauberes BPMN-Gleis mit eigenem Anfang und Ende, gestartet aus dem Fall heraus, sobald dessen Status und Regeln es zulassen. So muss niemand einen fallgetriebenen Vorgang in ein Fliessband pressen — und ebenso wenig ein Fliessband künstlich zum Fall erklären.
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, CMMN und DMN sind keine konkurrierenden Standards, zwischen denen man sich für immer entscheiden müsste, sondern drei Werkzeuge für drei Fragen: „In welcher Reihenfolge?“, „Was ist jetzt erlaubt und sinnvoll?“ und „Was gilt hier?“. Beide sind OMG-Standards, beide sind ausgereift, und die reifste Modellierungspraxis ist die, die zuerst den End-to-End-Prozess einordnet und dann darin arbeitet — ein Fliessband bleibt ein Fliessband, ein Fall ruft die Fliessbänder, die er braucht. 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.
