Die Zahl, die nicht aufging
Ich entdeckte es an einem Dienstag, drei Wochen vor unserer Swiss Solvency Test-Einreichung. Eine Abstimmung, die auf den Rappen genau aufgehen sollte, tat es nicht. Elf Basispunkte Differenz — bei einem Leibrentenbestand mit gut über einer Milliarde Franken Reserven.
Elf Basispunkte klingen nach wenig — bis man sie über sechs Jahre und jedes Quartal hochrechnet und erkennt, dass man seinen Prüfern, dem Verwaltungsrat und der FINMA nicht mehr sagen kann, in welchem dieser sechs Jahre die Zahlen jemals wirklich korrekt waren.
Das ist der Moment, in dem ein Migrationsprogramm aufhört, ein IT-Projekt zu sein, und zu einem persönlichen wird. Meine Unterschrift steht auf den versicherungstechnischen Rückstellungen. Nicht die des Anbieters. Nicht die des Integrators. Meine.
Das Problem sind nicht die Daten. Es ist die Logik.
Hier ist, was Ihnen niemand über ein vierzig Jahre altes, auf AS/400 und DB2 laufendes Bestandsverwaltungssystem sagt: Die Daten waren nie nur Daten. Jeder Nettobarwert in unserem Rentenbestand war das Ergebnis einer gespeicherten Prozedur — Logik, die von Personen geschrieben wurde, die die Branche verlassen hatten, bevor einige meiner Analysten geboren waren.
Wir verfolgten unsere elf Basispunkte zurück auf eine einzige Routine, die unsere eigene Dokumentation immer noch Stored_Procedure_01 nannte: eine NBW-Berechnung auf Basis 360/365. Die tatsächlich in der Produktion laufende Routine war seit vier Jahren nicht mehr diese. Irgendwann hatte ein Nachfolger — äusserlich ähnlich, funktional verschieden — auf Basis actual/365 ihren Platz eingenommen.
Für sich genommen ist das eine Rundungsanmerkung. Was mich nachts wachhielt, war die daraus folgende Rechenaufgabe: Wenn eine Prozedur stillschweigend gedriftet war, wie viele der rund vierhundert anderen hatten dasselbe getan — zu einem unbekannten Zeitpunkt, auf eine unbekannte Weise? Jede Reservezahl, jeder Erfüllungs-Cashflow, jede Zahl mit meinem Namen war auf Logik aufgebaut, deren Stabilität ich nicht mehr beweisen konnte.
Was wir zuerst versuchten
Wir taten, was die meisten Teams tun. Wir holten zwei pensionierte AS/400-Programmierer aus dem Beratungsruhestand, zu einem Stundensatz, der unseren CFO grimassieren liess, und liessen sie RPG und eingebettetes SQL Prozedur für Prozedur gegen unsere letzte vollständige Dokumentation prüfen. Nach sechs Wochen hatten sie einundvierzig von rund vierhundert Prozeduren abgearbeitet. In diesem Tempo hätten wir irgendwann nach unserem nächsten SST-Zyklus fertig geworden. Möglicherweise dem übernächsten.
Unterdessen stand die eigentliche Migration — jene, die uns endgültig von dieser Plattform befreien sollte — auf Eis. Niemand würde den Umzug auf ein neues Kernsystem genehmigen, solange die Quelle der Wahrheit unter dem alten, streng genommen, noch unbekannt war.
Einführung eines KI-Managed-Service
Was die Wende brachte, war die Einbindung eines KI-Managed-Service, der die AS/400- und DB2-Landschaft übernahm — nicht um sie einmalig zu extrahieren und sich dann zu verabschieden, sondern um sie als lebendiges System of Record zu behandeln. Jede gespeicherte Prozedur, jede Tabelle, jeder Batch-Job wurde analysiert, versioniert und gegen jede frühere Version, die wir noch hatten, bis zu unseren ältesten Archiven zurück, geprüft.
Innerhalb von drei Wochen verfügten wir über eine rekonstruierte Änderungshistorie für die Prozeduren hinter unserem gesamten Rentenbestand — einschliesslich des genauen Zeitpunkts, an dem Stored_Procedure_01a stillschweigend Stored_Procedure_01 ablöste, und welche Berichtsperioden unter welcher Version berechnet worden waren.
Ein regulatorisches Bild, das ich endlich vertreten konnte
Diese Rekonstruktion war das Erste, das mich wieder schlafen liess. Für jedes historische Datum, das ich nannte, zeigte sie präzise, welche Version welcher Prozedur welche Zahl produziert hatte — und konnte sie reproduzieren. Keine Schätzung. Eine verteidigbare, reproduzierbare Antwort auf die Frage: „Wie wurde das berechnet, und wird es heute noch gleich berechnet?"
Wir führten unsere externen Prüfer in zwei Sitzungen durch sechs Jahre wiederhergestellte Sicherheit, statt der sechs Monate, die wir budgetiert hatten. Die FINMA erhielt eine Einreichung, bei der jede versicherungstechnische Rückstellung auf spezifische, dokumentierte Berechnungslogik zurückzuführen war — aktuell und historisch, auf Abruf.
Daten, die ich endlich befragen konnte
Der zweite Nutzen überraschte mich, weil ich ihn nicht angefordert hatte. Sobald die Berechnungslogik entwirrt war, wurden die zugrundeliegenden Versicherungsnehmerdaten — Jahrzehnte davon, in Flat Files und Green-Screen-Extrakten — in etwas umstrukturiert, das eine moderne Analytics-Schicht tatsächlich in einfacher Sprache abfragen konnte.
Unsere Produkt- und Vertriebsteams, die jahrelang mit Tabellenkalkulationen aus vierteljährlichen Datenexporten gearbeitet hatten, konnten endlich echte Fragen stellen und den Antworten vertrauen: Welche Rentengruppen traten frühzeitig aus, welche Kundensegmente waren wirklich profitabel, sobald die korrekte NBW-Logik die ungefähre ersetzte, gegen die alle geplant hatten. Zwei Segmente, die wir jahrelang als marginal eingestuft hatten, erwiesen sich als komfortabel profitabel. Ein grösseres Segment, das wir für gesund gehalten hatten, war es nicht.
Diese Erkenntnisse bekommt man nicht aus einem Migrationsprojekt. Man bekommt sie, wenn man endlich in der Lage ist, dreissig Jahren eigener Daten zu vertrauen — und sie zu befragen.
Warum wir endlich auf der grünen Wiese bauen konnten
Hier ist der Teil, der die Migration eigentlich freigegeben hat. Sobald der KI-Managed-Service hinter der Legacy-Landschaft stand — sie abstimmte, erklärte, das regulatorische Bild kontinuierlich korrekt hielt, mit einer SLA-Garantie, dass Legacy-Daten so lange verfügbar und korrekt interpretierbar bleiben würden, wie wir sie benötigten — hörte mein Architekturteam auf, vierzig Jahre angehäufte Logik zu migrieren. Wir mussten es nicht mehr.
Wir migrierten genau zwei Dinge: die Legacy-Daten selbst und die Eröffnungsbilanzen, die die neue Plattform für den Go-live benötigte. Jede Übergangslösung, jeder undokumentierte Patch, jede „vorübergehende" Lösung, die jemand 2003 dauerhaft gemacht hatte, blieb genau dort, wo sie war — abgestimmt, erklärt und ausser Scope.
Das befreite mein Team, die Zielarchitektur zu entwerfen, die wir wirklich wollten, anstatt einer treuen, überkonstruierten Replik von vierzig Jahren technischer Schulden. Keine Schattenlogik zum Rückwärtsentwickeln. Keine gespeicherten Prozeduren, die „as-is" reimplementiert werden mussten, wenn niemand beweisen konnte, was „as-is" jemals bedeutet hatte. Nur ein sauberer Kern, Eröffnungsbilanzen, die am ersten Tag aufgingen, und eine Legacy-Umgebung, die ruhig im Hintergrund stand — unter SLA abrufbar, falls jemand jemals eine weitere Frage stellen musste.
Es war nie wirklich ein Migrationsproblem. Es war ein „Wissen wir eigentlich, was unsere eigenen Zahlen bedeuten?"-Problem. Ich habe die Migration am Ende genehmigt — die gesamte Plattform, nicht ein Patch. Mein Name steht darauf. Aber es ist die einzige Unterschrift in sechs Jahren, die ich unter eine Zahl gesetzt habe, die ich tatsächlich verteidigen konnte — Zeile für Zeile, zurück bis zum Tag, an dem die Logik sich geändert hatte. Sobald das gelöst war, war der Rest nur noch Engineering.