STRATEGIE15. April 2020

Migration extrem: Core-System – Transformations­praxis bei Versicherungen

Helmut Körfer, verantwortlich für den Bereich Testdaten und Testumgebungen bei Expleo
Helmut Körfer, verantwortlich für den Bereich Testdaten und Testumgebungen bei ExpleoExpleo

Die Kernsoftware einer Versicherung aus­zu­tauschen (Migration), kommt einer Operation am offenen Herzen gleich und zählt daher zu den risikoreichsten Projekten für IT- und Business­-Verantwortliche. Wie lassen sich bei einem solchen Projekt Einschränkungen im Betrieb minimieren?

von Helmut Körfer und Mikel Becker, Expleo

Die Zeit der Individual­lösungen ist vorbei.“

Mikel Becker, Betreuer für Transformationsprojekte/Migration im Versicherungsumfeld bei Expleo
Mikel Becker, Betreuer für Transformationsprojekte im Versicherungsumfeld bei ExpleoExpleo
Viele Versicherer entscheiden sich in der Zeit des digitalen Wandels für die Einführung von Standardsoftware von Herstellern wie msg, Guidewire, Faktor-Zehn oder auch SAP mit ihren versicherungsspezifischen Modulen. Schneller mit Produkten auf den Markt kommen, ein besseres Serviceerlebnis für Kunden, die leichtere Implementierung gesetzlicher Änderungen, die Möglichkeit der Integration in mobile Anwendungen und Digitalisierungslösungen – gehen wir einmal davon aus, dass die Entscheidung für ein neues Core-System gefallen ist. Wie geht man nun die Migration an? Wie lassen sich Störungen im Betrieb minimieren?

Vorbereitung

In der Vorbereitungsphase wird der Umfang des Migrationsprojektes untersucht und dokumentiert. Erst mit diesen Informationen kann über das Vorgehen entschieden werden. Dafür müssen etliche ungeliebte Hausaufgaben gemacht werden: Der Datenbestand des Altsystems wird gesichtet und es wird geklärt, ob systematische Bestands- oder Produktfehler existieren, die im Vorfeld der eigentlichen Migration zu beheben sind – der Datenbestand innerhalb eines Versicherungssystems war im Rahmen der historisch gewachsenen Systeme üblicherweise bereits häufiger Änderungen ausgesetzt. Die technische Infrastruktur für das Zielsystem muss skizziert werden, wobei es sowohl in seiner Größe als auch in seiner datenschutzspezifischen Härtung am künftigen Produktivsystem Maß nehmen sollte. Diese frühe datenschutzrechtliche Härtung ist besonders wichtig, weil im folgenden Prozess überwiegend mit Produktionskopien, also mit echten Kundendaten gearbeitet wird. Die Migrationsumgebung mit allen erforderlichen Tools zur Transformation der Daten wird technisch zur Verfügung gestellt und dabei ist es wichtig, dass alle Lieferstrecken (Filetransfers) und Schnittstellen bestehen, damit eine End-to-End-Verarbeitung stattfinden kann. Um dies zu gewährleisten, ist es umso wichtiger, frühzeitig eine saubere Planung für die Testumgebungslandschaft aufzusetzen und per Checkliste die Vollständigkeit vor den Migrationsläufen zu prüfen.

Abschließend muss die Migrationsstrategie festgelegt werden. Diese bezieht sich nicht nur auf technische Fragen, etwa, ob man eine Extra-Datenbank als Zwischenschritt verwendet oder nicht. Vielmehr spielen fachliche Anforderungen ganz extrem in die Migrationsstrategie hinein. Man denke nur an Lebensversicherungen mit ihrer langen Historie – wie zieht man diese um? Was wird in das Produktivsystem übernommen, was wandert gleich ins Archiv? Im Sachbereich halten es manche Versicherungen bei der Transformation so, dass sie Kunden um einen Vertragswechsel bitten, um den Aufwand der Migration zu verringern. Im Rahmen der Neueinführung wird auch gleichzeitig das Produktportfolio überarbeitet.

Bei der Migration findet das klassische ETL-Verfahren Anwendung.
Bei der Migration findet das klassische ETL-Verfahren Anwendung.Expleo

Exkurs: Worüber sich das Management (hoffentlich) Gedanken gemacht hat

Das Folgende gehört nicht zur Aufgabe der IT. Doch wer die Datenmigration in ein neues Bestandssystem in einer Versicherung verantwortet, sollte hellhörig werden, wenn diese Vorbereitungen nicht erfolgten: Eine Versicherung sollte vor dem Wechsel ihres Core-Systems erwägen, welche Einführungsstrategie in Bezug auf den reibungslosen Fortgang des Geschäftsbetriebs optimal ist. In diese Überlegungen fließen Prioritäten, Budget, Risikobereitschaft, verfügbares Personal, Know-how sowie die Veränderungsbereitschaft der Organisation ein. Es sollte für alle Produkte und Prozesse eine Risikobewertung vorgenommen worden sein. Anders gesagt:

Welche Einbußen oder Aufwände (auch indirekter Natur) entstehen, wenn an dieser oder jener Stelle ein Fehler auftritt oder das Transformationsvorhaben aufgrund von Anpassungen oder Kurskorrekturen ins Stocken gerät?“

Über Expleo
Expleo (Website) biete ganzheitliche, integrierte Ingenieurs- und Qualitätsdienstleistungen ergänzt durch Managementberatung für die digitale Transformation. Das Unternehmen sieht sich als Partner für verschiedene Branchen. Zur Expleo-Gruppe gehören weitere Unternehmen wie Aerotec, Athos Aéronautique, Double Consulting, Edison Technical Recruitment, Moorhouse Consulting, Silver Atena, Stirling Dynamics, Sud Aviation Services, Trissential und Vista Technologies.

Eine sinnvolle Strategie, die sich daraus ergeben kann und dann auf die Priorisierung im IT-Projekt wirkt, ist zum Beispiel diese: Produkte mit hoher Nachfrage werden zunächst weiterhin aus dem Altsystem bedient. Nur Produkte und Prozesse, die als wenig risikoreich beurteilt wurden, werden im neuen System implementiert. Wenn zum Beispiel klassische Lebensversicherungen wegen der schlechten Zinslage gerade wenig nachgefragt und vertrieblich nicht priorisiert werden, bietet es sich an, deren Geschäftsprozesse früh umzuziehen.

Generell kann als Faustregel gelten: Je näher ein Prozess am Vertrieb und am Kunden ist, desto kritischer muss er in der Bewertung der Transformationsrisiken gesehen werden. Fehler, die die Interaktion mit dem Kunden beeinflussen, sind im Rahmen von Priorisierung und Risikobetrachtung entsprechend kritisch zu sehen. Diese Vorgehensweise gilt nicht nur für die Migration von Beständen, sondern auch bei der Einführung von neuen Bestandssystemen. In der Versicherungswelt wird hier auch von einer Core-to-Satellite-Strategie gesprochen. Das heißt, es wird zunächst das Bestandssystem erneuert und dann im Nachgang sukzessive alle anderen Systeme, wie beispielsweise der Point-of-Sales, In-/Exkasso oder Datawarehouse-Systeme.

Implementierung

Ein wesentliches Ergebnis aus der Vorbereitungsphase ist die Planung der weiteren Phasen bis zur produktiven Migration. Die folgende Implementierungsphase ist der aufwändigste Teil des Gesamtprojektes. Für den Ausbau des Zielsystems werden die funktionalen Deltas zwischen Quell- und Zielsystem ermittelt, um dann sowohl die für die Migration benötigten Produkte und Tarife zu implementieren als auch die funktionalen Anpassungen und Erweiterungen durchzuführen. In der Praxis geht es hier vor allem um das Mapping und die Migrationsskripte auf Feldebene. Auf die Analyse der Unterschiede folgt in der Regel nochmals eine Rücksprache mit dem Fachbereich, denn dort, wo Quell- und Zielsystem sich zum Beispiel aus Gründen der Kosten oder der Ressourcenverfügbarkeit nicht zur Deckung bringen lassen, stellt sich die Frage: Werden diese Felder noch benötigt und müssen im neuen System angelegt werden, oder kann etwas weggelassen und vereinfacht werden? Möglicherweise haben sich im Laufe der Zeit grundsätzliche Anforderungen an ein Produkt oder eine Sparte verändert. Die Transformationsregeln werden erarbeitet und dokumentiert. Parallel dazu wird das Migrationscontrolling aufgebaut: Ein Output, der die Anwendung des Regelwerks zum korrekten Mapping der Quell- und Zieltabellen dokumentiert. Durch dieses Logfile wird sichergestellt, dass alle Prozeduren nachvollziehbar und prüfbar sind (Hinweis: Migrationsvorhaben sind oft auch begehrt bei Revision und Wirtschaftsprüfern).

Migration: Der Prozess mit Controlling
Der Migrationsprozess mit ControllingExpleo

Schließlich wird das Testkonzept für das Zielsystem erstellt. Vor Abschluss der Implementierungsphase müssen alle Tarife eingestellt, getestet und abgenommen sein. Sprich, es muss sichergestellt sein, dass das neue System funktionsbereit ist. Diese Tests lassen sich teilweise, aber nicht vollumfänglich mit Produktionsdaten durchführen, sondern bedürfen an der einen oder anderen Stelle auch anonymisierte bzw. synthetische Daten. Das hat den Vorteil, dass man keine Datenschutzthemen hat, wenn man diese Tests auch durch externe Tester durchführen lässt.

Das eigentliche Migrationstesting muss aber zwangsläufig mit den Echtdaten gemacht werden.“

Denn Datenqualität lässt sich nur mit den bestehenden Daten aus der Produktion verbessern. Das bietet sich an, wenn aus Kapazitätsgründen beschlossen wurde, die Sachbearbeiter nicht mit solchen vorbereitenden Tests zu belasten.

Iterative Testläufe

Autoren Helmut Körfer und Mikel Becker, Expleo
Helmut Körfer ist seit 9 Jahren bei Expleo (bzw. vormals SQS) verantwortlich für den Bereich Testdaten und Testumgebungen in der Business Unit Banking and Financial Services. Helmut Körfer hat bereits zahlreiche Testdaten- und Datenmigrationsprojekte in der Versicherungswelt begleitet.

Mikel Becker hat seit 2017 bei Expleo mehrere Transformationsprojekte im Versicherungsumfeld betreut. Sein Schwerpunkt liegt auf Lebensversicherungen und dort insbesondere auf fachlichen Themen rund um versicherungstechnische Prozesse.

Was schiefgehen kann, wird auch schiefgehen. Wenn nichts schiefgegangen ist, hat man etwas übersehen – Murphy’s Law ist ein guter Rat in einem so riskanten Projekt wie Migration in ein neues Core-System. Die gute Nachricht: Testen hilft und nichts muss auf Anhieb perfekt sein. Wenn die Transformations- und Controlling-Regeln einmal umgesetzt sind, kann das Projekt in die Testphase gehen. Die Migration wird dabei in beliebig vielen iterativen Testläufen vorbereitet. Dazu werden wiederholt auch aktuelle Datenlieferungen aus dem Quellsystem benötigt. Der Migrationsdatenbestand wird mit jedem Mal besser – eine Migration ist ein beliebtes Mittel zur Bereinigung und Qualitätssicherung des Datenbestandes. Die iterativen Testläufe des Migrationsprozesses erfolgen so lange, bis die Daten korrekt (ohne oder mit genau definierten erlaubten Abweichungen) migriert werden können. Sobald dieser Zustand erreicht ist, werden migrierte Daten für die weiteren Tests bereitgestellt. Das heißt, zunächst führt man Funktionstests auf migrierten Verträgen innerhalb des Zielsystems und anschließend End-to-End-Tests in einer Integrationstestumgebung durch.

Iterative Migrationstests werden parallel und unabhängig voneinander zunächst pro Komponente durchgeführt, bis alle Komponenten für sich migrationsbereit sind. Im Anschluss daran wird der iterative Test auf die gesamte Plattform ausgeweitet, um die Migration auch im Zusammenspiel der Komponenten zur Produktionsreife zu bringen. Schließlich wird das Berichtswesen festgelegt und die produktive Migration über die gesamte Plattform geplant und vorbereitet. Diese wird eingeleitet durch einen letzten Test, eine Generalprobe inklusive der festgelegten und getesteten Berichte sowie des Controllings.

Migrationsdrehbuch

Für den Migrationstermin, an dem die Migration physisch durchgeführt wird und ab dem die Verwaltung der Bestände im neuen Bestandssystem erfolgt, wird üblicherweise ein Wochenende gewählt. Damit alle in den Quellsystemen auf den Monatsanfang folgenden Prozesse (z. B. Erstellung und Versand von Kontoauszügen, Batch- und Stichtagsverarbeitungen) korrekt und vollständig abgeschlossen werden können, …

… ist ein Migrationstermin ab, beziehungsweise in der dritten Woche eines Monats anzustreben.“

Die produktive Durchführung der Migration am Migrationstermin bereitet man am besten über ein detailliertes Migrationsdrehbuch vor, in dem alle im Rahmen der Migration durchzuführenden Schritte (mit Termin, Dauer, Ergebnis, Verantwortung etc.) aufgeführt sind. Das ist vor allem deshalb wichtig, weil hier die Abhängigkeiten und Reihenfolgen zu den Querschnittssystemen hinterlegt werden, das heißt zu den Querschnittfunktionen wie beispielsweise zentraler Geschäftspartner, Inkasso/Exkasso, Provision.

Die Strategie für die Migration
Die MigrationsstrategieExpleo

Migrationstag nicht unbedingt Stichtag

Bei der Durchführung der Migration ist wiederum die fachliche Seite besonders zu berücksichtigen – insbesondere im Aspekt des Migrationsstichtags. Dieses Standardverfahren wurde von msg life entwickelt. Der Migrationsstichtag bezeichnet den Termin, zu dem der jeweilige Vertrag funktional im Zielsystem angelegt wird und zu dem die Migration versicherungstechnisch durchgeführt wird. Er liegt zeitlich vor oder ist identisch mit dem Migrationstermin und wird bestimmt durch den Abschluss der letzten Verarbeitung. Im Zielsystem können migrierte Verträge bis maximal auf den Migrationsstichtag zurück reaktiviert, bearbeitet und beauskunftet werden.

Der Migrationsstichtag muss vertragsindividuell festgelegt werden. Er wird zunächst über den letzten vor dem Migrationstermin liegenden Jahrestag definiert. Liegen im Intervall zwischen dem Migrationstermin und dem letzten Jahrestag eine oder mehrere technische Änderungen, so ist der Migrationsstichtag der Termin der letzten technischen Änderung.

Bei der Feinkonzeption zum Migrationsstichtag ist tarifgruppenabhängig festzulegen, welche in den Quellsystemen durchgeführten Bearbeitungen als technische Änderungen gelten und somit bei der Bildung des Migrationsstichtags berücksichtigt werden. Bei FLV-Verträgen wird standardmäßig ein Migrationsstichtag nahe am Migrationstermin gewählt beziehungsweise ergibt sich ein solcher Stichtag aufgrund der letzten Prämienveranlagung in Fondsanteilen. Hier ist der Stichtag meist der letzte Monatserste. Beispiele von außerplanmäßigen technischen Änderungen im Sinne der Migration sind: allgemeine Änderungen an Prämien, Leistungen oder Versicherungsdauer, Dynamikänderungen oder -ablehnungen, Leistungen, Fonds-Shifts oder Veranlagungen.

Fazit

Ganz reibungslos wird eine Migration nie ablaufen und manches kann nicht ohne manuelle Eingriffe und Korrekturen migriert werden.“

Mahnverfahren, Leistungen, Dynamikerhöhungen oder Widerspruchsfristen können zum Beispiel dazu führen, dass Verträge von der Migration ausgenommen werden müssen. Was man auf jeden Fall raten kann, ist: Bei allem, was man im Rahmen einer Migration tut, auf Testbarkeit achten und Tests gegebenenfalls auch durch externe Kräfte durchführen lassen. Die eigentliche Migration lässt sich vergleichsweise bequem durch Testläufe vorbereiten, mit denen man sich iterativ der gewünschten Datenqualität annähert. Wenn die Fachabteilungen erfolgreich mit dem neuen System arbeiten und die Kunden nichts von den Umstellungen mitbekommen haben, weiß man, dass man es geschafft hat.Helmut Körfer und Mikel Becker, Expleo

 

Update 14.5.2020: „Dieses Standardverfahren wurde von msg life entwickelt. “ wurde auf Wunsch von Expleo in den Beitrag eingefügt.

 
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/104206 
 
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne (13 Stimmen, Durchschnitt: 4,00 von maximal 5)
Loading...

 

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Aareal Bank: Vom Kernsystem in die Cloud – das Praxis-Interview mit Aareal Bank, IBM & knowis

In Sachen Cloud betritt die Aareal Bank gemeinsam mit IBM und knowis Neuland. Wie sind die Erfahrungswerte bei der erstmaligen Auslagerung eines Geschäftsprozesses aus dem...

Schließen