Geschäftsprozesse mit Hilfe von KI optimieren

Die Themen BPMN und KI sind derzeit in aller Munde. Da liegt die Frage nahe, welche Potenziale sich durch die Verbindung der beiden Themen ergeben können. Und genau hier setzt BPMN.ai an. Es geht dabei zum einen darum, mit dem Einsatz von Methoden der künstlichen Intelligenz nützliche Informationen aus Daten zu gewinnen, die durch die Ausführung von Geschäftsprozessen entstehen. Zum anderen wird betrachtet, wie diese gewonnenen Informationen zur Modellierung, Optimierung und weiteren Automatisierung der Geschäftsprozesse genutzt werden können.

bpmn.ai umfasst dabei den gesamten Zyklus von der Extraktion der relevanten Daten, dessen Transformation und Aufarbeitung, über die Anwendung von KI-Methoden darauf (wie z. B. Machine-Learning), bis hin zur Integration und Orchestrierung von Ki-unterstützten Aktivitäten im Geschäftsprozess.

Bpmn.ai – KI-Prozessmuster im Zusammenspiel

Ein Beispiel: Ein Schadensprozess einer Versicherung soll entscheiden, ob eine externe Prüfung notwendig ist. Grundlage ist eine manuelle Entscheidung, zu der die im Verlauf des Prozesses Daten gesammelt wurden. Als letzter Schritt wird, je nach Prüfungsentscheidung, die Zahlung automatisiert freigegeben oder abgelehnt. Diese Konstellation ist in Unternehmensprozessen sehr häufig zu finden. Ein Python-Script, dass die Entscheidung trifft, ist oft schnell geschrieben. Für eine Produktivsetzung bietet sich eine verantwortungsvolle Kombination von bpmn.ai Patterns an.

Zunächst wird zufällig ein Teil der eingehenden Fälle ausgesteuert. Damit sicher wir uns für die Zukunft ab, indem wir die ausgeschleusten Fälle von KI-Logik und Mensch entscheiden lassen und die Ergebnisse vergleichen (Drift Detection). Im nächsten Schritt bietet sich eine Anomalieerkennung als Sicherheitsmaßnahme an. Es wird Sonderfälle geben, die sich nicht für automatische Verarbeitung eignen. Sie automatisch zu bemerken ist aber oft relativ einfach. Erst hinter diesem “Filter” kommt es zu einer Entscheidung des KI-Modells, die möglicherweise den Prozess-Ausgang beeinflusst. Dies geschieht aber nur, wenn das Modell den Einzelfall sicher genug entscheiden kann, der gewünschte Automatisierungsgrad wird so steuerbar.

Process Engines sind eine Chance für den Einsatz von KI

Die gesammelten Daten von vergangenen Prozessläufen enthalten sowohl die Informationen, welche der manuellen Entscheidung zur Notwendigkeit einer externen Prüfung zugrunde lagen, als auch die Entscheidung selber, da diese jeweils als Prozessvariablen vorliegen und gespeichert werden. Durch die Aufbereitung dieser Daten und das Anlernen eines ML-Modells kann ein Entscheidungsmodell für eine KI-gestützte Prozessoptimierung erstellt werden. Eine manuelle Entscheidungsaktivität kann so durch eine automatisierte Aktivität unterstützt werden.

Dabei ist wichtig zu verstehen, dass ML-Modelle nicht das Ende der DMN-Tabellen darstellt. Das Gegenteil ist der Fall. Jede (fachliche) DMN-Tabelle ist ein potenzieller Business Case für Data Science-Verfahren und sowohl ein “gemachtes Nest” (viele Daten sind schon im Prozess greifbar) als auch ein mögliches Betriebsmodell (“Serviceless AI“).

Integration und Orchestrierung von KI-Services

KI-Services stehen selten allein da. BPMN-Prozesse, die bspw. mit der Camunda-Plattform ablaufen, bieten sich an, um ihren Einsatz zu orchestrieren. Auf einer gröberen Eben kann die Integration der Künstlichen Intelligenz in den Prozess in verschiedenen Stufen oder auch Reifegraden gestaltet werden:

Beispiele aus der Praxis

Für Duni wird eine Prognose der Laufzeit des überarbeiteten Profile-Print-Prozesses daraus abgeleitet, indem beispielsweise individualisierte Servietten für Restaurants gestaltet und hergestellt werden – mit dieser Arbeit waren wir auf der CamundaCon 2018 dabei.

Die Idee hat sich als gut übertragbar erwiesen. Zusammen mit der Westfälischen Provinzial Versicherung AG verfolgen wir mit gleicher Technik die Idee, um die Notwendigkeit von Rechnungsprüfungen bei der Abwicklung von KFZ-Glasbruchfällen vorherzusagen. Das Ergebnis konnten wir auf den Versicherungsforen in Leipzig 2018 vorstellen.

Eine andere Perspektive auf bpmn.ai ist das Process Mining. Hierzu gab es einen schönen Erfolg, der in einer gemeinsamen Publikation mit der TIMOCOM Frachtenbörse sowie dem ERCIS auf der BPM 2020 im Industry-Forum geführt hat. Dort haben wir Nutzungsmuster aus einem Event-Stream einer Web-Anwendung herausgelesen und diese klassifiziert.

Ebenfalls ein schöner Erfolg war die Analyse von Process-Varianten der Warehouse-Logistik eines Industrie-Unternehmens inkl. Anomalie-Erkennung.

Die Pipeline

Unsere vorbereitete Pipeline konsolidiert Events einer Process Engine in eine auswertbare Form und ist Dank der Verwendung von Apache Spark auch auf sehr große Datenmengen anwendbar. Zudem ist sie einfach erweiterbar, so dass spezifische Anforderungen einfach in integriert werden können (wie z. B. das Hinzufügen von relevanten Daten aus Fachsystemen). Die Process Engine kann gerne eine Camunda-Engine sein, oder auch eine andere Steuerungsplattform. Prozess- oder Aktivitätsniveau sind wählbar.

Der “Wissensstand” der Prozessvariablen zum jeweiligen Aktivitätsstand wird eingesammelt und steht für ein Machine Learning zur Verfügung. Auch mit großen Datenmengen. Die R-Umgebung ist in der Analyse-Phase maximal flexibel. Das Machine Learning erfolgt dann per H2O auf Basis von Java-Technologien. Das entstehende Entscheidungsmodell bettet sich daher abschließend auch sehr gut in Java-basierte Anwendungslandschaften ein. Das resultierende Datenformat erlaubt aber auch die Verwendung beliebiger anderen Machine Learning Lösungen.

Was ist mit meinem Data Warehouse?

Die oben dargestellten Technologien beschreiben den „Grüne Wiese“-Ansatz. Sollten Sie bereits ein Data Warehouse im Einsatz haben, sollte es natürlich ebenfalls als Datenquelle im Machine Learning verwendet werden. Ein separate Infrastruktur für KI-Zwecke ist dabei dennoch sinnvoll:

• Viele Business-Prozesse verwalten JSON-Dokumente, bspw. Kund:innen oder Verträge. Um deren Inhalte effizient nutzen zu können, ist ein relationales DWH ungeeignet.
• Viele Business-Prozesse nutzen hierzu auch direkt Java-Objekte von Fachsystemen – diese sind nur aus einer Java-basierten Pipeline sinnvoll zugreifbar, um deren Inhalte für Analysen zugänglich zu machen.
• Wenn eine Analyse nicht nur pro Prozessinstanz, sondern auch pro Aktivitätsinstanz möglich werden soll, sind schnell Datenmengen erreicht, für die sich Big-Data-Technologien lohnen können, weil wir weniger lang auf Ergebnisse warten müssen. Besonders gut greifen hier Kafka, Spark und H2O ineinander: Die Daten können von Cluster-Knoten zu Cluster-Knoten parallel fließen. Bei einer traditionellen Datenbank wäre diese immer ein “Nadelör” für diesen Anwendungsfall.
• Eine relationale Behandlung von Prozess-Events erscheint für die Analyse unpassend: Oft interessieren uns nicht das einzelne Event oder seine Eigenschaften, sondern der gesamte aufgelaufene Wissensstand (Prozessvariablen) zum Zeitpunkt des Events. Dieses Zusammentragen über Zeilen hinweg ist mit Standard-SQL schlicht nicht ausdrückbar. Workarounds wie eine statische Vorverarbeitung im ETL oder Oracle’s OVER-Statement kommen durch die sich immer wieder ändernden Datenstrukturen ebenfalls nicht zum gewünschten Ziel: Alles unverändert speichern – alle Türen für Analysen offen halten.
• Und was ist mit meinem Archiv im ElasticSearch? Hier Prozessdaten zu sammeln ist so lange es nur um Suche und Aggregation geht eine gute Idee. Die Datenvorverarbeitung im Machine Learning macht aber auch viele weitere oft kreative (Schreib-) Operationen notwendig, insbesondere das Zusammenführen mit weiteren (DWH-) Datenbanken – das ist im Elastic-Konzept nicht vorgesehen.
• Die Prozessdatenpipeline ist, anders als das DWH, ein operatives System: Entscheidungen fließen zurück und beeinflussen den laufenden Geschäftsprozess ggf. unmittelbar als Stream oder Service-Call. Es lohnt sich daher aus Architektursicht die beiden (sich ergänzenden) Welten DWH und bpmn.ai separat zu betreiben, denn die Lehren der letzten Jahre rund um Domain-Driven-Design und Microservices gelten auch für die Anwendung von KI in Geschäftsprozessen.

Der Fluch der Datensammlung und -vorverarbeitung

Data preparation accounts for about 80% of the work of data scientists. Forbes

Der größte Aufwand bei der Analyse von Daten wird immer für Datensammlung und Vorverarbeitung betrieben. Im Umfeld der Process Engines lässt sich ein Großteil dieses Aufwands generalisieren, da die Verarbeitung nicht vom konkreten fachlichen Anwendungsfall abhängt. In der viadee haben wir diese Schritte so weit wie möglich generalisiert und skalierbar gestaltet. Weiterhin können wir individuelle fachliche Anforderungen einfach in unseren Ansatz integrieren und umsetzen (bspw. Java- oder JSON-Objekte). Weitere Informationen zum Thema Business Process Management und wie Sie die Daten aus einer Prozess Engine analysieren und nutzen können finden Sie auf unseren Seiten zum Thema Business Process Management und unserem viadee Process Warehouse. Bei weiterem Interesse im Bereich Business Intelligence finden Sie hier weitere Informationen. Ebenfalls relevant ist der Vortrag auf der CamundaCon 2018, wo wir über unsere Erfahrungen mit der Duni berichtet und die bpmn.ai-Idee mit Leben gefüllt haben. bpmn.ai ist seit November 2018 ein Open Source Projekt auf GitHub! Auf der Open-Source-Konferenz FrosCon 2019 hat unser Berater Mario Micudaj einen Vortrag zum Thema bpmn.ai gehalten, der online verfügbar ist. Die Vorträge finden Sie auch weiter unten.

BPMN.ai auf der Bühne