IT-Praxis: Workflow-Auto­ma­ti­sierung bei Talanx – >90% Dunkel, bald ereignis­gesteuerte Microservices

In einer aktuellen Anwenderstudie bezeichnen EU-weit 56 Prozent der Unternehmen eine auf Microservices basierende IT-Architektur als erfolgskritisch für digitale Trans­formation. Der Versicherungs­konzern Talanx zeigt, warum. In weniger als vier Jahren hat die Nummer drei im deutschen Versicherungsmarkt mit Hilfe der Workflow-Engine Camunda auf dem größten Eingangskanal für Abschlüsse eine Dunkelverarbeitungsquote von mehr als 90 Prozent erreicht und setzt künftig auf ereignisgesteuerte Microservices.

von  Uwe Koch, IT Enterprise Architect Talanx Systeme

3,4 Millionen Stellen seien allein in Deutschland gefährdet, warnt der IT-Branchenverband Bitkom. Die OECD stuft jeden siebten Job in den Mitgliedstaaten als hoch automatisierbar ein. Unternehmen müssen deshalb die fachlich-politische Frage, ob sie Menschen durch Maschinen ersetzen wollen, beantworten, bevor sie ihre Digitalisierungsprojekte starten.”

Talanx hat sich entschieden, Mitarbeiter von möglichst vielen Tätigkeiten zu entlasten, die starre und wiederkehrende Arbeitsabläufe enthalten und daher menschliche Entscheidungskompetenzen kaum erforderlich machen (vgl. Abb. 1).

Die Antragsstrecke für ein Standardprodukt wie die Kfz-Versicherung gehört zu den typischen Beispielen für einen nahezu vollständig dunkel zu verarbeitenden Prozess. Von der Datenprüfung bis zur Policierung braucht nur dann ein Mitarbeiter den Prozess zu bearbeiten, falls dieser vom System wegen auftretender Unregelmäßigkeiten ausgesteuert wird.

Talanx unternimmt diesen Automatisierungsschritt künftig bei einfach zu entscheidenden Versicherungsfällen wie Glasbruch und plant, Schadensmeldungen vom Eingang bis zur Auszahlung so weit wie möglich dunkel abzuwickeln.”

Dafür werden eine einheitliche Datenqualität auf allen Eingangskanälen gebraucht und eine Regel-Engine, die auf Plausibilität prüft und Daten validieren kann (Input-Management).

Schwache Prozess-Engines austauschen

Diese Voraussetzungen waren 2012 noch nicht gegeben. Nach der Fusion von HDI und Gerling unter dem Dach von Talanx existierten verschiedene Bestandssysteme aus der „alten Welt“, die zudem zwei unterschiedliche Marktschwerpunkte aufwiesen: „Leben“ (Gerling) und „Sach“ (HDI). Zunächst wurde eine Serviceorientierte Architektur (SOA) aufgebaut und Servicedienste an die bestehenden Systeme angeflanscht, um elementare Funktionen wie die Partner- und Vertragsverwaltung zentral zugriffsbereit zu machen. Anschließend wurden die Servicedienste mit einer Prozess-Engine verknüpft, doch das ausgewählte Workflow-System erwies sich als teuer und entgegen den Herstellerangaben als kaum skalierbar.

Autor Uwe Koch, IT Enterprise Architect bei der Talanx Systeme

Uwe Koch arbeitet seit 2013 als IT Enterprise Architect bei der Talanx Systeme AG, dem technischen IT-Dienstleister des Talanx-Konzerns zu dem unter anderem die Versicherungsmarke HDI gehört. Der diplomierte Informatiker beschäftigt sich schwerpunktmäßig mit den Themen Prozessautomatisierung und Integrationsarchitekturen. Koch verfügt über mehr als 20 Jahre Erfahrung im Bereich technischer Frameworks und Middleware-Architekturen bei Banken und Versicherungen.

Zudem verfolgte die Engine das „Best of Suite“-Prinzip, das unter anderem ein eigenständiges Deployment- und Build-Verfahren mit sich brachte sowie eine nur proprietäre Konfiguration für Administratoren. All das machte Spezialwissen für die Entwickler erforderlich, anstatt etablierte Standards nutzen zu können. Bereits vorhandene Skills und Verfahren für die Entwicklung, wie Java, sowie etablierte Produkte, wie Websphere und Oracle, waren inkompatibel zur Prozess-Engine. Erforderlich war eine Entscheidung für eine neue IT-Architektur, um die gewünschte Workflow-Automatisierung umzusetzen. Diese Entscheidung fiel 2014.

Die richtige Software auswählen

Am Markt waren vor vier Jahren vor allem Box-Lösungen in Mode, also Systeme mit Modulen „aus einem Guss“, die über eine einheitliche Bedienoberfläche verfügen und wegen des „One fits all“-Prinzips ein eigenes Ökosystem mitbringen, das Entwicklung, Build und Deployment vereint. Das Problem: Talanx hatte bereits bewährte Tools beispielsweise für die Versionierung im Einsatz sowie funktionierende Build-Systeme, die nicht allein wegen des Prozessmanagements vollkommen neu aufgesetzt werden sollten. Gefragt war also eine leicht integrierbare Workflow-Engine, die über offene Schnittstellen und etablierte (Web-)Standards weiter Nutzen aus bereits vorhandenen Ressourcen ziehen kann. Camunda erfüllt diese Anforderungen im Sinne einer Library mit Kernfunktionen, JEE-Standards sowie Websphere- und Java-Unterstützung.

Auf einer Anwenderkonferenz hat ein anderer Versicherer etwa zur gleichen Zeit über ähnliche Schwierigkeiten mit der gleichen Prozess-Engine berichtet, die Talanx bislang im Einsatz hatte. Nach direktem Austausch und einem Referenzbesuch folgte ein Proof of Concept, in das neben den IT-Architekten auch Produktionsexperten eingebunden waren, um sowohl die technische als auch die produktive Perspektive abzudecken. Das Ziel: Ein System, das den Fachabteilungen ermöglicht, Prozesse zu modellieren, die anschließend von der Prozess-Engine durchlaufen werden können. Camunda bietet nicht nur eine grafische Oberfläche zur Prozessmodellierung, sondern auch zur Visualisierung im Betrieb. Das erleichtert den Fachbereichen, die IT besser zu verstehen, da der grafisch erstellte Prozess auch maschinenlesbar ist und daher später genauso produktiv abläuft, wie zuvor in der Designphase entworfen.

Im Proof of Concept haben die Systemarchitekten zunächst technische Grundfunktionen wie ESB Pattern, Integration Java Entwicklungsumgebung und Websphere-Betrieb verifiziert sowie den BPL-Entwicklungsprozess aus der alten Welt in die Modellierungssprache BPMN (Business Process Model and Notation) überführt. Camunda unterstützt diese Standards und lässt sich, anders als das Altsystem, durch Plug-ins um sinnvolle Funktionen wie ein Cockpit erweitern – das sind sehr gute Voraussetzungen für ein Workflow-Werkzeug, das auch Altsysteme steuern können soll. Camunda unterstützt als offener Standard auch die existierende XML-basierte Servicearchitektur. So lässt sich mit angeschlossenen Systemen besser interagieren, da sich Servicetasks aus der BPMN-Sprache direkt aufrufen lassen. Damit waren alle wesentlichen Voraussetzungen für den Systemwechsel erfüllt (vgl. Kasten).

BPMN-Heatmaps für bessere Steuerung

In der Praxis hat sich bewährt, bei einer Architekturentscheidung vor allem die Lizenz- und Supportkosten zu vergleichen und dies den Migrationskosten gegenüberzustellen, um den Return on Invest (ROI) zu ermitteln. Camunda überzeugt vor allem wegen der Open Source-Grundausstattung und der damit verbundenen Verfügbarkeit sämtlicher Programmsourcen. Das ermöglicht, schneller Fehlerursachen aufzuspüren, da sich sowohl der eigene Programmcode wie auch der Programmcode der Prozess-Engine einfacher debuggen lassen. Der Hersteller bietet außerdem Enterprise-Support an, so dass kein zusätzliches Know-how für Wartung und Betrieb der Prozess-Engine aufzubauen war. Die Kostenabschätzung erfolgte daher wesentlich auf Basis einer Prozessinventur, um zu entscheiden, welche Prozesse übertragen werden und welche einfach auslaufen sollen.

Die unterjährige Architekturentscheidung für eine Migration auf Camunda fiel 2015 und floss unmittelbar in die Jahresfolgeplanung ein. Beim Startschuss 2016 bot sich so die Chance, Camunda in die digitale Produktstrategie einzubinden und mit der Kfz-Sparte eine erste Blaupause zu entwickeln, bevor das System vollständig ausgerollt werden sollte. Das Projekt umfasste die heutige HDI-Webseite, inklusive einer Schnittstelle zu Check24 für Online-Abschlüsse, sowie das zugehörige Online-Kundenportal, das Tarifberechnungen und Angebote rund um die Uhr anbieten kann. Die meisten Verarbeitungsprozesse im Hintergrund werden heute über Camunda gesteuert.

Kunden, die einen Kfz-Vertrag abschließen, erhalten vollautomatisch Zugangs- und Anmeldedaten sowie sämtliche Dokumente für die gewünschte Versicherung online zugestellt. Für die jeweiligen Einzelschritte existieren Servicetasks, die der Kunde durch seine Aktivitäten auf dem Portal auslöst und die intern von Camunda gesteuert werden. Die Bewährungsprobe im Herbst 2016 war der sogenannte „Herbststurm“, wenn Tausende von Kunden ihre Versicherungen verlängern oder ihren Anbieter wechseln wollen. Durch die BPMN-Modellierung und die von Camunda unterstützte Visualisierung als Heatmap (vgl. Abb. 2) ließ sich im laufenden Betrieb schon nachvollziehen, wie viele Instanzen gelaufen sind, was wo passiert ist, ob die Eingangsdaten korrekt waren und an welchen Stellen keine automatisierte Verarbeitung möglich gewesen ist. Daraus ließen sich Prozessbilder ableiten, die bei der Prozessoptimierung später enorme Vorteile geboten haben.

Prozesswerkstätten für die Modellierung

Wie bereits erwähnt, ermöglicht BPMN eine stark fachlich und weniger technisch getriebene Entwicklung von Prozessen. Die Fachbereiche brauchen kaum technische Spezifikationen, um Abläufe zu gestalten und anzupassen. Und das erleichtert wiederum die bereichsübergreifende Zusammenarbeit, die bei Talanx mehr und mehr agil organisiert ist. Typischerweise arbeitet ein Business Analyst mit dem jeweiligen Fachbereich sowie den Entwicklern für Camunda zusammen. Indem stets alle Beteiligten einbezogen werden, ist eine End-to-End-Sicht auf den Prozess gegeben. Die modellierten Prozesse werden sogar großflächig ausgedruckt, um während laufender Projekte die Zusammenhänge zu visualisieren. All dies läuft in einer sogenannten Prozesswerkstatt, die im Retailbereich Sach bereits umgesetzt ist. Industriegeschäft und Retailbereich Leben folgen derzeit.

Seit 2017 modelliert Talanx neben den Prozessen auch die Geschäftsregeln, die zuvor in Entscheidungstabellen gesammelt worden sind. Entscheidend ist, diese Geschäftsregeln in einem maschinenlesbaren Format wie DMN (Decision Model and Notation) vorzuhalten, damit die Workflow-Engine damit umgehen und auf diese Weise komplexere Abläufe steuern kann. So lässt sich etwa automatisch regeln, wie lange die Engine auf eine Reaktion des Kunden wartet, bevor das System beispielsweise eine Erinnerungsnachricht verschickt. Methodisch führt dies dazu, Prozesse zu parametrisieren und darauf aufbauend bestimmte Servicetasks zu starten, bedarfsweise zu pausieren oder abzubrechen.

Eine Herausforderung ergab sich jedoch im Bereich Leben. Auf Protokollebene müssen proprietäre Systeme aufgerufen werden, ohne dass bereits eine serviceorientierte Architektur etabliert gewesen wäre. Die Lösung: Über REST-Schnittstellen werden sogenannte Adapter eingeführt, die diese Systeme anbinden und sich aus den Camunda-Prozessen ansprechen lassen. Perspektivisch soll in der nächsten Ausbaustufe eine Steuerung über Ereignisse (vgl. Abb. 3) folgen. Eventbasierte Systeme reagieren auf vordefinierte Ereignisse wie dem Jahresende und fordern regelbasiert die vom Kunden benötigten Informationen, wie die gefahrene Jahreskilometerzahl bei einer Kfz-Versicherung, ab.

Ereignisgesteuerte Workflows

Talanx hat bereits damit begonnen, einen Ereigniskatalog zu erstellen. Künftig operieren moderne IT-Systeme nicht mehr nur nach der Logik, Benutzern oder Systemen einen Auftrag zu erteilen, sondern sie erzeugen ein Ereignis, auf das die Umwelt individuell reagiert. Das erfordert von der Architektur her eine Validierung, ob derjenige, der ein Ereignis auslöst, vertrauenswürdig ist oder nicht. Beispielsweise könnte wegen Vertraulichkeitsanforderungen unerwünscht sein, dass alle Prozessbeteiligten immer und überall über alle Ereignisse informiert werden. Verschiedene Rollenmodelle und Berechtigungen müssen dafür sorgen, dass nur qualifizierte Sender von Ereignissen und nur autorisierte Ereignisempfänger innerhalb des Systems operieren. Idealerweise lässt sich das in einem Dashboard überwachen.

Camunda erfüllt diese Anforderungen mit dem External Task Pattern, das Systeme nicht mehr über Schnittstellen direkt aufruft, sondern die anstehende Arbeit sammelt und von Ereignisempfängern abholen lässt. Das ereignisübernehmende System muss sich also autorisieren, bevor der nächste Arbeitsschritt durchgeführt werden kann. Systemübergreifend erleichtert dieses Vorgehen den „Ereignisaustausch“ erheblich und damit auch die Einführung einer auf Microservices basierenden IT-Architektur.

Workflow-Fazit

Ereignisgesteuerte Microservices sind die Zukunft in der Prozessautomatisierung. Talanx arbeitet aktuell daran, die dezentral aufgebaute IT-Architektur dahingehend weiterzuentwickeln. Künftig dürften sich immer mehr Unternehmen von Großsystemen verabschieden, um die Skalierbarkeit eigener Anwendungen zu gewährleisten und weniger abhängig zu sein von Release-Zyklen und damit einhergehenden Kompatibilitätsproblemen in herstellertechnisch inhomogenen Software-Landschaften. Darüber hinaus bieten Microservices mehr Flexibilität, wenn neue Funktionen realisiert oder bestehende Module aktualisiert werden sollen.Uwe Koch

 
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/80089

• teilen 
• teilen 
• teilen 
• teilen 
• teilen 
• RSS-feed 
• E-Mail 
• drucken