In diesem Blogpost zeige ich, wie eine Decision Engine - basierend auf dem neuen OMG-Standard DMN - im Kreditantragsprozess bei der Auswahl des dem Interessenten anzubietenden Kreditprodukts angewendet werden kann.
Dabei verwende ich die Open Source Produkte von camunda, wie den Camunda Modeler für die Modellierung von BPMN 2.0 Prozessdiagrammen und DMN 1.1 Entscheidungstabellen, die Camunda Process Engine und die Decision Engine (Release 7.4) für die Ausführung der modellierten Prozessdefinitionen und Entscheidungstabellen.
DMN in Kürze - Was ist das eigentlich?
Die Abkürzung DMN steht für Decision Model And Notation und ist eine von OMG (Object Management Group) verabschiedete Notation, die uns dabei hilft, die in Geschäftsprozessen angewendete Entscheidungslogik (Geschäftslogik) auf eine einheitliche (standardisierte) Art und Weise, leicht verständlich beschreiben zu können. Die Notation definiert u.a. Regeln für die Beschreibung von Diagrammen und Entscheidungstabellen, die zur visuellen Darstellung von Geschäftsregeln sehr gut geeignet sind und die somit das in den Geschäftsprozessen oft nur in Software-Codestrecken oder in Köpfen der betroffenen Mitarbeiter vorhandene Wissen explizit machen. Dadurch kann ein weiterer Fortschritt auf dem Weg der so oft und heftig diskutierten Business - IT - Alignment erreicht werden.
DMN hilft uns aber nicht nur bei der Modellierung und Dokumentation von Geschäftsregeln. Dank des Strebens nach Standardisierung können mithilfe der Notation beschriebene Entscheidungstabellen von verschiedenen Softwareprodukten - sogenannte Decision Engines - interpretiert und ausgeführt werden. Die Abhängigkeit zu einem Softwarehersteller (proprietäre Lösung) kann somit vermindert werden.
Entscheidungstabellen
Im Mittelpunkt der Notation stehen - aus operativer Sicht betrachtet - die Entscheidungstabellen. Eine Entscheidungstabelle besteht aus Kombination von Kriterien (Inputs) mit ihren jeweiligen Ausprägungen (Input-Werte) und die daraus resultierenden Ergebnisse (Outputs). Sie kann tabellarisch dargestellt werden. Eine Darstellungsform ist, dass die Kriterien und Ergebnisse als Spalten, die Regeln als Zeilen abgebildet sind. Es können beliebig viele Input- und Output-Werte definiert werden, ebenso wie die Regeln.
Die obige leere Entscheidungstabelle beinhaltet 2 (nicht definierte) Inputs (Kriterium 1 / Kriterium 2), 2 Outputs (Ergebnis 1 / Ergebnis 2) und hat 3 (nicht definierte) Regeln.
Wenn ein Kriterium bei einer Regel nicht relevant ist, kann die betroffene Zeile leer (undefiniert) bleiben.
Expression Language
Die Notation sieht bei Entscheidungstabellen die Verwendung einer eigenen Expression Language vor (FEEL - Friendly Enough Expression Language), die für Business-Anwender leicht verständlich ist. Mit deren Hilfe kann z.B. auf Variablen in einem Geschäftsprozess referenziert werden oder man kann arithmetische Formeln hinterlegen - eine große Stärke um die Welt der Business-Anwender und IT-Fachleute näher zueinander zu bringen.
Entscheidungsdiagramme (DRD’s)
Mehrere Entscheidungstabellen können eine logische Hierarchie zueinander bilden, in dem der Output von einer Entscheidungstabelle als Input für eine weitere Entscheidungstabelle dient. Diese Kette an Verbindungen kann mithilfe von Entscheidungsdiagrammen - Decision Requirements Diagram (DRD) - visuell dargestellt werden:
Ein Kriterium kann bei mehreren Entscheidungstabellen als Input verwendet werden (wie Input 1 im obigen Beispiel).
Zusammenspiel von DMN und BPMN
Die Geschäftsregeln bilden einen wesentlichen Bestandteil eines Geschäftsprozesses, die Entscheidungsfindung integriert sich untrennbar in einen Prozessablauf. Handelt es sich um eine softwaretechnische Unterstützung eines Prozesses innerhalb des Unternehmens, so können zwar DMN-Entscheidungstabellen eigenständig in die entsprechende Anwendung integriert werden, die grössten Vorteile ergeben sich allerdings in Kombination mit BPMN (Business Process Model And Notation). BPMN als Modellierungsstandard sieht den Aktivitätstyp “Geschäftsregel” (Business Rule Task) zur Unterstützung von diesen Arbeitsschritten vor. Daher bietet sich die kombinierte Verwendung beider Standards an.
Anwendungsbeispiel: der Kreditantragsprozess
Im nachfolgend beschriebenen Anwendungsbeispiel handelt es sich darum, wie die Entscheidungslogik zur Auswahl eines zutreffenden Kreditproduktes mithilfe von DMN-Entscheidungstabelle(n) beschrieben werden kann und wie sich diese Logik in den Auswahlprozess des Kreditproduktes - modelliert und ausgeführt als BPMN-Modelldiagramm - integrieren lässt.
Gesamtprozess-Sicht
Der Kreditantragsprozess lässt sich auf folgende gröbere Teilprozesse gliedern, woraus wir uns mit dem Teilprozess Anzubietendes Kreditprodukt bestimmen näher beschäftigen werden:
Kriterien zur Entscheidungsfindung
Unsere Beispiel-Bank benutzt eine Reihe von Kriterien zur Bestimmung des dem Interessenten anzubietenden Kreditprodukts. Die Kriterien sind im nachfolgenden DRD aufgeführt:
Die Kriterien können logisch gruppiert werden, um ihre Verwaltung übersichtlicher zu halten:
Der von der Höhe des beantragten Kreditbetrags abhängige Darlehenstyp kann in eine gesonderte Entscheidungstabelle ausgelagert werden, damit man bei Änderung des betroffenen Parameters nur auf eine Stelle zugreifen muss. Die Entscheidungstabelle hat eine Hit Policy = U (Unique), die aussagt, dass nur eine einzige Regel zutreffen kann (der Kreditbetrag ist entweder grösser gleich oder kleiner 19.000 EUR):
Die Definition, ob ein Kunde als “aktiv” bezeichnet werden kann, hängt von Kriterien ab, ob dem Kunden in dem definierten Zeitintervall bereits ein Kredit gewährt oder genehmigt (zugesagt) wurde, ob er über ein Sparprodukt bei der Bank verfügt oder ein in der Vergangenheit gewährtes Darlehen in letzter Zeit getilgt hat. Um die Kombination der möglichen Inputwerte übersichtlich abzubilden, bietet sich die Verwendung einer gesonderten Entscheidungstabelle wie folgt an. Wichtig anzumerken, dass wir hier eine Hit Policy = A (Any) anwenden, was bedeutet, dass mehrere Regeln zutreffen können, allerdings müssen alle Regel zum gleichen Output (Ergebnis) führen:
Die jeweiligen Outputs der beiden Entscheidungstabellen gelten als Input für die “große” Entscheidungstabelle Darlehensprodukt bestimmen, in der auch die weiteren Kriterien mit ihren jeweiligen Input-Werten aufgeführt sind. Ein Auszug daraus:
Bei dieser Entscheidungstabelle arbeiten wir mit der Hit Policy = R (Rule Order), bei welcher mehrere Regeln mit unterschiedlichen Ergebnissen zutreffen können. Als Output werden alle zutreffenden Regeln in ihrer Reihenfolge aus der Entscheidungstabelle aufgeführt.
Die DMN definiert insgesamt 7 unterschiedliche Hit Policies (Unique, Any, Priority, First, Output order, Rule order, Collect), mit deren Hilfe ein sehr breites Spektrum von Geschäftsregeln abbildbar ist.
Prozess-Integration
Die Entscheidungstabellen arbeiten mit den zugelieferten Daten, typischerweise werden diese Basisdaten aus dem Core Banking System besorgt. Dies passiert in unserem Anwendungsfall mithilfe von Service-Aufrufen aus folgendem BPMN-Prozessmodell, welches von der Process Engine interpretiert und ausgeführt wird:
Anhand der zu Beginn des Prozesses eingegebenen Kunden-ID werden die erforderlichen Basisdaten aus dem Core Banking System zum Kunden ermittelt. Handelt es sich um einen Interessenten, der bei unserer Bank noch kein Kunde ist, kann trotzdem auf offen zugängliche Daten verschiedener Register zugegriffen werden.
Der beantragte Kreditbetrag wird ebenfalls vom Anwender zu Beginn des Prozesses eingegeben. Sowohl die Kunden-ID als auch der beantragte Kreditbetrag stehen nachher als Prozessvariablen zur Verfügung.
Die anschliessende Service Task führt den Modul-Aufruf des Core Banking Systems zur Ermittlung aller erforderlichen Basisdaten aus. Als Eingabeparameter wird die eingegebene Kunden-ID benutzt, als Output stehen die Daten zur anschliessenden Ausführung der definierten Geschäftsregel zur Verfügung.
Alle 3 definierten Entscheidungstabellen werden der Reihe nach ausgeführt. Das Process Engine erkennt anhand des Aktivitätentyps “Business Rule” und der hinterlegten Referenz, welche Entscheidungstabellen auszuführen sind, die Verarbeitung der Entscheidungstabellen erfolgt durch das integrierte Decision Engine. Das Ergebnis wird in einer User Task Form dem Anwender visualisiert:
Auditing - Protokolle
Die Ergebnisse der ausgeführten Entscheidungstabellen können nach der Verarbeitung im Cockpit angeschaut werden. Die zutreffenden Regeln werden mit blauer Farbe hervorgehoben. Protokoll zur Entscheidungstabelle Darlehenstyp:
Protokoll zur Entscheidungstabelle Kundenstatus:
Protokoll zur Entscheidungstabelle Darlehensprodukt bestimmen:
Vergleich mit reiner BPMN-Abbildung
Der gleiche obige fachliche Anwendungsfall könnte theoretisch mithilfe von BPMN-Gateways (in diesem Fall mit Exclusive Gateways) ebenso modelliert werden:
Abgesehen davon, dass diese Art der Modellierung dem BPMN-Prinzip widerspricht, steht ausser Frage, dass diese Abbildung nicht übersichtlich ist und die Wartung des Prozessmodells bei Änderungen in den fachlichen Vorgaben aufwändiger ist als die erforderliche Anpassung in den Entscheidungstabellen.
Ausblick - Potenziale von Decision Engines
Wir begegnen in unserer Arbeit - bei Erstellung von Core-Banking-Software - oft der Fragestellung, wie eine Lösung aus Sicht der Parametrisierbarkeit so generisch designed werden kann, damit potenzielle Anforderungen der Zukunft (die wir zurzeit noch gar nicht kennen können) leicht abbildbar werden. Bei der Lösungsfindung stützen wir uns selbstverständlich auf gesammelte Erfahrungen vieler Jahre bzw. das Abstraktionsvermögen unserer Software-Architekten. Als Ergebnis kann dennoch eine statische Lösung entstehen, welche generische Ansätze und Elemente beinhaltet, die nie eingesetzt werden oder aber gegen Anforderungen von übermorgen doch nicht wasserdicht genug sind.
In diesem Bereich kann der Einsatz einer Decision Engine wirkliche Vorteile mit sich bringen. Die Ablaufsteuerung kann auf Basis aktuell bekannter Anforderungen leichtgewichtig und transparent aufgebaut werden, die Anpassung der Strukturen bestehender Regelwerke bzw. Aufnahme von neuen - bisher gar nicht berücksichtigten - Kriterien kann aufwandsschonend, transparent und auditgerecht erfolgen.
Download
Sie können den kompletten lauffähigen Anwendungsfall als Maven-Project aus unserer Repository in Github downloaden und selber ausprobieren. Für Feedbacks sind wir dankbar.
