Systemlandschaft im Wandel – das Vorbild E-Commerce

Viele Versicherer tragen schwer an ihren historisch gewachsenen Systemen: Zwar haben viele ihre externe Darstellung mittlerweile durch moderne Webseiten und zahlreiche Portale modernisiert, intern stehen aber weiterhin häufig nur Sparten-bezogene Systeme mit vielen redundanten und inkonsistenten Daten zur Verfügung. Anstatt sich aktuelle Entwicklungen in anderen Branchen zum Vorbild zu nehmen, zementieren sie mit dieser Haltung die bestehende fachliche Architektur oft weiter. Dabei wäre es relativ einfach, zum Beispiel aus dem Erfolg des Online-Handels, Rückschlüsse für eine zukunftsträchtige Architektur zu ziehen.

von Carsten Bovelet, adesso

Viele Versicherungsunternehmen zögern ihre IT-Systeme zu modernisieren. Doch mit einem konsistenten Kunden- und Interessentenmodell, den dazu gehörigen intelligenten Services sowie einer darauf aufgesetzten Portallandschaft könnten auch Versicherer eine moderne Systemlandschaft für alle ihre Nutzergruppen schaffen.

Stattdessen tendieren Versicherungsunternehmen dazu, neue Lösungen falsch zu schneiden und mit hohem Aufwand und vielen Kompromissen an die bestehende Systemlandschaft anzubinden (siehe Abbildung Beispiel einer Systemlandschaft). Eine sinnvolle Zielarchitektur ist in den meisten Fällen nicht zu erkennen. Versicherer, die über den Tellerrand schauen und sich grundsätzlich Gedanken über eine sinnvolle IT-Architektur machen, könnten sich aber damit signifikant von der Konkurrenz absetzen.

Zuviel Zement für echte Innovationen?

Wenn man sich die Entwicklungen in der Versicherungsbranche anschaut, reibt man sich verwundert die Augen. Eigentlich stehen Versicherungsunternehmen unter einem hohen Konsolidierungsdruck bezüglich ihrer bestehenden Systeme. Was die bestehenden Systemlandschaften derzeit kennzeichnet, ist insbesondere:
1. Keine 24/7-Verfügbarkeit der Systeme
2. Keine konsolidierte Sicht auf die Produktlandschaft beziehungsweise auf die Sparten
3. Inkonsistente Datenhaltung für Kunden und Vertriebspartner
4. Keine SaaS-Architektur der bestehenden Systeme

Diese Aspekte stehen vielen notwendigen Innovationen im Weg, denn sowohl für den Aufbau einer konsistenten Portallandschaft über alle Vertriebskanäle hinweg als auch für die Integration neuer Verkaufs- und Beratungsservices ist eine konsistente Architektur notwendig.
Anstatt aber ernsthaft die bestehenden Landschaften zu konsolidieren, erhalten Versicherer diese und fügen neue (Insel-)Lösungen hinzu, die zwar kurzfristig einzelne Aspekte lösen, aber aus ganzheitlicher Perspektive die Situation langfristig eher verschlimmern. Es entstehen weitere Redundanzen und die Systemlandschaft wird noch komplexer. Wie aber können sich Versicherungsunternehmen diesem Dilemma stellen? Eine Möglichkeit ist, dass sich Versicherer nicht länger an der eigenen, über Jahrzehnte gewachsenen Architektur orientieren, sondern sich andere Branchen als Vorbild nehmen.

Lohnt sich der Blick über den Tellerrand?

Ein klares Ja. Wenn man sich die erfolgreichen Internetgrößen wie Amazon oder Google anschaut und deren Erfolgsmodelle betrachtet, könnte man einige Aspekte auf die Versicherungsbranche übertragen, um eine tragfähige Basis zu schaffen. In der Praxis bedeutet das zum Beispiel, dass Versicherer ein simples E-Commerce-Modell (siehe Abb. E-Commerce-Modell) auf ihre Strukturen übertragen, um zukunftsfähig zu werden. Folgende Aspekte spielen hierbei eine Rolle:
1. Die kundenzentrierte Sicht mit einem vollständigen und konsistenten Objekt- oder Datenmodell
2. Produkte konsolidiert über den gesamten Lebenszyklus am Kundenobjekt
3. Durchgängiges Status-Handling
4. Integration von Pre-Sales-Objekten
5. Alle Services am Kunden und Produkt werden konsistent bereitgestellt (möglichst als SaaS-Ansatz)

Diese Aspekte sind sowohl für eine zukunftsfähige technische Lösung als auch für entstehende fachliche Anforderungen (Multikanal-Vertrieb, veränderte gesetzliche Rahmenbedingungen usw.) unbedingt notwendig. Mit einem solchen Modell lässt sich sehr einfach ein tragfähiges Objektmodell für Versicherungsunternehmen skizzieren (siehe Abb. Insurance-Modell).

Der wesentliche Unterschied zwischen den beiden Branchen ist der Produkt-Lebenszyklus. Während im E-Commerce mit dem Verkauf eines Produkts sein Lebenszyklus weitgehend abgeschlossen ist, zumindest aus Sicht des Verkäufers, beginnt der Lebenszyklus eines Versicherungsprodukts erst mit dem Vertragsabschluß zwischen Kunde und Versicherer. Grundsätzlich hat dieser Aspekt aber keine große Auswirkung auf die Architektur, da hier nur die Versicherungsunternehmen entsprechende erweiterte automatisierte Services zur Verfügung stellen müssen (Schaden, Vertragsänderungen usw.). Die grundlegende Architektur rund um Kunde, Produkt und Prozesse bleibt gleich.

Im Prinzip ist das in der Außendarstellung nichts Neues, viele Versicherungen bieten bereits Portale an, die zumindest teilweise Funktionalitäten von E-Commerce-Plattformen abbilden. Problematisch ist aber, dass die Unternehmen ihre Gesamtarchitektur nicht darauf abstellen und damit zusätzliche Komplexität wie zum Beispiel zusätzliche redundante Datenbanken schaffen.

Und was sonst noch?

Bei einer ergänzenden frühzeitigen Berücksichtigung des Themas Rechte und Sichten können Versicherer ihre IT-Architektur so konzipieren, das entsprechend entwickelte „Verkaufsportale“ auch weitere Nutzergruppen (zum Beispiel Vertriebspartner oder Innendienst) über entsprechend erweiterte Services nutzen können. Das bedeutet, dass hier das Potenzial ein integriertes Frontend vorhanden ist und sich weitere Synergieeffekte ergeben.

Der beste Ansatz, mit den bestehenden Herausforderungen wie neuen Portalen, dem veränderten Kundenverhalten oder neuen Marktteilnehmern umzugehen, ist eine Ausrichtung der eigenen Systemlandschaft an einer konsistenten IT-Architektur. Viele Portale, die zum Beispiel an bestehende Spartensysteme angebunden sind, behindern sich gegenseitig und führen im schlimmsten Fall dazu, dass die Reaktionsfähigkeit von Versicherern eingeschränkt wird. Daher sind entsprechende Projekte zur Umsetzung oder der Zukauf entsprechender Komponenten “alternativlos”, auch wenn das im ersten Schritt keine große Außenwirkung hat.aj