Lesedauer 20 Min

Entscheidungen automatisieren

2020-03-12 – In zunehmendem Maße werden wertschöpfende Aktivitäten durch technische Systeme ausgeführt. Bislang war das Treffen von Entscheidungen aber häufig dem Menschen überlassen. Der nachfolgende Beitrag bearbeitet NICHT das Thema „Künstliche Intelligenz“, sondern betrachtet theoretisch fundiert, aber hemdsärmelig im Praxisbezug wie „einfach“ Entscheidungen automatisiert werden können, ohne sich auf das neudeutsche Buzzword-Bingo einzulassen. Vielmehr orientiert es sich an praxiserprobten OMG-Standards und liefert das theoretische und methodische Rüstzeug.

• Intro
  • 1.1 Was sind Entscheidungen?
  • 1.2 Wie entscheiden wir?
• Wie haben wir bisher entschieden?
  • 2.1 Vorschriften
  • 2.2 Software
• Was ist die Decision Model and Notation (DMN)
  • 3.1 Warum sollte man die DMN einsetzen?
  • 3.2 Wo kann die DMN eingesetzt werden?
  • 3.3 Was kann ich mit der DMN ausdrücken?
  • 3.4 Entscheidungsanforderungen ermitteln mit DRDs
  • 3.5 Spezifikation der Entscheidungslogik
  • 3.6 DMN Simulator
• Wie wird ab jetzt entschieden?
  • 4.1 Vorschriften
  • 4.2 Zusammenspiel mit BPMN oder CMMN
  • 4.3 Rechtliches
• Fazit
• Quellen

Was sind Entscheidungen?

Wie so häufig gibt es zahlreiche Definitionen für „Entscheidungen“ und sogar ein umfassender theoretischer Ansatz (die „Entscheidungstheorie‘) ist verfügbar. Aber in der Einleitung haben wir einen hemdsärmeligen Beitrag versprochen und so soll es auch sein. Dennoch brauchen wir eine Abgrenzung, damit wir im Folgenden von den gleichen Dingen reden. Wir definieren also:

Eine Entscheidung ist eine nicht-situativ und willentlich gewählte Handlungsalternative,
basierend auf bekannten prä-selektional ermittelten und nicht beeinflussbaren Bewertungskriterien.

Mit dieser Definition grenzen wir ab von Entscheidungen zur Meinungsbildung, zu zwischenmenschlichen Beziehungen, spontan getroffenen sowie von strategischen, übergeordneten Entscheidungen, die in ihrer Operationalisierung noch immer mehrere Handlungsalternativen zulassen würden. Auf diese Weise können die von uns in diesem Beitrag behandelten Entscheidungen als datenbasiert, wiederholbar und nachvollziehbar charakterisiert werden. Und dies ist eine gute Voraussetzung für eine automatisierte Entscheidungsfindung.

Wie entscheiden wir?

Um automatisch Handlungsalternativen auswählen zu können, bedarf es einiger Vorüberlegungen. Bei den Entscheidungstheoretikern wird von einem Prozess gesprochen, der mehrere Phasen umfasst. Etwas hemdsärmliger wollen wir nachfolgend von zwei Phasen ausgehen. Erstens die Entscheidungsvorbereitung, zweitens die Entscheidungsdurchführung.

Was wir im Alltag teilweise in Sekunden erledigen, wird für die automatische Ausführung nun in zwei wesentliche Blöcke unterteilt. Es wird differenziert, was zur Lauf-Zeit (Run-Time) passiert (nämlich die Entscheidungsdurchführung) und was zur Entwurfs-Zeit (Design-Time) passiert (nämlich die Entscheidungsvorbereitung).

Die Entscheidungsvorbereitung enthält für die Automatisierung vielmehr Komplexität, denn die eigentliche Entscheidungsdurchführung ist (bei guter Vorbereitung) fast schon ohne Aufwand möglich.

Was ist also während der Vorbereitung zu tun?

1. Entscheidungsbedarf identifizieren Ein Analyst muss die Arbeitsbereiche identifizieren, in denen Entscheidungen getroffen werden und von allen möglichen Entscheidungen muss er diejenigen analysieren, die der zuvor genannten Definition entsprechen.
2. Kriterien sammeln Vom Analysten sind alle Kriterien zusammenzutragen, die bei der Entscheidung berücksichtigt werden müssen. Dabei sind „harte Fakten“, also eindeutige, valide Daten, ausschlaggebend.
3. Handlungsalternativen sammeln Genauso ist zu sammeln, was mögliche Handlungsalternativen sind, die überhaupt möglich (und erlaubt) sind. Geschlossene Entscheidungen, wie z. B. Zustimmung oder Ablehnung, decken dabei den vollständigen Raum aller Handlungsalternativen ab. Offene Entscheidungen, wie z. B. die Wahl des Verkehrsmittels für eine Dienstreise, sind nur schwer vollständig zu erfassen, zumal diese dann auch noch in Kombinationen auftreten können. Der Analyst ist hier gefragt, die Menge aller Handlungsalternativen möglichst vollständig zusammenzutragen.
4. Entscheidungsstruktur festlegen Vom Analysten sind die Abhängigkeiten der Kriterien und Handlungsalternativen zu identifizieren. Sind beispielsweise bei der Wahl von Verkehrsmitteln die Reisekosten oder der ökologische Fußabdruck höher zu bewerten? Diese Abstimmung erfordert häufig die Kenntnisse von unternehmensinternen Richtlinien oder regulative Vorgaben.
5. Regeln sammeln, bewerten und validieren Zu erkennen, welche Konsequenzen sich aus Kombinationen verschiedener Entscheidungskriterien ergeben, ist eine hoch analytische Aufgabenstellung.

Erst anschließend wird man die gesammelten Informationen nutzen für:

6. Entscheidungen umsetzen und validieren (Umsetzung der Entscheidung, Umsetzungskontrolle)
   Die Ermittlung der Handlungsalternative, also die Durchführung der Entscheidung, erfolgt basierend auf diesen vorbereitenden Überlegungen. Natürlich muss geprüft werden, ob die formulierten Regeln auch in jedem Fall das fachliche korrekte Ergebnis liefern. Ggf. bedarf es da noch weiterer Anpassungen.

 

Im persönlichen Bereich kennen wir sicher die eine oder andere Situation, in der wir versuchen eine möglichst rationale Entscheidung vorzubereiten. Denken wir z. B. an die Anschaffung eines neuen Autos. Sorgsam tragen wir die Kriterien wie Preis, Kapazität, Verbrauch, Wartungsintervalle, CO2-Ausstoß, u. a. zusammen, um dann doch nicht die Unterschrift beim Kaufvertrag des super-günstigen, ökologisch überlegenen Wagens aus Fern-Ost zu leisten, sondern eine Marke zu bevorzugen, zu der wir einen emotionalen Bezug haben.

Diese – im privaten Umfeld – gar nicht so selten anzutreffenden Entscheidungen, sind nicht zur Zufriedenheit zu automatisieren. Aber Entscheidungen, in denen Emotionalität außen vor bleiben kann/soll/muss, kann dies durchaus gelingen. Hierzu sind dann harte Fakten, belastbare Daten und Werte nötig, die es einzusammeln gilt.

Wie haben wir bisher entschieden?

In Organisationen, in denen nicht unendlich Ressourcen verfügbar sind (also in allen), müssen Entscheidungen getroffen werden. Wie diese Entscheidungen getroffen werden ist jedoch nicht einheitlich. Es gibt zahlreiche Wege zur Entscheidungsfindung.

Vorschriften

„Wir fragen den Chef“ ist in vielen patriarchisch geführten Organisationen häufiger mal zu hören. Dies ist jedoch schlecht skalierend, da der Entscheidungsträger irgendwann zum Engpass wird (daran scheitern viele Unternehmen in Wachstumsphasen, aber das ist einen eigenen Blogbeitrag wert).

Größere Unternehmen haben heutzutage Entscheidungsbefugnisse delegiert und damit ein wenig Macht an untergeordnete Einheiten (meist Manager) abgegeben. In solchen Kontexten wird gelegentlich versucht, die Entscheidungsfindung zu rationalisieren und zu rechtfertigen, indem verschiedene Methoden der Entscheidungsfindung angewendet werden. Beispielhaft seien hier Kosten-Nutzen-Analysen, Scoring-Modelle und Entscheidungs-Bäume genannt.

Für sich häufig wiederholende Entscheidungen erlassen die Unternehmen dann Vorschriften, wie ein Individuum zu entscheiden hat. Beispiele hierfür können sein: die Annahme von Geschenken, die Freigabe von Bestellungen, das Unterzeichnen von kaufmännischem Schriftverkehr, Vertretungsbefugnisse u. v. a. m.

Themenbezogen werden diese Vorschriften häufig in der Textverarbeitung der Wahl zusammengetragen, manchmal abgestimmt und auf dem File-Server gespeichert. In ihrer Gestaltung sind sie gut lesbar, allerdings sind sie textlich prosaisch beschrieben und nicht immer interpretationsfrei. In gut organisierten Unternehmen wird die neue Vorschrift auch allen Mitarbeitern bekannt gemacht. Die Mitteilung, dass die alte Vorschrift außer Kraft gesetzt wurde und daraufhin das Einziehen der nun ungültigen, alten Vorschrift, gelingt jedoch nicht mehr jedem Unternehmen. Wenn dann einige Zeit vergangen ist und der Mitarbeiter in der Vorschrift kurz mal nachschlagen muss, ist das Auffinden auch nicht bei jedem von Erfolg gekrönt. Häufig kommt es dann zu Nachfragen á la „Kannst Du mir die Einkaufsordnung bitte per E-Mail zusenden?“. Und schwupps, streunt eine weitere digitale Kopie des Dokumentes im Unternehmen umher, ohne dass es einer Dokumentenlenkung unterliegen würde.

Um bei Entscheidungen nicht jedes Mal eine Vorschrift konsultieren zu müssen, sind einige Unternehmen dazu übergegangen und haben die Einhaltung von Vorschriften einer Software überantwortet, um automatisch eine korrekte (neudeutsch: compliant) Entscheidung zu treffen.

Software

Automatisierte Entscheidungen existieren bereits heutzutage. Durch Software-Applikationen werden diese Entscheidungen vorgenommen. Wie diese zu treffen sind, wurde in der Anforderungsaufnahme definiert, der Programmierer hat es anschließend umgesetzt und hoffentlich gut getestet. Dem ist grundsätzlich nicht viel abzusprechen. Die Entwicklung der letzten Jahre hat jedoch deutlich gemacht, dass die Entscheidungsfindung regelmäßigen Anpassungen in ihrer allgemeinen Struktur sowie in einzelnen Regeln unterliegt. Und Software-Entwickler passen eher ungern Programm-Code an (schon gar nicht, wenn es nicht der eigene ist). Verschärft durch manchmal ausgeschiedene Software-Entwickler ist dann nicht mehr ersichtlich, wie die Details der Regel funktionieren, da diese ja nun im Quellcode versteckt und kompiliert sind. (Auf die Notwendigkeit einer guten Dokumentation und der gelebten Praxis gehen wir hier lieber nicht ein.) Bei „historisch gewachsenen“ Applikationen hört man dann gelegentlich, dass die Mitarbeiter keine Idee davon haben, warum eine Anwendung so reagiert, wie sie es tut. Selbst Mitarbeiter, die Ausdrücke wie „if-then-else“, „switch-case“ u. a. beherrschen, schrecken zurück, denn „Never touch a running system“. An eine Anpassbarkeit ist also nicht zu denken.

Aber natürlich hat die Informatik hierzu in den letzten Jahren Lösungen angeboten. So sind Technologien entstanden, die es erlaubten „deklarative Regeln“ auszulagern und mittels technischer Schnittstelle im Programmcode einzubinden. Diese Technologien hießen manchmal „Expertensysteme“, „Wissensbasierte Systeme“ oder zuletzt „Business Rules Management Systeme“ und verbesserten die Situation grundsätzlich. Allerdings wurden diese Technologien nicht in der Breite ein Erfolg, denn obwohl es um „Business Rules“ gehen sollte, waren sie in Wirklichkeit „technical rules“. Deren Funktionsweise und ihre Bedienung erforderte hohes technisches Verständnis (am Ende also wieder einen Software-Entwickler) und die Fähigkeit, Geschäftsanforderungen in eben diese „technical rules“ umzusetzen. Außerdem wurden sie aufgrund ihrer Granularität bei steigender Anzahl von Regeln riesig und komplex. Und so wollte man bei nötigen Änderungen im Nachhinein auch hier nicht so recht ran, da Seiteneffekte wieder schwer zu kontrollieren waren. Hinzu kamen sicher noch ein paar architektonische Webfehler, die eine harte Kopplung an Daten notwendig machte, und dass auch die gewünschte Performance am Ende nicht erreicht werden konnte.

Zuletzt hat die IT einen Schwenk gemacht zum Thema Decision Management. Dieser weiterentwickelte Ansatz verspricht nun die Unzulänglichkeiten des Rules Managements zu verbessern, weiterhin ausgelagerte Entscheidungslogiken repräsentieren und einbinden zu können und gleichzeitig eine Brücke zwischen den Fachbereichen und der Technik zu schlagen. Der vergleichsweise neue Standard „Decision Model and Notation“, oder kurz DMN, spielt hier seine Stärken aus.

Was ist die Decision Model and Notation (DMN)

In den letzten anderthalb Dekaden sind in Obhut der Object Management Group (OMG) zahlreiche Modellierungsstandards entstanden, die den Anspruch haben, sowohl für technisch-fähige Zielgruppen als auch für nicht-technische Zielgruppen nutzbar zu sein. Zu diesen Modellierungsstandards gehören die „Business Process Model and Notation“, kurz BPMN, welche sich in zum de facto Standard für die Modellierung strukturierter Prozesse entwickelt hat. Auch die „Case Management Model and Notation“, kurz CMMN, für schwachstrukturierte Prozesse (Fallarbeit) entwickelt sich erfolgreich weiter und ergänzt die Einsatzszenarien im Prozessmanagement. Die dynamischste Entwicklung jedoch hat die „Decision Model and Notation“ (DMN) in den letzten Jahren erfahren. Diese Standards zusammen werden auch als Triple-Crown (die drei Kronen) des Business Process Managements bezeichnet.

Die DMN ist eine gemeinsame Sprache für Business User und Softwerkern, um Entscheidungsanforderungen und Entscheidungslogiken in einem gemeinsamen Vokabular zu beschreiben. Der Standard umfasst zum einen eine visuelle Darstellung, zum anderen modell-getriebene Aspekte, die eine hinreichend logische Beschreibung der Entscheidung sicherstellen.

Dabei erlauben die Mittel der DMN eine technische Detaillierung, die präzise und ausführungssemantisch klar genug ist, sodass eine Ausführung der Regel direkt vom Modell aus erfolgen kann, ohne dass es einer technischen Anpassung bzw. Implementierung bedarf. Der DMN Standard schickt sich an, der de facto Standard zur Entscheidungsmodellierung zu werden.

Es ist erkennbar, dass immer mehr Softwareanbieter aus dem Business Rules und Decision Management-Segment diesen Standard übernehmen. Die Vorteile liegen auf der Hand:

1. Es handelt sich um einen Standard, der durch die OMG verwaltet wird und nicht durch einen Software-Hersteller allein. Die OMG hat jahrzehntelange Erfahrung durch erfolgreiche Standards wie die UML, SysML, BPMN u. a. Der DMN Standard wird bereits durch mehrere Software-Hersteller unterstützt und löst damit bereits Abhängigkeiten vom Hersteller auf.
2. Die Entscheidungsausführung basiert auf einem Modell, welches den gemeinsamen Sprachschatz für die Business-Seite und die IT-Seite liefert. Missverständnisse bei der Erstimplementierung werden vermieden und die spätere Anpassungsgeschwindigkeit verbessert sich durch das gemeinsame Vokabular.
3. Trotz des noch recht jungen Alters der DMN (Erstveröffentlichung in 2015), wurde sie von erfahrenen Leuten aus dem Business Rules Sektor entwickelt und auch die Erfahrungen aus der BPMN sind eingeflossen. So finden sich nun moderne, performance-starke und leichtgewichtige Decision Engines am Markt für die automatisierte Entscheidungsausführung.

Warum sollte man die DMN einsetzen?

Der DMN Standard ist sicher noch nicht so reif wie die BPMN, erfreut sich aber starker Beliebtheit und wird derzeit aktiv weiterentwickelt. Dennoch ist die DMN bereits in zahlreichen Organisationen weltweit im Einsatz. Eine Zurückhaltung ist also nicht nötig, denn die DMN stiftet großen Nutzen:

• Leichte(re) Lesbarkeit für Nicht-Techniker
• Bessere Steuerung von (automatisierten) Entscheidungen
• Flexiblere Anpassungen und leichtere Auswirkungsanalysen
• Größere Verfügbarkeit von Kompetenzträgern
• Besseres Zusammenspiel mit anderen Technologien
• Gute Grundlage für (Achtung! Buzzword:) Data Analytics und Künstliche Intelligenz
• Vermeidung einer Herstellerabhängigkeit (vendor lock-in)
• Reduzierte Umsetzungskosten und kürzere Umsetzungszeiten
• Konsistente Entscheidungen über verschiedene Kanäle

Wo kann die DMN eingesetzt werden?

Die DMN kann für alle Entscheidungen eingesetzt werden, die der nachstehenden Definition entsprechen:

Eine Entscheidung ist eine nicht-situativ und willentlich gewählte Handlungsalternative,
basierend auf bekannten prä-selektional ermittelten und nicht beeinflussbaren Bewertungskriterien.

Was könnte dies nun ganz konkret sein? Eine nicht abschließende – eher als Anregung gedachte – Liste von Anwendungsfällen gibt vielleicht Hinweise:

All diese Arten von Entscheidungen bringen jeweils eine Handlungsalternative hervor, die für eine Organisation Entlastung bieten und die Möglichkeit zur Skalierung schaffen kann. In allen Fällen kann die Entscheidungsmodellierung mit DMN erfolgen. Welche Möglichkeiten diese Modellierungssprache bietet, wird nachfolgend beschrieben.

Was kann ich mit der DMN ausdrücken?

Die Ausdrucksstärke der DMN bietet alles was benötigt wird, um die Business- und die IT-Seite „glücklich zu machen“. Auf der einen Seite ist die Regelbeschreibung visuell genug, auf der anderen Seite bietet sie alles, um präzise für die Ausführung beschrieben werden zu können.

Im Wesentlichen unterscheidet man dabei zwei Bereiche innerhalb der Notation. So wird zum einen von Anforderungen an Entscheidungen gesprochen, welche in einem sogenannten Decision Requirements Diagramm (DRD) ausgedrückt werden. Zum anderen, werden die einzelnen Entscheidungsregeln beschrieben (welche letztendlich die Entscheidungslogik beschreiben und dabei ggf. ein bisschen technisch werden).

Entscheidungsanforderungen ermitteln mit DRDs

Das Decision Requirements Diagramm (DRD) ist ein gutes Werkzeug, um zunächst die Details von Entscheidungen (bspw. in einem Workshop) zu ermitteln. Dabei werden Entscheidungen – die manchmal als komplex eingeschätzt werden – modellhaft zerlegt, um die Struktur der Entscheidung und eben die Anforderungen an Entscheidungen identifizieren zu können.

Das nachstehende Diagramm stellt dabei ein einfaches Beispiel dar, welches alle relevanten Symbole eines DRDs umfasst.

Das Modell liest sich wie folgt: Es existiert eine top-level-Entscheidung „Maximum Discount“ (also die eigentliche, relevante Entscheidung zur Bestimmung eines Maximalrabatts), welche sich wiederum aus eingehenden Informationen speist. Diese eingehenden Informationen können entweder harte Fakten sein (wie z. B. „Value“ (Umsatzwert)), oder das Ergebnis vorgelagerter Entscheidungen „Strategic Account“ (Strategischer Kunde) sowie „Customer Type“ (Kundentyp). Diese vorgelagerten Entscheidungen speisen sich wiederum aus eingehenden Informationen „Region“ bzw. „Industry“ sowie „Potential“ und „Turnover“. Darüber hinaus wurde das Modell hier ergänzt mit Wissensquellen „Internal Discount Policy“ sowie „Internal CRM policy“. Diese Wissensquellen dokumentieren, woher gewisse Anforderungen für die Regeln kommen und ermöglichen so, die Nachvollziehbarkeit der Regeln. Außerdem wird ein Geschäftswissen „Corporate Classification“ referenziert. Dieses Geschäftswissen kann wiederum eine eigene, aber in einer anderen Datei beschriebene Regelbeschreibung sein.

Spezifikation der Entscheidungslogik

Basierend auf dem DRD können jetzt die definierten Detailentscheidungen, also die rechteckigen Boxen, weitergehend spezifiziert werden. Nun gilt es zu beschreiben, welche Handlungsoptionen basierend auf welchen Eingangsdaten abgeleitet werden sollen. Am einfachsten lässt sich dies als Wenn-Dann-Beziehung beschreiben. Um diese Wenn-Dann-Beziehungen zu beschreiben, stehen innerhalb der DMN mehrere Spezifikationsmöglichkeiten zur Verfügung. Die DMN kennt hierzu die Spezifikation von Entscheidungslogiken mittels Entscheidungstabellen, BoxedExpressions und ist auch offen für andere Logikbeschreibungen. Im Folgenden beschränken wie uns jedoch auf die Entscheidungstabellen, da diese sicher die verbreitetste Logikbeschreibung sind und zusätzlich von Nicht-Entwicklern am leichtesten eingesetzt werden können.

Die oben stehende Tabelle unterliegt einer gewissen Struktur, die wir nachfolgend zeilenweise beschreiben wollen:

• Kopfzeile: In der Kopfzeile wird zunächst die Auswertemethodik (hit policy) der Tabelle (hier „U“ für „unique“) gefolgt von Input-Daten und Output-Daten dargestellt.
• Zweite Zeile: In der zweiten Zeile werden die Daten genauer spezifiziert (hier: „data 1“ und „data 2“).  Es werden Bezeichnungen angegeben für 1 bis n Eingabedaten.
  Des Weiteren werden die Bezeichnungen der Handlungsoptionen (hier: „output 1“ und „output 2“) bzw. der Regelergebnisse aufgeführt. Es werden Bezeichnungen angegeben für 1 bis n Regelergebnisse. Ggf. werden diese noch um technische Ausdrücke wie Variablen-Bezeichnungen, ggf. Wertemengen, ergänzt, um die spätere Ausführung zu ermöglichen.
• Dritte Zeile: In der dritten Zeile finden sich Datentypen, die deklarieren, ob ein Eingabewert bspw. eine Zeichenkette (String), einen ganzzahligen numerische Werte (Integer), o. a. enthält.
• Vierte und folgende Zeilen: Ab der vierten Zeile werden Regeln beschrieben. Hier finden sich üblicherweise eine fortlaufende Nummerierung der Regeln und anschließend konkrete Inputdaten sowie sich daraus ergebende Handlungsoptionen (m. a. W. Regelergebnisse).

Übergeordnet haben Entscheidungen natürlich ebenfalls eine Klartextbezeichnung („Decision1“) sowie einen technischen Bezeichner („Decision_example“).

Die Entscheidungstabelle wird also wie folgt gelesen:

WENN (data1 =“A“ UND data2 = 1)
DANN GILT output1 = „Red“ UND output2 =”bold”

Erläuterung:
Wenn die Voraussetzungen data1 = „A“ und data2 = 1,
dann wird die Handlungsoption (Regelergebnis) output1 = „red“ und output2 = „bold“ zurückgeben.
Da die Auswertelogik „U“ (also „unique“) gewählt wurde, trifft auch nur diese eine Regel für die übergebenden Voraussetzungen (Input-Daten) zu.

Durch das Hinzufügen weiterer Input- und Output-Spalten kann daher mit einer Entscheidungstabelle bereits eine sehr umfassende Regellogik beschrieben werden. In Abbildung 06 erkennt man auch, dass nicht nur Input-Daten an eine Entscheidung übergeben werden können, sondern auch die Ergebnisse vorgelagerter Entscheidungen. Durch diese verschachtelte Struktur, welche auf DRD-Ebene sichtbar wird, lassen sich auch die komplexesten Entscheidungen darstellen.

Ebenso können weitere Auswertelogiken in der DMN gewählt werden. So existieren:

• U(nique) = Es muss genau eine Zeile zutreffen
• A(ny) = Beliebig viele Zeilen können zutreffen, müssen dann aber das gleiche Ergebnis liefern
• F(irst) = Die erste Ziele, die zutrifft, bestimmt das Ergebnis
• P(riority) = Die Zeile mit der höchsten Priorität trifft zu

Neben diesen „single hit policies“ existieren auch noch „multiple hit policies“, welche einen noch weiteren Anwendungsraum der Entscheidungstabelle aufspannen.

• R(rule) = Liste der Ergebnisse in der Reihenfolge der Tabellenzeilen
• C(ollect) = Liste aller Ergebnisse ohne Reihenfolge. Optional können diese Ergebnisse noch weiter verarbeitet werden:
  • + (Summieren)
  • < (Minimum bestimmen)
  • > (Maximum bestimmen)
  • # (Anzahl bestimmen)
• O(utput order) = Liste der Ergebnisse in der Reihenfolge der Priorität

Damit die Entscheidungstabelle letztendlich ausführbar ist, bedarf es dann noch formaler Spezifikationen. Für diese wird von der DMN eine Sprache bereitgestellt, welche sich FEEL nennt. Die sogenannte „Friendly Enough Expression Language“ erinnert hier stark an Excel, denn sie enthält beispielsweise Operatoren wie ><= aber auch Wertebereiche [0, 10]. (Weitere Hinweise unter Camunda.)

 

Nachdem nun auch die komplexesten Regeln in DMN modelliert wurden, können wir unsere Regelbeschreibung als XML-Datei abspeichern. Dieses Datenformat wird von allen Decision Engines ausgeführt.

Wer die erstellte Datei auf einer Decision Engine mal ausprobieren möchte, kann beispielsweise den DMN Simulator von camunda ausprobieren (siehe nebenstehende Box). Der Simulator nutzt im Hintergrund eine Decision Engine. Zum Testen und Ausprobieren hervorragend.

Im operativen Echtbetrieb wird man üblicherweise sogenannte „Decision Services“ implementieren. Hierbei handelt es sich i. d. R. um Webservices, die die Ausführung von Business Rules anbieten. Eine DMN-Empfehlung ist es, einem Decision Service beim Aufruf alle benötigten Eingabedaten mitzugeben. Die Rules Engine beschafft sich also nie selbst Daten und ruft nicht selbst weitere Systeme auf.

DMN Simulator

Die camunda services GmbH in Berlin bietet einen Online-Simulator für die automatisierte Entscheidungsfindung mittels DMN an. Dieser ist zu finden unter https://camunda.com/de/dmn/simulator/
Erstellte DMN-Dateien können hier per Drag & Drop auf den Simulator gezogen und so getestet werden.

Wie wird ab jetzt entschieden?

Vorschriften

Die DMN schafft die Grundlage für die automatisierte Entscheidungsfindung – aber nicht nur. Es kann durchaus sein, dass der Automatisierungsaufwand (noch) nicht lohnt. Dies wäre aber dennoch kein Grund die DMN nicht zu nutzen und an den alten Beschreibungsarten (vgl. Abbildung 02) für Vorschriften festzuhalten. Vielleicht ist einfach nur noch nicht abzusehen, wann die Automatisierung erfolgen soll. Ein weiterer Aspekt ist, eine unternehmensweit einheitliche Sprache zur Formulierung von Regeln einzuführen. Die gemeinsame Sprache verschafft auch ohne Automatisierung bereits erhebliche Vorteile innerhalb der Kommunikation.

Warum also nicht die Unterschriftenregelung für die Beschaffung zukünftig wie folgt darstellen:

Durch die Darstellung mittels DMN könnte eine unternehmensweit einheitliche Darstellungsart etabliert werden und auch eventuelle zukünftige Automatisierungen von Entscheidungen wären bereits gut vorbereitet.

Zusammenspiel mit BPMN oder CMMN

Wer bereits andere OMG-Modellierungsstandards wie die BPMN oder CMMN anwendet, wird die DMN als sinnvolle Ergänzung identifizieren. Ohne auf Details dieser Modellierungssprachen eingehen zu wollen, zeigen wir dennoch zwei Beispiele zur Verdeutlichung. Der „Kenner“ wird weiterführende Dokumentation hierzu finden.

In BPMN existiert ein Rule Task, der den Aufruf einer extern implementierten Regelausführung vorsieht. Diese Regelausführung könnte beispielsweise in DMN umgesetzt worden sein. Im Modell sähe dies dann so aus:

In der CMMN existieren sogenannte Sentries. Hierbei handelt es sich um Eingangs- bzw. Ausgangsbedingungen, die zu erfüllen sind. Ob diese erfüllt sind, lässt sich per DMN prüfen. Im Modell könnte dies wie folgt aussehen:

Diese Beispiele sollen als Anregung dienen, aber auch verdeutlichen, dass die DMN sich nahtlos in die anderen OMG-Standards integrieren lässt. Es wird deutlich, warum BPMN, CMMN und DMN als „Triple Crown“ des BPM bezeichnet werden.

Was muss sonst noch beachtet werden?

Organisatorisches

Unabhängig davon, ob Entscheidungen nun menschlich oder technisch (sprich automatisch) durchgeführt werden, ist es hilfreich, sich über die folgenden Fragestellungen Gedanken zu machen.

Je kleiner der Teil derjenigen ist, die Verantwortung für diese Fragen traten, um so weiter nähert man sich einem Entscheidungsmanagement (Decision management), bei welchem Entscheidungen geplant, umgesetzt, geprüft und wieder angepasst werden (können). Folgender Nutzen ergibt sich daraus:

• Beschleunigung von Entscheidungen
• Höhere Transparenz
• Organisatorisch verankerte Sicherstellung der Compliance
• Kontinuierliche Verbesserung von Entscheidungen

Bernd Rücker (CTO und Co-Founder von Camunda) hat hierzu einen Decision-Management-Regelkreis als iterative Vorgehensweise des Decision Managements skizziert.

Nicht zuletzt ergibt sich hieraus ein Vorteil der DMN, denn die Lenkung von Entscheidungen kann nun einer zentralen Stelle verantwortet werden, die ggf. nicht mit weiteren Hoheiten belastet ist bzw. keine Zielkonflikte diesbezüglich zu klären hat. Beispielsweise können Prozesse und Entscheidungen nun eine getrennte Governance (Verantwortungszuordnung) erhalten.

Außerdem können eigene Lenkungsprozesse entwickelt werden, die sicherstellen, dass alle relevanten Stakeholder bei der Erstellung, Freigabe, Publizierung, Außerkraftsetzung etc. involviert werden.

Rechtliches

Um eine rechtliche Sicht nicht durch unsere laienhaften Formulierungen zu vernebeln, zitieren wir nachstehend die Landesbeauftragte für Datenschutz und Informationssicherheit Nordrhein-Westfalen zum Thema Scoring:

Was ist bei „automatisierten Einzelentscheidungen“ zu beachten?

Eine „automatisierte Einzelentscheidung“ liegt vor, wenn keine inhaltliche Bewertung und darauf gestützte Entscheidung durch eine natürliche Person stattgefunden hat. Das ist zum Beispiel dann der Fall, wenn Score-Werte alleine für das Zustandekommen eines Vertrages entscheidend sind, oder auch dann, wenn die Entscheidung über einen Vertragsschluss unmittelbar durch ein Computerprogramm und eben nicht durch einen Menschen getroffen wird. Damit sind auch Fälle erfasst, in denen eine formale Bearbeitung durch einen Menschen nachgeschaltet wird, dieser Mensch aber gar keine Befugnis oder ausreichende Datengrundlage besitzt, um von der automatisierten Entscheidung abzuweichen. Das Bundesdatenschutzgesetz (BDSG) verbietet solche Entscheidungen, wenn sie für die Betroffenen eine rechtliche Folge nach sich ziehen oder sie erheblich beeinträchtigen (§ 6a BDSG). Eine beeinträchtigende Entscheidung liegt etwa vor, wenn der gewünschte Vertrag abgelehnt oder ein höherer Zinssatz als bei optimaler Bonität angeboten wird. Das Verbot gilt jedoch ausnahmsweise nicht, wenn es sich um eine für den Betroffenen positive Entscheidung handelt (zum Beispiel Abschluss des begehrten Vertrages zu den gewünschten Konditionen) oder die Wahrung der berechtigten Interessen des Betroffenen durch geeignete Maßnahmen gewährleistet ist und das Unternehmen als verantwortliche Stelle dem Betroffenen auf Verlangen die wesentliche Gründe für die Entscheidung mitteilt. Als geeignete Maßnahme gilt insoweit insbesondere die Möglichkeit für die Betroffenen, ihren Standpunkt gegenüber dem Unternehmen geltend zu machen, das anschließend die Entscheidung erneut zu überprüfen hat. Darüber hinaus sind Unternehmen, die automatisierte Einzelentscheidungsverfahren einsetzen, verpflichtet, die Betroffenen über diese Tatsache zu informieren.

Quelle:
Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen: „Was ist bei ‚automatisierten Einzelentscheidungen‘ zu beachten?“, unter: https://www.ldi.nrw.de/mainmenu_Datenschutz/submenu_Datenschutzrecht/Inhalt/Scoring/Inhalt/
Antworten_FAQ_Scoring/automatisierte_Einzelentscheidungen1.php (abgerufen am 10.03.2020).

Der letzte Satz hat es in sich. „Darüber hinaus sind Unternehmen, die automatisierte Einzelentscheidungsverfahren einsetzen, verpflichtet, die Betroffenen über diese Tatsache zu informieren.“ Für Nutzung von automatisierten Entscheidungen mittels Scorings (durchaus mit der DMN zu realisieren) sind u. a. die Vorschriften des Datenschutzrechts zu kennen.

Fazit

Der Beitrag zeigt, dass die Automatisierung von Entscheidungen heutzutage kein unlösbares Unterfangen mehr darstellt. DMN spielt dabei eine wesentliche Rolle, da sie nicht nur ein gutes Kommunikationsinstrument ist, um Klarheit und Transparenz herbeizuführen, sondern auch geeignet ist ausgehend vom Modell Entscheidungen technisch umzusetzen (sprich zu automatisieren). Es besteht also keine Notwendigkeit mehr, an papierbasierten Regelbeschreibungen festzuhalten. Eine Umsetzung auf DMN – egal ob zur Automatisierung oder nicht – ist daher überlegenswert.

Der Beitrag zeigt aber auch, dass ein echtes „Decision Management“ nicht nur durch technische Sichtweisen getrieben werden darf. „Management“ heißt eben auch, dass organisatorische Überlegungen nötig sind, die eine Planung, Umsetzung, Überprüfung und Anpassung der Regelwerke ermöglichen. Nicht zuletzt sind bei einigen Entscheidungen auch rechtliche Überlegungen relevant.

Quellen

• Ronen, Gil (o.D.): „From Business Rules to Decision Management Using DMN“, in: Trisotech, unter: https://www.trisotech.com/articles/from-business-rules-to-decision-management-using-dmn (abgerufen am 12.03.2020).
• Rücker, Bernd (2016): „Der Brückenschlag: Warum DMN den Business-Rules-Engines-Markt aufmischt“, in: Jaxenter, unter: https://jaxenter.de/der-brueckenschlag-warum-dmn-den-business-rules-engines-markt-aufmischt-37252 (abgerufen am 12.03.2020).
• Dittmann, Traugott/ Jorch, David (2016): „DMN: Neuer Anlauf für Business Rules, den Markt zu erobern“, in: Sigs Datacom, unter: https://www.sigs-datacom.de/fachzeitschriften/objektspektrum/archiv/artikelansicht/artikel-titel/dmn-neuer-anlauf-fuer-business-rules-den-markt-zu-erobern.html (abgerufen am 12.03.2020).
• Object Management Group (2019): „Decision Model and Notation. Version 1.2“, in: OMG, formal/19-01-05, unter: https://www.omg.org/spec/DMN/1.2/PDF (abgerufen am 12.03.2020).
• Taylor, James (2019): „Core Principles for Decision Management Success in Insurance Claims Handling“, in: , unter: http://www.decisionmanagementsolutions.com/core-principles-for-decision-management-success-in-insurance-claims-handling/ (abgerufen am 12.03.2020).
• Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (o.D.): „Was ist bei ‚automatisierten Einzelentscheidungen‘ zu beachten?“, unter: https://www.ldi.nrw.de/mainmenu_Datenschutz/submenu_Datenschutzrecht/Inhalt/Scoring/Inhalt/
  Antworten_FAQ_Scoring/automatisierte_Einzelentscheidungen1.php
  (abgerufen am 12.03.2020).