Ich habe das schon mehrfach so erlebt. Im Einleitungsteil eines Vortrags werden BPMN, DMN und CMMN als kleine Familie von zueinander kompatiblen Standards vorgestellt. Doch ab dann wendet sich der Vortrag nur noch ersteren beiden zu, kein Wort mehr zu CMMN. Offenbar ist das Interesse an Prozessautomatisierung (BPMN) und an Geschäftsregeln (DMN) größer als an ... ja, an was eigentlich? CMMN steht für "Case Management Model and Notation".  Case Management bedeutet Fallbearbeitung. Aber wie grenzen sich diese Fälle des CMMN von den Prozessen des BPMN und den Entscheidungen des DMN ab?

Für welche Geschäftsvorfälle eignet sich CMMN?

Als Beispiele seien zwei alltägliche Geschäftsvorfälle vorangestellt:

• Ein Patient kommt mit gebrochenem Fuß zum Arzt und die Bearbeitung dieses Falls beinhaltet seine Registrierung, ein Arztgespräch, eventuell ein Röntgenbild, die Ausstellung eines Attests, einen Gips und auf jeden Fall die Abrechnung mit der Krankenkasse.
• Ein Bürger kommt ins Amt und beantragt einen Anwohnerparkausweis. Die Bearbeitung des Falls beinhaltet die Erfassung seiner Daten, die Prüfung der Adresse, die Erhebung einer Gebühr und die Ausstellung des Ausweises.

Kommen Geschäftsvorfälle häufig vor, lohnt es sich, über Prozessautomatisierung nachzudenken. Dazu muss der Ablauf gut verstanden sein. In welcher Reihenfolge geschieht was? Welche Fallunterscheidungen gibt es? Anhand welcher Regeln werden Entscheidungen getroffen? Welche Daten werden benötigt? Kann ich den Prozess aufgrund meines expliziten Wissens komplett modellieren?

Das Vorkommen menschlicher Aktivitäten ist übrigens kein Hinderungsgrund für einen automatisierten Prozess. Um im Beispiel mit dem Anwohnerparkausweis zu bleiben, könnte der städtische Mitarbeiter die Daten des Bürgers erfassen. Das IT-System verwaltet die Daten und steuert den Ablauf. Weitere Schritte wie die Überprüfung, ob für die Adresse Anwohnerparken zugelassen ist, und der Druck des Ausweises liefen ohne menschliches Zutun.

Es gibt zahlreiche Geschäftsvorfälle, die sich nicht leicht automatisieren lassen. Der nächste Schritt wird jeweils ad hoc bestimmt. Die zu erfassenden Daten unterscheiden sich von Fall zu Fall und lassen sich nicht in vordefinierte Strukturen pressen. Die Regeln, anhand derer Entscheidungen getroffen werden, existieren, wenn überhaupt, dann nur als implizites Wissen in den Köpfen der Mitarbeiter. Ein solcher Geschäftsvorfall ist der beschriebene Arztbesuch. Hier weitere Beispiele für Geschäftsvorfälle, die sich mutmaßlich eignen für Prozessautomatisierung oder Case Management.

Für einen Geschäftsvorfall, der ad-hoc und mit viel implizitem Wissen durchgeführt wird, ist es zwar schwierig, den Prozess zu modellieren, doch lassen sich bei der Durchführung Muster erkennen. Die Registrierung beim Arzt ist immer der erste Schritt. Ich gipse den Fuß nicht ein, ohne vorher geröntgt zu haben. Ein erfahrener Mitarbeiter weiß, welche Aktivitäten er überhaupt durchführen kann, welche Aktivitäten auf jeden Fall durchgeführt werden müssen und welche Voraussetzungen eine Aktivität hat. Ein neuer Mitarbeiter muss das alles erst lernen und es wäre schön, ihm ein wenig Orientierung zu bieten. Außerdem wünschte man sich, dass alle Aktivitäten und alle Daten zu einem Fall zusammengehalten werden. Bei diesen Wünschen setzt CMMN an.

Was leistet CMMN?

CMMN bietet eine Notation zur Modellierung von Case Plans, also von Plänen, wie Geschäftsvorfälle bearbeitet werden. Die Notation drückt Folgendes aus:

• Welche Aktivitäten kann ich bei der Fallbearbeitung durchführen?
• Was sind die Voraussetzungen, um eine bestimmte Aktivität zu starten?
• Was sind die Voraussetzungen, um eine bestimmte Aktivität zu beenden?
• Was sind die Voraussetzungen für den Abschluss des Falls?

 Hier ein denkbares Case Plan Model für den Arztbesuch:

Ein solches Case Plan Model wird am besten in Zusammenarbeit mit erfahrenen Mitarbeitern erstellt, die selber Fälle bearbeiten. Das fertige Case Plan Model schafft Transparenz über die Arbeitsweise und kann einem neuen Mitarbeiter den Einstieg erleichtern. Da das Case Plan Model in einem durch CMMN standardisierten Format gespeichert ist, lässt es sich auch durch eine Case Management Anwendung interpretieren und ausführen. Die Anwendung zeigt an, welche Aktivitäten schon durchgeführt wurden, welche Aktivitäten als nächstes möglich sind und was auf jeden Fall noch getan werden muss, um den Fall abzuschließen. Beim Einsatz des Case Plan Models werden neue Erfahrungen gesammelt, die dann wieder in das Model einfließen können. Es entsteht ein Kreislauf.

Das obige Beispiel „Behandlung einer Fraktur“ enthält nur einige der CMMN-Notationselemente. Diese und weitere werden im Folgenden vorgestellt.

Task - eine Aktivität, dargestellt durch ein abgerundetes Rechteck. Dieses Element ist analog zum BPMN Task und sieht auch genauso aus.

Task mit Sentry - Sentry bedeutet zu Deutsch „Wächter“ und ist hier eine Eingangsbedingung für den Task, dargestellt durch den Diamanten. Die konkrete Eingangsbedingung ist nicht grafisch dargestellt.

Connector - Die Punkt-Punkt-Strich-Verbindung sagt aus, dass der Abschluss der linken Aktivität die Eingangsbedingung für den Start der rechten Aktivität ist.

Time Event Listener - Ein Zeitpunkt ist Eingangsbedingung für den Start einer Aktivität.

User Event Listener - Ein Anwenderereignis ist Eingangsbedingung für den Start einer Aktivität.

Milestone - Ein Meilenstein ist Eingangsbedingung für den Start einer Aktivität. Meilensteine können vom Modellierer frei definiert werden und resultieren selbst aus dem Abschluss anderer Aktivitäten.

Document - Ein Dokument ist Eingangsbedingung für den Start einer Aktivität.

Discretionary Task - Die Aktivität kann nach Ermessen durchgeführt werden oder nicht.

Task mit Exit Sentry - Die Aktivität enthält eine Abschlussbedingung. Leider bietet CMMN keine grafischen Möglichkeiten für die Darstellung der Bedingung selbst.

Manual Activation Rule - Das Playsymbol zeigt an, dass die Aktivität nicht automatisch startet, wenn die Eingangsbedingungen erfüllt sind. Es ist eine nicht dargestellte Regel hinterlegt, die entscheidet, ob die Aktivität manuell gestartet werden muss.

Repetition Rule - Die Raute # zeigt an, dass Regel hinterlegt ist, die entscheidet, ob und wie oft die Aktivität wiederholt werden muss.

Required Rule - Das Ausrufezeichen zeigt an, dass eine Regel hinterlegt ist, die entscheidet, ob die Aktivität verpflichtend ist, um den Fall abzuschließen.

Aktivitäten können durch Stages modularisiert werden. Stages sind Achtecke und können selbst Ein- und Ausgangsbedingungen haben. Das Beispiel enthält zwei Stages. Erst wenn ich die Stage „Antragsdaten sammeln“ abgeschlossen habe, beginne ich mit der Stage „Antrag prüfen“.

Aktivitäten können durch Fragments grafisch gruppiert werden. Fragments sind abgerundete Rechtecke mit gestrichelter Linie. Es ist ein reines Darstellungselement ohne Bedeutung für die Ausführung des Case Plan Models durch eine Anwendung.

Process Task - das Chevron-Symbol zeigt an, dass für diese Aktivität ein Prozess hinterlegt ist, modelliert in BPMN.

Decision Task - die Minitabelle zeigt an, dass für diese Aktivität eine Geschäftsregel hinterlegt ist, modelliert in DMN. CMMN ist also integriert mit den beiden OMG Schwesterstandards.

Stärken und Schwächen der Notation

Ausdrucksstärke

Erwartung: Eine gute Notation kann alle wesentlichen Aspekte der Fachlichkeit ausdrücken.

Ein zentraler Aspekt bei der Abarbeitung von Geschäftsvorfällen ist die Zuständigkeit. Welche Rolle führt welche Aktivität durch? Dieser Aspekt lässt sich durch die Notation nicht darstellen und folglich auch bei der Ausführung eines Case Plan Models nicht berücksichtigen.

Zudem erlaubt die Notation vielfach bloß einen Hinweis darauf, dass eine Regel existiert, aber die Regel selbst kann nicht dargestellt werden. Um die Regeln bei der Ausführung eines Case Plan Models anwenden zu können, werden sie ausprogrammiert. Der Programmcode kann auch als Teil des Case Plan Models gespeichert werden, ist aber in der Notation nicht sichtbar. Die genauen Regeln, wann ich eine Aktivität beginnen, beenden, wiederholen darf oder muss, sind für die tägliche Arbeit maßgeblich. Und auch für die Konzeptionsphase, in der die Regeln festgelegt werden, wünschte man sich eine Darstellung. Hier sollte DMN stärker integriert werden!

Verständlichkeit

Erwartung: Eine gute Notation ist für alle Beteiligten verständlich. Im Fall von CMMN gehören zu den Beteiligten die durchführenden Sachbearbeiter, die Führungskräfte mit Verantwortung für den modellierten Geschäftsvorfall und die IT, welche das Modell zur Ausführung bringt.

Die Anzahl der Symbole ist moderat und insbesondere für Menschen, die BPMN kennen, leicht zu erlernen. Es genügt, sich einige Grundelemente zu merken. Die anderen Elemente verfeinern diese Grundelemente bloß, indem sie das Grundelement „dekorieren“. Diese Technik hat sich schon in BPMN bewährt. Zudem sind die Symbole gut unterscheidbar von den BPMN- und DMN-Symbolen, was eine Kombination der Standards im Projekt erleichtert. Ein kleiner Minuspunkt ist die Verwechslungsgefahr bei Fragments und Discretionary Tasks. Beide sind abgerundete Rechtecke mit gestrichelten Linien.

Es ist schwer, anhand eines Case Plan Models das genaue Verhalten zur Laufzeit zu erahnen. Wie ist das Zusammenspiel zwischen Required Rules, Discretionary Tasks, Sentries und anderen Elementen? Beim Versuch ein vollständiges Zustandsübergangsdiagramm zu zeichnen, sind wir an unsere Grenzen gestoßen. Einige Fragen zur Bedeutung bestimmter Passagen der Spezifikation blieben offen. Wenn uns das trotz einiger Erfahrung mit der Syntax und Semantik von Modellierungssprachen so geht, eignet sich die Notation nur bedingt für die Fachexperten, mit denen die Case Plan Models zusammen entwickelt werden. Es ist zudem zu befürchten, dass die Unklarheiten auch zu abweichendem Verhalten in der Ausführungslogik führen werden, je nach dem, welches Tool man dafür einsetzt. Die Syntax ist hingegen eindeutig und somit ist ein Case Plan Model durch ein Modellierungstool auf Korrektheit überprüfbar.

Eignung für eine Analysephase

Erwartung: Eine gute Notation kann bereits während der Konzeption benutzt werden und setzt keine vollständige Kenntnis des Zielbildes voraus.

Kennen Sie das? Sie möchten sich nur schnell einen Zusammenhang mit Kästen und Linien veranschaulichen, einfach mal laut nachdenken. Sie öffnen ein Modellierungstool und ziehen eine erste Linie zwischen zwei Kästchen, die Systeme darstellen. Da verlangt das Tool von Ihnen, dass sie Input- und Outputparameter samt Datentypen spezifizieren, sonst sei die Linie nicht syntaktisch korrekt. Entnervt schließen Sie das Tool.

Obwohl CMMN auf Ausführbarkeit abzielt, gibt es nur geringe Anforderungen an die syntaktische Korrektheit. Letztlich kann man die Tasks erstmal freischwebend in das Case Plan Model malen und sich erst später über Eingangs- und Ausgangsbedingungen und weitere Regeln Gedanken machen. Man gelangt schnell zu einer Diskussionsgrundlage für das Gespräch mit den Fachexperten.

Verbesserungsideen

Hier eine Skizze, wie CMMN um die Darstellung von Zuständigkeiten und die Darstellung von Regeln erweitert werden könnte.

Die Aktivität „Arztgespräch“ kann nur von einer Person mit der Rolle „Arzt“ durchgeführt werden. „Blutabnehmen“ kann entweder ein „Arzt“ oder eine „Krankenschwester“. CMMN kann natürlich nicht für jede denkbare Rolle ein Symbol anbieten. Stattdessen sollte dem Anwender erlaubt sein, eigene Rollensymbole zu verwenden oder Kürzel, zum Beispiel A für Arzt. Um Rollen als solche erkennbar zu machen, dienen die dargestellten Einrahmungen durch Kreise.

Bei der Darstellung der Regeln wird DMN enger integriert. Entscheidungslogik wird durch eine Entscheidungstabelle modelliert. Im Modellierungstool lässt sich die Tabelle beispielsweise mit Doppelklick öffnen. Im Gespräch mit den Fachexperten kann die Entscheidungslogik anhand der Tabellen diskutiert werden. Zudem kann DMN direkt zur Ausführung gebracht werden. Der Entwickler muss sich also nur noch um die Datenbeschaffung kümmern.

Im obigen Beispiel gibt es eine Eingangsbedingung, in die das abgeschlossene Arztgespräch einfließt. Die genaue Logik, ob die Aktivität „Blut abnehmen“ gestartet werden kann, ist in der Regel gekapselt. Würde die Minitabelle im Case Plan Model fehlen, so wüsste man, dass es außer dem Arztgespräch keine weiteren Eingangsbedingungen gibt.

Auch an der Ausgangsbedingung klebt eine Entscheidungstabelle. Damit hat CMMN erstmals eine Möglichkeit, konkrete Bedingungen für die Beendigung einer Aktivität darzustellen.

Semantik des Playbuttons: Enthält eine Aktivität keinen Playbutton, so wird die Aktivität manuell durch einen Anwender gestartet. Enthält eine Aktivität einen Playbutton ohne Entscheidungstabelle, so startet die Aktivität automatisch, sobald die Eingangsbedingungen erfüllt sind. Komplexere Logik kann über eine Entscheidungstabelle modelliert werden.

Semantik der Raute:  Enthält eine Aktivität keine Raute, so wird die Aktivität nie wiederholt. Enthält eine Aktivität eine Raute ohne Entscheidungstabelle, so kann ein Anwender die Aktivität nach Belieben wiederholen. Komplexere Logik kann über eine Entscheidungstabelle modelliert werden.

Semantik des Ausrufezeichens: Enthält eine Aktivität kein Ausrufezeichen, so ist die Aktivität nicht zwingend erforderlich, um den Fall abzuschließen. Enthält eine Aktivität ein Ausrufezeichen ohne Entscheidungstabelle, so muss die Aktivität durchgeführt werden. Wie immer kann komplexere Logik über eine Entscheidungstabelle modelliert werden. Es besteht keine Notwendigkeit mehr für „Discretionary Tasks“.

Durch die dargestellten Erweiterungen gewönne die Notation an Verständlichkeit und Relevanz.

Visualisierung von nicht komplett durchdrungenen Abläufen

Es gibt Geschäftsvorfälle, die sich nicht für Prozessautomatisierung und Modellierung mit BPMN eignen. Das liegt an mangelndem expliziten Wissen und sehr unterschiedlichen Bearbeitungsabläufen. Dennoch kann es sinnvoll sein, auch solche Geschäftsvorfälle zu strukturieren und, so gut es geht, zu visualisieren. Wer vor einer solchen Herausforderung steht, sollte einen Blick auf CMMN werfen! Für den Einzelfall muss beurteilt werden, inwieweit die dargelegten Stärken und Schwächen von CMMN ins Gewicht fallen.

Die geringe Zahl an Implementierungen, Fachartikeln und Konferenzvorträgen lässt daran zweifeln, dass CMMN sich als Industriestandard etabliert. Nichtsdestotrotz kann es für meinen Anwendungsfall die passende Notation sein oder zumindest die nötigen Ideen für eine Visualisierung liefern!