Kundendaten nutzbar machen – warum konsistente Kundendaten in Versicherung eine Herausforderung ist, die zeitnah adressiert werden muss

von Christina Bachfisch | 2. Dezember 2024 | Data, Insurance

Christina Bachfisch

Christina ist Expertin für die Analyse und das Design von Zielbildern für digitale Plattformen und Operating Modelle.

In der Versicherungsbranche sind die EU-Initiative „Financial Data Access (FiDA)“, Künstliche Intelligenz und Customer Relationship Management (CRM) momentan häufig diskutierte Themen. Diese bieten viele Chancen den Kundenservice zu verbessern, Effizienzen zu steigern und Wettbewerbsvorteile zu erzielen. Eine der größten Herausforderungen bei der Umsetzung liegt jedoch oftmals nicht in der Implementierung der Themen selbst, sondern im dazu notwendigen Aufbau einer konsistenten Datenbasis an Kundenstammdaten. In vielen Versicherungsunternehmen stellen wir fest, dass eine einheitliche Sicht auf die Kundenstammdaten oft fehlt. Dies führt dazu, dass Umsetzungsprojekte zeitaufwändiger und kostenintensiver werden. Um diese Herausforderungen zu bewältigen ist es entscheidend frühzeitig die Herstellung der benötigten Datenbasis im Zielbild zu betrachten und entsprechende Datenlösungen zu entwickeln.

Status Quo

Meist treffen wir in Versicherungsunternehmen auf eine Fragmentierung der Kundendaten. Bedingt ist dies meist durch die Speicherung in isolierten Systemen und einer rein vertragsbasierten Ablage. Hintergründe dieser Architekturen sind oftmals historisch bedingt und in Teilen auch auf die Spartentrennung nach VAG §8 zurückzuführen. Diese fragmentierte Systemstruktur führt jedoch zu inkonsistenten Kundendaten, da unterschiedliche Systeme Informationen zum Kunden speichern, ohne dass ein Abgleich dazwischen erfolgt oder es überhaupt möglich ist den Kunden aus einem System in einem anderen wieder zu finden. Meist ist es zudem so, dass die Definition eines „Kunden“ im Unternehmen nicht einheitlich vorliegt und in jedem Bereich mit unterschiedlichem Verständnis über Eigenschaften gehandhabt wird, wodurch es bei der Erstellung eines konsistenten Zielbilds schnell zu Herausforderungen kommt.

Insgesamt ist durch diesen beschriebenen Ist-Zustand ein vollständiges Bild über die bestehenden Verträge eines Kunden nur mit erheblichem, zumeist manuellem Aufwand möglich, was sich auf verschiedene Themen auswirkt, wie im Folgenden dargestellt:

Notwendigkeit von konsistenten Kundenstammdaten in verschiedenen Themen

Betrachtet man nun die eingangs angesprochenen Themen, wird schnell klar, warum diese konsistente Kundenstammdaten benötigen:

Thema 1: FiDA

Mit FiDA folgt nun nach PSD2 (Payment Service Directive) eine weitere Regulatorik, die Datenaustausch und Zugänge zu Kundendaten besser möglich machen soll, und nun mit FiDA auch Versicherungen mit einbezieht. Die Verordnung soll auf die Förderung eines datengesteuerten Finanzwesens abzielen (vgl. FiDA S.01) und bezieht sich auf alle Kundendaten. Damit unterscheidet sich die Anforderung durch FiDA zu der wie sie die DSGVO in Art. 20 (2) beschreibt. Danach hat eine natürliche Person das Recht auf Datenübertragbarkeit gemäß Art. 20 (1) DSGVO, nach dem ihre personenbezogenen Daten direkt von einem Verantwortlichen einem dritten Verantwortlichen übermittelt werden müssen, soweit dies technisch machbar ist. FiDA hingegen verschärft bzw. erweitert die DSGVO in folgenden Punkten: Die Daten müssen digital weitergegeben werden und auch Daten juristischer Personen sind miteingeschlossen, wodurch auch Unternehmensdaten in Form der Kundendaten mit einbezogen werden.

Die konkreten Forderungen von FiDA lassen sich dabei zu zwei wesentlichen Punkten zusammenfassen: Zum einen fordert sie die Transparenz über die bereitgestellten Kundendaten mit den gegebenen Einwilligungen zur Datenübertragung an Dritte in Form eines Dashboards, das der Kunde jederzeit einsehen kann, zum anderen verpflichtet sie Versicherungen die gewünschten Kundendaten in einem standardisierten Format zur Verfügung zu stellen. Um diesen Forderungen gerecht zu werden ist – neben der reinen Umsetzung der genannten Anforderungen – ein Zugriff auf aktuelle und korrekte Kundendaten notwendig, um sicherstellen zu können, dass die richtigen Kundendaten weitergegeben werden. Somit ist selbst vor dem Hintergrund, dass nach Inkrafttreten der Verordnung volle 24 Monate Zeit zur Implementierung gegeben werden soll, eine frühzeitige Beschäftigung mit der Thematik notwendig. Denn so kann auf ein gesamthaft sinnvolles Zielbild hingearbeitet werden und bei anfallenden Aufwendungen für die Umsetzung von FiDA die Nutzung entsprechender Synergien zu ermöglichen. Denn über die reine Erfüllung der regulatorischen Forderung hinaus kann FiDA ebenso zum Zwecke der Ertragssteigerung genutzt werden. Bestandskunden können bspw. gefragt werden, ob die Daten ihrer anderen Versicherungen eingeholt werden dürfen, um so optimierte Angebote zu erstellen. Durch FiDA wird dies möglich, ohne dass der Kunde selbst einen Aufwand hat. Auch wenn vorgesehen ist, dass durch die Nutzung der Schnittstelle Gebühren eingenommen werden dürfen, beschränkt sich diese rein auf die unmittelbar mit der Bereitstellung zusammenhängenden Kosten (vgl. Art. 10 (1) h) i)), sodass nicht davon auszugehen ist, dass sich rein aus der regulatorischen Erfüllung Erträge erwirtschaften lassen. Um den notwendigen Umbau zur Herstellung einer konsistenten Datenbasis aus wirtschaftlicher Sicht zu rechtfertigen, können Synergien zur Nutzung der Datenbasis für weitere Anwendungsfälle geschaffen werden oder wie erwähnt die Möglichkeiten zu nutzen, die sich durch Datennutzung mit FiDA ergeben.

Abbildung 1 – FiDA Überblick

Thema 2: Künstliche Intelligenz

Die Implementierung von Künstlicher Intelligenz (KI) in Versicherungsunternehmen wird häufig durch unzureichende Datenqualität erschwert. Ein Beispiel ist der Einsatz von Chatbots oder virtuellen Beratern, die dem Kunden wie ein echter Berater Einblick in seine Versicherungsdaten gewähren können sollen, um darauf basierend passende Aussagen treffen oder Kundenaufträge auslösen zu können (siehe auch unseren Blogbeitrag zu diesem Thema). Damit der Kunde solch eine Leistung nutzen kann, ist es zunächst notwendig, dass der Kunde sich entsprechend authentifiziert. Liegen vertragsbasiert nicht konsistent gehaltene Kundenstammdaten vor, ist es entweder notwendig, dass sich der Kunde für jeden einzelnen Vertrag bei der Versicherung authentifiziert, um compliancekonform zu agieren. Diese notwendigerweise separaten Authentifizierungen, führen nicht nur zu einer schlechten User Experience, sondern erschwert auch die Gesamtsicht des Produktportfolios mit entsprechenden Auskunftmöglichkeiten durch einen virtuelle Berater.

Thema 3: Analytisches und operatives CRM

Für ein analytisches CRM ist eine konsolidierte Datensicht unerlässlich, um präzise Vorhersagen über profitable Zielgruppen oder erfolgversprechende Produktabschlüsse zu treffen. Oft ist dies bei Versicherern auch bereits in Teilen erfolgt, als sich Datalakes die letzten Jahre vermehrt als Marktreife Lösung etabliert haben. Nicht nur bei Versicherern sehen wir viele Unternehmen, die dem Trend aufgesprungen waren und bei denen die IT einen Datalake als Infrastruktur bereitstellte. Viele Unternehmen hatten die Hoffnung damit eine Lösung für alle Datenprobleme gefunden zu haben. Sämtliche Daten, die im Unternehmen anfallen, werden dort gesammelt und unabhängig von der Art des Usecases kann auf diese Datenlösung zugegriffen werden. Entsprechend kommt es zum unerwünschten Lösungsmuster, dass neben analytischen Auswertungen auch für operative Zwecke auf den einen Datalake direkt zugegriffen wird. Damit ergeben sich in Folge schnell Probleme hinsichtlich unterschiedlicher Nutzungsanforderungen an Echtzeiterwartung und Datenqualität. Diese reichen von dem Laufen in Deadlocks, weil Datenbanktabellen durch analytische Auswertungen gelockt sind, während ein operativer Usecase auf eine Rückmeldung wartet, bis hin zu gegenseitigen Überschreibungen, wenn die eigentlich für analytische Zwecke bereitgestellte Infrastruktur zu einer „Source of truth“ für andere operative Systeme wird, die jedoch am Ende die Daten wieder zur analytischen Auswertung zurückspielt. Neben dieser beschriebenen Problematik aufgrund fehlender Trennung der Datenquellen, sehen wir zudem oft, dass die Komplexität der erstellten Datenlösung in ihrer Wartbarkeit sehr teuer wird. Beispielsweise, wenn aufgrund des breiten Spektrums an Daten eine hohe Komplexität der vorgehaltenen Daten vorliegt. Im Zusammenhang mit Kundenstammdaten ist daher darauf zu achten, dass diese für operatives CRM aus einer Datenquelle bezogen werden, die nicht für analytisches CRM genutzt wird.

Vorgehensmodell

Um das Potenzial von FiDA, KI und CRM voll auszuschöpfen, müssen Versicherungsunternehmen zunächst eine konsistente Sicht auf Kundendaten herstellen, sodass die operativen und analytischen Anwendungsfälle darauf aufbauen können. Zur Herstellung einer konsistenten Sicht ist es notwendig die aktuelle Systemlandschaft und Datenflüsse zu verstehen sowie ein einheitliches Verständnis über den Begriff „Kunden“ herzustellen. Da die aktuelle von Kundenstammdaten meist nicht transparent vorliegt erweist es sich aus unserer Erfahrung als sinnvoll zu Beginn mit einer Analyse des Ist-Zustands zu beginnen, wie in Abb. 2 dargestellt. Bei dieser Analyse des Ist-Zustands lassen sich direkte Handlungsfelder identifizieren und so ein individuell passendes Zielbild ableiten. Durch Transparenz des Ist-Zustands können notwendige Änderungen für mögliche Zielbilder in ihrem Aufwand eingeschätzt werden und es lassen sich Zielbildoptionen entsprechend abwägen, sodass eine möglichst Kosten-Nutzen-optimierte Lösung erarbeitet werden kann. Mit vorhandener Datenbasis könnten anschließend die verschiedenen Usecases umgesetzt werden. Diese sollten wie oben bereits erläutert in ihrer Lösung nach operativer Nutzung und analytischer Auswertung unterschieden werden – sie sind daher im Vorgehensmodell entsprechend getrennt dargestellt.

Abbildung 2 – Vorgehensmodell

Umsetzungen und Lösungen

Zur Erstellung einer konsistenten Datensicht kommen verschiedene Lösungsmuster in Frage: Grundsätzlich wäre es möglich in den Backoffice Systemen ein bestandsführendes System zu erstellen oder eines der bestehenden Systeme entsprechend zu erweitern. In Versicherungsunternehmen mit geringer Angebotsbreite ihres Produktportfolios ist dies oftmals eine geeignete Lösung und ein häufig anzutreffendes Lösungsmuster. Bei Versicherungen mit einer breiteren Sparten- und Produktpalette zeichnet es sich häufig ab, dass die bestandsführenden Systeme auf Silos verteilt sind und sich keines davon als Mastersystem für Kundenstammdaten als geeignet erweist. Oftmals fehlt es auch an einem dazu notwendigen Datenaustausch zwischen den Systemen. Bei solch einer vorliegenden Landschaft stellt ein „Operational Data Store“ (ODS) als Zwischenschicht eine geeignete technische Lösung dar, die auf den bestehenden Backend -Systemen aufsetzt. Der ODS stellt eine konsistente Datensicht er und ermöglicht durch die Abstraktion, dass die meist schwer anzupassenden Altsysteme zur Zielerreichung nicht geändert werden müssen.

Ist die konsistente Sicht auf die Kundenstammdaten hergestellt und somit Stufe 2 des Vorgehensmodells (vgl. Abb. 2) erreicht, können operative und analytische Usecases darauf aufbauen. In der technischen Lösung ist dies ebenso zu unterscheiden, sodass sich im Wesentlichen die folgenden verschiedenen technischen Lösungsbereiche ergeben:

Abbildung 3 – Lösungsbereiche

Im Bezug auf analytische Usecases, die im Kontext der Kundendaten vor allem das analytische CRM darstellen, können Datawarehouses, Datalakes, Data-Meshes und andere Datenlösungen für analytische Zwecke genutzt werden. Diese Lösungen können auf die erstellte konsistente Datenbasis zugreifen und Daten entsprechend anreichern oder auch anonymisieren, sodass historische Sichten aufgebaut werden können. Für operative Usecases kann je nach oben beschriebenem Lösungsmuster zur Erstellung der Datenbasis auf die Systeme im Backend direkt durchgegriffen werden oder über einen Data Layer eine konsistente Sicht zur Laufzeit erzeugt werden. Durch die Trennung der Lösungsbereiche zur operativen Nutzung und analytischen Auswertung wird zudem die Changefähigkeit begünstigt, da beide Bereiche unabhängig voneinander Änderungen umsetzen können. Darüber hinaus löst sich das Problem möglicher falsche Überschreibungen durch einen rein-lesenden Zugriff der analytischen Datenlösung auf bestandsführende Systeme, die beispielsweise via Events Änderungen direkt pushen können, jedoch nie ein Schreiben in die andere Richtung erfolgt.

Fazit

Zusammenfassend lässt sich feststellen, dass die Schaffung einer konsistenten Kundenstammdatenbasis für Versicherungsunternehmen von entscheidender Bedeutung ist. Eine konsistente Datenbasis verschafft nicht nur Vorteile für die Implementierung von Regulierungsanforderungen wie FiDA, sondern schafft auch die Basis für einen Einsatz von künstlicher Intelligenz und effektives Customer Relationship Management.

Ein strukturierter Ansatz zur Analyse des Ist-Zustands und zur Implementierung geeigneter Datenlösungen ermöglicht Versicherungsunternehmen eine einheitliche Sicht auf ihre Kundendaten zu entwickeln. Dabei ist es nicht zwingend notwendig Backend Systeme zu erweitern oder zu ersetzen, sondern es kann eine Datenabstraktionsschicht, beispielsweise in der Form eines „ODS“, auf die bestehenden Systeme aufgesetzt werden.