Entscheidungsanforderungsdiagramm

Zweck

Das Diagramm kartiert eine komplexe Geschäftsentscheidung und zerlegt sie in ein Netz von Teilentscheidungen, deren jede sich einzeln beschreiben, steuern und pflegen lässt. Es beantwortet eine Frage, welche die Logik einer einzelnen Regel offenlässt: Was braucht diese Entscheidung, um getroffen zu werden, welche Daten, welches Wissen, welche Autorität und wie fügen sich diese Teile zusammen. Das Ergebnis ist das Diagramm selbst, die Anforderungsebene eines Entscheidungsmodells, auf die anschliessend die Detaillogik aufgesetzt wird.

Sein Wert verdichtet sich an zwei Fronten. Es trennt die Entscheidungslogik vom Prozessfluss, sodass sich die eine steuern lässt, ohne die andere anzurühren. Und es liefert das Gerüst eines ausführbaren Modells, den Ausgangspunkt einer regelbasierten Automatisierung.

Einsatz

Wann einzusetzen

• Komplexe Entscheidung zum Zerlegen: sie in ein Netz einzeln beschriebener und gesteuerter Teilentscheidungen aufspalten.
• Grosse Menge an Regeln zu ordnen: sie nach Entscheidung gruppieren, für Wiederverwendung und Auswirkungsanalyse statt einer unbeherrschbaren Tabelle.
• In einem BPMN-Prozess vergrabene Entscheidung: die Logik aus dem Fluss lösen, damit eine Geschäftsregelaufgabe sie aufruft.
• Regelbasierte Automatisierung als Ziel: das DRD ist die strukturelle Schicht eines Modells, das eine Entscheidungs-Engine ausführt.
• Geteiltes Bild einer zu treffenden Entscheidung: eine für Stakeholder lesbare Zeichnung, welche die Auswirkungsanalyse über Grenzen hinweg trägt.

Wann nicht einzusetzen

• Eine einzelne atomare Entscheidung: eine Entscheidungstabelle allein erfasst sie, das Netz bringt nichts, die Entscheidungstabelle wählen.
• Eine einfache, mit dem Prozess verschweisste Entscheidung: sie im Fluss belassen, ein eigenes Modell fügt nur Komplexität hinzu, BPMN wählen.
• Überwiegend verhaltensbezogene Regeln (Verhalten, Verpflichtung): der Rahmen des DRD adressiert sie nicht, die Geschäftsregelanalyse wählen.

Beschreibung

Der Anforderungsgraph und das Diagramm

DMN unterscheidet zwei Objekte. Der Entscheidungsanforderungsgraph (DRG) ist das vollständige Modell: die Gesamtheit der Entscheidungen, Daten, Wissensbestände und der Abhängigkeiten, die sie verbinden. Das Entscheidungsanforderungsdiagramm (DRD) ist eine Sicht darauf, vollständig oder teilweise, jene, die man zeichnet und teilt. Das DRD ist eine der drei Notationen, welche BABOK unter der Entscheidungsmodellierung zusammenfasst, jene, die auf der Ebene des Netzes statt auf der Ebene einer einzelnen Regel arbeitet.

Vier Knoten und drei Beziehungen

Die Zeichnung beruht auf vier Formen, deren jede einen Elementtyp trägt.

• Die Entscheidung, ein Rechteck: Sie nimmt einen Satz von Eingaben und leitet daraus eine Ausgabe aus einer definierten Menge ab, indem sie eine Entscheidungslogik anwendet. Sie ist das, was entschieden wird.
• Das Eingabedatum, ein Oval: ein dem Diagramm gelieferter Wert, die rohe Tatsache, die eine Entscheidung verbraucht, ein Einkommen, ein Alter, ein Betrag.
• Das Geschäftswissensmodell (business knowledge model, BKM), ein Rechteck mit zwei abgeschnittenen oberen Ecken: ein wiederverwendbarer Logikblock, ein Regelsatz, eine Entscheidungstabelle oder ein Entscheidungsbaum, sogar ein Vorhersagemodell, der genau beschreibt, wie zu entscheiden ist.
• Die Wissensquelle, eine Dokumentform mit gewelltem Fuss: die Autorität, aus der die Logik stammt, ein Dokument, eine Vorschrift oder eine Person.

Drei Beziehungen drücken die Abhängigkeiten aus, und das macht die Zeichnung zu einem Anforderungsdiagramm.

• Die Informationsanforderung, ein durchgezogener Pfeil, verbindet ein Eingabedatum mit einer Entscheidung oder eine Entscheidung mit einer übergeordneten Entscheidung, die sie speist. Sie ist das Rückgrat, das eine komplexe Entscheidung in Teilentscheidungen zerlegt.
• Die Wissensanforderung, ein gestrichelter Pfeil, verbindet ein Geschäftswissensmodell mit der Entscheidung, die es aufruft: Diese Entscheidung wird mittels dieser Logik getroffen.
• Die Autoritätsanforderung, eine gestrichelte Linie mit einem ausgefüllten runden Kopf, verbindet eine Wissensquelle mit einer Entscheidung oder einem Wissensmodell: Dieses Dokument oder diese Person ist massgebend für die Logik.

Das Netz aufbauen

Man geht von der Kopfentscheidung aus, jener, die der Betrachtungsbereich verlangt, und zerlegt sie dann: Jede Teilentscheidung, die sie speist, wird zu einem durch eine Informationsanforderung verbundenen Knoten, bis hinunter zu Entscheidungen, die elementar genug sind, um sich mit einer einzigen Logik beschreiben zu lassen. An jede Entscheidung hängt man die Eingabedaten, die sie verbraucht, dann das Geschäftswissen, das sie steuert, und schliesslich die Quelle, aus der dieses Wissen seine Autorität bezieht. Das entstandene Netz zerlegt die komplexe Entscheidung in einfachere Blöcke, jeder für sich beschreibbar und steuerbar.

Das DRD hört auf der Ebene des Netzes auf. Die Logik einer elementaren Entscheidung, die Regeln, die Eingabewerte auf eine Ausgabe abbilden, liegt in einer Entscheidungstabelle oder einem Entscheidungsbaum, der unter dem Knoten angehängt ist. Diese Bedingungen im DRD selbst zu zeichnen ist der häufigste Fehler: Er vermengt die beiden Ebenen und überlädt das Diagramm mit einem Detail, das nicht das seine ist. Umgekehrt kostet ein DRD für eine atomare Entscheidung, die eine einzige Tabelle erfasst, ohne etwas einzubringen: Das Netz rechtfertigt sich nur durch die Zerlegung oder die Automatisierung.

Die Entscheidung vom Prozess trennen

Das DRD verbindet sich mit der BPMN-Notation, und die Rollenverteilung ist klar: BPMN modelliert den Fluss, die Folge der Aktivitäten, während DMN die Entscheidung modelliert, die der Fluss aufruft. Im Prozess ruft eine Geschäftsregelaufgabe die Entscheidung auf, die in ihrem eigenen DMN-Modell lebt, statt sich in eine Traube von Verzweigungen im Fluss zu zerstreuen. Der Nutzen liegt in ihren Änderungsrhythmen: Die Entscheidungslogik ändert sich weit häufiger als die Prozessstruktur, und sie aus dem Fluss zu lösen erlaubt, sie zu ändern und zu steuern, ohne den Prozess anzurühren.

Mehr Details finden Sie in unserem BPMN-Tutorial.

Diese Struktur dient auch der Automatisierung. Ein DMN-Modell ist dafür gebaut, vom Geschäft gelesen und von einer Maschine ausgeführt zu werden: Das DRD gibt das Gerüst, und die zugrunde liegenden Tabellen, in der Ausdruckssprache FEEL geschrieben, tragen eine Logik, die eine Entscheidungs-Engine unmittelbar abarbeitet. Das ist es, was DMN für die regelbasierte Automatisierung tragfähig macht, ohne die manuelle Entscheidung oder die Vorhersageanalyse auszuschliessen.

Drei Fallstricke kommen zur Vermengung der Ebenen und zum Übermodellieren hinzu. Ein dokumentiertes Modell kann den trügerischen Eindruck erwecken, die Organisation entscheide kohärent, obwohl sie es nicht tut. Da eine Entscheidung oft mehrere organisatorische Grenzen überschreitet, verlangt es einen einzuplanenden Aufwand, das Modell genehmigen zu lassen. Und eine Automatisierung ist nur zuverlässig, wenn die Geschäftsterminologie klar und gemeinsam definiert ist: unscharfe Begriffe pflanzen sich als Datenqualitätsmängel fort, die die Engine erben wird.

KI-Überlegungen

Zwei Anwendungen tragen. Die erste ist der Entwurf: Aus einer Vorschrift oder einer geschriebenen Richtlinie schlägt ein Sprachmodell eine erste Zerlegung vor, mögliche Entscheidungen, die Daten, die sie zu verbrauchen scheinen, und die genannten Quellen, welche die Analystin korrigiert, statt vom leeren Blatt auszugehen. Die zweite ist die Formprüfung, mechanisch und delegierbar: Erhält jede Entscheidung ihre Eingabedaten, ist jedes Geschäftswissensmodell an eine Entscheidung und eine Autorität angehängt, ist der Graph azyklisch, bleibt ein Eingabedatum ungenutzt?

Was sich nicht delegieren lässt, liegt im Sinn. Zu entscheiden, dass ein Element eher eine Teilentscheidung als bloss ein Datum ist, verlangt ein Verständnis des Geschäfts. Die Quelle zu bestimmen, die Autorität besitzt, die anwendbare Vorschrift von einem Dokument zu unterscheiden, das nur ein Kommentar dazu ist, erfordert Kenntnis des Rahmens. Und zu entscheiden, dass eine Entscheidung automatisiert werden soll oder bei einem Menschen bleiben muss, ist eine Verantwortungswahl, die kein Modell anstelle der Organisation trägt.

Beispiele

Der Begriff, den die Zeichnung sichtbar macht, ist das Zusammensetzen der vier Formen und der drei Beziehungen auf einem einzigen kleinen Netz: eine Entscheidung, ihre Eingabedaten, das Wissen, das sie steuert, und die Quelle dieses Wissens. Die gewählte Entscheidung ist die Anspruchsberechtigung eines Haushalts auf die individuelle Prämienverbilligung der Krankenversicherung, die kantonale Verbilligung nach dem KVG.

Die Entscheidung «Anspruch auf Verbilligung bestimmen» steht im Zentrum des Netzes. Sie verbraucht zwei Eingabedaten, das massgebende Einkommen in CHF und die Haushaltsgrösse, und stützt sich auf den «Kantonalen Verbilligungstarif», ein Geschäftswissensmodell. Dieser Tarif ist selbst eine Entscheidungstabelle, eine Einkommensschwelle je Haushaltsgrösse, deren Logik in einer Entscheidungstabelle unter dem Knoten statt im DRD ausgeführt wird: Das ist die Trennung der Ebenen, das Diagramm trägt das Netz und der Knoten verweist auf seine Logik. Der Tarif bezieht seine Autorität aus der «Kantonalen Verordnung über die Prämienverbilligung», der Wissensquelle des Netzes, was die Auswirkungsanalyse unmittelbar macht: Eine Änderung der Verordnung pflanzt sich entlang der Beziehungen bis zur Entscheidung fort. Fünf Knoten genügen, um die vier Elementtypen und die drei Beziehungstypen zu tragen.

Visualisierungen

Die Form trägt den Sinn. Der Typ eines Knotens liest sich an seiner Silhouette, das Rechteck für eine Entscheidung, das Oval für ein Eingabedatum, das Rechteck mit abgeschnittenen Ecken für ein Geschäftswissensmodell, der gewellte Fuss für eine Quelle. Der Typ einer Abhängigkeit liest sich am Strich, durchgezogen für eine Informationsanforderung, gestrichelt für eine Wissensanforderung, gestrichelt mit rundem Kopf für eine Autoritätsanforderung. Wer DMN kennt, liest das Netz ohne Legende.

Aufwand

Werkzeuge

Ein Whiteboard genügt für einen ersten Entwurf: einige Knoten und ihre Beziehungen passen auf ein Blatt und lassen sich im Stehen korrigieren. Allgemeine Diagrammwerkzeuge, diagrams.net, Lucidchart oder Visio, führen DMN-Schablonen und liefern eine saubere Zeichnung, halten aber bei der Zeichnung an: Die Verbindung zu den Logiktabellen und zur Ausführung bleibt anderswo zu leisten. Spezialisierte DMN-Plattformen, wie der quelloffene DMN-Editor von Camunda, Trisotech, Signavio oder Red Hat Decision Manager, halten das DRD als oberste Schicht eines ausführbaren Modells: Man steigt von einem Entscheidungsknoten zu seiner Tabelle hinab, validiert das Modell und stellt es dann auf einer Entscheidungs-Engine bereit, die es ausführt. Diese Werkzeuge arbeiten in der Regel mit einem BPMN-Modellierer zusammen, sodass eine Geschäftsregelaufgabe des Prozesses die modellierte Entscheidung unmittelbar aufruft.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.17: das Entscheidungsanforderungsdiagramm unter den drei Notationen der Entscheidungsmodellierung, die Liste seiner Elemente und die genannten Stärken und Grenzen seines Einsatzes.
• OMG (Object Management Group), Decision Model and Notation (DMN), version 1.5, Clause 6 (Requirements): der Entscheidungsanforderungsgraph und das -diagramm, die vier Elementtypen (Entscheidung, Eingabedatum, Geschäftswissensmodell, Wissensquelle) und die drei Anforderungen (Information, Wissen, Autorität), die sie verbinden.