Ein Versicherer sitzt auf einigen der dichtesten Daten der gesamten Wirtschaft: Jede Police, jede Prämie, jeder Schaden und jede Reserve ist ein messbarer Datensatz. Der Haken ist, dass diese Datensätze an einem Dutzend Stellen zugleich leben, und wenn der Vorstand nach der Schadenquote eines Produkts fragt, kommt die Antwort aus einer Tabelle, die jemand drei Tage lang von Hand zusammennäht. Der wirkliche Vorsprung liegt nicht darin, die Daten zu besitzen, sondern darin, sie schneller in Analytik und Berichte zu verwandeln als Ihre Wettbewerber und Ihre Aufsicht.
Aus unserer Erfahrung ist der Engpass selten die Idee für ein Dashboard. Es fehlen meist Menschen, die Policenkern, Schadensystem und aktuarielle Daten zu einem stimmigen Modell verbinden und es über Jahre am Leben halten. Deshalb arbeiten wir bei Daten und BI für Versicherer über Kompetenz: Wir verstärken Ihr Team mit Data Engineers, BI-Spezialisten und Warehouse-Architekten aus der RITS Group, statt Sie eine Analytikabteilung von null aufbauen zu lassen.
Warum sind die Daten eines Versicherers so verstreut?
Die Zersplitterung kommt nicht aus schlechten Absichten, sondern aus der Geschichte. Ein Versicherer betreibt meist getrennte Systeme für Vertrieb, Bestandsverwaltung, Schadenbearbeitung und Buchhaltung, und jedes davon ist in einem anderen Jahrzehnt und einer anderen Technologie entstanden. Dazu kommen Partnerkanäle, Mehrfachagenturen, Marktdaten und Tabellen der Aktuare, die neben den offiziellen Datenbanken ein eigenes Leben führen.
Das Ergebnis ist immer ähnlich: Dieselbe Police sieht in drei Systemen anders aus, ein Kunde hat vier getrennte Kennungen, und das Abstimmen einer einzigen Zahl zum Monatsabschluss frisst genau die Menschen auf, die analysieren statt kopieren sollten. Deshalb legen wir, bevor wir irgendeinen Bericht bauen, ein gemeinsames Datenmodell und einen Kundenschlüssel fest - ohne das ist jedes Dashboard nur eine hübschere Version des Chaos.
Wie bauen Sie ein Warehouse für Policen- und Schadendaten?
Analytik ruht auf einem Warehouse, das Daten aus den Quellsystemen sammelt und um Geschäftsfragen herum ordnet. Wir bauen es in Schichten, damit es ohne Neuschreiben wachsen kann:
- Pipelines aus den Kernsystemen (Police, Schaden, Finanzen) im ELT-Ansatz, mit inkrementellem Laden und Latenzprüfungen,
- eine Roh- und eine bereinigte Schicht, in der wir Deduplizierung, Änderungshistorie und Konsistenz der Schlüsselverzeichnisse durchsetzen,
- ein dimensionales Modell mit Fakten zu Police, Prämie und Schaden sowie Dimensionen für Kunde, Produkt, Zeit und Kanal,
- eine semantische Schicht, die Tabellen in Begriffe übersetzt, die ein Aktuar und ein Controller tatsächlich verstehen.
Mit diesem Aufbau kommt ein neues Produkt oder ein neuer Kanal als weiterer Satz von Dimensionen und Fakten hinzu und nicht als weiteres Silo. Wir entwerfen es so, dass es sowohl historisches Reporting als auch laufende operative Analytik trägt.
Wie berechnen Sie die Schadenquote in einer Kennzahlenschicht statt in Excel?
Die zentrale Schadenkennzahl kann fünf Definitionen haben, weil jede Abteilung sie etwas anders zählt. Deshalb lassen wir sie nicht in Tabellen, sondern verankern sie in einer Kennzahlenschicht, in der die Schadenquote eine abgestimmte Definition hat und alle aus derselben Quelle rechnen.
- wir definieren die Kennzahlen einmal, im Code (Brutto- und Netto-Schadenquote, Kostenquote, Combined Ratio),
- wir binden sie an Dimensionen, sodass sich dieselbe Schadenquote nach Produkt, Kanal, Region oder Kohorte aufteilt,
- wir halten die Konsistenz über die Zeit, damit eine Definitionsänderung die Historie nicht zerstört,
- wir stellen die Kennzahlen den BI-Werkzeugen (z. B. Power BI, Tableau, Looker) über eine Schicht bereit und nicht über Dutzende getrennter Abfragen.
So hört das Schadendashboard auf, ein monatliches Projekt zu sein, und wird zu etwas, das sich selbst aktualisiert und allen, die hineinschauen, dieselbe Zahl zeigt.
Wie berechnen Sie den Kundenwert (CLV) für einen Versicherer?
Kundenwert in der Versicherung ist mehr als die Summe der Prämien. Sie müssen Bestandsfestigkeit, Erneuerungen, die Schadenerfahrung dieses Kunden, Cross-Selling und die Betreuungskosten berücksichtigen. Wir bauen CLV-Modelle auf Warehouse-Daten, denn nur dort liegt die vollständige Historie aus Policen und Schäden beisammen.
Wir starten mit einer beschreibenden Variante auf Basis echter Kohorten und des Erneuerungsverhaltens und greifen erst dann, wo es sinnvoll ist, zu prädiktiven Modellen. CLV wird damit zu einer Dimension statt zu einer Folie: Sie segmentieren den Bestand danach, setzen Prioritäten für die Bestandsfestigkeit und beurteilen die Profitabilität der Akquisekanäle. Wir hängen dieses Modell an dieselben Dashboards, in denen die Schadenquote lebt, damit Preis- und Kundenentscheidungen auf einem Bild getroffen werden.
Wie sichern Sie regulatorisches und aktuarielles Reporting ab?
Berichte für die Aufsicht und für die aktuarielle Funktion folgen anderen Regeln als ein Vertriebsdashboard: Es zählt nicht Eleganz, sondern Datenqualität und Prüfbarkeit. Hier ist kein Platz für eine Zahl, die Sie nicht aus dem Quellsystem herleiten können.
Deshalb behandeln wir den Datenweg in der Reporting-Schicht wie eine Buchung. Jeder Wert lässt sich vom Bericht bis zum Datensatz im Kernsystem zurückverfolgen, Änderungen an der Logik sind versioniert, und Datenqualitätsregeln laufen automatisch und stoppen die Beladung, wenn etwas nicht stimmt. Wir bereiten Daten für Anforderungen wie Solvency II und das aufsichtsrechtliche Reporting auf und sorgen dafür, dass derselbe Zahlensatz den Aufsichtsbericht und die interne Analytik speist. Dadurch arbeitet ein Aktuar auf Daten, denen er vertraut, und eine Prüfung endet nicht in der Suche danach, woher eine Zeile kam.
Wo passt die AI-Schicht in die Versicherungsanalytik?
Wir behandeln die AI-Schicht als Option auf reifen Daten, nicht als Ausgangspunkt. Sobald Warehouse und Kennzahlen funktionieren, ergänzen wir Modelle dort, wo sie wirklich Arbeit sparen oder fangen, was Regeln übersehen:
- prädiktive Modelle für Abwanderung, Schadenerfahrung oder Erneuerungsneigung,
- Anomalieerkennung im Schaden als Unterstützung für Anti-Fraud-Teams,
- GenAI und RAG über Policen- und Schadendokumentation, um schneller an den Inhalt von Verträgen und Bedingungen zu kommen.
Unsere AI- und Datenkompetenzen in der RITS Group sind real (darunter unsere AI-, LLM- und Datenteams; wir haben GenAI-, RAG- und LLM-Projekte geliefert). Wir sind dabei auch ehrlich: Wir haben keine AI-Einführung bei einem konkreten Versicherer, wir sprechen also über die Kompetenz, die wir mitbringen, und nicht über eine fertige Referenz.
Welche Kompetenzen stellen wir für ein Datenprojekt in der Versicherung?
Wir schneiden das Team auf die Phase zu, in der Sie stehen, nicht „für alle Fälle”. Meistens besetzen wir die Rollen, die ein Analytikprojekt wirklich voranbringen:
- einen Data-/Warehouse-Architekten, der Modell und Schichten entwirft,
- Data Engineers, die die Pipelines aus den Kernsystemen bauen und die Datenqualität hochhalten,
- BI-Spezialisten, die Kennzahlenschicht und Dashboards zusammensetzen,
- Analysten und aktuarielle Unterstützung auf der Modellierungs- und Reportingseite.
Wir hängen ein solches Team in Ihre Prozesse, Werkzeuge und Ihren Kalender ein, unter Ihrer Führung oder als dediziertes Team. Die Unterschiede zwischen diesen Varianten haben wir in unserem Artikel zu IT-Kooperationsmodellen dargelegt.
Wie machen wir das bei RITS?
Wir arbeiten als Nearshore-Partner aus Polen, der Data Engineering mit dem Verständnis dafür verbindet, was Versicherung tatsächlich bedeutet. Wir stützen uns auf die Kompetenzen der RITS Group in Big Data und Analytik (darunter unsere AI-, LLM- und Datenteams) und auf Erfahrung im Bau von Software für anspruchsvolle, regulierte Branchen.
In der Praxis beginnen wir mit einem Bild der Daten, die Sie haben, entwerfen Warehouse und Kennzahlenschicht und lassen beides dann iterativ gemeinsam mit Ihrem Team wachsen. Wir prüfen die Kompetenzen vor dem Start und skalieren das Team im Rhythmus des Projekts, von der Verstärkung einzelner Rollen bis zu einem dedizierten Team. Meistens machen wir das als Individualsoftware, gebaut von unserem Team, und wo eine konkrete Kompetenz fehlt, als Team-Verstärkung.
Wo beginnen Sie mit Versicherungsanalytik?
Beginnen Sie bei einer Entscheidung, die heute zu langsam fällt (etwa Produktprofitabilität oder Abwanderung im Bestand) und bei der Frage, welche Daten sie bräuchte, um sich selbst zu berechnen. Das definiert den Warehouse-Umfang, die ersten Kennzahlen und die Rollen, die Sie brauchen, bevor Sie das Ganze bauen. Statt eines Zweijahresprogramms starten wir einen schmalen, funktionierenden Schnitt und erweitern ihn um weitere Produkte und Kennzahlen.
Sie wollen Policen- und Schadendaten in Analytik und Berichte verwandeln, die sich selbst berechnen? Sprechen wir darüber - wir stellen Team und Architektur passend zu Ihrem Bestand zusammen.