© BMI DV

Gleich vorweggenommen: CMMN ist nur für BPMN-Profis geeignet. Wer noch nicht an den Punkt gekommen ist, an dem mit den forgeschrittenen Möglichkeiten Ad-hoc und Ereignisunterprozessen von BPMN kein sinnvolles Modell eines Sachverhalts erzeugt werden kann, benötigt CMMN derzeit nicht.

Auch sind riesige, unübersichtliche CMMN-Diagramme wie der Projektablauf im Einstieg keine sinnvollen Anwendungen für CMMN. Denn CMMN wurde ausdrücklich nicht für strukturierte Abläufe geschaffen, wie sie in der Grafik über weite Strecken abgebildet sind. Wer CMMN verwenden will, muss das Ebenenkonzept von BPMN verinnerlicht haben und in der Lage sein, genau die Informationen herauszufiltern, die für ein CMMN-Diagramm sinnvoll zu modellieren sind.

© BMI DV

Nehmen wir einen einfachen BPMN-Prozess, bestehend aus 5 Aktivitäten und einer Verzweigung. Nach dem Start werden die Aufgaben 1 und 2 abgearbeitet, dann wird auf Basis von Daten aus dem Prozess entschieden, ob entweder Aufgabe 3 oder Aufgabe 4 durchgeführt wird, nach der dann Aufgabe 5 durchgeführt wird. BPMN führt die Aufgaben sequenziell durch, d. h. bevor Aufgabe 1 nicht abgeschlossen ist, kann Aufgabe 2 nicht starten.

© BMI DV

Schauen wir uns dagegen den sehr ähnlich aussehenden Ablauf in CMMN an, gibt es einige Unklarheiten. Vor Aufgabe 2 sitzt ein Wächter, der eine Bedingung für den Start von Aufgabe 2 enthalten kann. Um konform mit dem BPMN-Diagramm zu sein, müsste die Bedingung lauten: „Aufgabe 1 komplett“. Fehlt die Bedingung beginnt Aufgabe 2 unmittelbar nach dem Start von Aufgabe 1 zu laufen, auch wenn Aufgabe 1 noch nicht abgeschlossen ist.

Schlimmer noch: die Verzweigung, die in BPMN als exklusives Gateway existiert, sagt hier nicht aus, ob nur Aufgabe 3 oder 4 oder beide ausgeführt werden können. Ein exklusives Gateway müsste mit komplexen Eingangsbedigungen versehen werden, die allerdings nicht grafisch angezeigt werden. Man müsste also in die Attribute des Diagramms eintauchen, um hier Klarheit zu bekommen.

Das alles zeigt, dass CMMN niemals als Ersatz für BPMN gedacht war. Es ist - wie auch DMN - eine Ergänzung für spezielle Anwendungsfälle.

Genau wie BPMN ist CMMN von Anfang an auf Automatisierung ausgelegt, d. h. CMMN-Diagramme können in entsprechenden Ablaufumgebungen direkt ausgeführt werden. Daher ist die Logik von CMMN viel einfacher zu verstehen, wenn man zumindest über grundlegende Programmierkenntnisse verfügt.

All das zeigt, dass CMMN nicht für Einsteigerinnen und Einsteiger geeignet ist. Warum es sich dennoch lohnt, finden Sie im 2. Schritt.

Ein Zustandsautomat ist ein System, das Objekte mit Zuständen versieht, um damit einen Ablauf zu erzeugen. So kann ein Dokument den Status „In Bearbeitung“, „Vorgelegt“ oder „Final“ besitzen, wobei durch die einzelnen Statuswerte auch ein Workflow zur Finalisierung beschrieben wird.

Aber fangen wir mit einem anderen Beispiel an. Wenn eine Person ein Beschäftigungsverhältnis mit einer Organisation beginnt, benötigt sie heutzutage mindestens ein Benutzerkonto. Das Benutzerkonto ist normalerweise aktiv, kann aber auch inaktiv gestellt werden, z. B. weil die Person beurlaubt ist. Nach der Beurlaubung wird das Konto wieder reaktiviert. Versuchen wir das einmal in BPMN abzubilden.

© BMI DV

Sieht schon ziemlich kompliziert aus. Verfolgen wir das Diagramm einmal nach: Am Anfang steht die Aktion Benutzer anlegen. Wir gehen davon aus, dass eine Person durch aus auch mehrere Benutzerkonten haben kann, und manche von denen Aktiv und andere Inaktiv sind.

Nach zwei schließenden Gateways steht das Warten auf das nächste Ereignis. Wenn ein Ereignis eingetreten ist, muss der zugehörige Pfad gewählt werden. Ist ein Benutzerkonto hinzuzufügen, wird es in einem Teilprozess erledigt und dann auf das nächste Ereignis gewartet. Sind mehrere Benutzerkonten anzulegen, werden die der Reihe nach abgearbeitet, bevor der Prozess wieder wartet.

Ist ein Konto zu deaktivieren, weil z. B. eine Aufgabe nicht mehr wahrgenommen wird, dann wird es kompliziert. Das parallele Gateway erzeugt ein zusätzliches Token. Das eine Token läuft zurück zum Warten auf ein Ereignis, z. B. das Anlegen eines weiteren Benutzerkontos. Das zweite Token erledigt die Deaktivierung in einem Teilprozess. Jetzt muss wieder gewartet werden, aber mit anderen möglichen Ergebnissen. Deshalb läuft der Prozess nicht zurück, sondern hat eine neue Warteaktivität in diesem Pfad. Wenn das Benutzerkonto wieder reaktiviert werden soll, dannn wird das in einem weiteren Teilprozess durchgeführt und wieder zurück zum zusammenführenden Gateway.

Und hier haben wir schon das erste Problem: Der BPMN-Prozess würde am schließenden parallelen Gateway warten, bis beide Token angekommen sind. Während also ein Benutzerkonto deaktiviert ist, kann kein weiteres deaktiviert oder angelegt werden.

Wenn der Benutzer gelöscht werden soll, weil die Person die Organisation verlässt, müssen nicht nur sämtliche Benutzerkonten gelöscht werden, sondern auch alle laufenden Aktivitäten abgebrochen. Daher das Eskalationsereignis, das in allen Aktivitäten als unterbrechendes angehängtes Ereignis modelliert ist. Nicht ganz BPMN-konform, aber besser geht es nicht.

Wie man sieht, kann man den Prozess gar nicht sematisch korrekt modellieren, extrem kompliziert ist er auch. Aber probieren wir das mal mit einem Ad-hoc-Prozess.

© BMI DV

Der Prozess sieht schon viel klarer aus. Nach dem grundsätzlichen Anlegen des Benutzers folgt ein Ad-hoc-Teilprozess, erkennbar an der Tilde unten. Dort sind zwei Aktivitäten modelliert, die nicht in der angegebenen Reihenfolge ablaufen müssen, Benutzerkonto anlegen und Benutzerkonto deaktivieren. Das Deaktivieren kann, muss aber nicht mit einem Löschen des Benutzers einhergehen.

Wird das Konto gelöscht, wird der ereignisbasierte Unterprozess „Benutzerkonto löschen“ ausgelöst, der alle Konten und den Benutzer löscht. Problem hier: Der Ereignisunterprozess kann nicht den aufrufenden Hauptprozess terminieren. Das würde ein spezifisches Endereignis und einen Ereignis-Handler am Ereignisunterprozess erfordern, auf den dann der Teilprozess mit einer weiteren Verzweigung reagiert.

Wurde das Konto deaktiviert, dann kommt der nächste Ad-hoc-Teilprozess zum Einsatz, in dem die Aktivität Benutzerkonto reaktivieren enthalten ist. Allerdings wird hier nicht klar, ob das sofort oder in Abhängigkeit von Voraussetzungen erfolgt.

Außerdem kann man auch hier wieder keine Benutzerkonten anlegen, wenn eines deaktiviert wurde. Auch der Ad-hoc-Ansatz bringt uns keine brauchbare Lösung.

Sie konnten bis hierher problemlos folgen? Dann sind Sie reif für CMMN.

© BMI DV

Was sehen wir hier? Eine Fallakte bildet in diesem Zustandsänderungsdiagramm den Rahmen um den gesamten Ablauf. Die Aktivität „Benutzer anlegen“ ruft einen Prozess auf und wird gestartet, sobald der Fall gestartet ist. Wenn die Aktivität vollständig ist, kann die Aktivität „Benutzerkonto hinzufügen“ gestartet werden, und zwar manuell und mehrfach. Das Play-Symbol bedeutet, dass eine Person das starten muss, und die Raute, dass es mehrere Instanzen geben darf. Der Pfeil in der linken oberen Ecke verweist auf einen Prozess, der durch die Aktivität gestartet wird.

Ist das jeweilige Benutzerkonto hinzugefügt, wechselt die Instanz in die Phase „Aktiv“, die ebenfalls mehrfach ausgeführt werden kann, d. h. eine pro Benutzerkonto. Wenn in der Phase die manuell zu startende Aktion „Benutzerkonto deaktivieren" ausgeführt wird, wechselt das Konto in den Status Inaktiv. Von dort führt eine ebenfalls manuell zu startende Aktion „Benutzerkonto aktivieren“ zur Phase „Aktiv“. Jedes Konto wird also hier vorgehalten.

Neben dem Hauptlauf kann jederzeit die manuell zu startende Prozessaktivität „Benutzer löschen“. In der Grafik fehlt eine Linie, die zu einer schwarzen Raute am Rand der Fallakte führt. Das ist noch ein Fehler in der Software. Diese Linie zeigt, wie der Verlauf weiter geht, die schwarze Raute ist ein sogenannter „Wächter“, der die Bedingungen für das Ende der Fallakte inklusive aller enthaltenen Aktivitäts- und Phasen-Instanzen beschreibt. Die Aktion „Benutzer löschen“ beendet also auch die Fallakte für den Benutzer.

CMMN hilft uns hier sehr elegant aus unserem Problem mit BPMN.

Schauen wir uns noch ein komplizierteres Zustandsänderungsdiagramm in CMMN an:

© BMI DV

Für die Freigabe-Workflows von Prozessdiagrammen gibt es die Zustände „In Bearbeitung“, „Zur methodischen Freigabe“, „methodisch freigegeben“, „fachlich freigegeben“ und „archiviert“. Eine Zeitsteuerung fügt noch den Zustand „abgelaufen“ dazu.

Jeder Status besitzt eigene Aktionen, die jeweils zu einem anderen Status führen. Ausnahme ist hier die Aktion „Diagramm überarbeiten“, die den Status „In Bearbeitung“ beibehält. Im Status „Fachlich freigegeben“ existiert ein Zeitereignis, das den Status auf „abgelaufen“ setzen kann.

Aus den Zuständen „Abgelaufen“ und „Archiviert“ können Kopien zur erneuten Bearbeitung erzeugt werden, so dass eine neue Version des Prozessdiagramms gestaltet werden kann.

Versuchen Sie einmal, das in BPMN zu bauen.

Im nächsten Schritt schauen wir uns die verwendeten CMMN-Elemente einmal näher an.

© BMI DV

Fallaktenmodell

„Das Fallaktenmodell („Case File Model“) ist das kontextbildende Element der CMMN und dient als Klammer für die Fallbearbeitung. Es beinhaltet alle Elemente im CMMN-Diagramm. Es gibt Ähnlichkeiten zum Pool in BPMN 2.0. Allerdings muss zwingend genau ein Fallaktenmodell in einem CMMN-Diagramm existieren. Die Bezeichnung des Falls steht in dem Karteireiter oben.“

Eine Sonderform ist ein Fallaktenmodell, das eine automatische Beendigung („Auto Complete“) anzeigt. Dies wird durch ein Stopp-Symbol am unteren Rand angezeigt. Dieses wird benötigt, wenn manuell zu aktivierende Aktivitäten enthalten sind. Da eine manuell zu aktivierende Aktivität nicht zwangsläufig ausgeführt und daher dann auch nicht beendet wird, blockiert sie das Beenden des Fallaktenmodells unendlich lange. Die automatische Beendigung sorgt dafür, dass das Fallaktenmodell beendet wird, wenn keine aktiven Phasen oder Aufgaben mehr vorhanden sind.

© BMI DV

Phasen

„Die Phase („Stage“) ist ein Container und kann die nachfolgenden Elemente enthalten. Sie ist mit einem eingebetteten Teilprozess vergleichbar. Sie stellt einen abgegrenzten, überwachbaren Teil des Falls dar. Je nach Werkzeug kann sie auch auf- oder zugeklappt werden und dadurch ihre Inhalte zeigen oder verbergen. Im Fall von Zustandsänderungsdiagrammen werden Phasen zur Symbolisierung von Zuständen verwendet, in dem sich die referenzierte Objekte befinden.“

Wichtiger Hinweis:

Verbindungen dürfen laut Spezifikation der OMG nicht über Grenzen gehen. Ein Element innerhalb einer Phase darf nicht mit einem Element außerhalb der Phase verbunden werden. Von dieser Vorgabe wird für Zustandsänderungsdiagramme abgewichen, weil sonst nicht dargestellt werden kann, welche Aktion in welchem Zustand ausgeführt wird, und zu welchem weiteren Zustand sie führt.

Phasen können mehrere Markierungen besitzen, die auch miteinander kombiniert werden können:

• Optionale Phasen („Discretionary“) können ausgeführt werden, müssen aber nicht. Das gilt grundsätzlich zwar für alle Phasen, solange sie nicht als erforderlich markiert sind. Von daher ist der Mehrwert dieser Markierung fraglich. Da jedoch alle Phasen automatisch beginnen, wenn nichts anderes angegeben ist, muss eine optionale Phase zwingend mit einer Startbedingung oder einer manuellen Aktivierung versehen werden.
• Automatisch beendete Phasen („Auto Complete“) werden wie das Fallaktenmodell beendet, sofern keine Tätigkeit mehr darin aktiv ist.
• Manuell zu aktivierende Phasen („Manual Activation“) sind optional, sofern sie nicht zusätzlich als erforderlich markiert sind. Der Start der Phase erfolgt willkürlich durch den Fallbearbeiter, nicht automatisiert aufgrund von Regeln.
• Erforderliche Phasen („Required“) müssen zwingend beendet werden, bevor das übergeordnete Fallaktenmodell erfolgreich beendet werden kann.
• Zu wiederholende Phasen („Repetition“) können oder müssen mehrfach ausgeführt werden. Sofern sie nicht mit einer Startbedingung versehen sind, wird direkt nach der Beendigung einer Instanz eine neue Instanz gestartet.

© BMI DV

Planfragment

„Das Planfragment („Plan Fragment“) ist ein Container, der am ehesten mit einer Gruppe in BPMN vergleichbar ist. Er hat keine Bedeutung außer einer optischen Zusammenfassung von Elementen.“

© BMI DV

Aufgaben

„Aufgaben („Tasks“) sind, wie Aktivitäten in BPMN, die zentralen Elemente in CMMN. Sie definieren eine Aktion, die ausgeführt werden soll. Dabei können wie in BPMN verschiedene Aufgaben-Typen sowie verschiedene Besonderheiten von Aufgaben kombiniert werden.“

Aufgaben-Typen sind nicht miteinander kombinierbar, d.h. es gibt für jede Aufgabe nur einen Typ. Folgende Typen sind möglich:

• Allgemeine Aufgabe („Task“) ohne nähere Spezifikation
• Nicht-blockierende Aufgabe für Menschen („Non-Blocking Human Task“) bezeichnen Aufgaben, die von Menschen ausgeführt werden müssen, aber den Ablauf nicht blockieren. Daher werden sie sofort beendet, sobald sie begonnen wurden. Das funktioniert vergleichbar einer Nachrichtenversandaktivität in einem Kollaborationsdiagramm.
• Blockierende Aufgabe für Menschen („Blocking Human Task“) bezeichnen Aufgaben, die von Menschen ausgeführt werden müssen und sie während der Ausführung für andere Aufgaben blockieren. Beispiel: das Schreiben eines Konzepts
• Fall-Aufgaben („Case Tasks“) sind wie Teilprozesse der Verweis auf eine weitere Fallakte. Sie werden mit einer Verknüpfung auf ein anderes CMMN-Fall-Diagramm versehen. Sie sollten nur sparsam eingesetzt werden, weil die Verschachtelung von Fällen schnell komplex und unübersichtlich wird.
• Prozess-Aufgaben („Process Tasks“) sind wie Teilprozesse der Verweis auf einen Prozess. Sie werden mit einer Verknüpfung auf ein BPMN-Prozessdiagramm versehen.
• Entscheidungs-Aufgaben („Decision Task“)  sind wie Geschäftsregelaufgaben der Verweis auf eine Entscheidungsstruktur. Sie werden mit einer Verknüpfung auf ein DMN-Entscheidungsdiagramm versehen.

Aufgaben können mehrere Markierungen („Deorators“) besitzen, die auch miteinander kombiniert werden können:

• Optionale Aufgaben („Discretionary“) können ausgeführt werden, müssen aber nicht. Das gilt grundsätzlich zwar für alle Aufgaben, solange sie nicht als erforderlich markiert sind. Von daher ist der Mehrwert dieser Markierung fraglich. Da jedoch alle Aufgaben automatisch beginnen, wenn nichts anderes angegeben ist, muss eine optionale Phase zwingend mit einer Startbedingung oder einer manuellen Aktivierung versehen werden.
• Manuell zu aktivierende Aufgaben („Manual Activation“) sind optional, sofern sie nicht zusätzlich als erforderlich markiert sind. Der Start der Phase erfolgt willkürlich durch den Fallbearbeiter, nicht automatisiert aufgrund von Regeln.
• Erforderliche Aufgaben („Required“) müssen zwingend beendet werden, bevor das übergeordnete Fallaktenmodell erfolgreich beendet werden kann.
• Wiederholbare Aufgaben („Repetition“) können oder müssen mehrfach ausgeführt werden. Sofern sie nicht mit einer Startbedingung versehen sind, wird direkt nach der Beendigung einer Instanz eine neue Instanz gestartet.

© BMI DV

Meilensteine

„Meilensteine („Milestones“) sind Etappenziele innerhalb eines Falles. Das Erreichen eines Meilensteins im Sequenzfluss bedeutet, dass eine weitere Phase des Falles abgeschlossen ist. Sie sind vergleichbar mit Zwischenereignissen in BPMN 2.0.“

Meilensteine können mehrere Markierungen besitzen, die auch miteinander kombiniert werden können:

• Erforderliche Meilensteine („Required“) müssen erreicht beendet werden, bevor das übergeordnete Fallaktenmodell erfolgreich beendet werden kann.
• Wiederholbare Meilensteine („Repetition“) können oder müssen mehrfach erreicht werden.

© BMI DV

Ereignisse

„Ereignisüberwachungen sind mögliche Auslöser für Bedingungen. Neben allgemeinen Ereignissen existieren Zeit- und Benutzerereignisse. Zeitereignisse funktionieren wie die entsprechenden Start- oder Zwischenereignisse in BPMN. Benutzerereignisse warten dagegen auf eine Aktion des Fallbearbeiters.“

Sofern keine Bedingungen („Sentries“) definiert sind, starten Fallaktenmodelle, Phasen und Aufgaben allesamt sofort. Wenn man eine Reihenfolge festlegen oder auf Ereignisse reagieren möchte, benötigt man Eingangsbedingungen. Die Beendigung eines Elements kann ebenfalls von einer Bedingung abhängen. Um diese Voraussetzungen zu prüfen, werden sogenannte „Sentries“ (auch Wächter genannt) verwendet, welche bestimmen, was die Start-Voraussetzungen (weißer Sentry) oder Abschlussvoraussetzungen (schwarzer Sentry) für ein Element sind.

In unserer komplexen Welt sind lineare Abläufe selten und wenn, dann nur im Kleinen anzutreffen. Führungsaufgaben, gerade die höheren, benötigen ein übergreifendes Verständnis für Zusammenhänge. Prozesslandkarten können das nicht befriedigen, denn sie aggregieren nur, ohne das Zusammenspiel aufzuzeigen. Selbst Fähigkeitenlandkarten können allenfalls die theoretischen Zusammenhänge verdeutlichen, aber nicht den zeitlichen Ablauf. BPMN-Diagramme können zwar den zeitlichen Ablauf, aber nicht die non-lineare Komplexität abbilden.

Genau für diese Lücke wurde CMMN entwickelt. Demonstrieren wir seine Leistungsfähigkeit am Beispiel eines abstrakten Projekts:

Ein Projekt wird als erstes initialisiert. Dann folgt die Planung und schließlich die Durchführung, bevor das Projekt abgeschlossen ist. Aber schon dieser lineare Ablauf ist nicht ganz so einfach. Denn eine Durchführung findet nur statt, wenn die Planung zum Ergebnis kam, dass die Durchführung wirtschaftlich sein wird. Während der Projektlaufzeit können regelmäßige Ereignisse wie Berichtspflichten oder Ausnahmen wie eine Eskalationsnotwendigkeit auftreten. Auch die Wirtschaftlichkeit muss immer wieder neu berechnet werden.

© BMI DV

Sie können spaßeshalber versuchen, das in BPMN darzustellen. Selbst mit Ad-hoc-Teilprozessen bleibt das ein hoffnungsloses Unterfangen.

Das CMMN-Diagramm zeigt, dass die Projektinitialisierung automatisch gestartet wird, sobald das Projekt gestartet wird. Nach ihrer Beendigung beginnt die Phase "Durchführung". Gleichzeitig fangen die Uhren für die beiden zeitgesteuerten Ereignisse an zu laufen.

Die Planung führt einerseits zur Wirtschaftlichkeitsberechnung. Mit einer Eingangsbedingung im Wächter der Phase "Durchführung" wird sichergestellt, dass die Wirtschaftlichkeitsberechnung mit einem positiven Ergebnis beendet wurde. In jedem Fall läuft am Ende der Meilenstein Projektabschluss.

Eine Eskalation kann natürlich auch schon während der Projektinitialisierung erforderlich sein, deshalb gibt es keine Linie zwischen der Aufgabe und dem Ereignis.

So einfach lassen sich komplexe Zusammenhänge mit CMMN visualisieren. Das funktioniert aber nur, wenn man sich vorher Gedanken gemacht hat, was man darstellen möchte. Mein erster Versuch war viel komplexer, weil ich ganze Abläufe in den Phasen modelliert habe, statt einfach Prozessaufgaben für den ganzen Ablauf zu verwenden. Das führte zu einem sehr unübersichtlichen Diagramm. Gerade für CMMN ist die Fertigkeit grafische Exzellenz unabdingbar.

Fazit

CMMN ist als Notation nicht besonders komplex, obwohl die Elemente in vielen verschiedenen Varianten existieren. Die Schwierigkeit besteht darin, komplexe Sachverhalte zu visualisieren. CMMN bietet dafür das Handwerkszeug, aber die Fertigkeit im Umgang damit muss man sich hart erarbeiten.

Daher wird der Einsatzraum von CMMN auch weiter langsam wachsen. Wenn Sie Ideen für weitere Anwendungsfälle haben, kontaktieren Sie uns gerne.