1. Einleitung
Seit mehreren Jahren hält der neue Rechnungslegungsstandard IFRS17/9 die Versicherungsbranche auf Trab. Komplexe Anforderungen, sich verschiebende Zeitpläne und Moving Targets verursachen diverse Probleme bei der termingerechten Umsetzung des Standards. Zudem führt die internationale Zusammenarbeit einzelner Legal Entities oftmals zu weiteren Schwierigkeiten. Im Zusammenhang mit solch umfangreichen Projekten und dem Bedarf viele Systeme in ein einziges System zu integrieren, spielt Datenintegration eine zentrale Rolle. Neben den fachlichen Herausforderungen gibt es zahlreiche technische Fallstricke bei der nahtlosen Integration vieler Systeme in ein einheitliches Modell.
Know-How bezüglich Data Warehousing und Datenintegration helfen dabei den Projekterfolg zu gewährleisten. Der folgende Artikel beschreibt einerseits die Chancen durch sinnvoll eingesetzte Datenintegration in IFRS17, Risiken, welche minimiert werden sollten, und zeigt dadurch auch für weitere länderübergreifenden Grossprojekte einen sinnvollen Weg für die Umsetzung auf.
2. Zentrale Integration und Dezentrale Logik
Betrachtet man ein durchschnittliches Versicherungsunternehmen, so findet man häufig eine sehr heterogene Systemlandschaft vor. Die verschiedenen Branchen (Leben, Nicht Leben, Kollektivleben…) sowie die verschiedenen Legal Entities operieren oft sehr unterschiedliche und weisen wenig Gemeinsamkeiten auf technischer Ebene auf.
Beispielsweise sieht ein Unternehmen wie folgt aus:
Die IT Systeme sind historisch gewachsen und oftmals nicht in bestehende Systeme migriert worden. Somit gibt es meist eine Vielzahl Jahresabschluss relevanter Systeme, die für IFRS17/9 mit neuen Anforderungen zusammengebracht werden müssen.
Datenintegration bietet an dieser Stelle eine grosse Chance, birgt allerdings auch ein gewisses Risiko.
Die Möglichkeiten Systeme für den Jahresabschluss zusammenzubringen sind vielzählig. Jede Variante hat sowohl Vorteile als auch Nachteile.
Ein Ansatz, der die Vorteile maximiert und die Nachteile minimiert, ist eine zentrale Datenintegration mit dezentraler Business Logik.
2.1 Zentrale vs. Dezentrale Integration
Geht man davon aus, dass alle relevanten Daten in letzter Konsequenz in ein zentrales Nebenbuch überführt werden müssen, gibt es zwei Arten dieses Ziel zu erreichen.
Bei der Dezentralen Integration ist jedes Quellsystem dafür verantwortlich die Daten in einem definierten Format an das Nebenbuch (und alle Zwischensysteme, welche die gleichen oder ähnlichen Daten benötigen) zu überführen.
Das System sieht dann wie folgt aus:
Die Abbildung zeigt, dass es viele Punkt zu Punkt Verbindungen gibt, die alle jeweils sowohl die Logik der Quelle als auch des Ziels beinhalten. Diese Darstellung bezogen auf mehrere Legal Entities, die in die Gruppen Systeme liefern, zeigt die Problematik einer dezentralen Integration auf. Um Punkt zu Punkt Verbindungen zwischen Systemen zu vermeiden und die Komplexität zu verringern, bietet sich eine Zentrale Datenintegration an.
Die zentrale Datenintegration verringert die Komplexität und bietet zugleich den Vorteil, zentrale Logiken nur einmal statt mehrfach dezentral umzusetzen.
Zusätzlich zum unmittelbaren Nutzen für das konkrete Projekt bietet dieser Ansatz auch nachhaltige Vorteile für Folgeprojekte. Dadurch, dass ein System nur einmal an die zentrale Datendrehscheibe angebunden wird, kann diese Verbindung auch für andere eingehende oder ausgehende Anforderungen in einem anderen Kontext wiederverwendet werden. IFRS17/9 und die fachliche Komplexität bringt aber genau an dieser Stelle auch ein Risiko mit sich. Der Ansatz der zentralen Integration verleitet all zu leicht, auch die fachliche Logik zentral umzusetzen.
2.2 Zentrale vs. Dezentrale Logik
Auch wenn Systeme über einen zentralen Knotenpunkt geleitet werden, der Punkt zu Punkt Verbindungen aufhebt und zentrale Logik implementiert, so ist es wichtig, bei komplexen Projekten wie IFRS17/9 nicht die gesamte Logik in der zentralen Schicht abzubilden.
Jegliche Logik, die zum Quellsystem gehört, sollte auch dort abgebildet werden. Z.B. können die einzelnen Informationsobjekte (Verträge, Schäden, Prämien…) in jedem Quellsystem gebildet werden, da auch dort die Experten für die jeweiligen Daten sitzen.
Folgende Logiken bieten sich für die zentrale Umsetzung an:
- Erstellen von globalen IDs
- Nachschlagen von zentralen Stammdaten, welche den Quellsystemen nicht bekannt sind
- Befüllen von technischen Spalten mit Konstanten für z.B. das Nebenbuch
- Ableiten spezieller zusätzlicher Lieferformate aus einer einheitlichen Lieferung, z.B. Portfolio Zuweisung aus Verträgen, da Portfolien z.B. globale Stammdaten sind, welche einem Quellsystem nicht bekannt sind, und die Quellsysteme bereits Verträge anliefern
Die Architektur sieht in diesem Fall wie folgt aus:
Jedes System bzw. jede Abteilung übernimmt in dieser Architektur die Aufgaben die am ehesten ihrer Expertise entspricht.
3. Rahmenbedingungen und Vorbereitungen
Neben den technischen Fragen der Beladung ist es sehr wichtig sich frühzeitig über weitere Themen Gedanken zu machen, die im Verlauf des Projektes zu signifikantem Mehraufwand führen könnten.
Beispiele hierfür sind:
- Target Operating Model und Scheduling
- Monitoring, Error Handling und Reconciliation
- Testing und Umgebungen
- Mandantenfähigkeit
- Manuelle Prozesse
- Namenskonventionen und Datenmodelle
All diese Punkte sind Teil einer soliden Projektplanung und generell selbsterklärend. Die Erfahrung zeigt jedoch, dass sie häufig vergessen werden, was später zu mehr Aufwand, Kosten und weniger Zeit und Flexibilität führt.
3.1 Target Operating Model und Scheduling
Um frühzeitig zu wissen, welche Informationen zu welchem Zeitpunkt an welcher Stelle vorhanden sein müssen bzw. überhaupt vorhanden sein können, ist es wichtig frühzeitig zu beschreiben, welches System welche Informationen liefert und welches System welche Informationen benötigt, um liefern zu können.
Der Fokus hierbei liegt im ersten Schritt auf genereller Machbarkeit sowie Verhindern von Kreisbeziehungen oder Ähnlichem. Ziel ist es nicht vorab alles genau zu beschreiben, sondern ein Verständnis für die späteren Abläufe und das Scheduling zu erlangen.
Projekte in dieser Größenordnung erstrecken sich über viele Geschäftsprozesse, die möglicherweise erweitert oder angepasst werden müssen. Daher ist ein Verständnis über vorliegende und benötigte Prozesse essentiell für einen reibungslosen Projektfortschritt.
3.2 Monitoring, Error Handling und Reconciliation
Bevor Datenmodelle und Ladeprozesse gebaut werden, sollten die Anforderungen an diese drei Punkte geklärt werden. Sollte dies nicht der Fall sein kann es später Probleme damit geben, alle Anforderungen abdecken zu können. Beispielsweise werden evtl. nicht alle Informationen über alle Schichten gesendet, was zu einem Unterbruch der Reconciliation führt.
Wenn Prozesse im Nachhinein angepasst werden müssen, ist das aufwändig und führt in letzter Konsequenz evtl. zu sehr pragmatischen «gebastelten» Lösungen.
3.3 Testing und Umgebungen
Die Arten der Tests und die dafür geplanten Umgebungen sollten so früh wie möglich festgelegt werden.
z.B. Unittest -> Entwicklungsumgebung; Integrationstest -> Integrationsumgebung, Simulationen -> Pre Prod Umgebung, Produktion -> Produktionsumgebung
In diesem Szenario führt es zu einem späteren Zeitpunkt zu Problemen und erhöhtem Aufwand, wenn z.B. Simulationen nicht geplant waren aber plötzlich gemacht werden sollen, die dafür notwendige Umgebung aber nicht existiert.
Bei einem Projekt dieser Größenordnung ist es besonders wichtig, ein standardisiertes Vorgehen für das Testing inkl. genauen Regeln zur Testdurchführung und Dokumentation zu erstellen, damit Tests die von verschiedenen Personen durchgeführt werden, dennoch vergleichbar sind.
3.4 Mandantenfähigkeit
Auch wenn es keine Anforderung ist, ist es durchaus ein guter Ansatz eine simple Mandantenfähigkeit in alle Prozesse und Tabellen zu implementieren. Vor allem in großen Projekten, wo beispielsweise über Themen wie den vorherigen Punkt keine Aussagen gemacht werden, ist es besonders wichtig. Über eine Mandantenfähigkeit ist es zu einem späteren Zeitpunkt beispielsweise möglich, eine «virtuelle» Pre Produktionsumgebung auf der Integrationsumgebung aufzubauen, ohne die vorhandene Integrationsumgebung inkl. den Integrationstests zu blockieren. Im Nachhinein ist es ein aufwändiges Unterfangen Mandantenfähigkeit einzubauen. So können darüber nicht nur tatsächliche Mandanten abgebildet werden, sondern auch diverse Lade- und Testszenarien.
3.5 Manuelle Prozesse
Ein besonderes Augenmerk sollte auch auf manuelle Prozesse und Anlieferungen gelegt werden. Da sich hinter manuellen Prozessen oft Excel Anwendungen oder ähnliches verbergen, ist es wichtig diese frühzeitig zu beschreiben und klar definierte Regeln und Vorgehensweisen zu etablieren. Automatisierte Schnittstellen müssen aus der Natur der Sache über solche Regeln und Vorgehensweisen verfügen. Bei manuellen Prozessen kann es hier zu einem späteren Zeitpunkt im Projekt zu Problemen führen, vor allem wenn die Zeit knapp ist und diverse Formate über diverse Wege (FTP, Mail, File Share…) bereitgestellt werden. Ein frühes Bewusstsein über die damit verbundenen Schwierigkeiten kann später Zeit und Geld sparen.
3.6 Namenskonventionen und Datenmodelle
Ein Teil der klaren Strukturierung stellen Datenmodelle und Namenskonventionen dar. In Projekten wo viele Systeme miteinander verknüpft werden und unterschiedliche Datenmodelle benötigt werden bringt der Einsatz von Business Glossaren und Data Catalog Software entscheidende Vorteile.
Dasselbe kann auch mit Excel in Kombination mit SharePoint/Confluence usw. erreicht werden, allerdings ist die Verwaltung der Dokumente und die Wahrung von Konventionen wesentlich schwieriger und nicht nachhaltig.
Ein Business Glossar und die Ablage von Datenmodellen in zentraler wieder verwendbarer Form beschleunigen somit das Projekt und liefern zusätzlich nachhaltige wieder verwendbare Ergebnisse.
4. Best Practice und Adaptierbarkeit
Der Ansatz eine zentrale Datendrehscheibe im Unternehmen einzuführen ist nicht neu, zeigt aber bei länderübergreifenden Grossprojekten besondere Wirksamkeit, wenn gewisse Methoden beachtet werden.
Grossprojekte wie IFRS17/9 Projekte sollten immer die Themen Komplexität und Prozesse im Allgemeinen beachten. Unter Komplexität fällt in diesem Fall sowohl die Entwicklungskomplexität also auch die Prozesskomplexität sowie die zukünftige Betriebs- und Wartungskomplexität.
Jeder einzelne Schritt in einem End-to-End Prozess sollte daher so viel wie nötig aber so wenig wie möglich Komplexität aufweisen. Dasselbe gilt für den Prozess an sich.
Der folgende Prozess zeigt, dass jedes System gewisse Daten aufbereitet und zur Verfügung stellt. Unter Beachtung der Tatsache, dass es von jedem genannten Systemtyp mehrere Systeme über mehrere Länder geben kann, ist klar ersichtlich, dass die Komplexität bereits durch die realen Gegebenheiten nicht zu unterschätzen ist und somit auf keinen Fall durch schlechte Architektur erhöht werden sollte.
Jedes System und jede Abteilung sollten genau die Aufgaben erfüllen, auf die es/sie spezialisiert ist. Quellsysteme kennen ihre Daten und wissen, wie sie diese extrahieren und umwandeln. Buchhaltungssysteme und Abteilungen wissen, wie sie die Abschlussbuchhaltung mit validen Daten erstellen. Datenintegrationssysteme sind dafür gemacht viele Daten in eine einheitliche Form zu bringen und gleichartige Anreicherungen auf gleichartige Daten zu machen.
Aus Perspektive der Datenintegration ist somit klar, dass keine fachliche Aufbereitung der Daten erfolgen sollte. Das Ziel ist es, einen Single Point of Truth zu erstellen. Sprich: alle Daten werden auf die exakt gleiche Art angereichert. Technisch gesehen eignen sich an dieser Stelle folgende Aktionen:
- Zentrales Monitoring
- Zentrales Error Handling
- Zentrale Reconciliation
Um diese Art der Verarbeitung zu gewährleisten, müssen standardisierte Schnittstellen entworfen werden. Z.B. ist ein IFRS17/9 Vertragsobjekt so zu gestalten, dass es von allen Quellen befüllt werden kann. Dasselbe gilt für Schäden Prämien usw.. Die Integrationsschicht muss mit den notwendigen Stammdaten angereichert werden. Da die Integrationsschicht normalerweise in der IT Abteilung angesiedelt ist, sollte folgende klare Prämisse gelten: Keine Business Logik in der Integrationsschicht!
Wenn darauf geachtet wird und diese Regel nur in absoluten Ausnahmefällen gebrochen wird, besteht die Chance ein konzernweites Verständnis für den Austausch von Daten zu schaffen und gleichzeitig die Komplexität so gering wie möglich zu halten. Die Einführung von standardisierten Schnittstellen und dieser Art von Architektur könnte allerdings auf Widerstand bei einzelnen Verantwortlichen treffen und benötigt somit die Unterstützung des Managements.
Einmal eingeführt, kann dieses Vorgehen jedoch auch für andere Projekte adaptiert werden. Egal ob der Aufbau neuer Warehouse Schichten oder die Abwicklung von anderen Anforderungen. Der Ansatz zentral zu integrieren und dezentral aufzubereiten kann, sobald ein gemeinsames Verständnis über die Vorteile dieses Ansatzes besteht, zukünftige Entwicklungsvorhaben beschleunigen sowie nachhaltiger gestalten.
Als Beispiel könnte die Entwicklung eines übergreifenden Firmen Datenmodells und die Anlieferung von Objekten in der vorgegebenen Form die Erstellung eines unternehmensweiten Warehouses beschleunigen und zukünftig wartbarer machen.
5. Fazit
Auch wenn das Thema IFRS17/9 derzeit vielen Versicherungen sehr viel abverlangt, so bringt es dennoch grosse Chancen mit sich. Kaum ein Projekt in einem Unternehmen wird so hohe Managementattention haben. Und somit ist es ideal, um die Grundsteine für allgemeine Verbesserungen und solide Umsetzungen zu legen. Ein Projekt, das so viele Stellen in einem Unternehmen erreicht, ermöglicht es ein gemeinsames Vorgehen für zukünftige Projekte zu etablieren. Aus Sicht der Datenintegration ist IFRS17/9 die perfekte Gelegenheit, um eine zentrale Datendrehscheibe einzuführen bzw. eine vorhandene zu stärken.
Technisch gesehen eignen sich für dieses Szenario konventionelle ETL Tools, da diese Systeme dafür ausgelegt sind grosse Datenmengen zu verarbeiten, zu vereinheitlichen und weiterzuleiten. Monats‑, Quartals- und Jahresabschlüsse sind zudem keine zeitkritischen Anforderungen, welche moderne Ansätze wie Streaming erfordern würden. Alles im Bereich von Micro Batching bis normalen Batch Verfahren sollte hier ausreichend sein.
Da die Umsetzung und die Vorbereitung solcher Massnahmen aufwändig und kompliziert sind, lohnt es sich auf einen Partner zu setzen, der einem hierbei zur Seite steht. Datenintegration für IFRS17/9 und Data Warehousing verfolgen sehr ähnliche Methoden und Ansätze. Somit eignen sich Partner im Warehouse Bereich für die Unterstützung bei Projekten wie IFRS17/9.
