Was gibt es da zu entscheiden?

Entscheidungen mit der DMN analysieren und modellieren

Marcus Winteroll

© istockphoto / Photo Dave

In unserem Arbeitsleben spielt das Treffen von Entscheidungen eine wichtige Rolle, doch vielen fällt genau das schwer. Hierbei kann der neue Standard der Object Management Group (OMG) zum Thema Entscheidung, die Decision Model and Notation (DMN), weiterhelfen. Denn die DMN ermöglicht es uns, Entscheidungen strukturiert zu beschreiben, und dadurch besser zu verstehen. Und auch bei der Automatisierung kann sie hilfreich sein.

Um es gleich vorwegzunehmen: Die DMN ist kein Werkzeug, um etwas zu entscheiden. Es geht vielmehr darum, Entscheidungen besser zu verstehen, die wiederholt anfallen. Die Gründe dafür, über Entscheidungen zu sprechen, sind die Gleichen, die uns dazu bewegen, beispielsweise Geschäftsprozesse zu beschreiben. Das heißt, wir wollen Entscheidungen verstehen, analysieren und verbessern, um eine gleichbleibende Qualität der einzelnen Entscheidungen zu gewährleisten.

Was bietet die DMN hierfür an? Welche Strukturen gibt sie für Entscheidungen vor? Aus der Sicht des neuen OMG-Standards sind Beschreibungen von Entscheidungen folgendermaßen strukturiert:

  • Der Kontext: Wie bettet sie sich in den Geschäftsprozess ein?
  • Die Anforderungen: Welche Informationen werden benötigt? Welche Entscheidungen müssen zuvor getroffen werden? Welche Vorgaben sind dabei einzuhalten?
  • Die Entscheidungslogik: Welches Verfahren soll angewendet werden, um zu einer Entscheidung zu kommen? Etwa die Anwendung von Regeln? (S. 19)

Die DMN selbst bietet nur Notationen für die letzten beiden Aspekte an. Bezüglich der Einbettung in die Geschäftsprozesse wird auf die BPMN verwiesen, wobei Business-Rule-Tasks als Brückenkopf zwischen der BPMN-Ablaufbeschreibung und dem DMN-Entscheidungsmodell auserkoren wurden (Abb. 1).

Abb. 1: Die verschiedenen Aspekte einer Entscheidung und deren Zusammenhang

Abb. 1: Die verschiedenen Aspekte einer Entscheidung und deren Zusammenhang

Decision Requirements

Betrachten wir also, was der neue Standard für die Beschreibung der Anforderungsperspektive bereithält. Zählen wir die Grundelemente für diese Perspektive zusammen, ergibt sich ein überschaubares Bild: Es gibt lediglich vier Grundelemente und drei Arten von Beziehungen zwischen ihnen.

Abb. 2: Die Elemente des Decision Requirements Diagram (DRD)

Abb. 2: Die Elemente des Decision Requirements Diagram (DRD)

Werfen wir zunächst einen Blick auf die vier Grundelemente (Abb. 2). Das zentrale Element ist die Entscheidung selbst. Mit Entscheidung ist hier der Akt der Entscheidung gemeint, nicht das Ergebnis. Natürlich hält die Spezifikation auch eine Reihe von Attributen bereit, um eine Entscheidung genauer zu charakterisieren. Im Folgenden die wichtigsten:

  • Die Frage: Was soll durch die Entscheidung beantwortet werden?
  • Erlaubte Antworten: Wie sehen mögliche Antworten aus? Hier sind die möglichen Antworten aufzuzählen bzw. eine repräsentative Auswahl.
  • Die Entscheidungslogik: Wie sieht der Weg zur Entscheidung aus? Das kann beispielsweise eine Entscheidungstabelle sein, der Aufruf einer Funktion oder andere, wie auch immer geartete Beschreibungen des Entscheidungsverfahrens.

Hiermit ist der Akt der Entscheidung schon ganz gut charakterisiert, der nun an einem Beispiel illustriert werden soll: Dem Auswahlprozess für Bewerber, wie er in Abbildung 3 beschrieben ist. Der Ablauf wurde für unsere Zwecke vereinfacht; Varianten und fachliche Fehler brauchen wir zur Illustration der Entscheidungen nicht. Auch die Herausforderungen im Ablauf, die beispielsweise dadurch entstehen, dass noch interessante Bewerbungen eintrudeln, während schon die ersten Gespräche geführt werden, müssen uns hier nicht interessieren.

Abb. 3: Ein einfaches Einstellungsverfahren als Beispielprozess

Abb. 3: Ein einfaches Einstellungsverfahren als Beispielprozess

 

Abb. 4: Entscheidung samt zugehöriger Anforderungen im Decision Requirements Diagram

Abb. 4: Entscheidung samt zugehöriger Anforderungen im Decision Requirements Diagram

Hinter jeder Business-Rule-Task des betrachteten Prozesses steht eine Entscheidung. Diese sehen wir in Abbildung 4 als Decision Requirement Diagram (DRD) dargestellt. Dort sehen wir neben den Entscheidungen noch weitere Elemente, die für die Entscheidung eine Rolle spielen. Schauen wir uns zunächst die Entscheidung „Über Angebot entscheiden“ genauer an. Im Prozess wird die Entscheidung durch die gleichnamige Business-Rule-Task repräsentiert.

Die Entscheidung kann durch die Frage „Soll ein Angebot an den Bewerber gehen und mit welchem Gehalt?“ charakterisiert werden; mögliche Antworten könnten die Form „Ja mit folgendem Gehalt …“ haben oder schlicht „Nein“ lauten. Auf die zugehörige Entscheidungslogik werden wir später eingehen.

Weitere wichtige Informationen über die Entscheidung lassen sich dem Diagramm entnehmen: die Bewerbung, die Gehaltsklassen und der persönliche Eindruck stellen direkte oder indirekte Eingabedaten für die Entscheidung dar. Sie werden mit dem DMN-Element Eingabedaten (Input Data) dargestellt und mittels der so genannten Informationsanforderung (Information Requirement) mit der Entscheidung verbunden.

Mit Informationsanforderungen können Entscheidungen nicht nur Eingabedaten zugeordnet werden, sondern auch andere Entscheidungen, deren Ergebnisse in gewisser Weise auch als Eingabedaten dienen. So setzt „Über Angebot entscheiden“ voraus, dass zuvor die fachliche Eignung des Bewerbers und der Gesamteindruck beurteilt wurde.

Weitere Elemente, die mit der Angebotsentscheidung zusammenhängen, sind zum einen das so genannte Geschäftswissensmodell (Business Knowledge Model), zum anderen die Wissensquelle (Knowledge Source). Das Geschäftswissensmodell „Entscheidung über Angebot“ repräsentiert die Entscheidungslogik, die später noch genauer betrachtet wird. Der gestrichelte Pfeil, mit dem das Element an die Entscheidung geheftet wird, steht für eine Wissensanforderung (Knowledge Requirement).

Mit Wissensquellen können im DRD Vorgaben ins Modell aufgenommen werden. In unserem Beispiel über die Form des Angebots und die Zeit, die für die Entscheidung zur Verfügung steht. Solche Vorgaben können beispielsweise firmenintern sein, etwa gesetzliche Vorschriften oder allgemeine Standards, die es einzuhalten gilt. Die Zuordnung einer Wissensquelle zu einer Entscheidung oder einem Geschäftswissensmodell wird mit einer Vorgabe (Authority Requirement) modelliert.

In einem DRD haben Vorgaben eher informativen Charakter – während die Eingabedaten und die Entscheidungslogik bei jeder einzelnen Entscheidung benötigt werden, beschreiben die Vorgaben, welche Regeln in der Entscheidung oder der zugehörigen Entscheidungslogik einzuhalten sind. Würde diese Angabe fehlen, könnten wir aus dem Diagramm immer noch herauslesen, was für die Entscheidungen benötigt wird. Uns würde allerdings die Information fehlen, warum der Akt der Entscheidung so aussieht, wie er aussieht.

Das DRD ist ein Instrument, mit dem sich die Anforderungen an Entscheidungen analysieren lassen. Es hilft, zu verstehen, welche Eingabedaten eine Entscheidung braucht, welche weiteren Entscheidungen benötigt werden, und welche Vorgaben zu beachten sind.

Der Zusammenhang zwischen DMN und BPMN

Eine solche Analyse kann beispielsweise hilfreich sein, um die Geschäftsprozesse besser zu verstehen, in die die Entscheidungen eingebettet sind. Wenn wir das DRD aus Abbildung 4 mit der zugehörigen Geschäftsprozessbeschreibung in Abbildung 3 vergleichen, finden wir nicht nur die Entscheidungen als Business-Rule-Task in der Prozessbeschreibung wieder, sondern auch die Eingabedaten „Bewerbung“, „Bedarf“, „Persönlicher Eindruck“ und „Gehaltsklassen“ als Datenobjekte. Wenn wir also die Eingabedaten der Entscheidungen bestimmen, bestimmen wir damit auch Datenobjekte des Geschäftsprozesses. Und anders herum: In der BPMN-Beschreibung können wir erkennen, woher die benötigten Daten kommen.

Ein weiterer wichtiger Aspekt des Zusammenspiels zwischen der Entscheidungs- und Ablaufmodellierung: Eine saubere Trennung der beiden Modellierungen macht das Geschäftsprozessmodell verständlicher und einfacher zu pflegen. Häufig wird beides vermischt, was zu einer Kaskade von Verzweigungen in der Prozessmodellierung führt. Bei einer sauberen Trennung zwischen Ablauf und Entscheidung modellieren wir die Entscheidung – wie schon gezeigt – mit einer Business-Rule-Task, häufig gefolgt von einem Gateway, sodass abhängig von der Entscheidung der weitere Ablauf bestimmt wird. Die eigentliche Entscheidung lässt sich dann mithilfe der DMN beschreiben. Und zwar nicht nur die Anforderung an eine Entscheidung, sondern auch die Entscheidungslogik selbst, z. B. in Form von Geschäftsregeln. Bei Änderungen in der Entscheidungslogik müssen wir auch nur diese ändern, während die BPMN-Prozessbeschreibung davon unberührt bleibt.

Beschreibung der Entscheidungslogik

Wir haben gesehen, wie mittels eines DRD die Anforderungen an eine Entscheidung analysiert werden können. Wir haben auch gesehen, dass zu jeder Entscheidung eine Frage und mögliche Antworten gehören. Was aber noch unklar ist: Wie kommen wir von der Frage zu den Antworten? Diesen Weg weist uns die Entscheidungslogik, die sich in der DMN unterhalb des DRD abspielt (Abb. 1). Grundsätzlich sieht die DMN drei Varianten zur Beschreibung der Entscheidungslogik vor:

  • per Entscheidungstabelle
  • durch den Aufruf eines Geschäftswissensmodells
  • durch einen geeigneten Ausdruck in einer beliebigen Sprache

Die letztgenannte Variante eröffnet alle Möglichkeiten, die Entscheidungslogik zu beschreiben; angefangen bei natürlicher Sprache, über Ausdrücke eines logischen Kalküls bis hin zu direkt ausführbaren Programmiersprachen wie Java. Allerdings bewegt man sich dann außerhalb der DMN. Mit den Entscheidungstabellen bringt sie aber ein mächtiges Instrument mit, das viele Fälle abdeckt.

Tabelle 1: Entscheidung über Angebot

Tabelle 1: Entscheidung über Angebot

In unserem Beispiel könnte eine Entscheidungstabelle für die Entscheidung über das Angebot aussehen wie Tabelle 1. Die Spalten „Gehaltsforderung“, „Fachliche Eignung“ und „Gesamteindruck“ stehen für mögliche Eingabedaten, die Spalte „Angebot“ steht für den zugehörigen Ausgabewert. Die entsprechenden Überschriften sind also die Namen der Ein- bzw. Ausgabeparameter. In den Zeilen unter den Überschriften können die möglichen Ein- bzw. Ausgabewerte oder der Datentyp angegeben werden. Jede der nummerierten Zeilen bildet eine Regel. Die Entscheidungstabelle verbindet also alle Regeln, die zu einer Entscheidung gehören.

Zu der Entscheidung über das Angebot muss aber nicht allein die Frage beantwortet werden, ob überhaupt ein Angebot an den Bewerber geht, sondern es – das geht aus den genannten möglichen Antworten hervor – muss auch die Höhe des angebotenen Gehalts ermittelt werden. Für diese beiden Teilfragen werden zwei unterschiedliche Entscheidungslogiken verwendet. Im DRD wird dies durch die beiden Geschäftswissensmodelle sichtbar, die der Entscheidung mittels Wissensanforderung zugeordnet sind.

Das heißt, die Entscheidungstabelle (Tabelle 1) ist der Entscheidung nur mittelbar über das entsprechende Geschäftswissensmodell zugeordnet. Für die Gehaltsbestimmung verwendet die Entscheidung das „Gehaltsmodell“. Damit haben wir ein Beispiel für den Aufruf von Geschäftslogik.

Jetzt müssen wir das alles noch zusammenfügen. Hierfür dienen in der DMN so genannte Boxed Expressions. Das heißt, dass sämtliche Ausdrücke in Kästchen erscheinen. Ein Beispiel hierfür haben wir bereits kennengelernt, denn auch die Entscheidungstabellen sind eine Form von Boxed Expressions. Um nun die verschiedenen Geschäftswissensmodelle in der Entscheidung zu verwenden, formulieren wir eine Boxed Expression wie in Abbildung 5. In der ersten Zeile steht dort der Name der beschriebenen Entscheidung. Darunter finden wir links die Ausdrücke „Angebot“ sowie „Gehalt“ und rechts davon die Berechnung dieser Ausdrücke durch den Aufruf der Geschäftswissensmodelle „Entscheidung über Angebot“ bzw. „Gehaltsmodell“.

Abb. 5: Entscheidungslogik als Boxed Expression

Abb. 5: Entscheidungslogik als Boxed Expression

Die Aufrufe selbst sind auch eine Form von Boxed Expressions und daher nochmals geschachtelt. Der Aufruf der Entscheidungstabelle „Entscheidung über Angebot“ geschieht mittels der Parameter „Gehaltsforderung“, „Fachliche Eignung“ und „Gesamteindruck“, rechts davon steht jeweils die Bindung der Parameter für den Aufruf, die hier zum einen durch das Eingabedatum „Bewerbung“ erfolgt, zum anderen durch weitere Entscheidungen sowie auch aus dem DRD hervorgeht. Schließlich wird in der untersten Zeile der Rückgabewert aus „Angebot“ und „Gehalt“ bestimmt.

Für die Ausdrücke in den Boxed Expressions definiert die DMN eine eigene Sprache, die Friendly Enough Expression Language (FEEL). Damit können einfache und komplexe Ausdrücke formal und damit maschinenlesbar formuliert werden.

Abb. 6: Boxed Expression mit natürlichsprachlichen Ausdrücken

Abb. 6: Boxed Expression mit natürlichsprachlichen Ausdrücken

Grundsätzlich können in den Boxed Expressions aber auch Ausdrücke in beliebiger Sprache stehen. Ein einfaches Beispiel sehen wir in Abbildung 6. Dort wird in natürliche Sprache (und mit etwas Interpretationsspielraum) beschrieben, wie das Gehalt zu berechnen ist. Die dafür notwendigen Größen „Gehaltsforderung“  und „Berufserfahrung“ werden in der zweiten Zeile als Parameter definiert. Zudem wird die finanzielle Lage eingeschätzt, hierfür wird das entsprechende Geschäftswissensmodell genutzt. Die letzte Zeile besagt, das „Gehalt“ schließlich als Ergebnis zurückgegeben wird.

Die Verwendung von Geschäftswissensmodellen ist nicht zwingend, denn die Entscheidungslogik kann auch direkt mit der Entscheidung verknüpft werden. Durch die Verwendung der Geschäftswissensmodelle wird in unserem Beispiel allerdings schon im DRD deutlich, dass die Entscheidung über das Angebot auch das Gehaltsmodell benötigt, weil dieses als Element im DRD auftaucht. Dies wäre bei der direkten Verknüpfung nicht der Fall. Ein anderer Grund für die Verwendung von Geschäftswissensmodellen ist die Wiederverwendung: Greifen mehrere Entscheidungen auf dieselbe Entscheidungslogik zurück, muss diese nur einmal definiert werden. Im Beispiel in Abbildung 4 gilt das für Einschätzung der finanziellen Lage.

Die Beispiele zeigen nur einige der Möglichkeiten, die Entscheidungslogik mit den Mitteln der DMN zu beschreiben. Es handelt sich hierbei um ein mächtiges Werkzeug. Vor allem die Boxed Expressions ermöglichen es, die Entscheidungslogik beliebig in immer kleinere Bestandteile zu zerlegen. Dafür zahlt man aber auch einen Preis: Anders als die DRD sind die Boxed Expressions sehr viel schwerer zu erlernen. Und der Anspruch der DMN, nicht nur für Analytiker und Entwickler verständlich zu sein, sondern auch für Fachleute (S. 13) wird dadurch unterhöhlt. Letztlich verhält es sich hier wie mit anderen formalen Sprachen wie z. B. der UML oder auch der BPMN: Verwendet man nur wenige unterschiedliche Elemente, kann man einfache Beschreibungen entwickeln, die zumindest von gutwilligen Fachleuten verstanden werden können. Das gilt mit Sicherheit für die DRD und zumindest auch für einfache Entscheidungstabellen. Doch je mehr Register wir ziehen, um an Ausdrucksmächtigkeit zu gewinnen, desto eher bleibt die Verständlichkeit auf der Strecke.

Verwendungsmöglichkeiten

Abschließend wollen wir noch einen kurzen Blick auf die Einsatzmöglichkeiten der DMN werfen. Drei Möglichkeiten liegen auf der Hand: Analyse, Automatisierung und Compliance.

Wer beginnt, Entscheidungen mithilfe von DRD zu analysieren, wird schnell merken, dass sich dieses Werkzeug als hilfreich dabei erweisen kann, zu verstehen, was eigentlich zu entscheiden ist, welche Informationen dazu benötigt werden und wie das mit anderen Entscheidungen zusammenhängt. Die so gewonnenen Erkenntnisse kommen einem beispielsweise bei der Gestaltung der Geschäftsprozesse zugute.

Zuweilen lohnt es sich auch, in der Analyse noch eine Ebene tiefer zu gehen und die Entscheidungslogik mithilfe von Entscheidungstabellen genauer zu analysieren, um wirklich zu verstehen, welche Informationen tatsächlich für eine Entscheidung benötigt werden; denn bekanntlich steckt der Teufel im Detail.

Das Zusammenspiel von DRD und Entscheidungstabellen kann auch hilfreich sein, um bei einer sehr großen Anzahl von Geschäftsregeln Struktur und Ordnung in den Regelzoo zu bringen.

Eine weitere Verwendungsmöglichkeit wäre die Automatisierung der Entscheidungslogik. Die Verwendung von Boxed Expressions zusammen mit FEEL oder anderen maschinenlesbaren Sprachen bietet prinzipiell die Möglichkeiten, die Entscheidungslogik zu automatisieren. Doch was das anbetrifft, müssen wir erst einmal abwarten, inwieweit die Toolhersteller die DMN unterstützen werden. Es gibt zwar bereits erste Modellierungstools, aber noch keine Tools, die etwa die Entscheidungstabellen der DMN interpretieren und ausführen.

Die dritte Anwendungsmöglichkeit ist das Thema Compliance. Dabei geht es vor allem darum, Regeln einzuhalten, z. B. im Umgang mit Risiken. Hier unterstützt die DMN insbesondere mit dem DRD: Einzuhaltende Regelwerke können einfach als Wissensquellen dargestellt werden. Über Vorgaben kann außerdem die Verbindung zu den betroffenen Entscheidungen modelliert werden, bei denen die Regelwerke einzuhalten sind. Die anzuwendenden Regeln, die in den Entscheidungstabellen formuliert werden, stellen dann die konkrete, direkt anwendbare Ausgestaltung der allgemeinen Regelwerke dar, die durch die Wissensquellen repräsentiert werden.

Verwandte Themen:

Geschrieben von
Marcus Winteroll
Marcus Winteroll
Dr. Marcus Winteroll ist Mitglied der oose Innovative Informatik eG und beschäftigt sich als Trainer und Berater mit der Analyse sowie Verbesserung von Geschäfts- und Entwicklungsprozessen. Dazu setzt er auf agile Methoden, aber auch die klassischen Vorgehensweisen sind ihm aus seiner langjährigen Erfahrung als Projektleiter, Prozessmanager, Analytiker, Qualitätssicherer und Entwickler vertraut. Seine Erfahrungen berichtet er als Sprecher auf Konferenzen und Autor von Fachartikeln. Außerdem ist er Fragenschreiber für das BPM-Zertifikat der OMG (OCEB2).
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Entscheidungen mit der DMN analysieren und modellieren"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Michael Gröschel
Gast
Schön erklärt! In Abbildung 1 bezieht sich das DRD zu „Über Angebot entscheiden“ auf einen anderen Task, als den, der im BPMN-Modell „verbunden“ ist. Nicht „Bewerbungsgespräch führen“ sondern der Geschäftsregel-Task „Über Angebot entscheiden“. Den Prozess kann man verbessern. Es werden ja von n Bewerbern i.d.R. x (z.B. x=1) Angebote und n-x Absagen verschickt. Im Prozess kommt das mit den Endereignissen m.E. nicht zum Ausdruck. Da sollte auch eine „Multiple Instance Activity“ zum Einsatz kommen. An den XOR-Gateways wären Bedingungen schön. In Abbildung 2 sollte es beim Pfeil „Wissensanforderung“ vermutlich „Knowlede Requirement“ statt „Information Requirement“ heißen. Grüße an den Autor von… Read more »