Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03265.jsonl.gz/2077

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.
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.
In DMN unterscheiden wir die folgenden Bereiche:
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:
Das Decision Requirement Diagramm (DRD) sieht für dieses Beispiel wie folgt aus:
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 Entscheidungsregeln und -daten definieren wir in der nachfolgenden Entscheidungstabelle.
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:
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 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:
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.
Die Neukundenbearbeitung unseres Bankenbeispiels zeigt die Vorteile des kombinierten Einsatzes von DMN und BPMN. Ohne DMN würde das BPMN-Modell so aussehen:
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 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:
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.