Immer mehr Versicherer entscheiden sich dafür, ihr Mainframe-System abzulösen und durch eine modernere & effizientere IT-Infrastruktur zu ersetzen. Die Ablösung solcher Systeme und damit über Jahrzehnte hinweg gewachsener Anwendungslandschaften stellt jedoch eine große Herausforderung und enorme Kostenaufwände dar. Ein besonders kritischer Teil solcher Projekte ist die Migration bestehender Vertrags- und Schadenbestände aus den Alt- bzw. Quellsystemen in das Zielsystem.

Voraussetzung für eine erfolgreiche Migration ist ein gelungener Migrationsstreckentest

Migrationsprojekte stehen dabei vor einer Reihe von Herausforderungen, die nicht selten auch zum Scheitern des gesamten Projektes führen können. Ein entscheidender Faktor für den Erfolg der Migration ist der Abnahmetest der häufig komplexen Migrationsstrecke mit einer Vielzahl an zugehörigen (Teil-)Systemen und beteiligten Akteuren sowie damit verbundenen Aktivitäten. Es muss auf verschiedenen Testumgebungen unter wechselnden Bedingungen getestet werden. Oftmals fehlt es an Transparenz, Verfügbarkeiten sind nicht geregelt und Verantwortlichkeiten unklar. Stakeholder können den Überblick verlieren, es kann zu Fehlentscheidungen und schlimmstenfalls zum Stillstand des Migrationslaufs kommen.

PPI unterstützt einen großen deutschen Versicherer bei der Ablösung ihres IT-Altsystems. In diesem Rahmen sollten in einem ersten Schritt Vertragsbestände fondsgebundender Rentenversicherungen mit BU-Zusatztarifen inklusive aller damit zusammenhängender Informationen vom Quell- in das Zielsystem überführt werden. Im Testbetrieb traten die oben genannten Probleme immer wieder zu Tage. Entscheidungen wurden unabgestimmt getroffen, nicht zueinander passende Daten- und Softwarestände verfälschten das Migrationsergebnis und es kam zu unzähligen Abbrüchen. Der Status der Migrationsläufe wurde nicht kommuniziert, der Prozess geriet ins Stocken und Folgeverarbeitungen wurden nicht angestoßen. Der Zeitplan für die erste Produktivmigration war hochgradig gefährdet. Doch wie konnten solche Hürden überwunden und der Migrationsstreckentest erfolgreich absolviert werden?

Man stelle sich dafür den Migrationsstreckentest wie im Flughafenbetrieb vor. Würde vor Start oder Landung keine Prüfung der relevanten Funktionen im Flugzeug durchgeführt sowie keine Koordination zwischen Tower und Pilot stattfinden, wäre dies fatal! Wichtiger Bestandteil sind dabei die Cockpits und Checklisten, die Fluglotsen und Piloten gleichermaßen zur Verfügung stehen. Genau hier hat PPI angesetzt und in Zusammenarbeit mit dem Kunden ein sogenanntes Migrationscockpit implementiert.

Steuerung und Kontrolle von Migrationsstreckentests mit dem Migrationscockpit

Das Migrationscockpit ist wie eine Checkliste zu verstehen, bei der eine Reihe von Anforderungen bzw. Teilschritten eines Migrationslaufes erfasst werden, die durch die dafür definierten Verantwortlichen geprüft, qualitätsgesichert und freigegeben sowie durch einen definierten Personenkreis ausgeführt werden müssen. Für jede Testumgebung gibt es ein eigenes Cockpit, in dem der aktuelle Migrationslauf abgebildet ist, mit dem Ziel diesen transparent darstellen und koordinieren zu können. Fachliche Tests sind nicht Teil des Cockpits und sollten über dafür geeignete Tools durchgeführt und dokumentiert werden.

Im Laufe des Projektfortschritts zeigte sich deutlich, dass das Migrationscockpit nur dann einen Mehrwert schaffen konnte, wenn die Rolle der Migrationstestkoordination im Sinne eines Single Point of Contact (SPOC) eindeutig bestimmt ist. Die Migrationstestkoordination, etwa durch das Test-Management oder die Projektleitung, pflegt das Cockpit, indem sie aktiv auf Stakeholder zugeht und die Anforderungen des Migrationslaufs abstimmt und aufnimmt, To-dos absteckt, die Verantwortlichen informiert und den Testlauf koordiniert. Ohne Abstimmung dürfen keine Anpassungen vorgenommen werden, da dies dazu führen kann, dass Teile der Migrationsstrecke nicht den Anforderungen genügen und der Migrationslauf schlimmstenfalls fehlschlägt.

„Beispiel-Cockpit“ aus PPI Projektgeschehen

Die Struktur und der Inhalt des Cockpits sind projektspezifisch und müssen anhand der im Projekt vorliegenden Anforderungen determiniert werden. PPI stellt dafür einen Prototyp zur Verfügung und führt anschließend Workshops mit dem Kunden durch, um das Beste aus dem Tool herausholen zu können.

Abbildung: anonymisiertes Beispiel-Cockpit für einen Migrationstestlauf

Ein „Beispiel-Cockpit“ aus dem PPI-Projektgeschehen sieht eine Gliederung nach den folgenden Teilabschnitten vor:

  1. Testumgebung und Daten bzw. Softwarestände

    In einem ersten Teil werden die Testumgebungen sowie die einzelnen Software- und Datenstände definiert. Es muss angegeben werden, wie die Selektionskriterien aussehen bzw. welche Verträge migriert werden sollen. Weiterhin wird geprüft, welche Hilfsdaten benötigt werden. Dazu gehören z.B. bestimmte Controlling-Toleranzwerte oder Simulationsdaten (Fondsdaten, Wechselkurse etc.). Außerdem wird in der Checkliste festgelegt, welche Testumgebung der Migrationsstrecke genutzt werden soll und in welchem Status sich die Systeme, also das Quell- und das Zielsystem sowie das Datenmigrationstool befinden. In diesem Abschnitt teilen die Verantwortlichen mit, ob alle Daten bereitgestellt wurden und die Testumgebung und die relevanten Systeme für die Migration bereitstehen.

    Sind all diese Anforderungen an den Migrationslauf erfüllt und die einzelnen Aktionen abgearbeitet und freigegeben, gibt die Migrationskoordination das Go für den Migrationslauf. Dabei wird immer auf das entsprechende Cockpit zum Testlauf verwiesen. In diesem Zusammenhang werden der geplante Start und der tatsächliche Start des Migrationslaufs dokumentiert.

  2. Ablauf der Migration, z.B. anhand eines Jobplans

    In einem zweiten Teil des Cockpits wird nun der eigentliche Migrationsablauf thematisiert. Hier werden die einzelnen Schritte der Migration, also vom QS und Selektion der Verträge über die Befüllung der entsprechenden DB-Tabellen und Transformation der Daten bis hin zur tatsächlichen Migration in das Zielsystem, behandelt. Auch entsprechende Nacharbeiten im Zusammenhang mit der Migration können mithilfe des Cockpits abgewickelt werden. Wohingegen im Bereich der Anforderungen (siehe Abschnitt 1. Testumgebung und Daten bzw. Softwarestände) teilweise noch parallel gearbeitet werden kann, ist hier eine sequenzielle Abarbeitung der Teilschritte bzw. einzelnen Jobs notwendig.

  3. Ergebnisse des Migrationslaufs

    In einem dritten Teil wird das Migrationsergebnis kurz und knapp veröffentlicht. D.h. es wird persistiert wie viele Verträge erfolgreich migriert und wie viele Verträge nicht migriert oder gar nicht erst für die Migration berücksichtigt werden konnten. Zugehörige Listen und Dokumente werden im Cockpit abgelegt, sodass im Anschluss ein ausführlicher Test durchgeführt werden kann.

  4. Nach- bzw. Folgeverarbeitungen

    Im letzten Bereich des Cockpits werden Folgeverarbeitung behandelt. Berücksichtigt wird beispielsweise, ob die entsprechenden Umsystem-Tabellen befüllt und Folge-GeVos ausgeführt werden konnten.

Das Migrationscockpit erwies sich als ein Erfolgsgarant für den Migrationsfortschritt

Die Einführung des Migrationscockpits durch PPI ermöglichte eine zielgerichtete Koordination der Testläufe. Die oben genannten Maßnahmen steigerten Effizienz und Produktivität im Team deutlich und verbesserten die Qualität der Migrationsstreckentests nachhaltig. Eine rechtzeitige Abnahme der Migrationsstrecke konnte gewährleistet werden. Die Produktivmigration der ersten Tranche verlief schlussendlich gemäß Zeitplan und konnte ohne große Schwierigkeiten erfolgreich abgeschlossen werden.

Autor: Konstantin Starke, PPI AG

Schreibe einen Kommentar

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

49  +    =  59

Verwandte Artikel