24.08.2020

Decision Management Systeme und Machine Learning: Tipps für die Auswahl des richtigen Anbieters

Artikel teilen:

Interview mit Fabian Cotic, Machine-Learning-Spezialist und Presales-Consultant bei Actico, über den Einsatz von KI-Techniken wie Machine Learning bei automatisierten Geschäftsentscheidungen und Decision Management Systemen.

Wer viele tausend Geschäftsentscheidungen pro Tag fällen muss, kommt um ein performantes Decision Management System (DMS), dass auch KI-Techniken wie Machine Learning (ML) einsetzt, nicht herum. Als Hilfe für die Auswahl hat das weltweit bekannte IT-Beratungsunternehmen Gartner in seinem Paper „How to Choose Your Best-Fit Decision Management Suite Vendor“ herausgearbeitet, welche die größten Herausforderungen sind und worauf es bei der Auswahl ankommt.

Actico kennt als Pionier von Künstlicher Intelligenz in DMS die typischen Stolpersteine, wenn es darum geht, dass beste Setting oder System für konkrete Anforderungen zu finden. Wir haben deshalb die Gelegenheit genutzt, mit Fabian Cotic, einem Machine-Learning-Spezialist und Presales- Consultant bei Actico, darüber zu sprechen, worauf es bei der Auswahl eines Decision Management System für Kunden ankommt.

Warum sollten Unternehmen ein DMS einsetzen?

Geschäftsentscheidungen sind heutzutage extrem wichtig. Ein gutes Beispiel ist, wenn Sie den Preis für ein Produkt bestimmen oder einen Kredit vergeben wollen. Das sind Situationen, bei denen Entscheidungen elementar sind und unmittelbar über den geschäftlichen Erfolg entscheiden. DMS können dabei helfen, diese Entscheidungen zu automatisieren und das über eine einfache Handhabung einer Entscheidungslogik und einen Low-Code-Approach zu erreichen. Sie benötigen dann keinen ausgebildeten Programmierer mehr, eine Entscheidungslogik zu schreiben, sondern lassen einen Fachanwender diese Fälle modellieren.

Also die Leute, die schon wissen, wie sie selbst entscheiden würden …

Genau, das ist ein entscheidender Punkt. Wer schon einmal für ein Projekt Requirements-Engineering betrieben hat, der weiß, dass das nicht ganz einfach ist und viele Aspekte auf der Strecke bleiben können. Aus diesem Grund ist es sehr schön, wenn man grafisch den Fluss der Entscheidung vom Fachanwender aufzeichnen kann. Das hilft ungemein, ein gutes Verständnis aufzubauen. Und letztlich erzeugt man auf dieses Weise performanten Java-Code. Diesen Code kann ich anschließend einfach in meine IT-Anwendungslandschaft integrieren. Das Besondere an diesem Vorgehen ist, dass man die Entscheidungslogik aus dem Code herauszieht und die Implementierung nicht mehr nur den ITlern überlässt, sondern dass der Fachbereich nun auch in der Lage versetzt wird, selbst Hand anzulegen.

„Mit einem DMS extrahieren Sie die Entscheidungslogik aus einer Anwendung und entlasten die IT deutlich.“
Was sind die Unterschiede zwischen einem DMS und Business Rules?

Früher hießen diese Anwendungen Business Rules Management Systeme (BRMS). Durch die Renaissance der KI in den letzten Jahren hat sich der Begriff DMS etabliert. Diese kombinieren reine BRMS mit Künstlicher Intelligenz und Machine Learning. Und um den Unterschied klar zu machen, spricht man jetzt von Decision Management Systemen (DMS).

Ein DMS ist also eine Weiterentwicklung, um zusätzliche Features wie beispielsweise Event-Processing zu integrieren …

Nicht nur Event-Processing, sondern eben auch Machine Learning und neue Features, um Entscheidungen besser zu zerlegen (weil sie sehr komplex sein können). Dazu brauche ich Tools, die BRMS nicht liefern konnten. DMS-Anwendungen können zum Beispiel komplexe Entscheidungen in viele kleine Entscheidungen automatisch herunterbrechen, um eine höhere Transparenz zu erreichen.

Wie erkenne ich als potenzieller Kunde, ob ich Machine Learning benötige oder nicht?

Wenn mir die Entscheidungslogik bekannt ist, dann ist ein regelbasiertes System wahrscheinlich die richtige Wahl. Wenn ich aber feststelle, dass ein Regelsystem nicht ausreichend ist, weil ich nicht weiß, wie ich diese Entscheidungslogik bauen soll, macht es Sinn, auf Machine Learning zu setzen. Wichtig ist dabei aber, dass man auch auf die dafür notwendigen Daten zugreifen kann.

Wir haben einen Kunden aus dem Bankenbereich, die ermittelt Produktaffinitäten mit unserer Software. Dabei ist es relativ schwierig eine Wenn-Dann-Regel zu schreiben, ob ein Kunde Interesse an einem bestimmten Produkt haben könnte. Die Bank hat deshalb einen großen Datenpool („Data-Lake“) aufgebaut, der zum Beispiel Informationen darüber enthält, ob der Kunde vor kurzem ein Fahrrad gekauft hat oder sich in einer Facebook-Gruppe mit dem Thema „Immobilien“ bewegt hat. Anhand solcher Real-Life-Touchpoints lässt sich dann mit Machine Learning ermitteln, ob er eine gewisse Affinität für ein Produkt hat. Und das funktioniert ziemlich gut. Für einen Menschen wäre es bei sehr vielen Quellen aber viel zu komplex, die Regeln manuell zu erstellen.

Wie können Software-Architekten ermitteln, wann der Einsatz eines DMS sinnvoll ist?

Zuerst muss man schauen, wie komplex sind die Regeln: Benötige ich dafür überhaupt ein dediziertes System oder kann ich das nicht einfach in meinem Source-Code abbilden? Natürlich lassen sich Geschäftsregeln auch direkt in gängigen Programmiersprachen formulieren. Wenn allerdings die Komplexität stark steigt und sich im Code nicht mehr so einfach managen lässt, wird es schnell sehr unübersichtlich. Hinzu kommt, dass man häufig viele Änderungen an den Regeln vornehmen möchte oder muss.

Wenn Sie zum Beispiel einmal pro Woche ihre Entscheidungslogik anpassen müssen, ist es nahezu utopisch, dass Ihnen ihre IT jede Woche ein neues Release programmiert. Das ist der entscheidende Aspekt einer DMS: Unternehmensbereiche können losgelöst von der IT agieren und Veränderungen im Produktivsystem vornehmen.

Dazu gehört natürlich auch eine Qualitätssicherung, die in Form einer Continuous Integration im Hintergrund stattfindet. Das muss aber nicht der Anwender programmieren, sondern dass muss das Tool out of the Box mitliefern. Nur das stellt sicher, dass die Änderungen wie gewünscht funktionieren.

Damit sind Anwender in der Lage, die Entscheidungslogik anzupassen (und nicht nur die IT). Wenn das eine wichtige Anforderung für ein Projekt ist, sollte man sich ein Tool aussuchen, dass auch für normale Fachanwender leicht zu bedienen ist.

Wenn außerdem Machine Learning und KI eingesetzt werden, ist der Einsatz eines DMS sinnvoll, weil es in der Lage ist zu erklären, warum es sich im konkreten Fall so entschieden hat. Das System muss auf Knopfdruck eine Dokumentation des Entscheidungsalgorithmus liefern können – vor allem auch deshalb, weil Decision Management Systeme in stark regulierten Branchen wie der Finanz- und Versicherungswelt zum Einsatz kommen. Unternehmen können die Entscheidungen darüber nicht nur dokumentieren, sondern das DMS auch dazu nutzen, die Entscheidungen kontinuierlich zu verbessern.

„Mit einem Logging können Unternehmen Entscheidungen nicht nur dokumentieren, sondern ihre Entscheidungen auch kontinuierlich verbessern.“
Wie bewertet man die technischen Eigenschaften eines DMS am besten?

Indem man sich zuerst klar wird, was man benötigt. Ich muss mir also im Vorfeld schon Gedanken machen, welche Entscheidungstechnologie ich brauche. Reichen mir Geschäftsregeln, ist Machine Learning notwendig, ist eine Streaming-Analyse wichtig    und brauche ich vielleicht auch noch einige Optimierungsverfahren? Über die vier Anforderungen muss man sich zu Beginn klar werden. Die Anforderungen sollte man daher schriftlich festhalten und ausformulieren, um anschließend über RFIs und RFPs Anbieter auszuwählen.

Als nächstes kommt dann oftmals ein Proof-of-Concept (PoC) hinzu, um zu zeigen, dass die ausgewählte Lösung in der Lage ist, die Anforderungen zu erfüllen. Einige Kunden fragen dazu nur nach einer Probelizenz, um selbst mit dem System eigene Erfahrungen zu sammeln und herauszufinden, welche Möglichkeiten es bietet. Andere haben ein konkretes Projekt, für das wir als Anbieter ein PoC aufsetzen, um den konkreten Einsatz zu zeigen.

Aber wir haben auch viel mit ITlern zu tun, die gerne selbst Hand anlegen wollen und kein Interesse daran haben, dass wir die Projektleitung für den Einsatz des DMS übernehmen. Das sind meistens Personen, die festgestellt haben, dass sie den Bedarf an einer DMS-Lösung haben – etwa weil sie die Logik von der Anwendung entkoppeln möchten. Häufig geht es auch um Agilität, weil man sehr schnell entwickeln kann. In unserem System können Sie per Drag-and-Drop sehr schnell eine Logik aufsetzen. Ich habe ja selbst auch schon viel in Java programmiert, aber mit Templates und fertigen Bausteinen kommen sie viel schneller ans Ziel.

Wie muss ich mir das konkret vorstellen?

Sie müssen zum Beispiel nicht erst einen Testfall schreiben und eine neue Klasse einfügen. Sie klicken auf „Neuen Regeltest erstellen“, sehen die möglichen Input- und Output-Daten, müssen diese nur auswählen und festlegen, was rauskommen soll. Außerdem haben wir für typische Compliance-Fälle, die bei Banken und Versicherungen immer wieder vorkommen, auch schon fertige Regelsätze, die sie nicht komplett neu erstellen müssen. Eine Bank muss beispielsweise sicherstellen, dass keine Transaktionen mit Personen durchgeführt werden, die auf einer Blacklist stehen. Das können Terroristen oder andere Verbrecher sein. Dafür gibt es zum Beispiel ein Template, dass basierend auf der Regeltechnologie genau diese Überprüfung vornimmt.

Gibt es noch andere Entscheidungskriterien?

Wenn Sie etwa eine Event-Stream-Plattform haben, die kontinuierlich Daten produziert und das DMS in eine solche Plattform integriert werden soll, ist es sinnvoll, einen Anbieter zu wählen, der das gleich mitliefert. Häufig entscheiden sich Kunden in diesem Umfeld allerdings für eine Open-Source-Lösung wie Kafka, die sie über Java und entsprechende Regeln integrieren.

Sie haben bereits erwähnt, wie wichtig die einfache Bedienung so eines Systems für Nicht-ITler ist. Gibt es da noch größere Unterschiede?

Es gibt Tools, die bedienen sich natürlicher Sprache. Man schreibt also Fließtexte wie „Wenn das größer als das ist, dann mache Folgendes.“ Das funktioniert erst einmal ganz gut für Mitarbeiter aus den Fachbereichen, ist aber bei vielen Regeln sehr unübersichtlich.

Unser Tool ist dagegen grafisch aufgebaut und in der Lage, Unterbereiche zu definieren und diese auch optisch zu gliedern. Es gibt eine Abhängigkeitsmatrix, die anzeigt, welche Regel andere Regeln aufruft und wie alles zusammenhängt. Durch die grafischen Modelle – Gartner nennt sie „Decision Flows“ – ist das sehr übersichtlich.

Dann gibt es auch Entscheidungstabellen, über die nahezu jedes DMS verfügt. Das ähnelt Excel, das viele der Anwender gut kennen. Und natürlich kann man bei den meisten Anwendungen Entscheidungstabellen aus Excel importieren.

Kann man Regeln auch aus bestehenden Systemen extrahieren? Gartner spricht hier von Rules-Harvesting.

Out of the Box gibt es das nicht, aber über Machine Learning kann ein DMS sowas natürlich gut lernen. Theoretisch könnte man die Erkenntnisse dann auch wieder automatisiert in Regeln umsetzen, in der Praxis machen wir das aber nicht, weil es keine besseren Ergebnisse liefert. Es würde natürlich der Erklärbarkeit dienen, die ist aber häufig gar nicht gefordert und daher auch nicht nötig. Und wenn die Erklärbarkeit gefordert ist, können wir das auch bei Machine Learning über den Shapley-Algorithmus leisten.

Aus meiner Erfahrung kann ich sagen, dass das Rules-Harvesting in der Praxis aktuell aber kaum eingesetzt wird. Selbst Gartner sagt, dass das eher noch im experimentellen Stadium ist.

Spielt das Thema Cloud und Deployment bei den Kunden auch eine größere Rolle bei der Entscheidung?

Für eine RFI muss man sich natürlich im Klaren sein, wo die Anwendungen laufen soll: In der Cloud oder im eigenen Rechenzentrum. Wir unterstützen beides, aber das ist nicht bei allen Anbietern so.

Außerdem sollte man eruieren, welche Mechanismen und Unterstützung ein DMS zum Erstellen und zum automatischen Deployen der Lösung zur Verfügung stellt. Dazu gehört auch die Qualitätssicherung, die sehr wichtig ist.

Wir können aus dem System heraus den Source-Code erzeugen, das Programm kompilieren, mit Testsuites die notwendigen Tests durchführen und das Ergebnis dann beispielsweise als eigenen Webservice mit SOAP- oder REST-API zur Verfügung stellen. Es gibt auch die Möglichkeit, eine Java-API bereitzustellen, die im Hintergrund auf das Regelwerk des DMS zugreift und dabei immer  das aktuelle Regel-Set verwendet. Damit können wir uns in jede IT-Landschaft integrieren.

Kann man bei einem DMS auch noch nach Jahren nachvollziehen, warum es so entschieden hat?

Ein wichtiger Punkt! Jede Entscheidung und Transaktion im System wird gespeichert und protokolliert. Ich kann Ihnen jederzeit sagen, vor beispielsweise fünf Jahren wurde das Modell in der Version X und mit diesen konkreten Daten durchgeführt und das war die Entscheidung, die das System getroffen hat. Sie können also auf einer Testinstanz den exakten Zustand herstellen, der vor Wochen oder Jahren zu einer Entscheidung geführt hat und noch einmal durchlaufen lassen.

Was passiert eigentlich, wenn sich durch aktuelle Entwicklungen – jetzt beispielsweise Corona – das Verhalten der Menschen deutlich ändert? Kann das System das selbst erkennen?

Beim Machine Learning spricht man hierbei von einem Konzept-Drift. Der kann ganz plötzlich kommen, weil so etwas wie Corona erscheint und das Kaufverhalten von Kunden komplett verändert. Das heißt, die Vorhersagen der ML-Modelle funktionieren nicht mehr. Diesen Drift automatisiert zu erkennen, ist relativ schwierig. Nichts desto trotz haben wir uns auf die Fahnen geschrieben, dass wir das Problem lösen wollen. Ziel ist es, ein Monitoring zu implementieren, das einen Drift erkennt und ein Nachtraining des Modells auslöst. Die Idee dahinter ist, ein System zu bauen, dass so intelligent ist, dass es sich von selbst updatet, wenn es eine Veränderung erkennt.

„Ein intelligentes DMS kann Veränderungen der Ausgangsdaten erkennen und sich automatisch neu trainieren – auch wenn das in Deutschland noch niemand macht.“
Geschieht die Erkennung des Drifts statistisch und automatisch?

Um so etwas zu implementieren, ist es nötig, Schwellwerte darauf zu prüfen, ob sie überschritten werden. Eine mögliche Herangehensweise ist zu schauen, wie wichtig ein bestimmtes Feature im Training war und zu prüfen, ob sich die statistische Verteilung dieses Features in den Daten verändert hat. Anschließend gilt es zu bewerten, ob das wichtige Auswirkungen auf die Aussagen des ML-Modells hatte.

Über diesen (noch theoretischen) Weg könnten wir die Anpassungen auch vollautomatisch durchführen, allerdings kenne ich in Deutschland niemanden, der die Modelle ohne finale menschliche Überprüfung anpassen würde. Aber in Asien beispielsweise gibt es Unternehmen, die bereit sind, im Sinne des technologischen Fortschrittes mehr Risiken einzugehen.

Wenn ein Unternehmen vor der Entscheidung steht, ein DMS zukünftig einzusetzen: Wann sollte er eine One-Stop-Shop-Lösung und wann einen Multi-Vendor-Ansatz wählen?

Die Frage ist natürlich: Gab es schon Investitionen in dem Bereich? Oft existieren schon Data-Science-Plattformen, bevor ein DMS eingeführt wird. Das gilt es auf jeden Fall zu berücksichtigen. Aber selbst, wenn sie einen One-Stop-Shop-Approach wählen können, ist es noch nicht gewährleistet, dass sie darüber zu durchgängig integrierten Lösungen kommen. Denn viele DMS-Anbieter haben Teile ihres Lösungsportfolios durch Firmenübernahmen hinzugekauft. Die Kompatibilität der einzelnen Komponenten ist deshalb nicht so hoch, wie sie sein sollte. Nur mit größtmöglicher Kompatibilität kann man sicherstellen, dass das Versionskontrollsystem das gleiche ist, die Modelle immer gleich deployt werden und ein einheitliches Logging und Monitoring möglich ist.

Außerdem muss man wissen, dass Data-Scientist normalerweise keine Regel-Systeme bedienen und steuern, weil sie strukturell in unterschiedlichen Unternehmensbereichen angesiedelt sind. Oft sind das getrennte Silos: Die Data-Scientist kümmern sich um die Machine-Learning-Modelle und die anderen erstellen die Regelwerke.

Wir finden oft die Situation vor, dass Kunden schon eine Regeltechnologie im Einsatz haben und die grafische Eingabe der Regeln kennen. Die nutzen gerne auch unsere ML-Technologie, weil sie die bekannte grafische Oberfläche wiederverwenden können. Wir schulen dann die Fachanwender darin, wie sie Machine-Learning-Modelle in der Oberfläche erstellen können. Hier macht eine One-Stop-Shop-Lösung Sinn, um Schulungskosten zu vermeiden.

Wenn Kunden schon bestehende Machine-Learning-Modelle haben, dann liegen diese oft als Python-Skript vor. Das können wir dann auch in unser System integrieren.

Noch mal konkret: Was spricht dafür oder dagegen, die eingebaute ML-Lösung eines DMS zu verwenden und wann ist eine externe Lösung sinnvoll?

Letztlich hängt es an den Tools, die die Data Scientists bevorzugt verwenden. Die meisten arbeiten am liebsten mit Open-Source-Technologien wie Python oder R. Diese können laut Gartner von allen untersuchten DMS integriert werden. Sprich: Hier ist keine externe DSML sinnvoll. Dann gibt es auch Unternehmen, die sich strategisch für eine externe DSML-Plattform entschieden haben, da sie einen „Best-of-breed“-Ansatz fahren. Etwa weil ein gewisses Feature benötigt wird, das nur ein externes DSML liefern kann. Diese Unternehmen wollen die Modellerstellung dann auch nicht außerhalb der DSML vornehmen. Dies führt meist dazu, dass das DMS und DSML lose über Webservices gekoppelt werden. Allerdings bringt diese Anbindung einen gewissen Overhead aufgrund von Latenzzeit mit sich. Wir haben Kunden, die zehntausende Anfragen pro Sekunde verarbeiten müssen und das funktioniert mit einer Webanbindung nicht mehr. Wir sind da einer der wenigen Anbieter, die keine externen Systeme über Webservices aufrufen müssen, um ein ML-Modell auszuführen. Letztlich hängt die Entscheidung aber immer vom Einzelfall ab.

Fabian Cotic
PRESALES-CONSULANT / VERTRIEB

Fabian Cotic arbeitet als Spezialist für maschinelles Lernen für ACTICO und hat an vielen KI-basierten Projekten im Finanzdienstleistungssektor mitgewirkt. Neben seiner Arbeit in Beratungsprojekten hat er auch als Software-Ingenieur die Integration von KI und Maschinellem Lernen in die ACTICO-Platform vorangetrieben. Während seiner drei Jahre bei ACTICO hat er außerdem viele ML-Modelle entwickelt, die sehr erfolgreich produktiv eingesetzt werden.

Das könnte Sie auch interessieren

Whitepaper: Erfolgreiche Automatisierung

Erfahren Sie wie Sie Experten der Fachabteilung direkt einbinden mit Low-Code-Plattformen.

Whitepaper herunterladen
eBook: Die 7 entscheidenden Fragen bei der Auswahl eines Decision Management Systems

Decision Management Automation – Welcher DMS-Anbieter ist der Richtige?
Wer ein Decision Management System einführen möchte, muss dem potenziellen Anbieter die richtigen Fragen stellen. Dieses eBook greift die wichtigsten Aspekte & Fragen aus einem Gartner Toolkit auf und liefert für Sie die relevanten Antworten.

eBook herunterladen
Intelligente Automatisierung der nächsten Generation

ACTICO Platform ist eine leistungsstarke Software für intelligente Automatisierung und Digital Decisioning.

Mehr erfahren