Q_PERIOR Audit & Risk Newsletter - REVISIONSWELT

AKTUELLESUm mit diesem Dilemma umzugehen, schlagen wir aus unserer Projekterfahrung zwei Lösungswege vor:• Eine indirekte, aber verhältnismäßig leicht umsetzbare Lösung basierend auf der zur QRT Erstellungverwendeten Software• Eine grundsätzliche und strukturelle Lösung basierend auf einem einheitlichen und zentralen Datenbestand.Die grundsätzliche Lösung des dargestellten Problems bedarf einer Vereinheitlichung des gesamten Datenbestandesidealerweise in einem unternehmensweiten Data Warehouse, in dem sämtliche Abteilungen ihreDaten zentral speichern und vorhalten. Solche Projekte sind derzeit auch bereits in unterschiedlich starkerAusprägung bei den meisten Versicherern geplant oder in der Umsetzung. Darüber hinaus wäre dann eineinheitliches Vorgehen hinsichtlich der Aktualisierungsfrequenzen, mit denen fachliche Daten aktualisiertwerden, zwischen den einzelnen Abteilungen abzustimmen.Ein solch abgestimmtes Vorgehen impliziert, dass im System stets zueinander passende Daten aller Abteilungenliegen. Infolge dessen ist dann bspw. im Notfall nur ein System wiederherzustellen und es müsstezudem aufgrund der hergestellten Synchronität der Datenaktualisierungen auch kein Bereich Datenverlusteerleiden. Ebenso würde dieses Vorgehen die Datenqualität im Allgemeinen verbessern, da mehrfache Datenhaltungausgeschlossen ist und alle Abteilungen auf einen zentralen, überprüften und korrekten gemeinsamenDatenbestand zugreifen können. Aufgrund der historisch gewachsenen in der Regel sehr großenZahl unterschiedlicher Datentöpfe und Systeme bei (Rück)-Versicherungsunternehmen ist dies aber einüberaus aufwändiges Vorgehen.Eine zweite denkbare Herangehensweise beruht auf der für das Reporting ausgewählten Software. 2 Hierbeiwürde diese Software mittels zu implementierender ETL Strecken (Extrahieren, Transformieren, Laden) 3jeweils mit genau den Daten beladen, die zur Erstellung einer bestimmten Berichtsgeneration erforderlichsind. Dies stellt zweierlei Dinge sicher. Zum einen ist damit die Synchronität der benötigten Daten gewährleistetund zum anderen werden die erforderlichen Daten zentralisiert abgelegt und können gesammeltweiterverarbeitet werden. Besitzt die verwendete Softwarelösung nun die Möglichkeit einer Historisierung,so kann man diese verwenden, um die historischen Daten abzulegen und später im Sinne von Zeitscheibeneinzelne Berichte wiederherstellen zu können.Jedoch ist dieses Vorgehen auch mit Nachteilen verbunden. Einerseits impliziert es eine doppelte Datenhaltung,da die Daten sowohl im Bestandssystem als auch in der Softwarelösung vorgehalten werden. Andererseitsbesteht damit eine erhebliche Abhängigkeit vom Softwareanbieter, dessen softwareeigenen Datenbankstrukturenund dessen Aktualisierungs- und Updatepolitik. Ändert der Softwareanbieter nämlichdie Datenbankstruktur, so müssen ggf. die dazu verwendeten Beladeskripte angepasst werden. Zudem istes im Allgemeinen unklar, inwieweit die so historisiert abgelegten Daten mit vertretbarem Aufwand in einealternative Software migrierbar wären, wenn man den Softwareanbieter wechseln möchte.Zusammenfassend lässt sich konstatieren, dass es sich bei der Ausgestaltung der Datensicherung und dendamit verbundenen Themen um ein sehr wichtiges Feld der Solvency II Umsetzung handelt, was sich imDetail und in der Praxis als erstaunlich vielschichtig und kompliziert erweisen kann. Aus diesem Grund solltenVersicherer und Rückversicherer das Thema von Beginn an intensiv verfolgen und bearbeiten sowiefrühzeitig fach- und funktionsübergreifende Dialoge zwischen den involvierten Parteien (Fachbereiche undIT als interne, Software-Anbieter, beratende Unternehmen) suchen, um so zu einer langfristig gangbarenund wertstiftenden Lösung für das Unternehmen zu gelangen.2 In der Regel wählen Versicherungs- und Rückversicherungsunternehmen eine Standardsoftware aus, die an die Bestandsystemeanzubinden ist und mit der dann die QRTs erstellt werden können.3Unter einer ETL Strecke versteht man den Prozess sowie der technischen Umsetzung, Daten aus einem System zuextrahieren, ggf. zu transformieren und ein anderes System mit diesen transformierten Daten zu beladen.Q_PERIOR Audit & Risk Newsletter – 2013 – Ausgabe 4/611