DMN (Decision Model and Notation) – Entscheidungsprozesse noch flexibler modellieren

Business Process Model and Notation (BPMN) hat sich spätestens seit Version 2.0 als Standard für die Modellierung und Ausführung von Geschäftsprozessen etabliert. Im Umfeld von BPMN haben sich weitere Standards durchgesetzt, die BPMN für spezifische Anwendungen erweitern. Zu den wichtigsten gehören DMN (Decision Model and Notation) und CMMN (Case Management Model and Notation). In diesem Blog führen wir DMN und seine Bedeutung im Kontext von BPMN aus.

Das ist und kann DMN

Bei DMN ist der Name Konzept: Hier geht es um die Modellierung von Entscheidungen und damit um Fragen wie diese: Wie treffe ich Entscheidungen? Auf welche Informationen stütze ich mich dabei ab? Welche Einflussfaktoren gibt es? Welche Regeln gelten? Wie kann ich nachvollziehbar und reproduzierbar entscheiden? Wie lassen sich Entscheidungsgrundlagen und Regeln zeitnah aktualisieren?

DMN stellt Unternehmen eine Modellierungssprache (Notation) zur Verfügung, mit denen sie ihre Entscheidungsprozesse und -regeln beschreiben können. DMN deckt den gesamten Lebenszyklus von der Anforderungserhebung über das Design bis zur Konkretisierung von Entscheidungsregeln und -parametern ab. Ähnlich wie bei BPMN können die DMN-Modelle von einer «DMN Engine» ausgeführt werden.

Ein Beispiel zur Erläuterung

In DMN unterscheiden wir die folgenden Bereiche:

• Anforderungsbereich («Decision Requirements») Die Anforderungen für Entscheidungen werden mit dem «Decision Requirement Diagram» (DRD) modelliert. Das Diagramm zeigt grafisch die Eingabe- und Ausgabedaten von Entscheidungen sowie – falls vorhanden – deren Zusammenhänge. Diese Darstellung dient der Definition von Entscheidungsgrundlagen und wird vor allem in der Designphase genutzt.
• Entscheidungslogik («Decision Logic») Die konkrete Entscheidungslogik kann entweder mit Hilfe von Entscheidungstabellen («Decision Tables») oder mit Regeln der «FEEL»-Syntax definiert werden. Entscheidungstabellen haben den Vorteil, dass sich Änderungen einfacher und weniger fehleranfällig vornehmen lassen. Im nachfolgenden Beispiel verwenden wir daher eine Entscheidungstabelle. Entscheidungstabellen und Entscheidungsregeln sind gerade in der fachlichen Implementierung relevant.

Als Beispiel dient uns die Entscheidungssituation innerhalb der Neukundenbearbeitung einer Bank. Je nach Regeln und Daten soll ein neuer Kunde von verschiedenen Organisationseinheiten betreut werden:

• Kunden mit sehr hohem Vermögen vom Private Banking
• Kunden mit hohem Vermögen oder hohen Darlehen von der regionalen Geschäftsstelle
• Kunden mit mittlerem Vermögen oder Darlehen von der lokalen Filiale
• Andere Kunden vom Customer Care Helpdesk (Retailgeschäft)

Die Betreuungskategorie des Neukunden (als Resultat der Entscheidung) wird gemäss Diagramm durch Einkommen, Vermögen und Darlehen (Inputdaten) bestimmt. Der Output ist die Betreuungskategorie eines Kunden. Diese liesse sich wiederum als Input für eine weitere Entscheidung verwenden, etwa für die Festlegung der Kontogebühren. Darauf haben wir in diesem Beispiel verzichtet.

Die im DRD definierten Input- und Outputparameter sind hier als Spalten dargestellt. Die Zeilen definieren die Entscheidungsregeln. Über eine Zeile hinweg sind die Inputspalten mit «AND» verknüpft; ein Feld ohne Wert wird als «ANY» interpretiert. Demnach liest sich die Entscheidungstabelle so:

• WENN Vermögen > 1’0000’000
• DANN Betreuungsart = «Betreuer Private Banking»
• WENN Einkommen < 120’000 UND Vermögen < 50’000 UND Darlehen < 300’000
• DANN Betreuungsart = «Customer Care Helpdesk»

Die Entscheidungsregeln – beispielsweise eine niedrigere Vermögenssumme als Schwellwert für die Betreuung durch das Private Banking – lassen sich einfach durch eine Änderung des Werts in der Tabelle anpassen. Das kann auch von Fachanwendern ohne detailliertes IT-Wissen oder sogar ohne Entwicklerkompetenz durchgeführt werden.

DMN in Verbindung mit BPMN

DMN ist ein eigenständiger Standard. Trotzdem wurde bei seiner Konzeption darauf geachtet, dass er mit BPMN harmoniert. Denn Entscheidungen sind bei der Modellierung von Geschäftsprozessen zentral. In der Praxis findet man häufig Prozessmodelle, deren Fluss sich anhand von Entscheidungen aufgrund von Geschäftsdaten und -regeln verzweigt:

• Unterschiedliche Genehmigungsschritte je nach Wert oder potenziellem Risiko
• Kunden werden je nach Bedeutung unterschiedlich betreut
• Preise, Gebühren oder Nachlässe werden nach Auftragswert und/oder Umsatzvolumen vergeben
• Weitere

Die Entscheidung, ab wann man welchen Prozesspfad verfolgt, soll sich möglichst dynamisch an neue Situationen anpassen, ohne dass an den Prozessen etwas zu ändern ist. Eine solche Entscheidungslogik abzubilden, ist die Hauptanwendung von DMN.

Zwar lassen sich Entscheidungen auch mit BPMN abbilden (z.B. mit dem Bordmittel «XOR- Gateway»). Allerdings muss bei einer Änderung der Entscheidungsparameter eine Änderung am Prozessmodell erfolgen: Die Entscheidung ist in einem solchen Fall im BPMN-Modell «hardcoded». Mit DMN können Entscheidungslogik und Prozesslogik – also der in BPMN modellierte Prozess – getrennt werden. Änderungen von Entscheidungen können so schneller, flexibler und sicherer aufgenommen werden.

Hier sind die Geschäftsregeln – d.h. die Entscheidungen, wann welche Betreuungsform zum Zug kommt – in der Logik des XOR-Gateway definiert. Dies sieht nicht nur unübersichtlich aus, sondern erfordert bei sich ändernden Geschäftsregeln oder Schwellenwerten das Anpassen im Prozessmodell und ein erneutes Ausrollen des modellierten Prozesses. Dazu braucht es in der Regel die IT-Abteilung, was eine Anpassung der Geschäftsregeln deutlich unflexibler macht.

Mit DMN kann die Entscheidungslogik des BPMN-Modells ausgelagert werden. In BPMN erscheint das als separate Aktivität (eine «Business Rule Task», im untenstehenden Diagramm blau markiert).

Mit dem Auslagern der Entscheidungslogik in DMN sieht das Prozessmodell deutlich aufgeräumter aus: Die Entscheidung der Kundenkategorie wird in einen «Decision Task» ausgelagert. Das Gateway im Prozessdiagramm verwendet nun die Resultatwerte der Entscheidungstabelle und damit die festgelegte Kundenbetreuungskategorie.

DMN vereinfacht die Aktualisierung der Entscheidungsregeln deutlich: Neu müssen lediglich die Daten in der Entscheidungstabelle gepflegt werden. Der BPMN-Prozess selber muss nicht neu ausgerollt werden.

DMN vs. BRM

DMN ist zwar ein relativ neuer Standard, doch das Thema ist nicht neu: Unter dem Fachbegriff «Business Rules Management» (BRM) sind in den vergangenen Jahren Konzepte und Produkte entstanden, die sich mit Entscheidungen befassen. Es erstaunt daher nicht, dass sich einige der Konzepte ähneln. Zum Beispiel sind Entscheidungstabellen in den meisten BRM-Produkten enthalten. Die DMN-Regelsprache «FEEL» unterscheidet sich nicht grundlegend von ihren Pendants in traditionellen BRM-Systemen. Dennoch hat DMN klassischen BRM-Systemen einiges voraus:

• Internationaler Standard, damit Vereinheitlichung und Austauschbarkeit für Anwender
• Theoretische Austauschbarkeit zwischen verschiedenen DMN-Produkten
• Normierte Modellierungsnotation, die das Decision Management über den gesamten Lebenszyklus und damit für verschiedene Anwenderrollen (Fachspezialisten, Businessanalysten, IT-Entwickler) unterstützt
• Konzipiert zur Komplementierung von BPMN

Als Nachteile von DMN gegenüber etablierten BRM-Produkten wird teilweise die geringere Reife von Implementierung und Standard genannt. Zudem verfügen etablierte BRM-Systeme über die eine oder andere Funktionalität, die DMN-Implementierungen heute noch nicht bieten. Allen Unkenrufen zum Trotz: Die Leichtigkeit, mit der sich BPMN- und DMN-Modelle verbinden lassen, ist unserer Ansicht nach ein Schlüsselvorteil. Langfristig wird dieser DMN zum Durchbruch verhelfen.