Bestandsmigration: Migration von Vertragsbeständen nach ReSy

Nutzung einer Migrationsschnittstelle

Zur Migration von Altbeständen in das Bestandsführungssystem ReSy empfiehlt Convista die Nutzung einer File-basierten Migrationsschnittstelle, die per Customizing an die Besonderheiten der jeweiligen Kundendistribution von ReSy angepasst wird. Über die Migrationsschnittstelle können sämtliche zu migrierenden Informationen zu einem Vertrag aus dem Altsystem nach ReSy importiert werden:

• Antragsdaten/Zugangsdaten
• Zeitscheiben (insbesondere bei Saldenverträgen)
• Vertragsstornos/Deckungsstornos
• Stornovormerkungen (mit Stornodatum in der Zukunft)
• Vertragszahlungen
• Offene Posten (z.B. Zahlungsretouren)
• Aufstockungen
• …

Die Befüllung der Migrations-Dateien mit Daten aus dem Altsystem erfolgt dabei üblicherweise durch Zuarbeiten der für die Betreuung des Altsystems zuständigen Entwickler. Bevorzugtes Dateiformat ist CSV mit jeweils separaten Dateien pro Satzart.

Zur Entlastung der oftmals knappen Mitarbeiter-Ressourcen, die das Altsystem betreuen, kann die Migrationsschnittstelle auch per Customizing an das Datenmodell des jeweiligen Altsystems angepasst werden. In diesem Fall erfolgt die Befüllung der Migrationsdateien weitestgehend in einem den Altsystem-Entwicklern vertrauten Datenformat. Komplexe Datentransformationen in das von ReSy standardmäßig erwartete Datenformat werden dann im Rahmen des Imports der Migrationsdateien ReSy-seitig durchgeführt.

Nachfolgend zwei Beispiele hierfür, die zeigen, wie komplex diesbezügliche Migrationslogiken sein können:

Die obigen Beispiele zeigen, dass durch fachliche Erweiterungen der Migrations-Logik ggfs. auch Informationen für neue Features, die im Altsystem so gar nicht zur Verfügung standen, bereitgestellt werden können.

Vor- und Nachteile einer solchen Migrationsschnittstelle

Die Nutzung einer Migrationsschnittstelle nach obigem Muster hat den Vorteil, dass die Anlage der migrierten Geschäftsobjekte (Anträge, Verträge, Zeitscheiben, Vertragszahlungen, etc.) über die Anwendung ReSy erfolgen kann. Hierdurch erhält die Anwendung ReSy die volle Kontrolle über die Befüllung der ReSy-Datenbank und kann hierzu auch bestehende Geschäftsprozess-Logiken (z. B. für die Vertragsanlage oder für einen Vertragsstorno) nutzen, um invalide Datenkonstellationen, deren Einspielung so nicht erwünscht ist, zuverlässig zu entdecken und auszusteuern.

Von Ansätzen, die ReSy-Datenbank an der Anwendung ReSy „vorbei“ zu befüllen, raten wir ausdrücklich ab. Das Risiko, dass auf diesem Wege unbemerkt invalide Datenkonstellationen nach ReSy migriert werden, ist unserer Erfahrung nach zu hoch. Folgeverarbeitungen auf den migrierten Verträgen können aufgrund solcher invalider Datenkonstellationen leicht zu unerwünschten Effekten führen, die nur durch sehr aufwändige Tests nach Migration aufgefunden und behoben werden können. Diese Einschätzung dürfte für alle modernen Bestandsführungssysteme mit entsprechend komplexem Datenmodell zutreffen.

Die Nutzung einer Migrationsschnittstelle nach obigem Muster hat sich bei den bislang durchgeführten Migrationen von Altbeständen bei existierenden ReSy-Bestandskunden bestens bewährt. Mehrere Millionen Verträge konnten ausnahmslos ohne technische Fehler migriert werden.

Ein gewisser Nachteil dieses Vorgehens ist die Performance der Migration. Für die Migration von Verträgen muss mit einer Migrationslaufzeit von ca. 20 Stunden pro eine Million Verträge gerechnet werden. Die Vorteile des Vorgehens wiegen diesen Nachteil aber unserer Einschätzung nach mehr als auf.

Umgang mit invaliden Daten

Da der Import von Verträgen nach ReSy über obige Migrationsschnittstelle bestehende Geschäftsprozess-Logik nutzt, werden die übergebenen Daten automatisch auf analoge Art und Weise validiert, wie ReSy dies bei Durchführung der jeweiligen Geschäftsprozesse für nicht migrierte Verträge tun würde. Insbesondere prüft ReSy beim Migrations-Import eines Vertrags analog zu einer Vertragsneuanlage, ob tarifliche Zugangsbeschränkungen verletzt sind, und steuert den Migrations-Import ggfs. aus. Ein Beispiel hierfür könnte eine versicherte Person sein, die eine Todesfall-Deckung erhalten hat, obwohl sie diese aufgrund ihres zu hohen Alters gar nicht hätte erhalten dürfen. Ein anderes Beispiel könnte ein hochpreisiges Fahrzeug sein, dessen Kaufpreis den gemäß Tarifbedingungen maximal versicherbaren Kaufpreis in einem Vertrag zur Kaufpreisabsicherung (GAP) übersteigt.

In der Regel wird man sich nach Erkennung und Analyse solcher Fälle im Rahmen von Probemigrationen bewusst entscheiden, die zugehörigen Prüfungen im Kontext der Migration zu deaktivieren. Wichtig dabei ist, dass die Entscheidung zur Deaktivierung von Plausibilitätsprüfungen bewusst getroffen wird: Nur nach hinreichender Verifikation oder durch Anpassungen der Kundendistribution von ReSy kann sichergestellt werden, dass die Einspielung der eigentlich invaliden Verträge keine unerwünschten Auswirkungen auf Folgeprozesse wie beispielsweise zukünftige Leistungsbearbeitungen hat.

Grundsätzlich sollte vor jeder Aufweichung von Plausibilitäten für migrierte Verträge geprüft werden, ob es nicht bessere Alternativen gäbe, wie beispielsweise eine manuelle oder maschinelle Bestandskorrektur im Altsystem vor Durchführung der Migration.

Migration von mathematischen Werten

Sofern das abzulösende Altsystem und ReSy einen gemeinsamen externen Tarifierer benutzen, können die von diesem externen Tarifierer für die Altverträge berechneten mathematischen Werte einfach mit migriert werden. Sofern ReSy seinen eigenen Tarifierer benutzt, empfehlen wir, den ReSy-Tarifierer bei der Migration von Verträgen sämtliche mathematischen Werte für diese Verträge neu berechnen zu lassen und die Ergebnisse mit den vom Tarifierer des Altsystems errechneten mathematischen Werten zu vergleichen. Bei Abweichungen, deren Ursache fehlerhafte Berechnungen im Altsystem sind, muss sodann im Einzelfall geklärt werden, wie mit diesen Abweichungen umgegangen werden soll. Eine naheliegende Idee kann sein, die Migration einfach für eine diesbezügliche Bestandskorrektur zu nutzen. Ein solches Vorgehen muss allerdings eng mit den Wirtschaftsprüfern abgestimmt werden, da diese die Korrektheit der Migration attestieren sollen.

Prüfung der Migration auf Vollständigkeit

Zum Nachweis der vollständigen Migration der bestehenden Bestände empfehlen wir eine zentrale Migrationsprüfungstabelle anzulegen, die pro Vertrag Prüfkennziffern und ausgewählte besonders relevante Informationen enthält – und zwar einmal für die aus dem Altsystem exportierten und einmal für die in das neue System importierten Verträge. Die Befüllung dieser Tabelle sollte nach vollständiger Durchführung jeder Migration/Probemigration durch zwei unabhängig von der Migrationslogik implementierte Batches erfolgen. Einer dient zur Befüllung der Tabelle mit Daten aus dem Altsystem und einer dient zur Befüllung der Tabelle mit Daten aus ReSy. Anschließend kann die Migrationstabelle durch Migrationsprüfungs-Skripte maschinell auf Abweichungen überprüft werden. Durch eine Automatisierung dieser Form der Migrationsprüfung können Migrationen/Probemigrationen nach deren Durchführung sofort maschinell hinsichtlich ihrer Vollständigkeit beurteilt werden.

Prüfung der Migration auf semantische Korrektheit

Selbst wenn eine durchgeführte Migration/Probemigration ohne technische Fehler alle Verträge migriert und bei der obigen Prüfung der Migration auf Vollständigkeit keine Abweichungen erkannt werden, ist dies noch keine Garantie dafür, dass die Verträge auch semantisch korrekt migriert worden sind. Insbesondere nach komplexen Datentransformationen genügt es nicht, alle zu migrierenden Daten aus dem Altsystem im Zielsystem ReSy „irgendwo“ wiederzufinden. Es muss auch geprüft werden, ob die migrierten Daten von ReSy wie gewünscht interpretiert werden oder ob es „semantische Missverständnisse“ gibt. Letztere können sogar Daten betreffen, die 1:1 übernommen worden sind. Nachfolgend zwei Beispiele:

Natürlich sollten solche semantischen Missverständnisse idealerweise schon bei der fachlichen Spezifikation der Migrationsschnittstelle auffallen und korrigiert werden. Die obigen Beispiele zeigen aber, dass das oftmals einfacher gesagt als getan ist. Größtmögliche Sicherheit diesbezüglich liefert nur ein sorgfältiger Regressionstest, in dem möglichst viele typische Folgebearbeitungen auf einem migrierten Vertragsbestand durchgespielt und dahingehend überprüft werden, dass diese zu den erwarteten und gewünschten Ergebnissen führen. Nachfolgend einige typische Beispiele für Folgeverarbeitungen, die in keinem Regressionstest auf einem migrierten Bestand fehlen sollten:

• Verträge, die im Altsystem zum Zeitpunkt der Migration noch aktiv sind, sollten nach deren Migration im Zielsystem ReSy problemlos storniert werden können.
• Verträge, die im Altsystem storniert worden sind, sollten nach Migration im Zielsystem ReSy problemlos wiederherstellbar sein.
• Verträge, für die im Altsystem eine Stornovormerkung zu einem Stornodatum in der Zukunft erfasst worden ist, sollten auch im Zielsystem ReSy bei Erreichung dieses Stornodatums maschinell storniert werden.
• Zahlungen, für die im Altsystem ein Zahlungsrückläufer (z.B. wegen erloschenem Zielkonto) eingegangen ist, sollten im Zielsystem ReSy nach Ermittlung und Erfassung einer  neuen Empfängerbankverbindung an diese neue Empfängerbankverbindung angewiesen werden können oder nach Ablauf einer konfigurierbaren Frist maschinell vereinnahmt werden.
• …

Insbesondere bei migrierten offenen Vertragsposten – wie Zahlungsrückläufern und Lastschriftretouren – sollte das Rechnungswesen in die Prüfung von Migration und Folgeverarbeitung mit einbezogen werden, da bei deren Migration auch die zugehörigen im Nebenbuch gebuchten Forderungen und Verbindlichkeiten vom Nebenbuch des Altsystems in das Nebenbuch des Zielsystems übertragen und im Hauptbuch analog umgebucht werden müssen.

Migration der Vertragshistorie

ReSy führt eine Vertragshistorie, die in einer speziellen Historienansicht eingesehen werden kann. In der Historienansicht sind alle zum Vertrag getätigten Geschäftsvorfälle mit deren Bezeichnung, Durchführungsdatum und Bearbeiter chronologisch sortiert aufgelistet. Zudem kann zu jedem Historieneintrag der zugehörige historische Stand des Vertrags in einer speziellen Read-Only-Vertragsansicht eingesehen werden.
Natürlich wäre es wünschenswert, dass die Vertragshistorie eines migrierten Vertrags nicht erst mit einem Eintrag für dessen Migration nach ReSy neu beginnt, sondern auch die im Altsystem vor Migration getätigten Geschäftsvorfälle lückenlos auflistet und in der alle historischen Vertragsstände weiterhin einsehbar sind.

Die Erfahrung aus bisherigen Migrationsprojekten hat allerdings gezeigt, dass abzulösende Altsysteme historische Daten in dieser Qualität normalerweise nicht liefern können. Verfügbar ist häufig nur ein vom Altsystem oder auch manuell im Altsystem geführtes Vertragslogbuch, dessen Einträge mehr oder weniger Notizcharakter besitzen. Da auch solche einfachen Vertragslogbücher wertvolle Informationen für den Sachbearbeiter enthalten, wurde in den jeweiligen Kundendistributionen von ReSy speziell für migrierte Verträge eine Möglichkeit geschaffen, ein vorhandenes Vertragslogbuch in der vom Altsystem vorgegebenen Struktur zu einem migrierten Vertrag zu hinterlegen und in einer zugehörigen tabellarischen Ansicht anzuzeigen. Die Fortschreibung eines so migrierten Vertragslogbuchs im migrierten Vertrag wird dabei aber nicht unterstützt. Nach Migration übernimmt die ReSy-Vertragshistorie auch für migrierte Verträge die Verwaltung der historischen Vertragsstände.

Eine letzte Anmerkung zum Thema historische Vertragsstände: Sämtliche Daten, die für Folgeverarbeitungen eines Vertrags benötigt werden, z.B. für die Anlage und Bearbeitung von zugehörigen Leistungen, sind aus Sicht von ReSy keine historischen Vertragsdaten, die nur noch in der Vertragshistorie angezeigt werden. Ein Beispiel hierfür sind die von einem Bankpartner pro Monat/Zeitscheibe gemeldeten Sollstände eines durch einen Saldenvertrag abgesicherten Girokontos. Die vollständige Liste aller bislang vom Bankpartner gelieferten Zeitscheiben mit diesen Sollständen ist aus Sicht von ReSy Bestandteil der aktuellen Vertragsversion. In früheren und somit mittlerweile historischen Vertragsversionen ist diese Liste auch vorhanden, allerdings nur mit deren historischem Befüllungsstand, d.h. mit entsprechend weniger bereits vom Bankpartner gelieferten Einträgen.

Migration von Leistungen

Für die Migration von Leistungen empfiehlt die enowa ebenfalls die Nutzung einer File-basierten Migrationsschnittstelle. Sämtliche obigen Ausführungen zu diesbezüglichen Vor- und Nachteilen, zum Umgang mit invaliden Daten, zur Prüfung von Vollständigkeit und semantischer Korrektheit der Migration gelten dabei völlig analog. Lediglich die konkreten Beispiele und die anhand von diesen exemplarisch aufgezeigten Problemfelder sind aufgrund des anderen fachlichen Kontexts naturgemäß andere als bei der Migration von Verträgen.