Migration mit Historie

Wenn ein Lebensversicherungsunternehmen ein neues Bestandsführungssystem eingeführt hat, soll in der Regel auch der Vertragsbestand in das neue (Ziel-)System überführt werden. Warum wird dann regelmäßig die Frage diskutiert, wie viel „Historie“ dabei migriert werden soll?

Der Lebenszyklus eines Vertrags

Jede Bearbeitung eines Lebensversicherungsvertrags erzeugt einen „Vertragsstand“ und weil in der Lebensversicherung alle Bearbeitungen in einer wohldefinierten Reihenfolge stattfinden, erzeugt die Menge aller plan- und außerplanmäßigen Bearbeitungen zu jedem Vertrag auch eine wohldefinierte Reihenfolge von Vertragsständen. Dies wird auch „Lebenszyklus eines Vertrags“ genannt.

Wenn eine Bearbeitung mit Wirksamkeit in der Vergangenheit durchzuführen ist, positioniert das Bestandsführungssystem auf den richtigen (historischen) Vertragsstand und der Lebenszyklus wird ab diesem Stand neu erzeugt. Fallen sehr häufig „rückwirkende“ Bearbeitungen an und liegt deren Wirksamkeit auch weit in der Vergangenheit, muss „viel Historie“ verfügbar sein, sonst wären derartige Bearbeitungen nicht durchführbar.

Standardvorgehen in der Migration

Die Migration selbst ist auch eine Bearbeitung (Vertragsübernahme). Liegt deren Wirksamkeitstermin (= MWT) in der Vergangenheit, muss der Lebenszyklus ab MWT im Zielsystem(!) neu erzeugt werden. Dabei gibt es aber ein Problem: Während die planmäßige Entwicklung eines Vertrags (im Wesentlichen die Fortschreibung der Überschussbeteiligung) durch Geschäftspläne und weitere juristische und regulatorische Festlegungen definiert und deshalb auch genauso im Zielsystem abgebildet ist, trifft dies für die vielen möglichen außerplanmäßigen Bearbeitungen zumeist nicht vollständig zu. Nicht selten sind funktionale (Un-)Vollständigkeit und Zukunfts(un)fähigkeit dieser Bearbeitungen ein Mitgrund für die Anschaffung eines neuen Systems. Dann ist es kein vernünftiges Ansinnen, diesen Zustand im Zielsystem zu reproduzieren, nur um den Lebenszyklus der Verträge im Zielsystem 1:1 wiederherstellen zu können. In der Regel liegt der MWT deshalb niemals vor der letzten technischen Vertragsänderung und selten vor dem letzten Jahrestag; die Historie ist damit nach der Migration maximal 12 Monate lang.

Voraussetzungen für eine Alternative

Wenn vorausgesetzt werden kann, dass die Vertragsstände im Quellsystem fehlerfrei sind, d. h. die (meisten) außerplanmäßigen technischen Änderungen sind mathematisch korrekt und gemäß aktuellen Verfahren abgebildet, gibt es eine realistische Chance auf die Migration einer längeren Historie. Denn im neuen Bestandsführungssystem sind alle benötigten Bearbeitungen implementiert: vollständig, mathematisch korrekt und flexibel.

Letzteres bedeutet, dass gleichartige Geschäftsvorfälle in einheitlichen Ablauf-Templates abgebildet sind, welche einen komplexen Algorithmus in modulare, wiederverwendbare Einzelschritte („Codefragmente“) zerlegen. Durch die Wiederverwendbarkeit vieler modularer Arbeitsschritte ist es sehr schnell möglich, durch einfaches „Zusammenklicken“ nicht nur das Gros der benötigten versicherungsmathematischen Algorithmen bereitzustellen, sondern auch „neue“ Bearbeitungen vorzusehen, mit denen die Geschäftsvorfälle des Quellsystems nachgestellt werden können.

Ein ordentlicher Rechenkern beherrscht ferner das Feature, mehrere Bearbeitungen zu klammern und nacheinander als Bearbeitungsliste auszuführen. Auch damit können bestimmte Geschäftsvorfälle des Quellsystems nachgebildet werden.

Eine unabdingbare Voraussetzung für die Migration einer längeren Historie ist die eindeutige Identifizierbarkeit der „nachzuziehenden“ Vertragsbearbeitungen des Quellsystems. Dies ist schwierige konzeptionelle Arbeit, denn es müssen die im Zielsystem zu modellierenden Bearbeitungslisten definiert werden und dies gegebenenfalls ausschließlich auf Basis einer Datenanalyse im Quellsystem. Es ist herauszufinden, zu welchen Veränderungen in den grundlegenden Vertragsdaten ein Geschäftsvorfall im Quellsystem geführt hat, welche Bearbeitungsliste des Zielsystems diese Vertragsänderung abbildet und welche Vorgabedaten mindestens erforderlich sind.

Nachziehen außerplanmäßiger Bearbeitungen

Es hängt von den Fähigkeiten des Zielsystems ab, ob und wie das Nachziehen außerplanmäßiger Bearbeitungen im Rahmen der Migration implementiert werden kann. Die folgenden Features sind dabei sehr hilfreich:

• Für jede Bearbeitung gibt es einen Bearbeitungsauftrag, der im Wesentlichen den „änderbaren Vertrag“ und die benötigten Steuerungsinformationen enthält.
• Es stehen „Rechenkern“-Services zur Initialisierung, Vervollständigung und Synchronisation eines jeden Bearbeitungsauftrags bereit. Damit kann die Menge der erforderlichen Vorgabedaten auf ein absolutes Minimum reduziert werden.
• Bearbeitungen können vordatiert freigegeben (= beauftragt) und dann von der planmäßigen Fortschreibung der Verträge auf der korrekten Position aufgegriffen und bestandswirksam verarbeitet werden. Die Liste der beauftragten Bearbeitungen wird am Vertrag persistiert.
• Es ist eine Softwarelösung (Migrationstool) für die revisionssichere Datentransformation auf Basis eines von Wirtschaftsprüfern zertifizierten Migrationsprozesses und mit einer zentralen Steuerung verfügbar.

Dieses Migrationstool erzeugt dann neben dem Bearbeitungsauftrag für die eigentliche Vertragsübernahme weitere rudimentäre Bearbeitungsaufträge für die nachzuziehenden Vertragsbearbeitungen, genauer, für jede Bearbeitung in einer Bearbeitungsliste.

Der Rechenkern erstellt aus diesen „Minimal-Aufträgen“ in der Bearbeitung Vertragsübernahme vollständige, synchronisierte Bearbeitungsaufträge und hinterlegt diese als beauftragte Bearbeitungen am migrierten Vertrag. Die vom Migrationstool danach durchgeführte erste Fortschreibung im Zielsystem verarbeitet diese Bearbeitungsaufträge bestandswirksam und reproduziert damit die Vertragshistorie ab MWT.

Da dieser eben beschriebene Migrationsprozess technisch in einer Transaktion erfolgt, ist ein Controlling über die gesamte nachgezogene Vertragshistorie möglich.

Flankierende Kontrollmechanismen

Jedes Migrationsvorhaben wird von einem Garantiewerte- und einem Controlling-Konzept flankiert.

Die mit dem Versicherungsnehmer vereinbarten bzw. prognostizierten garantierten Leistungswerte und -verläufe müssen bei der Migration erhalten bleiben. Deshalb werden diese Leistungsverläufe im Rahmen der Migration übernommen. Sie stehen dann auch für das Nachziehen von technischen Änderungen zur Verfügung und können für die Berechnung der anrechenbaren Werte verwendet werden.

Aufgabe des Controlling-Konzepts ist die Prüfung der korrekten Vertragsübernahme. Durch Abgleich ausgezeichneter versicherungstechnischer Größen wird kontrolliert, ob der Vertrag genauso im Zielsystem angekommen ist, wie er das Quellsystem verlassen hat, d. h. es werden (mindestens) der letzte im Quellsystem vorhandene Vertragsstand mit dem jüngsten im Zielsystem angekommenen Vertragsstand verglichen. Jede nachzuziehende Bearbeitung kann zusätzliche Kontrollwerte beisteuern, was aber voraussetzt, dass auch aus dem Quellsystem zusätzliche Vertragsstände selektiert werden müssen.

Ein Praxisbeispiel

Im Rahmen einer Migration mit MIGSuite in die Bestandsführung in|sure PSLife wurde ein 6‑stelliger Vertragsbestand mit einer Historie von 36 Monaten migriert. Die dabei nachzuziehenden Geschäftsvorfälle erforderten Bearbeitungslisten mit bis zu sechs Bearbeitungen.

Zusätzliche Kontrollmechanismen für Verträge mit nachzuziehenden Bearbeitungen waren nicht erforderlich, d. h. die Ergebnisse der nachgezogenen Bearbeitungen wurden nicht separat kontrolliert. Ein geeignetes Garantiewertekonzept wurde angewendet.

Das Verfahren war so erfolgreich, dass die nächste Tranche – etwa 1,5 Millionen Verträge – mit vollständiger Historie (inkl. Rentenübergängen) migriert wird.

Sie möchten mehr über den Praxiseinsatz unserer Migrationslösung erfahren? Dann registrieren Sie sich kostenlos für unsere Virtual Ecosphere. Dort finden Sie neben Case Studies auch einen „DeTECHtive – der in|sure Tech Talk“ zum Thema.