Gleich zu Beginn im Buch wird ein Versicherungsunternehmen beschrieben, bei dem die Migration zur «gewaltigen Herausforderung» wurde. Was ist da schiefgelaufen?
Ildiko: Ja, im Buch ist ein fiktiver Fall beschrieben, aber wir haben das tatsächlich so erlebt. Unternehmen, die die Komplexität unterschätzen. Sie dachten mit ein paar Excel-Tabellen und ein paar SQL-Statements sei es gemacht. Aber bei solchen Projekten werden die Anforderungen erst mit der Zeit komplexer. Plötzlich werden die SQL-Statements immer länger, unübersichtlicher und fehleranfälliger. Dann kommen noch unvorhergesehene Sachen dazu, wie alte Verträge, die niemand auf dem Schirm hatte. Am Ende ist die IT mit dem alten System beschäftigt, versucht das neue aufzubauen und muss zudem noch migrieren. Das ist zu viel.
Was macht ein Migrationsexperte, wenn er zu diesem Zeitpunkt um Hilfe gebeten wird?
Solche Fälle sind natürlich Worst-Case-Szenarien – aber sie kommen leider vor. Wenn man in so eine Situation gerufen wird, ist der erste Schritt: analysieren. Besonders bei fehlerhaften Daten müssen wir herausfinden, woher sie kommen. Was genau ist schiefgelaufen? Fehlen Daten aus einem Quellsystem, weil sie bei der Extraktion falsch selektiert wurden? Oder wurden Spezifikationen falsch umgesetzt?
Dann muss man prüfen, ob und wie sich die Daten nachträglich einspeisen lassen – entweder über Seiteneingänge im Zielsystem oder durch technische Workarounds. Dabei arbeiten wir eng mit den Fachbereichen, der Projektleitung und den Quellsystem-Experten zusammen. Es gibt kein Standardrezept – jedes Problem muss individuell gelöst werden.
Aber in der Regel ist es viel teurer und schlechter, wenn eine Migration schon so schiefgelaufen ist. Besser ist es, wenn von Anfang an richtig gearbeitet wird.
Was macht das Nacharbeiten so viel mühsamer als eine saubere Migration von Anfang an?
Stell dir vor, während der Migration wird beispielsweise ein Steuerungs-Flag falsch gesetzt – und im Zielsystem kann man es im Nachhinein nicht mehr ändern. Dann lassen sich bestimmte Prozesse gar nicht mehr ausführen, etwa bei einem Versicherer, wenn der Kunde auf bestimmte Leistungen keinen Zugriff hat. Das ist fatal.
Ein anderes Beispiel: Wenn die Berechnungslogik im neuen System leicht abweicht und nicht sauber getestet wurde, können schon bei der nächsten Beitragserhebung Abweichungen auftreten – und das kostet Vertrauen und Geld.
Solche Fehler nachträglich zu beheben, ist extrem aufwendig. Vor allem, wenn sie viele Datensätze betreffen. Bei drei Verträgen kann man noch manuell eingreifen. Bei 1.700 wird das unmöglich.
Was kann eine IT-Abteilung machen, damit es nicht so weit kommt?
Grundsätzlich ist es eine gute Idee frühzeitig Experten hinzuzuziehen. Das heisst nicht, dass die Migration dann ausschliesslich von einer externen Firma umgesetzt wird. Wir haben die besten Erfahrungen mit gemischten Ansätzen gemacht. Das heisst, dass wir als externe Dienstleister Wissen und erprobte Vorgehensmodelle einbringen. Wir haben schon viele Migrationen umgesetzt und dieses Praxiswissen haben die IT-Abteilungen üblicherweise nicht inhouse. Es wäre auch viel zu teuer, dieses aufzubauen für nur eine Migration in zehn Jahren. Das interne Wissen über Quellsysteme und Datenstrukturen ist aber auch wichtig. Darum arbeiten wir eng mit unseren Kunden zusammen. Davon profitiert die IT-Abteilung unserer Kunden, denn so können sich die Teams trotzdem weiterentwickeln und wissen genau, wie wir die Migration umgesetzt haben.
Damit meinst du das Vorgehensmodell. Wie sieht das bei der nag informatik aus?
Wir legen grossen Wert auf Scoping und Produktmapping. Es geht dabei darum, genau zu definieren, was wohin migriert wird. Sonst passiert, was wir "Scope Creep" nennen. Das Projekt bläht sich auf wie ein Hefeteig, und die Kosten explodieren. Beim Scoping schätzen wir ab, wohin die Reise geht und was wir mitnehmen müssen. Stell dir vor, du bist eine Schweizer Versicherung und hast ein Produkt wie "Vollkasko", das kaum noch Verträge hat. Macht es Sinn, das ins neue System zu schleppen? Nein! Da kann man Verträge kündigen oder ersetzen und Ressourcen sparen. Oder historische Daten nur für die letzten zehn Jahre migrieren statt für die letzten 50 Jahre, wie es die Datenschutzbestimmungen etwa die DSGVO fordern. Scoping spart enorm Aufwand und konzentriert die Ressourcen auf das Wesentliche.
Und was ist das Produktmapping?
Beim Produktmapping geht es darum, wie alte Produkte im neuen System abgebildet werden. Manchmal braucht es dafür kreative Migrationsprodukte als Übergangslösung oder man muss sehr alte, nicht kündbare Verträge manuell weiterverwalten. Das möchten wir aber möglichst vermeiden, weil es viel Aufwand generiert.
Ist das nichts, was die IT-Abteilung selbst machen kann?
Grundsätzlich schon, aber solche Projekte werden schnell unterschätzt. Das Resultat ist oft Schlafmangel und Überforderung. Die IT muss gleichzeitig das alte System am Laufen halten, das neue System implementieren und auch noch die Migration selbst planen und durchführen. Auch wenn du die Wartung des Altsystems auf Minimum reduzierst. Externe Migrationsdienstleister entlasten dein Team enorm. Wir können aus unserer Erfahrung sagen, dass unsere Prozesse und Tools das Risiko von Projektverzögerungen massiv reduzieren. Und die benötigten Kapazitäten ändern sich dynamisch im Projektverlauf; in späteren Phasen, wenn bereits viel wiederverwendet werden kann, sinkt der Aufwand für unsere Kunden um 40 bis 60 %. Am Ende ist ein externer Dienstleister immer günstiger, als wenn der Kunde selber migriert.
