Zentrales Framework zur Bewertung von Bestandsänderungen. Christian Wolder Continentale Versicherungsverbund a.g.

Transkript

1 Zentrales Framework zur Bewertung von Bestandsänderungen Christian Wolder Continentale Versicherungsverbund a.g.

2 Topics Der Continentale Versicherungsverbund Änderungen auf Versicherungsbeständen Ausgangslage Ziel des zentralen Frameworks Herausforderungen Lösungen Status Quo Bewertung und Aussicht

3 Der Continentale Versicherungsverbund Bietet für Privatkunden sowie kleinere und mittlere Unternehmen Versicherungsschutz aus einer Hand

4 Der Continentale Versicherungsverbund Der Verbund besteht aus folgenden Unternehmen: Continentale Krankenversicherung a.g. in Dortmund gegr als Volkswohl Krankenunterstützungskasse Continentale Lebensversicherung AG in München gegr als Münchener Pensionsverein Continentale Sachversicherung AG in Dortmund gegr als Continentale Allgemeine Europa Lebensversicherung AG in Köln Europa Versicherung AG in Köln Mannheimer Versicherungen in Mannheim

5 Der Continentale Versicherungsverbund Innendienst rund Mitarbeiter im Innendienst rund Mitarbeiter in Dortmund Rund 250 Mitarbeiter in der IT Außendienst rund selbstständige Continentale-Agenturen rund 300 Agenturen der Mannheimer

6 Der Continentale Versicherungsverbund Kennzahlen 3,3 Mrd. Euro Beitragseinnahmen ca. 4,4 Mio Verträge (ohne Mannheimer Versicherung) mehr als 6 Mio. Risiken

7 Ä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?

8 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.

9 Ä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

10 BAT Änderungen auf bitemporalen Daten Die Datenhaltung ist bitemporal BAT Bearbeitungstermin WIT Wirksamkeitstermin WIT Am 1.1. zum 1.1. Am 1.1. zum 1.3. Am 1.2. zum 1.2.

11 BAT Bewegungen Vor- und Korrekturbuchung Korrektur der nicht mehr gültigen Änderungen durch zurückbuchen : WIT Am 1.1. zum 1.1.: + Am 1.1. zum 1.3.: + Am 1.2. zum 1.3.: - Am 1.2. zum 1.2.: +

12 Ausgangslage Wie wurden die Bestandsänderungen vor dem zentralen Framework analysiert und bewertet? Und warum wollte man das ändern?

13 Ausgangslage - Systemlandschaft OperativeSysteme MOLAP Cubes UDS RDBMS Propr. Systeme

14 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

15 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

16 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

17 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

18 Ausgangslage ODS UDS RDBMS ODS Oracle 11.2 Bestandsänderungen??? Propr. Systeme

19 Ziele des Frameworks Vereinheitlichung über die Systeme hinweg Normierung der Analyse- und Bewertungsqualität Durchgängige einheitliche Dokumentation

20 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

21 Herausforderungen für ein zentrales Framework

22 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)

23 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 Risiko 1 2 Tarif

24 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

25 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.

26 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.

27 Unsere Lösung für ein zentrales Framework

28 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

29 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

30 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

31 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_

32 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

33 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

34 Status Quo

35 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

36 Bewertung und Aussicht

37 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

38 Danke für ihre Aufmerksamkeit! Continentale Versicherungsverbund auf Gegenseitigkeit Dipl.Inform. Christian Wolder Abteilung ik3-sta Ruhrallee 92, Dortmund Tel.: