Zentrales Framework zur Bewertung von Bestandsänderungen Christian Wolder Continentale Versicherungsverbund a.g.
Topics Der Continentale Versicherungsverbund Änderungen auf Versicherungsbeständen Ausgangslage Ziel des zentralen Frameworks Herausforderungen Lösungen Status Quo Bewertung und Aussicht
Der Continentale Versicherungsverbund Bietet für Privatkunden sowie kleinere und mittlere Unternehmen Versicherungsschutz aus einer Hand
Der Continentale Versicherungsverbund Der Verbund besteht aus folgenden Unternehmen: Continentale Krankenversicherung a.g. in Dortmund gegr. 1926 als Volkswohl Krankenunterstützungskasse Continentale Lebensversicherung AG in München gegr. 1892 als Münchener Pensionsverein Continentale Sachversicherung AG in Dortmund gegr. 1960 als Continentale Allgemeine Europa Lebensversicherung AG in Köln Europa Versicherung AG in Köln Mannheimer Versicherungen in Mannheim
Der Continentale Versicherungsverbund Innendienst rund 3.600 Mitarbeiter im Innendienst rund 1.400 Mitarbeiter in Dortmund Rund 250 Mitarbeiter in der IT Außendienst rund 1.100 selbstständige Continentale-Agenturen rund 300 Agenturen der Mannheimer
Der Continentale Versicherungsverbund Kennzahlen 3,3 Mrd. Euro Beitragseinnahmen ca. 4,4 Mio Verträge (ohne Mannheimer Versicherung) mehr als 6 Mio. Risiken
Änderungen auf Versicherungsbeständen Es geht um eine Bewertung von Änderungen: Welche Änderungen haben sich ergeben und wie haben sich die Kennzahlen (insb. der Beitrag) dabei geändert?
Beispiele für Bestandsänderungen Neuzugang eines Vertrages (Neupolicierung) Kündigung eines Vertrages Weitere(s) Person/Risiko/Absicherung in einem Vertrag Wegfall eine(r/s) Person/Risiko/Absicherung Summenanpassung Aber es geht dabei auch um die Bewertung der Änderung: Beispiel: Hat eine Summenanpassung zu einem Mehr- oder Minderbeitrag geführt? Und das wiederum auf das versicherte Risiko und den Vertrag bezogen.
Änderungen auf Baumstrukturen In allen Systemen ähnliche Baumstruktur Vertrag Risiko/VP Absicherung/Tarif n Vertrag Tarif Risiko Tarif Risiko Tarif Nachlässe Zusätzlich noch ergänzende Objekte in einer 1-zu-n-Relation z.b.: Zuschläge Nachlässe Risiko Tarif Tarif Risiko Tarif n Zuschläge
BAT Änderungen auf bitemporalen Daten Die Datenhaltung ist bitemporal BAT Bearbeitungstermin WIT Wirksamkeitstermin 1.1. 1.2. 1.3. WIT 1.1. 1.2. Am 1.1. zum 1.1. Am 1.1. zum 1.3. Am 1.2. zum 1.2.
BAT Bewegungen Vor- und Korrekturbuchung Korrektur der nicht mehr gültigen Änderungen durch zurückbuchen : 1.1. 1.2. 1.3. WIT 1.1. 1.2. Am 1.1. zum 1.1.: + Am 1.1. zum 1.3.: + Am 1.2. zum 1.3.: - Am 1.2. zum 1.2.: +
Ausgangslage Wie wurden die Bestandsänderungen vor dem zentralen Framework analysiert und bewertet? Und warum wollte man das ändern?
Ausgangslage - Systemlandschaft OperativeSysteme MOLAP Cubes UDS RDBMS Propr. Systeme
Ausgangslage Pro Sparte eine verantwortliche IT-Gruppe teilweise mehrere Systeme pro Versicherungssparte unterschiedliche Historienlösungen in den Systemen mit unterschiedlichen Zugriffsmodulen Zugriffe über unterschiedliche Programmiersprachen (Cobol, Java, Assembler) Heterogene Datenbanklandschaft (UDS, RDBMS, propr. Systeme auf ISAM-Basis) Bewertung der Änderungen gemäß Vorgabe durch eine Fachabteilung teilweise werden die Änderungen schon vorbewertet im System abgelegt Anlieferung der Bewertungen gemäß Schnittstelle an die Datamarts
Ausgangslage - Bewertung sehr viele Ansprechpartner für die Fachabteilung unterschiedliche Abstimmungsprozesse hoher Abstimmungsaufwand bei spartenübergreifenden Änderungen unterschiedliche Dokumentation, sowohl die Struktur als auch die Qualität betreffend sehr unterschiedliche Qualität der Bewertung Situation für die Fachabteilung schlecht messbar
Ausgangslage Entstehung des ODS 2004 begann der Verbund mit der Schaffung einer Kopie der operativen Bestände in einer Oracle-Datenbank Ziele hierfür: Generierung aller dispositiven Daten aus diesem Topf Zentralisierung der Verantwortung für diese Daten Leichtere Auswertbarkeit spartenübergreifend Lastreduzierung auf dem Großrechner Kürzere Abstimmungsprozesse zwischen Fachabteilung und IT
Ausgangslage ODS oder DWH? ODS in Anführungszeichen? Abweichung von der klassischen Sicht: Normierung der zweidimensionalen temporalen Datenhaltung Damit Normierung des Historienzugriffs auf die Daten Normierung der Begriffe Ruhe und Storno für alle Objekte Normierung der vorbewerteten Bewegungen Das ODS der Continentale ist nicht flüchtig Ansonsten handelt es sich um eine klassische Kopie. Je nach Definition kann man auch von einem DWH sprechen. DeFacto ist es ein Teil des Datawarehouse des Verbundes
Ausgangslage ODS UDS RDBMS ODS Oracle 11.2 Bestandsänderungen??? Propr. Systeme
Ziele des Frameworks Vereinheitlichung über die Systeme hinweg Normierung der Analyse- und Bewertungsqualität Durchgängige einheitliche Dokumentation
Ziele des Frameworks Ein anpassungsfähiges Framework für alle Sparten Dadurch Normierung des Bewertungsprozesses Bessere Bewertungsqualität Einheitliche Dokumentation Neue Qualität durch nachträgliche Bewertung von Bewegungskonstellationen Möglichst Nutzung von vorhandenen Techniken
Herausforderungen für ein zentrales Framework
Herausforderungen für ein zentrales Framework Weiterhin heterogene Daten (Baumstruktur mit Hauptpfaden ist aber definierbar) Datenqualität des ODS (Kopie ohne Data Cleaning) Was analysiert man? Den ganzen Baum oder erst Teile des Baumes mit anschließender Nachinterpretation? Wie und welche Analysephasen kann und sollte man definieren? Gibt es Frameworks/Tools am Markt? Oder ist eine proprietäre Lösung besser? Womit implementieren? Wie bekommt man eine Sicht auf die Daten (Integration Historienlogik, Beschreibung der Datenstruktur, vorbewertete Bewegungen)
Herausforderungen: Abbildung eines Vertragsbaumes zu BAT/WIT Logische Zusammenführung von Objekten zu einem fachlichen Keine Struktur aus Referenzen Vertrag ableitbar -> Beschreiben! Tab1 Tab2 Tab3 1 2 Bereits bewertete Bewegungen 3 zu BAT/WIT abbilden 1 2 3 Risiko 1 2 Tarif
Herausforderungen: Wie bewerten? z.b. Vertragsverlängerung Vertrag Vertrag z.b. Versicherungssumme Risiko 1 Risiko 2 Risiko 1 Risiko 2 Tarif 1_1 100 Tarif 2_1 100 Tarif 2_2 10 Tarif 1_1 130 Tarif 1_2 20 Tarif 2_1 100 z.b. zusätzliche Gefahren
Herausforderungen: Wie bewerten? Änderungen vererben sich von oben nach unten Änderungen haben verschiedene Prioritäten Für jede Änderung muss ein Zwischenzustand mit den dazu geänderten Kennzahlen geschaffen werden.
Herausforderungen: Finden eines Frameworks Auf Grund der recht spezifischen Anforderungen konnte kein geeignetes Tool gefunden werden. Deshalb: Implementierung eines eigenen Frameworks Auf Grund der im Haus vorhandenen Kenntnisse fiel die Wahl auf eine Implementierung in Java. Pl/Sql als Alternative fiel auf Grund der im Haus nicht vorhandenen Kenntnisse aus.
Unsere Lösung für ein zentrales Framework
Lösung: Einteilung in 6 Module 1. Ermittlung der BAT/Wit/VersNr-Stände für Vor- und Korrekturbuchung und Aufbau der Bäume 2. Anreicherung der Bäume mit transienten Felder 3. Bewertung von Übergängen zwischen Pfaden des Baumes 4. Bewertung von Konstellationen von Pfadübergängen zu BAT/WIT 5. Bewertung von Konstellationen von Pfadübergängen zu BAT 6. Formatierung der Ausgabe für das Zielsystem
Teillösung: Erstellung der Vertragsbäume Beschreibung der Datenstrukturen in XML gemäß einer XSD. Folgende Funktionalitäten: Zusammenfassen von Relationen zu einem Objekt Referenzen untereinander Festlegung der Hauptpfade (Vertrag, Risiko, Tarif) Erstellung der Objekte und Verknüpfung zu Vertragsbäumen gemäß dieser Vorgaben. Haltung der Daten in Maps Einfach aber keine Typsicherheit Alternative JPA-Lösung über Reverse Engineering in früher Alpha-Phase
Teillösung: Änderungen zwischen Pfaden Reduzierung des Bewertungsproblems auf einzelne Pfade im Baum Vertrag Vertrag Risiko 1 Risiko 2 Risiko 1 Risiko 2 Tarif 1_1 100 Tarif 2_1 Tarif 2_2 Tarif 1_1 130 Tarif 1_2 Tarif 2_1
WIT-1 Teillösung: Änderungen zwischen Pfaden Vertragsverlängerung Versicherungssumme zusätzliche Gefahren WIT Vertrag Vertrag Vertrag Vertrag Risiko 1 Risiko 1 Risiko 1 Risiko 1 Tarif 1_1 100 Tarif 1_1 100 Tarif 1_1 110 Tarif 1_1 130 - + - + - +
Teillösung: Konstellation zu BAT/WIT Bewertung der Konstellation zu Bewegungen zu BAT/WIT Entfernung von Nullbuchungen Korrektur- und Normalbuchung identisch Vererbung von Bewegungen von unten nach oben Änderung an Bewertungen z.b. Korrektur- ohne Normalbuchung Produktionswertung Versehen der Bewegung mit einem zweiten Bewegungsgrund vertragsübergreifend betrachtet
Teillösung: Konstellation zu BAT Bewertung der Konstellation zu Bewegungen zu BAT über alle WITs Hier geht es hauptsächlich um die Generierung von so genannten Infogründen: Stornoverlegung Wieder-In-Kraft-Setzung Beginnverlegung Dynamikverlegung
Status Quo
Status Quo Im Einsatz für einen Großteil unserer Sparten Die noch nicht eingesetzten Sparten sind auf Grund zufriedenstellender Datenqualität und anderer Prioritätenlage nicht umgesetzt Ein System wird ausgetauscht und ist deshalb noch nicht umgesetzt Täglich im Einsatz, die Daten stehen wie gewünscht ab 6:30Uhr zur Verfügung
Bewertung und Aussicht
Bewertung Abstimmung ab der zweiten Sparte zwischen Fachabteilung und IT von deutlich geringerem Aufwand geprägt als vorher Die Bewertungsqualität hat zugenommen und ist spartenübergreifend ähnlich Fehler können auf Grund der definierten Analysephasen besser lokalisiert werden Service durch die IT kann auch bei krankheitsbedingtem Ausfall besser geleistet werden Nebeneffekt: Qualitätsanalyse bezüglich der referentiellen Integrität zu BAT/WIT Nebeneffekt: inhaltliche bewegungsrelevante Fehler sind aufgedeckt worden Technisch gilt es noch die fehlende Typsicherheit zur Programmierzeit zu erschaffen
Danke für ihre Aufmerksamkeit! Continentale Versicherungsverbund auf Gegenseitigkeit Dipl.Inform. Christian Wolder Abteilung ik3-sta Ruhrallee 92, 44139 Dortmund Tel.: +49-231-919-2611 Email: christian.wolder@continentale.de