In den Modellierungskonventionen haben wir im Artikel über den Umgang mit Verzweigungen unter der Überschrift „Verketten exklusiver Verzweigungen vermeiden“ die Situation beschrieben, dass exklusive Gateways fälschlicherweise für die Modellierung von Entscheidungen verwendet werden. Als Lösung haben wir die Verwendung einer Geschäftsregelaufgabe mit einem Gateway empfohlen. Wie man die Entscheidung selbst modelliert, ging aus dem Artikel jedoch nicht hervor. Hier soll diese Lücke geschlossen werden. Um Entscheidungsstrukturen zu modellieren, wurde die Notation DMN geschaffen.

In dieser Artikelreihe betrachten wir systematisch Schritt für Schritt die einzelnen Elemente von DMN. Dieser Artikel legt die Grundlagen, während wir dann erst einmal zeigen, welche Probleme entstehen, wenn man falsch vorgeht, bevor wir dann Stück für Stück zeigen, wie man zu guten Ergebnissen kommt.

Grundlagen

Bevor wir uns mit dem Thema anhand praktischer Beispiele auseinandersetzen, müssen wir zuerst einmal eine Reihe von Fragen klären.

Was ist eine Entscheidung?

„Eine Entscheidung ist eine Auswahl zwischen mehreren Möglichkeiten und die damit verbundene Verständigung auf die Alternative, die die besten Erfolgsaussichten aufweist.“

Was ist Entscheidungsmanagement?

„Business Decision Management ist ein systematischer Ansatz, um sowohl automatisierte als auch nicht automatisierte Entscheidungen zu erfassen, zu dokumentieren, zu optimieren, auszuführen, zu messen und zu überwachen. Dokumentierte Entscheidungen fördern maßgeblich das Erreichen der Unternehmensziele.“

Welche Herausforderungen gibt es beim Entscheidungsmanagement?

Menschliche Entscheidungen können durch folgende Probleme beeinträchtigt werden:

• Unklare Regeln bzw. fehlende Transparenz
• Unsicherheiten
• Inkonsistente Entscheidungen (d.h. unterschiedliche Ergebnisse bei gleichen Fakten)
• Hoher Kommunikationsaufwand
• Langsame Entscheidungsfindung

Was ist DMN?

„Decision Model and Notation (DMN) ist eine grafische Spezifikationssprache, die Elemente definiert, um Geschäftsentscheidungen zu modellieren und deren Logik zu dokumentieren. DMN dient darüber hinaus als Schnittstelle zwischen Modellierung und Implementierung und verbessert die Kommunikation zwischen Fachbereich und IT.“

DMN definiert grafische Elemente zur Modellierung von Entscheidungsstrukturen. Darüber hinaus unterstützt es Logik und Entscheidungsregeln.

DMN wurde als internationaler Standard von der Object Management Group definiert, die auch BPMN standardisiert hat. Deshalb gibt es auch eine enge Verzahnung zwischen BPMN und DMN.

Was sind Entscheidungsdiagramme?

Ein Entscheidungsdiagramm (im Englischen Decision Requirement Diagram bzw. DRD) ist ein visuelles Modellierungswerkzeug zur Analyse und Modellierung von Entscheidungsprozessen. Es ist Teil der Entscheidungsmodellierung und hilft dabei, die logische Struktur von Entscheidungen zu visualisieren. DRDs können auch verwendet werden, um Entscheidungen zu optimieren, indem sie die Auswirkungen von Änderungen an Entscheidungsregeln und Bedingungen simulieren.

DRDs/Entscheidungsdiagramme beinhalten folgende Fragen:

• Welche Informationen werden benötigt?
• Gibt es vorgelagerte Entscheidungen?
• Gibt es externe oder interne Richtlinien?
• Wie sind die Abhängigkeiten?

Wie sieht die Notation aus?

In voller Größe anzeigen

© BMI DV

Die Notation DMN besteht im Wesentlichen aus drei grafischen Elementen und zwei Verbindungstypen.

Die Entscheidung ist das wichtigste Element. Sie wird durch ein dunkelorange gefülltes Rechteck symbolisiert. Jede Entscheidung benötigt Eingaben (oder Inputs). Diese werden durch ein hellorange gefülltes Rechteck mit abgerundeten Ecken symbolisiert. Von der Eingabe zur Entscheidung führt ein Pfeil.

Daneben existiert noch die Wissensquelle. Diese wird über eine gestrichelte Linie entweder mit der Entscheidung oder mit einer Eingabe verbunden.

Es gibt noch ein paar zusätzliche Elemente, die sind aber für den Anfang nicht relevant.

Was sind Entscheidungstabellen?

„Eine Entscheidungstabelle ist eine tabellarische Darstellung von Entscheidungsregeln, die zeigt, welche Aktionen basierend auf verschiedenen Kombinationen von Eingangsbedingungen ausgeführt werden sollen. Die Entscheidungslogik wird in einer Entscheidungstabelle dargestellt, die aus verschiedenen Komponenten besteht. In der Entscheidungstabelle entspricht jede Reihe einer Geschäftsregel.“

Entscheidungstabellen sind schon viel älter als DMN. Sie stammen aus der Programmierung und sind schon seit den 1970er Jahren in Gebrauch.

Das Reisekostengesetz als Beispiel

Fast alle haben schon einmal eine Dienstreise getätigt. Führungskräfte müssen sie meist genehmigen. Für diese Genehmigung fallen schon eine ganze Reihe von Entscheidungen an. Schauen wir uns also mal § 2 Abs. 1 BRKG näher an:

§2 BRKG

(1) Dienstreisen sind Reisen zur Erledigung von Dienstgeschäften außerhalb der Dienststätte. Sie müssen, mit Ausnahme von Dienstreisen am Dienst- oder Wohnort, schriftlich oder elektronisch angeordnet oder genehmigt worden sein, es sei denn, dass eine Anordnung oder Genehmigung nach dem Amt der Dienstreisenden oder dem Wesen des Dienstgeschäfts nicht in Betracht kommt. Dienstreisen sollen nur durchgeführt werden, wenn sie aus dienstlichen Gründen notwendig sind. Dienstreisen dürfen nur angeordnet oder genehmigt werden, wenn das Dienstgeschäft nicht auf andere Weise, insbesondere durch Einsatz digitaler Kommunikationsmittel, erledigt werden kann. Dienstreisen sind auch Reisen aus Anlass der Versetzung, Abordnung oder Kommandierung. 

Alles klar? Ich musste den Absatz mehrfach lesen, um mir die Struktur der Entscheidungen zu erschließen. Bevor wir jedoch hier tiefer einsteigen, habe ich eine Grafik eingefügt wie man das nicht darstellen sollte, nämlich mit BPMN:

© BMI DV

Die Grafik zeigt deutlich das Problem, warum BPMN nicht für die Modellierung von Entscheidungen geeignet ist. Jedes in dieser Form beschriebene BPMN-Diagramm ist unübersichtlich und hilft nicht beim Verständnis des Sachverhalts.

Wo liegen nun die Vorteile von DMN? Das schauen wir uns in den nächsten Schritten genauer an. Im zweiten Schritt werden wir zuerst einmal falsch herangehen und scheitern.

Im ersten Schritt haben wir uns die Grundlagen von DMN angesehen und gelernt, dass wir für Entscheidungen etwas Besseres benötigen als BPMN. Als Beispiel haben wir § 2 Abs. 1 BRKG gewählt, der uns durch diesen und noch einige weitere Schritte begleiten wird.

㤠2 BRKG

(1) Dienstreisen sind Reisen zur Erledigung von Dienstgeschäften außerhalb der Dienststätte. Sie müssen, mit Ausnahme von Dienstreisen am Dienst- oder Wohnort, schriftlich oder elektronisch angeordnet oder genehmigt worden sein, es sei denn, dass eine Anordnung oder Genehmigung nach dem Amt der Dienstreisenden oder dem Wesen des Dienstgeschäfts nicht in Betracht kommt. Dienstreisen sollen nur durchgeführt werden, wenn sie aus dienstlichen Gründen notwendig sind. Dienstreisen dürfen nur angeordnet oder genehmigt werden, wenn das Dienstgeschäft nicht auf andere Weise, insbesondere durch Einsatz digitaler Kommunikationsmittel, erledigt werden kann. Dienstreisen sind auch Reisen aus Anlass der Versetzung, Abordnung oder Kommandierung.“

Schauen wir uns den Absatz etwas näher an, sehen wir, dass hier drei Entscheidungen zusammengewürfelt werden. Die erste Entscheidung wird auf zwei Sätze des Abschnitts aufgeteilt, die nicht einmal nahe beieinander stehen. Heben wir daher die erste Entscheidung hervor:

„Dienstreisen sind Reisen zur Erledigung von Dienstgeschäften außerhalb der Dienststätte. [...] Dienstreisen sind auch Reisen aus Anlass der Versetzung, Abordnung oder Kommandierung.“

Die Entscheidung stellt die Frage, ob eine Dienstreise vorliegt oder nicht. Dafür werden vier Fälle angeführt:

1. Erledigung von Dienstgeschäften außerhalb der Dienststätte
2. Anreise wegen Versetzung
3. Anreise wegen Abordnung
4. Anreise wegen Kommandierung

© BMI DV

„Nit long schwätzä, schaffä“, wie der Schwabe sagt. Legen wir also los, indem wir einfach ein DMN-Diagramm ohne großes Nachdenken modellieren. Wie schon im ersten Artikel beschrieben, ist eine Entscheidung ein dunkeloranges Rechteck, eine Eingabe (Input) ein helloranges Rechteck mit abgerundeten Ecken.

Die Entscheidung wird mit der Frage beschriftet, die wir hier behandeln wollen. Die Eingaben werden mit den Kategorien beschriftet, für die sie stehen. Mit vier Inputs habe ich die vier Varianten abgebildet. Sieht doch hübsch aus, oder?

Leider ist das doch nicht ganz so einfach. Doch um den Fehler zu finden, müssen wir etwas tiefer einsteigen. Dafür benötigen wir eine Entscheidungstabelle.

Beispiel Entscheidungstabelle

Zum Verständnis der Probleme unseres ersten Diagramms stellen wir dieses einmal als Entscheidungstabelle dar. Es gibt einen engen Zusammenhang zwischen dem Entscheidungsdiagramm und der Entscheidungstabelle. Jede Spalte im Eingabeteil der Tabelle entspricht einem Eingabefeld im Entscheidungsdiagramm. Jede Zeile stellt die möglichen Kombinationen für die Eingabespalten dar. Die Zeile wird Regel genannt, und jede Regel hat eine eindeutige Kennzeichnung.

Zu den Eingabespalten gibt es mindestens eine Ergebnisspalte. Für Ergebnisspalten habe ich die Schrift blau eingefärbt.

Regel	Dienstgeschäft außerhalb der Dienststätte	Versetzung	Abordnung	Kommandierung	Ergebnis
1	= Ja	= Nein	= Nein	= Nein	Ja
2	= Nein	= Ja	= Nein	= Nein	Ja
3	= Nein	= Nein	= Ja	= Nein	Ja
4	= Nein	= Nein	= Nein	= Ja	Ja

Am Beispiel der Tabelle wird schnell das Problem klar, das ich oben modelliert habe. Es kann sich nur entweder um ein Dienstgeschäft oder eine Versetzung oder eine Abordnung oder eine Kommandierung handeln. Kombinationen der Eingaben sind nicht möglich. Damit handelt es sich um eine unechte Eigenständigkeit der Eingaben.

Und es gibt noch ein zweites Problem: Als Ergebnis steht immer nur „Ja“. Es muss jedoch auch ein „Nein“ möglich sein. Die Tabelle ist also nicht vollständig.

Diese beiden Probleme sind die häufigsten Fehler, die man beim Modellieren von Entscheidungen machen kann. Und sie entstehen immer dann, wenn man zuerst mit der grafischen Modellierung beginnt und nicht mit der Entscheidungstabelle.

Lassen Sie uns im dritten Schritt also die richtige Herangehensweise wählen.

 

Wir haben in den beiden vorigen Schritten die Grundlagen gelegt und gezeigt, warum man Entscheidungen nicht mit BPMN modelliert, und dass man bei DMN garantiert scheitert, wenn man nicht mit Entscheidungstabellen beginnt. Die Fehler, die zum Scheitern führen, sind unechte Eigenständigkeit und unvollständige Ergebnisse.

Die erste Entscheidung – eine Eingabe

Wir sind immer noch bei der ersten Entscheidung aus § 2 Abs. 1 BRKG.

㤠2 BRKG

(1) Dienstreisen sind Reisen zur Erledigung von Dienstgeschäften außerhalb der Dienststätte. Sie müssen, mit Ausnahme von Dienstreisen am Dienst- oder Wohnort, schriftlich oder elektronisch angeordnet oder genehmigt worden sein, es sei denn, dass eine Anordnung oder Genehmigung nach dem Amt der Dienstreisenden oder dem Wesen des Dienstgeschäfts nicht in Betracht kommt. Dienstreisen sollen nur durchgeführt werden, wenn sie aus dienstlichen Gründen notwendig sind. Dienstreisen dürfen nur angeordnet oder genehmigt werden, wenn das Dienstgeschäft nicht auf andere Weise, insbesondere durch Einsatz digitaler Kommunikationsmittel, erledigt werden kann. Dienstreisen sind auch Reisen aus Anlass der Versetzung, Abordnung oder Kommandierung.“

Betrachten wir die vier Alternativen Erledigung von Dienstgeschäften außerhalb der Dienststätte, Versetzung, Abordnung oder Kommandierung, dann handelt es sich bei jedem um einen Anlass für eine Reise. Damit haben wir einen Oberbegriff, der alle Alternativen umfasst: den Anlass der Reise. Und wir haben einen Namen für eine fünfte Variante, die zu dieser Aufzählung passt: den sonstigen Anlass.

Wie sähe also eine richtige Entscheidungstabelle aus?

Regel	Anlass der Reise	Ergebnis
1	= Dienstgeschäft außerhalb der Dienststätte	Ja
2	= Versetzung	Ja
3	= Abordnung	Ja
4	= Kommandierung	Ja
5	= Sonstiger Anlass	Nein

© BMI DV

Es gibt nur noch eine Spalte „Anlass der Reise“, die als Eingabe die vier bisherigen Spalten akzeptiert, sowie zusätzlich einen „Sonstigen Anlass“. Damit sieht die DMN-Modellierung auch viel einfacher aus.

Um von vornherein richtig zu modellieren, beginnt man immer mit Entscheidungstabellen. Aus den Eingabespalten der Entscheidungstabelle lassen sich dann die Eingabeelemente des Diagramms ableiten.

Für die Entscheidungstabelle gelten dabei wie für jede andere Tabelle auch die Grundsätze der Datenmodellierung, z. B. die Normalformen.

Wer hat übrigens gesehen, dass vor jedem Wert in den Eingabespalten ein Gleichheitszeichen (=) steht? Das ist der sogenannte Operator. Der kann auch mal Größer (>) oder Kleiner (<) lauten, oder ganz anders. Aber dazu später mehr.

Die zweite Entscheidung – zwei Eingaben?

Betrachten wir die zweite Entscheidung näher, die sich in unserem Beispiel-Paragraphen aus dem BRKG verbirgt:

„Dienstreisen [...] müssen, mit Ausnahme von Dienstreisen am Dienst- oder Wohnort, schriftlich oder elektronisch angeordnet oder genehmigt worden sein, es sei denn, dass eine Anordnung oder Genehmigung nach dem Amt der Dienstreisenden oder dem Wesen des Dienstgeschäfts nicht in Betracht kommt. [...]“

Die Frage, die hier gestellt wird, ist die Genehmigungspflicht für Dienstreisen. Dienstreisen können entweder angeordnet werden, d. h. die Führungskraft fordert die beschäftigte Person auf, die Reise zu unternehmen. Das gilt bei Versetzung, Abordnung oder Kommandierung immer. Bei Dienstgeschäften außerhalb der Dienststelle kann das auch gelten. Oder die Dienstreise geschieht auf eigenen Wunsch der beschäftigten Person, dann muss sie genehmigt werden, es sei denn, es gelten die Ausnahmen.

Beginnen wir also streng formalistisch:

Regel	Anordnung liegt vor	Ausnahmetatbestand	Ergebnis
1	= Ja	= Dienstreise am Dienst- oder Wohnort	Keine Genehmigung erforderlich
2	= Ja	= Kommt nicht in Betracht wegen dem Amt des Dienstreisenden	Keine Genehmigung erforderlich
3	= Ja	= Kommt nicht in Betracht wegen dem Wesen des Dienstgeschäfts	Keine Genehmigung erforderlich
4	= Ja	= Kein Ausnahmetatbestand erfüllt	Keine Genehmigung erforderlich
5	= Nein	= Dienstreise am Dienst- oder Wohnort	Keine Genehmigung erforderlich
6	= Nein	= Kommt nicht in Betracht wegen dem Amt des Dienstreisenden	Keine Genehmigung erforderlich
7	= Nein	= Kommt nicht in Betracht wegen dem Wesen des Dienstgeschäfts	Keine Genehmigung erforderlich
8	= Nein	= Kein Ausnahmetatbestand erfüllt	Genehmigung erforderlich

Wir haben 8 Regeln, weil wir zwei Eingaben haben, von denen die erste zwei und die zweite vier Möglichkeiten bietet. Die maximale Anzahl der möglichen Regeln ist immer das Produkt aus allen Varianten der Eingaben.

Wenn man sich die ersten vier Regeln anschaut, bei denen die Anordnung vorliegt, dann fällt auf, dass als Ergebnis immer herauskommt, dass keine Genehmigung erforderlich ist. Die zweite Eingabe spielt also keine Rolle dabei. Das kann man auch einfacher abbilden.

Regel	Anordnung liegt vor	Ausnahmetatbestand	Ergebnis
1	= Ja	= -	Keine Genehmigung erforderlich
2	= Nein	= Dienstreise am Dienst- oder Wohnort	Keine Genehmigung erforderlich
3	= Nein	= Kommt nicht in Betracht wegen dem Amt des Dienstreisenden	Keine Genehmigung erforderlich
4	= Nein	= Kommt nicht in Betracht wegen dem Wesen des Dienstgeschäfts	Keine Genehmigung erforderlich
5	= Nein	= Kein Ausnahmetatbestand erfüllt	Genehmigung erforderlich

Nach dieser Bearbeitung haben wir nur noch fünf Regeln, und einen „Joker“ im Ausnahmetatbestand. Diesen stelle ich mit dem Minus-Zeichen hinter dem Operator dar. In manchen Werkzeugen steht hier auch ein Stern.

Genauso kommt als Ergebnis immer heraus, dass keine Genehmigung erforderlich ist, wenn ein Ausnahmetatbestand erfüllt ist. Damit ist es für jeden Ausnahmetatbestand egal, ob eine Anordnung vorliegt. Nur wenn kein Ausnahmetatbestand vorliegt, darf auch keine Anordnung vorliegen, damit eine Genehmigung erforderlich ist. Wir haben also hier wieder eine unechte Eigenständigkeit. Wenn ich jetzt also meinen inneren Sprachpuristen in den Feierabend schicke, dann kann ich die Anordnung unter Ausnahmetatbestand subsumieren, um eine Spalte und damit eine Eingabe zu sparen.

Regel	Ausnahmetatbestand	Ergebnis
1	= Anordnung liegt vor	Keine Genehmigung erforderlich
2	= Dienstreise am Dienst- oder Wohnort	Keine Genehmigung erforderlich
3	= Kommt nicht in Betracht wegen dem Amt des Dienstreisenden	Keine Genehmigung erforderlich
4	= Kommt nicht in Betracht wegen dem Wesen des Dienstgeschäfts	Keine Genehmigung erforderlich
5	= Kein Ausnahmetatbestand erfüllt	Genehmigung erforderlich

© BMI DV

Wir haben also drei Regeln und eine ganze Spalte eliminiert. Gute Arbeit!

Modellieren wir also flugs das DMN-Diagramm für diese Tabelle, das fast genauso aussieht wie das für die erste Entscheidung.

Da wir jetzt so schön in Übung sind, betrachten wir die dritte Entscheidung.

Die dritte Entscheidung – zwei Eingaben und eine Wissensquelle

„(1) [...] Dienstreisen sollen nur durchgeführt werden, wenn sie aus dienstlichen Gründen notwendig sind. Dienstreisen dürfen nur angeordnet oder genehmigt werden, wenn das Dienstgeschäft nicht auf andere Weise, insbesondere durch Einsatz digitaler Kommunikationsmittel, erledigt werden kann. [...]“

Die dritte Entscheidung dreht sich um die Frage, ob eine Dienstreise angeordnet genehmigt werden darf. Hier sind zwei unterschiedliche Aspekte benannt: Erstens muss eine dienstliche Notwendigkeit für die Dienstreise vorliegen. Zweitens darf es keine Möglichkeit geben, das Dienstgeschäft auf andere Art als durch eine Dienstreise zu erledigen, z. B. mittels Videokonferenz. Jetzt könnte man die Frage stellen, ob die Notwendigkeit überhaupt besteht, wenn es eine Alternative gibt, aber der Sprachpurist hat ja zum Glück Feierabend. Also modellieren wir die Tabelle:

Regel	Dienstliche Notwendigkeit	Alternativen vorhanden	Ergebnis
1	= Ja	= Ja	Abordnung / Genehmigung nicht möglich
2	= Ja	= Nein	Abordnung / Genehmigung möglich
3	= Nein	= -	Abordnung / Genehmigung nicht möglich

© BMI DV

Damit ich nicht immer identisch aussehende DMN-Diagramme modellieren muss, habe ich hier mal ein neues Element eingebracht: die Wissensquelle. Neben den Eingabedaten, die man auch aus der Tabelle erkennt, kann in der Grafik die Wissensquelle angegeben werden, um anzugeben, woher man die Informationen erhält.

Das kann wie im Beispiel die Begründung des Antrags sein (woraus man beim Erstellen eines Antragsformulars weiß, dass man ein Feld für die Begründung vorsehen muss), das kann aber auch der Paragraph eines Gesetzes, eine Rolle oder ein Datenspeicher sein. Das Element Wissensquelle ist universell verwendbar.

Entscheidungstabellen mit mehreren Ausgaben

Frage: Ist es möglich, eine Entscheidungstabelle auch mit mehreren Ausgaben zu versehen? Radio Eriwan: Im Prinzip ja, aber...

Regel	Temperatur	Wetter	Jacke	Schuhe
1	> 20° C	Trocken	Ohne	Sandalen
2	> 20° C	Niederschlag	Leichte Regenjacke	Halbschuhe
3	>= 5° C und <= 20°C	-	Übergangsjacke	Halbschuhe
4	< 5° C	Trocken	Mantel	Halbschuhe
5	< 5° C	Niederschlag	Regenmantel	Stiefel

Dieses fiktive Beispiel enthält nicht nur zwei Eingaben (Temperatur und Wetter), sondern auch zwei Ausgaben in der Tabelle (Jacke und Schuhe). In Abhängigkeit von Temperatur und Wetter wird eine Empfehlung für eine Jacke und für Schuhe gegeben. Eigentlich handelt es sich auch um zwei Entscheidungen (Welche Jacke trage ich und welche Schuhe ziehe ich an?). Weil sich beide Eingaben auf beide Ausgaben auswirken, ist das ein Fall, in dem man mehrere Ausgaben in einer Tabelle haben kann.

Wäre es nicht auch möglich, unsere Entscheidungen zur Dienstreise in einer Tabelle zusammenzufassen? Wenn wir das mit der zweiten und dritten Entscheidung versuchen, ergibt sich folgendes Bild:

Regel	Ausnahmetatbestand	Dienstliche Notwendigkeit	Alternativen vorhanden	Erfordernis Genehmigung	Genehmigungs-fähigkeit
1	= Anordnung liegt vor	= -	= -	Keine Genehmigung erforderlich	-
2	= Dienstreise am Dienst- oder Wohnort	= -	= -	Keine Genehmigung erforderlich	-
3	= Kommt nicht in Betracht wegen dem Amt des Dienstreisenden	= -	= -	Keine Genehmigung erforderlich	-
4	= Kommt nicht in Betracht wegen dem Wesen des Dienstgeschäfts	= -	= -	Keine Genehmigung erforderlich
5	= Kein Ausnahmetatbestand erfüllt	= Ja	= Ja	Genehmigung erforderlich	Abordnung / Genehmigung nicht möglich
6	= Kein Ausnahmetatbestand erfüllt	= Ja	= Nein	Genehmigung erforderlich	Abordnung / Genehmigung möglich
7	= Kein Ausnahmetatbestand erfüllt	= Nein	= -	Genehmigung erforderlich	Abordnung / Genehmigung nicht möglich

Sie sehen selbst: Liegt ein Ausnahmetatbestand vor, ist bleibt die zweite Ergebnisspalte leer, und die beiden anderen Eingaben spielen keine Rolle. Nur wenn kein Ausnahmetatbestand vorliegt, haben die beiden anderen Eingaben eine Bedeutung. Die erste Eingabe wirkt sich jedoch immer nur auf die erste Ergebnisspalte aus, die beiden anderen Eingaben zusammen auf die zweite Ergebnisspalte. Dieser Zusammenhang geht jedoch nicht auf den ersten Blick aus der Tabelle hervor.

Zwar haben wir bei zwei Entscheidungen 5+3=8 Regeln und hier nur 7, aber die Übersichtlichkeit leidet. Dadurch ist es auch schwieriger zu erkennen, ob die Tabelle konsistent und vollständig ist. Mehr Aufwand ohne Mehrwert sollte vermieden werden.

Fazit

In diesem Artikel haben wir gelernt, dass Entscheidungstabellen die Basis für die grafische Notation DMN sind. Ohne eine konsistente und vollständige Entscheidungstabelle sollte man mit der grafischen Modellierung nicht beginnen.

Wir haben auch gelernt, dass das Prüfen und Optimieren von Entscheidungstabellen aufwändig, aber notwendig ist.

Das Kombinieren von Entscheidungen in einer Tabelle ist möglich, aber nur dann sinnvoll, wenn darunter die Übersichtlichkeit nicht leidet.

Im nächsten Schritt werden wir die Kombination von Entscheidungen bzw. das Modellieren von Entscheidungsstrukturen näher betrachten.

Wir haben in den letzten Artikeln gesehen, wie man Entscheidungsdiagramme auf Basis von Entscheidungstabellen modelliert. Wir haben auch gesehen, wie man Entscheidungstabellen optimiert, und dass man sie kombinieren kann, wenn es dafür gute Gründe gibt.

In diesem Artikel betrachten wir die Kombination von Entscheidungen zu Entscheidungsstrukturen etwas näher. Dafür verwenden wir weiterhin unser Beispiel aus § 2 Abs. 1. BRKG.

㤠2 BRKG

(1) Dienstreisen sind Reisen zur Erledigung von Dienstgeschäften außerhalb der Dienststätte. Sie müssen, mit Ausnahme von Dienstreisen am Dienst- oder Wohnort, schriftlich oder elektronisch angeordnet oder genehmigt worden sein, es sei denn, dass eine Anordnung oder Genehmigung nach dem Amt der Dienstreisenden oder dem Wesen des Dienstgeschäfts nicht in Betracht kommt. Dienstreisen sollen nur durchgeführt werden, wenn sie aus dienstlichen Gründen notwendig sind. Dienstreisen dürfen nur angeordnet oder genehmigt werden, wenn das Dienstgeschäft nicht auf andere Weise, insbesondere durch Einsatz digitaler Kommunikationsmittel, erledigt werden kann. Dienstreisen sind auch Reisen aus Anlass der Versetzung, Abordnung oder Kommandierung.“

Wie verwendet man nun Entscheidungsdiagramme in einer Prozessdarstellung? In den meisten Werkzeugen ist es möglich, ein DMN-Diagramm mit der Geschäftsregelaufgabe (Business Rule Task) in BPMN zu verknüpfen. So kann man direkt aus dem Prozessmodell auf das Entscheidungsmodell zugreifen. Wir haben am Beispiel des Bundesreisekostengesetzes bislang drei Entscheidungen modelliert:

1. Liegt eine Dienstreise vor?
2. Ist eine Genehmigung erforderlich?
3. Ist eine Genehmigung oder Abordnung möglich?

Eine vierte Frage steht noch aus: Wird die beantragte Dienstreise genehmigt?

Diese Entscheidung ist am Ende eines Ablaufs, den man in BPMN modellieren kann. Das Diagramm sieht bereits deutlich einfacher aus als das Diagramm aus unserem ersten Artikel, als wir versucht haben, die Entscheidung vollständig in BPMN zu modellieren:

© BMI DV

Man kann jedoch auch die Entscheidungsstruktur hinter diesem Ablauf in einen Entscheidungsbaum zusammenfassen. Der entstandene Entscheidungsbaum hat zwei Ebenen, es wären jedoch auch mehr Ebenen möglich:

© BMI DV

Die Ergebnisse der drei ersten Entscheidungen werden als Eingabe für die vierte Entscheidung verwendet. Die zusätzliche Eingabe „Genehmigung durch die Führungskraft“ wird mit der Wissensquelle „Führungskraft“ verbunden.

In der Konsequenz vereinfacht sich das BPMN-Diagramm für den Entscheidungsablauf noch einmal erheblich:

© BMI DV

Betrachten wir die Entscheidungstabelle für den Entscheidungsbaum. Auch hier werden die Ausgaben der vorlaufenden Entscheidungen als Eingaben verwendet werden.

Regel	Dienstreise liegt vor?	Dienstreisegenehmigung erforderlich?	Dienstreise genehmigungsfähig?	Genehmigung durch Führungskraft?	Ergebnis
1	= Ja	= Genehmigung erforderlich	= Abordnung / Genehmigung möglich	= Ja	Genehmigt
2	= Ja	= Genehmigung erforderlich	= Abordnung / Genehmigung möglich	= Nein	Nicht genehmigt
3	= Ja	= Genehmigung erforderlich	= Abordnung / Genehmigung nicht möglich	= -	Nicht genehmigt
4	= Ja	= Genehmigung nicht erforderlich	= -	= -	Genehmigungsfrei
5	= Nein	= -	= -	= -	Genehmigungsfrei

Wie man hier sehr schön sehen kann, wird durch die Kombination von Entscheidungstabellen sowohl grafisch als auch von der Tabellenstruktur her eine gut lesbare Entscheidungsstruktur entworfen.

Fazit

Das Kombinieren von Entscheidungen kann nicht nur innerhalb einer Tabelle, sondern auch durch die Kombination von Tabellenergebnissen geschehen. Die daraus entstehenden Entscheidungsbäume können in DMN auch grafisch dargestellt werden.

Entscheidungsbäume sind leichter zu lesen als Tabellen mit mehreren Ergebnissen.

Die Verwendung von Entscheidungsbäumen in DMN vereinfacht BPMN-Prozessdiagramme erheblich.

Schauen wir uns im nächsten Schritt die Operatoren etwas genauer an.

Bislang haben wir Entscheidungen, Entscheidungstabellen und Entscheidungsstrukturen betrachtet. Um Entscheidungstabellen zu optimieren, gibt es zwei Funktionalitäten, die wir in diesem und dem nächsten Schritt näher beleuchten. Für Menschen, die selbst Computer programmieren, sind diese beiden Artikel Binsenweisheiten, für andere jedoch nicht ganz einfach zu verstehen. Dennoch ist das Verständnis notwendig, um Entscheidungslogiken gut zu modellieren.

Leider ist dieser Teil auch nicht interessant zu beschreiben, sondern zeigt wichtige Grundlagen auf, die einfach auswendig gelernt werden müssen.

Datentypen

Datentypen legen fest, wie ein Computer die Daten behandelt. Die wichtigsten Datentypen sind Zahl und Text. Zahlworte wie „Zwei“ sind immer Text, obwohl ihre Bedeutung für uns numerisch ist.

Die Ziffernfolge „15“ kann vom Computer sowohl als Zahl wie auch als Text interpretiert werden. Die Interpretation hat Auswirkungen darauf, wie die Operatoren mit den Werten umgehen.

Ein Beispiel illustriert das: Für einen Menschen gilt immer: 15 > 2. Für einen Computer gilt das nur, wenn er die 15 und die 2 als Datentyp Zahl interpretiert. Werden die beiden Ziffernkombinationen als Text interpretiert, dann gilt jedoch: 15 < 2. Das mag überraschen, wenn man nicht weiß, wie Computer intern funktionieren.

Da Computer nur Zahlen kennen, werden intern auch Buchstaben in Zahlen umgewandelt. Die Zahlen sind international standardisiert. So steht die 65 für den Buchstaben A, die 66 für B, die 67 für C usw. Der Text „15“ wird im Computer also „49 53“ geschrieben, denn 49 ist der Code für 1 und 53 der Code für 5. Der Text „2“ entspricht dem Code 50. Vergleicht der Computer also die Texte „15“ und „2", dann vergleicht er die 49 mit der 50 und kommt zum Ergebnis, dass 49 kleiner 50 ist. Folglich ist der Text „15“ kleiner als der Text „2".

Operatoren

Operatoren vergleich zwei Werte miteinander. Als Ergebnis kommt „wahr“ heraus, wenn der Vergleich korrekt ist, und „falsch", wenn der Vergleich nicht korrekt ist.

Für die Beispiele wird immer zuerst der Wert der Eingabe angegeben und dann der Wert, der in der Entscheidungstabelle hinter dem Operator angegeben ist. Danach wird mit einem Pfeil das Ergebnis der Auswertung beschrieben.

Folgende Operatoren können in Tabellen zum Einsatz kommen, mit Bedeutung und Beispielen:

Operator (Varianten)	Bedeutung beim Datentyp Zahl	Bedeutung beim Datentyp Text
= (is, ist)	Der Eingabewert entspricht der angegebenen Zahl. Beispiel: 0 = 5 → falsch 10 = 2 → falsch	Der Eingabewert entspricht genau dem angegebenen Text. Beispiel: Kuchen = Kuchen → wahr Kuchen = Teig → falsch 10 = 2 → falsch
≠ (is not, ist nicht, <>)	Der Eingabewert entspricht nicht der angegebenen Zahl. Beispiel: 0  ≠ 5 → wahr 10 ≠ 2 → wahr	Der Eingabewert entspricht nicht genau dem angegebenen Text. Beispiel: Kuchen ≠ Kuchen → falsch Kuchen ≠ Teig → wahr 10 ≠ 2 → wahr
> (greater than, größer als)	Der Eingabewert ist größer als die angegebene Zahl. Beispiel: 0  > 5 → falsch 10 > 2 → wahr	Der Eingabewert liegt bei einer alphabetischen Sortierung hinter dem angegebenen Text. Beispiel: Kuchen > Kuchen → falsch Kuchen > Teig → falsch 10 > 2 → falsch
< (less than, kleiner als)	Der Eingabewert ist kleiner als die angegebene Zahl. Beispiel: 0  < 5 → wahr 10 < 2 → falsch	Der Eingabewert liegt bei einer alphabetischen Sortierung vor dem angegebenen Text. Beispiel: Kuchen < Kuchen → falsch Kuchen < Teig → wahr 10 < 2 → wahr
≥ (greater than or equal, größer oder gleich, >=)	Der Eingabewert ist größer als die angegebene Zahl oder entspricht ihr. Beispiel: 0  ≥ 5 → falsch 10 ≥ 2 → wahr	Der Eingabewert liegt bei einer alphabetischen Sortierung hinter dem angegebenen Text oder entspricht ihm genau. Beispiel: Kuchen ≥ Kuchen → wahr Kuchen ≥ Teig → falsch 10 ≥ 2 → falsch
≤ (less than or equal, kleiner oder gleich, <=)	Der Eingabewert ist kleiner als die angegebene Zahl oder entspricht ihr. Beispiel: 0  ≤ 5 => wahr 10 ≤ 2 → falsch	Der Eingabewert liegt bei einer alphabetischen Sortierung vor dem angegebenen Text oder entspricht ihm genau. Beispiel: Kuchen ≤ Kuchen → wahr Kuchen ≤ Teig → wahr 10 ≤ 2 → wahr
enthält (has)	Die angegebene Liste enthält alle Eingabewerte. Beispiel: 0  enthält 5 → falsch 10 enthalt 2 → falsch 12 enthält 2 → falsch	Der Eingabewert ist in dem angegebenen Text enthalten. Beispiel: Kuchen enthält Kuchen → wahr Kuchen enthält Teig → falsch 10 enthalt 2 → falsch 12 enthält 2 → wahr
enthält nicht (has not)	Die angegebene Liste enthält nicht alle Eingabewerte bzw. enthält nicht den Eingabewert. Beispiel: 0  enthält nicht 5 → wahr 10 enthält nicht 2 → wahr 12 enthält nicht 2 → wahr	Der Eingabewert ist nicht in dem angegebenen Text enthalten. Beispiel: Kuchen enthält nicht Kuchen → falsch Kuchen enthält nicht Teig → wahr 10 enthält nicht 2 → wahr 12 enthält nicht 2 → falsch

Vor- und Nachteile der Operatoren

Natürlich haben Operatoren ihre Vorteile. Es ist einfacher, eine einzige Regel mit dem Vergleich „< 18 Jahre“ zu schreiben, als 17 Regeln mit den Vergleichen von „=1 Jahr“ bis „=17 Jahre". Die manuelle Überprüfung der Vollständigkeit und Widerspruchsfreiheit einer Tabelle wird mit Operatoren jedoch erheblich schwieriger.

Es gibt Computerprogramme, die zumindest teilweise die Vollständigkeit und Widerspruchsfreiheit von Entscheidungstabellen automatisiert prüfen können.

Fazit

Operatoren vereinfachen die Schreibweise von Regeln in Entscheidungstabellen. Sie erfordern jedoch, dass man ihre Bedeutung für die einzelnen Datentypen verinnerlicht hat.

Durch Operatoren wird jedoch auch das Prüfen auf Vollständigkeit und Konsistenz schwieriger.

Im nächsten Schritt betrachten wir die Hit Policies, die zusammen mit Operatoren die Bedeutung von Entscheidungstabellen festlegen.

In den vorigen Schritten haben wir fast ausschließlich mit dem Ist-Gleich-Operator (=) gearbeitet. Mit den Operatoren aus dem vorigen Schritt haben wir aber nicht nur mehr Möglichkeiten, sondern auch eine ganz neue Art von Problemen geschaffen.

Um diese Probleme zu lösen, gibt es in Entscheidungstabellen sogenannte Hit Policies. Dieses nahezu unübersetzbare Wort bedeutet so viel wie Strategie zur Auswahl der Regeln. Bislang haben wir immer die Hit Policy „U“ (für unique, eindeutig) verwendet, d. h. es konnte immer nur eine Regel zutreffen. Bei Ist-Gleich-Operatoren erschließt sich jedem, dass zwei identische Regeln in einer Tabelle keinen Sinn ergeben. Doch wie sieht es mit Bereichsoperatoren aus?

Nehmen wir einmal folgende Tabelle für männliche Personen an:

Regel	Alter der Person in Jahren	Bezeichnung
1	< 18	Knabe
2	< 65	Mann
3	>= 65	Senior

Hier ist unschwer zu erkennen, dass für einen 17jährigen nicht nur eine Regel zutrifft, sondern die Regeln 1 und 2 gleichermaßen. Diese Tabelle ist also fehlerhaft, wenn man von einer eindeutigen Auswahl ausgeht. Stattdessen müsste man die Tabelle so formulieren:

Regel	Alter der Person in Jahren	Bezeichnung
1	< 18	Knabe
2	>=18 und < 65	Mann
3	>= 65	Senior

Alternativ könnte man auch eine andere Hit Policy auswählen. Schauen wir uns einen ersten Satz an Richtlinien an:

Buchstabe	Englischer Name	Deutscher Name	Bedeutung
U	unique	eindeutig	Für jeden möglichen Eingabewert muss genau eine Regel zutreffen. Es darf keinen Eingabewert geben, für den keine oder mehr als eine Regel zutrifft. Das ist die Standard-Richtlinie
F	first	erste	Es können mehrere Regeln für einen Eingabewert zutreffen. Die oberste zutreffende Regel wird ausgewählt. Es darf keine Eingabewerte geben, für die keine Regel zutrifft.
P	priority	prioritär	Diese Regel ist dem F sehr ähnlich. Statt der Reihenfolge der Regeln zählt aber die Reihenfolge, in der die möglichen Ergebnisse definiert ist.
A	any	irgendein	Hier können mehrere Regeln zutreffen, solange sie zum selben Ergebnis führen. Führen die Regeln zu unterschiedlichen Ergebnissen, ist die Tabelle fehlerhaft, und es wird kein Ergebnis zurückgegeben.

Schauen wir uns nochmal die erste Beispieltabelle an:

Regel	Alter der Person in Jahren	Bezeichnung
1	< 18	Knabe
2	< 65	Mann
3	>= 65	Senior

Mit der Hit Policy F wäre die erste Beispieltabelle also korrekt, da für einen 17jährigen die Regel 1 zutrifft und daher alle anderen Regeln ignoriert werden.

Schauen wir uns eine weitere Tabelle an. Für die Ausgabe definieren wir einen Datentyp „Monat", der die Monatsnamen in der regulären Reihenfolge (Januar, Februar, ..., Dezember) enthält. Die Eingabe ist die Nummer des Monats.

Regel	Monat (numerisch)	Monat (Text)
1	< 13	Dezember
2	< 12	November
3	< 11	Oktober
4	< 10	September
5	< 9	August
6	< 8	Juli
7	< 7	Juni
8	< 6	Mai
9	< 5	April
10	< 4	März
11	< 3	Februar
12	< 2	Januar

Gibt man eine 9 ein, dann sind die Regeln 1 bis 4 zutreffend. Bei einer Hit Policy „U“ wäre die Tabelle ungültig, ebenso mit „A", weil hier unterschiedliche Ergebnisse stehen.

Mit „F“ würde bei einer Eingabe von 9 die erste zutreffende Regel gelten, also die Nr. 1, und damit wäre das Ergebnis Dezember. Überrascht?

Mit „P“ würde dagegen würden die Ergebnisse des Datentyps gewählt, also Dezember, November, Oktober und September. Da im Datentyp die Monate in der regulären Reihenfolge stehen, kommt der September vor den anderen Ergebnissen zum Zug und wäre das Ergebnis der Tabelle.

Hinweis: Für Prozessmodellierung wissen Sie jetzt bereits alles über Entscheidungstabellen, was Sie jemals brauchen werden. Sie können also zum Fazit wechseln.

Sammelstrategien

Bislang sorgten alle Hit Policies dafür, dass am Ende nur ein Ergebnis aus der Tabelle purzelt. Die Erfinder der Hit Policies haben es aber gut mit uns gemeint, daher gibt es noch mehr davon.

Buchstabe	Englischer Name	Deutscher Name	Bedeutung
O	Output order	Ausgabereihenfolge	Alle Ergebnisse werden in der Reihenfolge zurückgegeben, wie sie im Datentyp des Ergebnisses definiert sind. Siehe auch P.
R	Rule order	Regelreihenfolge	Alle Ergebnisse werden in der Reihenfolge der Regeln zurückgegeben. Siehe auch F.
C	Collect	Sammeln	Alle Ergebnisse werden in einer willkürlichen Reihenfolge zurückgegeben.
C+	Collect (sum)	Summe	Alle Ergebnisse werden addiert, und die Summe als Ergebnis zurückgegeben. Das funktioniert natürlich nur, wenn der Ergebnistyp numerisch ist.
C#	Collect (count)	Anzahl Ergebnisse	Alle Ergebnisse werden gezählt und die Anzahl als Ergebnis zurückgegeben.
C<	Collect (min)	Minimum	Das kleinste Ergebnis wird zurückgegeben. Das funktioniert nur, wenn der Ergebnistyp numerisch ist.
C>	Collect (max)	Maximum	Das höchste Ergebnis wird zurückgegeben. Das funktioniert nur, wenn der Ergebnistyp numerisch ist.

Schauen wir uns die Beispieltabelle mit den Monaten noch einmal an. Die Hit Policies C+, C< und C> würden nicht funktionieren, weil das Ergebnis Text ist.

O würde bei einer Eingabe von 9 September, Oktober, November, Dezember zurück liefern, R dagegen Dezember, November, Oktober, September. C würde die Monatsnamen in einer nicht vorhersagbaren Reihenfolge zurück liefern. C# würde 4 ergeben.

Nehmen wir noch ein Beispiel: Ein Autofahrer fährt nicht angeschnallt mit Tempo 60 in einer 30er-Zone über eine schon länger rote Ampel und wird dabei geblitzt.

Regel	Geschwindigkeitsverstoß	Anschnallpflicht verletzt	Rotlichtverstoß	Punkte
1	<= 40 km/h	= -	= -	1
2	= -	= Ja	= -	0
3	= -	= -	= Ja, weniger als 1 Sekunde	1
4	= -	= -	= Ja, mehr als 1 Sekunde	2

Der Einfachheit halber habe ich den Bußgeldkatalog mal drastisch verkürzt. Und ja, die Tabelle ist auch nicht sinnvoll. Wer ein besseres Beispiel kennt, darf das in den Kommentaren hinterlegen.

Für den Autofahrer gelten im Beispiel die Regeln 1, 2 und 4 als erfüllt.

Mit der Hit Policy C+ würden die Punkte aufaddiert, das Ergebnis wäre also 3. Mit C< würde das kleinste Ergebnis zurückgegeben, also 0, mit C> das höchste Ergebnis, also 2. Und C# würde auch 3 ergeben, R dagegen 1, 0, 2. O und P würden nicht funktionieren, da es sich bei den Ergebnissen um Zahlen handelt und nicht um eine Aufzählung.

Fazit

Hit Policies haben Einfluss auf die Gültigkeit von Tabellen. Sie erlauben bei richtiger Anwendung, einfachere Entscheidungstabellen zu erstellen. Das Verständnis der Hit Policies und Operatoren ist ein wichtiges Werkzeug für die Modellierung von Entscheidungen.

Ziehen wir zum Schluss noch ein Gesamt-Fazit und geben einen Ausblick.

Wie Sie gesehen haben, ist die grafische Notation DMN nicht schwer zu erlernen. Sie besteht aus drei wesentlichen Elementen: Entscheidungen, Eingaben und Wissensquellen, sowie zwei Verbindungstypen zwischen den Elementen. Sie hat das Potenzial, die in BPMN modellierten Prozesse erheblich zu vereinfachen.

Um mit DMN gut zu modellieren, muss man das Konstrukt der Entscheidungstabellen einmal verstanden haben, was prinzipiell auch nicht schwer ist. Die Probleme ergeben sich erst dann, wenn man für die Entscheidungstabellen Vollständigkeit und Widerspruchsfreiheit sicherstellen will. Entscheidungsdiagramme sollten immer aus einer validen Entscheidungstabelle heraus modelliert werden, sonst ist die Gefahr zu groß, dass man dabei Fehler macht.

Werkzeugunterstützung im Rahmen der Maßnahme PMT

Derzeit (Stand Januar 2024) unterstützt Adonis leider nur die grafische Modellierung von DMN. Entscheidungstabellen können als Excel-Dateien verlinkt werden, was nicht wirklich weiterhilft. Wir sind jedoch mit dem Hersteller im Gespräch, um folgende Funktionalitäten in Adonis zubekommen:

• Native Darstellung von Entscheidungstabellen in Adonis
• Synchronisation zwischen Eingabespalten in der Tabelle und Eingabeelementen in der grafischen Notation
• Schaffung von Auswahllisten in den Eingabeelementen, die dann in der Tabelle verwendet werden können
• Vollständigkeitsprüfung für zumindest einen Teil der Datentypen
• Prüfung auf Widerspruchsfreiheit zusammen mit der Hit Policy für zumindest einen Teil der Datentypen

Was davon umgesetzt werden kann, ist noch nicht sicher. Definitiv nicht realisiert werden Funktionen zum Ablauf von Entscheidungsprozessen, weil das nur im Kontext einer Prozessablaufumgebung sinnvoll wäre. Und die wird von der Maßnahme PMT-Prozessmanagement ausdrücklich nicht unterstützt, weil das die Schutzbedarfsfeststellung für das Werkzeug aushebeln würde.

Ausblick

DMN eröffnet ein weites Spektrum an Möglichkeiten. So wird derzeit gerade im Digitalcheck daran gearbeitet, schon bei der Erstellung von Gesetzestexten von Legistinnen und Legisten eine Visualisierung vornehmen zu lassen. Richtig angewandt kann das nicht nur zu leichter verständlichen Gesetzestexten führen, sondern auch dabei unterstützen, durch die Kombination von unterschiedlichen Methoden mehr Fehler als durch bloße Abstimmung bereits vor der Veröffentlichung zu finden. Zudem erleichtert dieses Vorgehen die Digitalisierung der Gesetzesumsetzung bzw. des Verwaltungshandelns enorm.