Durch ein standardisiertes Datenmodell ist eine wesentliche Voraussetzung gegeben, Data Governance im Unternehmen zu erreichen. Ein Standard-Datenmodell unterstützt Data-Governance-Prozesse z. B. dadurch, dass, wo immer möglich, Industrie-Standards verwendet werden.
- Standards zur Vertrags- und Schadensdarstellung
- Mapping von Dateninhalten mit Standard-Definitionen (Glossarfunktion)
- Verwendung von Code-Feldern anstelle von Freitexten
- Mapping von Standard- und Individual-Codes, Definition von beliebigen Code-Hierarchien
Standardisierte Modellstrukturen
Es stehen Standard-Strukturen zur Modellierung unterschiedlicher Geschäftsprozesse zur Verfügung. Z. B. eine Standard-Struktur für die Modellierung von Versicherungsvertragsinformationen nach einem vierstufigen Hierarchie-Prinzip:
- Stufe 1: Allgemeiner Vertragsteil für alle Sparten (Police)
- Stufe 2: Vertragsspezifischer Teil nach einzelnen Spartengruppen
- Stufe 3: Spartenspezifischer Teil (versicherte Personen, versicherte Objekte)
- Stufe 4: Risikospezifischer Teil (versicherte Risiken und Wagnisse, versicherte Summen)
Dadurch muss gegenüber den Versicherungs-Fachbereichen nicht argumentiert werden, warum speziell diese oder jene Struktur im DWH zum Einsatz kommt (jeder Fachbereich sieht natürlich seine eigenen Strukturen als standard-relevant, und nicht diejenigen anderer Bereiche). Siehe hierzu auch meinen Blog Vorteile eines Standarddatenmodells für Versicherungen.
Standard-Glossar
Sofern sinnvoll wird in den Modell-Metadaten ein Mapping mit Standard-Definitionen dokumentiert, z. B. für Attribute, deren Definition in einem Standard-Glossar hinterlegt sind. Dadurch ist deren Bedeutung eindeutig festgelegt.
Verwendung und Mapping von Code-Feldern
Folgendes Beispiel soll eine typische Aufgabe bei der Entwicklung eines DWH-Projektes verdeutlichen:
Zur spartenübergreifenden Datenhaltung der Policen-Informationen ist es erforderlich, eine gemeinsam genutzte Tabelle zu implementieren, die wichtige Informationen beinhaltet, die für alle Sparten einer Versicherung von Bedeutung sind. Hierzu gehören z. B. Statusinformationen, Änderungsgründe oder Zahlungsmodalitäten der Police. Jede Versicherungsgesellschaft, die sowohl Sach- als auch Lebensversicherungen im Angebotsportfolio hat, hat mindestens zwei unterschiedliche Bestandssysteme und Fachabteilungen, die historisch gewachsen sind und meist keine gemeinsamen Strukturen haben. Jede dieser Fachabteilungen hat in der Vergangenheit eigene Datenstrukturen für Auswertungen und analytische Anwendungen entwickelt. In der Regel sind dies „Operational Datastores“, die übrigens vielfach fälschlicherweise als „Data Warehouse“ bezeichnet werden. Die Policen-Informationen des Fachbereichs Sachversicherung enthalten in der Regel andere Code-Felder zur Identifikation von Informationen wie „Status“, „Änderungsgrund“ und „Zahlungsmodus“ als die des Fachbereiches Lebensversicherung. Vielfach ist es auch nicht einfach möglich, diese Codes 1:1 zuzuordnen. Die Aufgabe besteht nun darin, eine Struktur und Wertebereiche für Codes zu definieren, die für beide Fachbereich Gültigkeit haben. Folgende Anforderungen sind in Einklang zu bringen:
- Definition von allgemeingültigen Strukturen und Codes, die eine übergreifende Auswertung auf Anwendungsebene ermöglichen. Für eine Versicherungsgruppe ist dies beispielsweise eine einheitliche Konzernsicht über die einzelnen „Operational Entities“ (OE) hinweg, für unser einfaches Beispiel eines Sach-/Lebensversicherers eine einheitliche Sicht auf die Sparten Leben und Sach.
- Konsistente Zuordnung der individuellen Strukturen und Codes der einzelnen OEs auf die standardisierte Einheitsstruktur und die konzern-/unternehmensweit gültigen Standard-Codes.
- Darüber hinaus sollten die individuellen Codes der OE im Anwendungs-Datamart noch zur Verfügung stehen, damit sich die OE dort wiederfindet und Auswertungen in gewohnter Art und Weise durchführen kann.
An diesen Aufgaben sind in der Vergangenheit viele Data-Warehouse-Projekte von Versicherungen gescheitert, und einfachheitshalber wurde kein spartenübergreifendes DWH eingeführt, sondern die einzelnen Strukturen der fach-spezifischen Operational Datastores wurden im DWH Layer kopiert.
Für ein Standard-Datenmodell ist es sinnvoll, wo immer möglich standardisierte Code-Felder zu verwenden, deren Inhalte jeder Fachbereich und jede OE individuell definieren kann und die dann auf einer Metaebene mit den konzernweit gültigen Standard-Inhalten abgeglichen werden, d. h. die Inhalte der Fachabteilung gehen im DWH nicht verloren. Damit entfällt beispielsweise die Notwendigkeit, ganz zu Anfang einer DWH-Entwicklung unterschiedliche Dateninhalte der unterschiedlichen Fachbereiche miteinander abzugleichen – was eine DWH-Implementierung erheblich verzögern kann. Vielmehr kann sequenziell mit der Implementierung für die einzelnen OEs begonnen werden, der Abgleich der individuellen Dateninhalte mit übergreifenden Standard-Werten erfolgt unabhängig davon in einer Referenztabelle auf der Metaebene.
Das Erzielen von Data Governance ist deshalb wesentlich davon abhängig, dass die Geschäftsprozesse innerhalb einer Organisation konsistent abgeglichen werden. Ein standardisiertes Datenmodell ist noch keine Garantie, dass Data Governance erreicht wird, aber eine wichtige Voraussetzung dafür.
Hartmut Schroth, Business Advisor Datenstrategien für Versicherungen bei SAS Deutschland. Bitte besuchen Sie mich in LinkedIn für weitere Diskussionen zum Thema.





