13. Jul 2020
Lesedauer 13 Min.
Regeln modellieren
Prozessmanagement mit BPMN, Teil 3
DMN bietet eine einfache und mächtige Alternative zu umfangreichen und komplexen Fallunterscheidungen mit Gateways in BPMN.
Autor
Kurz zur Erinnerung: Das Kürzel BPMN steht für Business Process Model and Notation, eine grafische Sprache, die in der Wirtschaftsinformatik und im Prozessmanagement verwendet wird [1]. Im Zentrum stehen also Geschäftsprozesse und eine Notation, wie diese Modelle dargestellt werden. Dabei ging es von Anfang an nicht einfach nur darum, einen neuen Diagrammtyp einzuführen; ein Ziel von BPMN war es, auch eine grafische Notation für die Automatisierung bereitzustellen. Die aktuelle Version 2.x wurde 2011 von der Object Management Group (OMG) verabschiedet und ist seit 2013 auch ISO-Standard. 2014 kamen CMMN (Case Management Model and Notation) und 2015 DMN (Decision Model and Notation) hinzu, die sich beide als Ergänzung zu BPMN verstehen.Mit der Decision Model and Notation können Regeln in Form von Tabellen modelliert werden, und mithilfe einer Decision Engine lassen sie sich auch automatisieren. Der Komplexitätsgrad dieser Tabellen ist dabei recht gering. So können die Tabellen auch von Anwendern nicht nur gelesen, sondern ebenso ohne großen Aufwand erstellt und bearbeitet werden. Änderungen in der Geschäftslogik können Fachabteilungen daher oft selbst umsetzen, ohne auf Entwickler zurückgreifen zu müssen. Das reduziert Missverständnisse zwischen Anwendern und Entwicklern und fördert in der Regel deutlich die Akzeptanz einer solchen Lösung im Unternehmen aufgrund ihrer Transparenz im Vergleich zu einer klassischen Softwarelösung.
Regeln und Entscheidungen
Zur Anfangszeit von BPMN sprach man vom „business rules management“. Davon leitet sich auch der Name der Geschäftsregel-Aufgabe („business rule task“) her. Mittlerweile spricht man vom „decision management“ und somit übergeordnet von Entscheidungen anstatt von Regeln. Zahlreiche Quellen verwenden die Begriffe Entscheidung und Regel allerdings synonym. Genau genommen werden in DMN Entscheidungstabellen modelliert, die aus Regeln bestehen und zu einer Entscheidung führen.
DMN kann zwar als alleinstehende Technologie verwendet werden, ein größerer Nutzen für den Anwender ergibt sich jedoch aus der Kombination mit BPMN. Dabei werden BPMN-Diagramme durch den Einsatz von DMN nicht noch komplizierter, als diese ohnehin schon sein können, sondern in vielerlei Hinsicht sogar deutlich vereinfacht. DMN wird ebenso wie BPMN von der OMG verwaltet [2].
Einführung anhand eines praktischen Beispiels
Alle Theorie ist grau, deshalb geht es am besten mit einem konkreten Beispiel los, das zunächst vollständig in BPMN abgebildet wird: ein einfacher Prozess, der Rabatte gewährt, die vom Bestellwert abhängig sind. Unter 100 Euro soll es keinen Rabatt geben, ab 100 Euro sollen 5 Prozent gewährt werden und ab 500 Euro 10 Prozent. Bild 1 stellt den Ablauf in BPMN mit einem XOR-Gateway dar.
BPMN-Diagrammmit Fallunterscheidung als XOR-Gateway(Bild 1)
Autor
Anhand der Abbildung kann man sich leicht vorstellen, dass das BPMN-Diagramm schnell unübersichtlich werden kann, sobald weitere Rabattstufen und vielleicht sogar noch andere Bedingungen für einen Rabatt hinzukommen. Übersichtlicher wird das Beispiel, wenn die Bedingungen als Regeln in eine DMN-Entscheidungstabelle ausgelagert werden. Über eine Geschäftsregel-Aufgabe in BPMN wird die Entscheidungstabelle dabei mit dem Prozess verknüpft (siehe auch den Kasten Regeln und Entscheidungen). Die Umsetzung des neuen Diagramms ist in Bild 2 und die DMN-Entscheidungstabelle in Bild 3 zu sehen. Das BPMN-Diagramm ist im Vergleich zur vorherigen Version nun wesentlich kompakter geworden. Vor allem aber muss es nicht geändert werden, wenn weitere Rabattstufen hinzukommen. In diesem Fall müssen der Tabelle einfach nur weitere Regeln (Zeilen) hinzugefügt werden.
Dieses Diagrammunterscheidet die Rabattfälle über eine Geschäftsregel-Aufgabe (hinten), die Entscheidungsgrundlage ist eine DMN-Tabelle (vorne)(Bild 2)
Autor
Das vereinfachteBPMN-Diagramm mit Fallunterscheidung als Geschäftsregel-Aufgabe(Bild 3)
Autor
Neben der besseren Übersichtlichkeit bei einer größeren Anzahl von Bedingungen hat die Umsetzung mit einer Kombination aus BPMN und DMN weitere Vorteile gegenüber reinem BPMN. Zum einen lassen sich die Bedingungen in Tabellenform auch von Anwendern ändern, die in BPMN ungeübt sind; zum anderen muss nicht der eigentliche Prozess geändert werden, was bei einer Prozessautomatisierung zumindest zu kleineren Anpassungen führen würde.Bevor sich die weiteren Erläuterungen den Möglichkeiten von DMN widmen, wird zunächst noch die Entscheidungstabelle aus Bild 2 näher beleuchtet. Oben links steht der Name der Tabelle. Idealerweise wurde der gleiche Name auch für die Geschäftsregel-Aufgabe im BPMN-Diagramm verwendet. Darunter steht ein U, das für die Hit Policy Unique steht; zu den Hit Policies mehr weiter unten. Daneben sind die Namen der Eingabespalten (Bestellwert) sowie der Ausgabespalten (Rabatt in %, Rabatt gewähren?) zu sehen. Unter den Eingabespalten werden die Bedingungen angegeben und unter den Ausgabespalten die jeweiligen Ergebnisse. Zu jeder Eingabe gehört auch eine Ausgabe. Die Kombination von beiden definiert pro Tabellenzeile eine Regel, die in der linken Spalte eine fortlaufende Nummer erhält.Das Beispiel lässt sich übrigens noch weiter vereinfachen, wobei das BPMN-Diagramm dann nochmals kompakter wird (Bild 3) und in der Entscheidungstabelle auf die zweite Ausgabespalte gänzlich verzichtet werden kann (Bild 4). Für Anwender ohne Erfahrung in BPMN und DMN kann diese Variante trotz ihrer kompakteren Darstellung auf den ersten Blick jedoch schwieriger zu verstehen sein als die erste Version. So ist in der ersten Variante allein aus dem BPMN-Diagramm schon klar erkennbar, dass es eine Fallunterscheidung gibt, ob Rabatt gewährt wird oder nicht. In der zweiten Variante ist diese Logik dem BPMN-Diagramm nicht zu entnehmen und die Fälle werden mithilfe der Entscheidungstabelle rein mathematisch unterschieden. Denn ein Rabatt von 0 Prozent bedeutet ja gleichzeitig, dass kein Rabatt gewährt wird, wohingegen jeder andere Prozentwert gleichzeitig bedeutet, dass es Rabatt gibt.An diesem Punkt darf man nicht außer Acht lassen, dass es für die Akzeptanz von BPMN im Unternehmen wichtig ist, dass auch alle an einem Prozess beteiligten Anwender die Modellierungen nachvollziehen können. In der Regel ist daher die erste, etwas umfangreichere Variante der kompakteren Darstellung vorzuziehen.
Die einfachereDMN-Entscheidungstabelle mit Regeln zu dem Diagramm in Bild 3(Bild 4)
Autor
Entscheidungstabellen im Detail
Weiter oben war bereits zu sehen, dass eine Entscheidungstabelle mehrere Outputs (Ausgaben) haben kann. So werden in Abhängigkeit vom Bestellwert in der Entscheidungstabelle aus Bild 5 neben dem Rabatt außerdem die Versandkosten ausgegeben, die bei einem Bestellwert ab 500 Euro entfallen. Eine Entscheidungstabelle kann beliebig viele Outputs haben.
DMN-Entscheidungstabellemit mehreren Ausgabespalten(Bild 5)
Autor
Neben mehreren Outputs sind auch mehrere Inputs (Eingaben) möglich. Wenn die Tatsache, ob ein Kunde Stammkunde ist oder nicht, bei der Rabattberechnung berücksichtigt werden soll, sähe die Entscheidungstabelle wie in Bild 6 aus. Um das Beispiel einfach zu halten, bekommen Stammkunden immer den vollen Rabatt von 10 Prozent, sodass eine einzige weitere Regel genügt. Mehrere Eingabespalten sind in einer Entscheidungstabelle immer mit einer UND-Logik verknüpft.
Auch mehrere Eingabespaltensind in einer DMN-Entscheidungstabelle möglich(Bild 6)
Autor
In der Tabelle aus Bild 6 steht als Bedingung für Stammkunden nun drei Mal der Wert false. Dies lässt sich in DMN noch weiter vereinfachen, da Zellen mit gleichen Bedingungen miteinander verbunden werden können. Das Ergebnis ist in Bild 7 zu sehen.Wenn neben Stammkunden noch weitere Kundentypen, wie zum Beispiel Neukunden bei einer Erstbestellung, mit einem individuellen Rabatt berücksichtigt werden sollen, müsste die Tabelle pro Kundentyp um eine weitere Eingabespalte erweitert werden. Dadurch würde die Tabelle schnell unübersichtlich werden und der Aufwand ihrer Pflege enorm ansteigen. Eine geschicktere Wahl anstatt der Eingabespalte Stammkunde wäre daher eine Eingabespalte Kundentyp, die als Bedingung einen Text für alle möglichen Kundentypen enthält. Für Kunden, die weder Stammkunden noch Neukunden sind, könnte dann auch die Funktion not() verwendet werden; sie negiert den in Klammern angegebenen Ausdruck. Durch Komma voneinander getrennt erlaubt not() auch die Angabe mehrerer Bedingungen, wie es in Bild 8 zu sehen ist.
Mit not()formulierte Bedingungen(Bild 8)
Autor
Eine Entscheidungstabellemit verbundenen Zellen(Bild 7)
Autor
Während Bedingungen in mehreren Eingabespalten mit einer UND-Logik verbunden sind, sind mehrere Bedingungen innerhalb einer Eingabespalte mit einer ODER-Logik miteinander verknüpft; dazu werden sie durch Komma voneinander getrennt. Würden Stammkunden sowie Neukunden bei einer Erstbestellung den gleichen Rabatt erhalten, ließen sich die entsprechenden Regeln auch zusammenfassen, siehe Bild 9.
Regelnmit ODER-Logik(Bild 9)
Autor
Vergleichsoperatoren, Bereiche und Funktionen
Während im vorausgegangenen Abschnitt so weit wie möglich auf die wichtigsten Möglichkeiten eingegangen wurde, die sich in der Darstellung einer Entscheidungstabelle ergeben, folgen nun die elementaren Möglichkeiten, die in Bedingungen genutzt werden können. Hierzu gehören zuallererst die Vergleichsoperatoren:- = (gleich)
- != (ungleich)
- > (größer als)
- < (kleiner als)
- >= (größer gleich)
- <= (kleiner gleich)
"Stammkunde"
und
="Stammkunde"
bedeuten somit das Gleiche.Sind in einer Bedingung mehrere Zahlen aus einem bestimmten Bereich zulässig, so müssen die Zahlen nicht einzeln und durch Komma voneinander getrennt aufgeführt oder durch komplizierte Konstrukte mit Vergleichsoperatoren festgelegt werden. Stattdessen können für Bereiche die folgenden Schreibweisen verwendet werden:
- [..] schließt die Grenzen ein.
- ]..[ schließt die Grenzen aus.
- (..) schließt die Grenzen aus.
2, [5..9], >17
Auch eine Kombination von einschließender und ausschließender Grenze ist erlaubt. So legt beispielsweise der Ausdruck
[0..10[
fest, dass ein Wert größer gleich 0 und kleiner als 10 sein muss.In der Praxis besteht in vielen Fällen die Notwendigkeit, mit Datumswerten zu arbeiten. DMN kennt hierfür die Funktion date(), die in Bedingungen in der folgenden Schreibweise verwendet werden kann:
date("yyyy-mm-dd")
Darüber hinaus gibt es zahlreiche weitere Funktionen wie String-Funktionen oder Listenfunktionen, und auch die Grundrechenarten sind in Bedingungen möglich. Eine vollständige Liste der Funktionen finden sich in der offiziellen Spezifikation [2].
Hit Policies
Mit der Hit Policy (siehe Tabelle 1) wird angegeben, wie viele Regeln einer Entscheidungstabelle zutreffen können und wie zu verfahren ist, wenn mehrere Regeln zutreffen. Die Kennzeichnung für die Hit Policy in einer Entscheidungstabelle wird oben links durch den jeweiligen Anfangsbuchstaben angegeben. Bislang wurde ausschließlich mit der Hit Policy Unique gearbeitet. Das heißt, dass genau eine Regel zutrifft, die das Ergebnis bestimmt. Bei Unique handelt es sich gleichzeitig um den Standardfall, sodass Unique auch weggelassen werden könnte.Tabelle 1: Gängige Hit Policies
|
Bei der Hit Policy First können hingegen auch mehrere Regeln aus der Tabelle zutreffen. Die Entscheidung für eine Regel basiert dann auf der Reihenfolge der Regeln in der Tabelle von oben nach unten, wobei die erste zutreffende Regel das Ergebnis bestimmt. Ein Beispiel ist in Bild 10 zu sehen. Es gewährt an einem durch ein Datum festgelegten Aktionstag pauschal allen Kunden einen Rabatt in Höhe von 10 Prozent. Nur wenn das Datum nicht zutrifft, wird der Rabatt auf Basis des Kundentyps ermittelt.
Verwendender Hit Policy First(Bild 10)
Autor
Wie in dem Beispiel zu sehen ist, muss nicht für jede Eingabespalte eine Bedingung angegeben werden. Ist eine Bedingung für eine Regel nicht von Bedeutung, kann die entsprechende Zelle leer bleiben oder mit einem Minuszeichen markiert werden.Ein Nachteil der Hit Policy First ist, dass die Entscheidungstabelle bei neuen Regeln aufwendig gepflegt und in Reihenfolge gebracht werden muss. Eine Lösung dieses Problems bietet die Hit Policy Priority. Bei der Verwendung von Priority wird über eine weitere Ergebnisspalte eine Priorität angegeben. Dabei muss es sich immer um die erste (linke) Ergebnisspalte handeln. Ein Beispiel zeigt Bild 11. Die Tabelle verfügt über die Ergebnisspalte Wichtigkeit. Unter dem Namen der Ergebnisspalte ist die Reihenfolge der Priorität angegeben. Da für den Aktionstag, der durch die Datumsregel repräsentiert wird, die Priorität mit hoch festgelegt wurde, greift diese Regel vor allen anderen Regeln, obwohl sie in der Tabelle ganz unten steht. Anders als bei der Hit Policy First spielt die Reihenfolge der Regeln bei der Verwendung von Priority keine Rolle. Neue Regeln können dadurch einfach der Tabelle als unterste, neue Zeile angefügt werden, was die Pflege von Entscheidungstabellen deutlich vereinfacht.
Verwendungder Hit Policy Priority(Bild 11)
Autor
Während bei den bislang betrachteten Hit Policies immer nur ein Treffer das Ergebnis bestimmt, ist es mit der Hit Policy Collect möglich, dass auch mehrere Treffer ausgewählt werden können. Das Ergebnis einer Entscheidungstabelle mit Collect ist daher eine Liste von Ergebnissen. Zusätzlich gibt es von dieser Hit Policy mehrere Untertypen mit Aggregatfunktionen, die in Tabelle 2 aufgeführt sind.Ein Beispiel für die Verwendung der Hit Policy Summe (abgekürzt mit C+) ist in Bild 12 zu sehen. Mit der abgebildeten Entscheidungstabelle sollen Kunden auf eine einfache Weise bewertet werden. Hierzu werden die Eigenschaften Zahlungsmoral und Rücksendungsaufkommen jeweils in den Ausprägungen hoch, normal und gering überprüft. In Abhängigkeit vom Zutreffen oder Nichtzutreffen der Bedingungen werden bestimmte Punkte vergeben. Da mehrere Regeln zutreffen können, werden die Ergebnispunkte durch die Hit Policy Collect in Verbindung mit der Summenfunktion zu einer Gesamtpunktzahl addiert.
Die Hit Policy Collectmit der Aggregatfunktion Summe(Bild 12)
Autor
Die Ausdruckssprache FEEL
Hinter den bislang verwendeten Bedingungen steht die Ausdruckssprache FEEL (Friendly Enough Expression Language). Das heißt, dass die Regeln in Entscheidungstabellen im Hintergrund immer in FEEL übersetzt werden. Ziel bei Entwicklung von FEEL war eine einfache Sprache, die auch von Fachanwendern verstanden wird und gleichzeitig so präzise ist, dass die Ausdrücke direkt von Engines ausgeführt werden können. Die allgemeine Syntax eines Ausdrucks in FEEL fällt deswegen auch sehr knapp aus:if
Bedingung
then
Ergebnis
Für die Modellierung von Entscheidungstabellen spielt FEEL eher eine untergeordnete Rolle. So erlauben zahlreiche Modellierungs-Tools zwar das Erstellen und Bearbeiten von Ausdrücken in FEEL (und anderen Sprachen), notwendig ist dies in der Regel jedoch nicht. Denn außer den fehlenden Schlüsselwörtern if und then bestehen gültige Regeln bereits aus FEEL. Die vollständige Regel mit der Nummer 5 aus Bild 8 würde so lauten:
if
Bestellwert > 0 and
Kundentyp = "Neukunde"
then
Rabatt = 5
Sie unterscheidet sich kaum von ihrer Tabellenform und ist auf Anhieb zu verstehen. Das Beispiel setzt natürlich voraus, dass die Variablen/Spaltennamen in einem Modellierungs-Tool auch entsprechend definiert wurden.Die Spezifikation von FEEL ist in der DMN-Spezifikation enthalten und vom Umfang her recht gering. Kenntnisse über FEEL sind eher dann von Bedeutung, wenn mit Regeln über das API einer Engine oder mit dem einer Entscheidungstabelle zugrunde liegenden XML-Format direkt gearbeitet wird.
Modellierungshilfen
Ebenso wie für BPMN gibt es auch für DMN zahlreiche Modellierungs-Tools. Ein Tool mit sehr passablem Funktionsumfang und der Möglichkeit, neben BPMN-Diagrammen auch DMN-Entscheidungstabellen zu erstellen, ist Camunda Modeler, das kostenlos im Internet heruntergeladen werden kann [3]. Die Software wurde auch für die meisten BPMN-Diagramme dieser Artikelserie herangezogen. Außerdem bietet der Hersteller einen Online-Simulator an [4]. Mit dessen Hilfe lassen sich selbst erstellte Tabellen hochladen und testen, wodurch man für einfache Fälle auf die Installation einer zusätzlichen Decision Engine in einer eigenen Testumgebung verzichten kann. Bild 13 zeigt einen Screenshot vom Camunda Modeler, in dem die gleiche Entscheidungstabelle wie in Bild 2 zu sehen ist. Da das Programm standardkonforme Entscheidungstabellen erstellen kann, die auch von einer Decision Engine verarbeitet werden können, enthält es vor allem einige notwendige Einstellungsmöglichkeiten, die bei einer Modellierung in Excel zur reinen Darstellung als Tabelle nicht benötigt werden. Das betrifft insbesondere die Zuweisung von Datentypen sowie Variablen und Namen für Eingabe- und Ausgabespalten.
Die Entscheidungstabelleim Camunda Modeler(Bild 13)
Autor
DMN basiert ebenso wie BPMN auf einem standardisierten XML-Format. So lassen sich Dateien, die mit dem Modellierungs-Tool des einen Herstellers erstellt wurden, in der Regel auch mit den Programmen anderer Hersteller bearbeiten. Gleiches gilt für die Ausführung von Entscheidungstabellen in Decision Engines. In beiden Fällen muss selbstverständlich noch nachgearbeitet werden, wenn ein Hersteller den Standard nicht vollständig unterstützt oder er sein Produkt um eigene Erweiterungen ergänzt hat.Allerdings sind solch spezielle Tools nicht unbedingt nötig, wie der Kasten Excel versus Modellierungs-Tool kurz erläutert.
Zusammenfassung und Ausblick
Nachdem Sie in den beiden vorausgegangenen Artikeln die Grundlagen der Prozessmodellierung mit BPMN kennengelernt haben, stand diesmal DMN und das Modellieren von Entscheidungen im Mittelpunkt. Regeln, die ansonsten umfangreich mit Gateways umgesetzt werden müssten, können Sie mit DMN wesentlich übersichtlicher und unkomplizierter in eine einfach zu verstehende Tabellenform abbilden.Excel versus Modellierungs-Tool
Für DMN-Entscheidungstabellen gibt es zahlreiche, teils auch kostenlose Modellierungs-Tools. Diese bieten für gewöhnlich einige Möglichkeiten, die erst im Zusammenhang mit der Ausführung in einer Decision Engine relevant sind, wie die Vergabe einer ID oder das Festlegen von Datentypen für Spalten. Die Verwendung von einfachen Programmen wie Excel ist nicht nur legitim, sondern lenkt den Fokus beim Einstieg auf das Wesentliche und ist den meisten Anwendern bereits bekannt.
Der Vollständigkeit halber soll nicht unerwähnt bleiben, dass DMN neben dem Abbilden von Regeln in Tabellenform auch eine einfache Notation zur Darstellung von Regeln in Diagrammform spezifiziert, die sich DRD (Decision Requirements Diagrams) nennt. Für Entscheidungen, die nicht in einer einfachen Tabelle darzustellen sind, oder wenn mehrere Entscheidungen voneinander abhängen, kann es zur besseren Visualisierung sinnvoll sein, zusätzlich DRD zu verwenden.Aufbauend auf den bislang vorgestellten Diagrammen und Tabellen zur Prozessmodellierung, wird der folgende und gleichzeitig letzte Teil dieser Serie anhand eines einfachen Beispiels zeigen, wie ein Prozess in einer Engine zum Leben erweckt wird.
Fussnoten
- Business Process Model and Notation bei Wikipedia, http://www.dotnetpro.de/SL2008BPMN1
- Decision Model and Notation, http://www.dotnetpro.de/SL2008BPMN2
- Camunda, http://www.dotnetpro.de/SL2008BPMN3
- Camunda Simulator, http://www.dotnetpro.de/SL2008BPMN4
