Die Zahl, die nicht aufging
Ich fand es an einem Dienstag, drei Wochen vor der Einreichungsfrist unseres Swiss Solvency Test. Eine Abstimmung, die auf den Rappen hätte aufgehen müssen, tat es nicht. Elf Basispunkte Differenz, bei einem Rentenbestand, der gut über eine Milliarde Franken an Reserven trägt.
Elf Basispunkte klingen gering — bis man sie über jeden Quartalsabschluss der letzten sechs Jahre hochrechnet und erkennt, dass man Prüfern, Verwaltungsrat und FINMA nicht mehr sagen kann, welche dieser sechs Jahresabschlüsse jemals tatsächlich korrekt war.
Das ist der Moment, in dem ein Migrationsprogramm aufhört, ein IT-Projekt zu sein, und zu einem persönlichen wird. Die Unterschrift auf den technischen Rückstellungen ist meine. Nicht die des Lieferanten. Nicht die des Integrators. Meine.
Die Daten sind nicht das Problem. Die Logik ist es.
Was Ihnen niemand über ein vierzig Jahre altes Bestandsverwaltungssystem auf AS/400 und DB2 sagt: Die Daten waren nie bloss Daten. Jeder Barwert unseres Rentenbestands war das Ergebnis einer Stored Procedure — einer Logik, die von Menschen geschrieben wurde, die die Branche verlassen hatten, bevor einige meiner Analysten geboren wurden.
Unsere elf Basispunkte führten wir auf eine einzige Routine zurück, die unsere eigene Dokumentation noch immer Stored_Procedure_01 nannte: eine NPV-Berechnung auf Basis einer 360/365-Tageszählungskonvention. Die Routine, die tatsächlich in der Produktion lief, war das seit vier Jahren nicht mehr. Irgendwann hatte eine inhaltlich ähnliche, funktional abweichende Nachfolgeroutine ihren Platz eingenommen — auf actual/365-Basis.
Für sich genommen ist das eine Rundungsanmerkung. Was mich nachts wach hielt, war die daraus folgende Frage: Wenn eine Prozedur still abdriftete, wie viele der übrigen rund vierhundert taten dasselbe — zu einem unbekannten Zeitpunkt, auf eine unbekannte Art? Jeder Reservewert, jeder Erfüllungs-Cashflow, jede Zahl, die meinen Namen trägt, basierte auf einer Logik, die ich nicht mehr als stabil beweisen konnte.
Was wir zuerst versuchten
Wir taten das, was die meisten Teams tun. Wir holten zwei pensionierte AS/400-Programmierer aus dem Beratungsruhestand — zu einem Tagessatz, der unserem CFO die Stirn runzeln liess — und liessen sie RPG und eingebetteten SQL Prozedur für Prozedur gegen unsere letzte vollständige Dokumentation lesen. 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. Vielleicht dem übernächsten.
Inzwischen lag die eigentliche Migration — die uns für immer von dieser Plattform befreien sollte — auf Eis. Niemand würde eine Freigabe für den Wechsel auf ein neues Kernsystem erteilen, solange die Quelle der Wahrheit unter dem alten noch, streng genommen, unbekannt war.
Einführung eines KI-Managed-Service
Was die Wende brachte, war die Einführung eines KI-Managed-Service, der sich quer über den AS/400- und DB2-Bestand legte — nicht um ihn einmalig zu extrahieren und dann zu gehen, sondern um ihn als lebendes System of Record zu behandeln. Jede Stored Procedure, jede Tabelle, jeder Batch-Job wurde geparst, versioniert und gegen jede frühere Version abgeglichen, die wir noch in unseren Archiven hatten.
Innerhalb von drei Wochen verfügten wir über eine rekonstruierte Änderungshistorie für alle Prozeduren hinter unserem gesamten Rentenbestand — einschliesslich des genauen Zeitpunkts, zu dem Stored_Procedure_01a still die Stored_Procedure_01 abgelöst hatte, und für welche Berichtsperioden unter welcher Version berechnet worden war.
Ein regulatorisches Bild, das ich endlich vertreten konnte
Diese Rekonstruktion war das Erste, das mir wieder Schlaf liess. Für jedes historische Datum, das ich nannte, zeigte sie exakt, welche Version welcher Prozedur welche Zahl erzeugt hatte — und konnte es reproduzieren. Keine Schätzung. Eine vertretbare, wiederholbare 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 neu bestätigter Zahlen — statt der sechs Monate, die wir budgetiert hatten. Die FINMA erhielt eine Einreichung, in der jede technische Rückstellung auf spezifische, dokumentierte Berechnungslogik zurückführbar war — aktuell und historisch, auf Abruf.
Daten, die ich endlich befragen konnte
Der zweite Nutzen überraschte mich, denn ich hatte nicht danach gefragt. Sobald die Berechnungslogik entwirrt war, wurden die zugrundeliegenden Versicherungnehmerdaten — Jahrzehnte davon, in Flat Files und Grünbildschirm-Extrakten — in etwas umstrukturiert, das eine moderne Analytics-Schicht tatsächlich in natürlicher Sprache abfragen konnte.
Unsere Produkt- und Vertriebsteams, die jahrelang mit Tabellen gearbeitet hatten, die auf vierteljährlichen Datenexporten basierten, konnten endlich echte Fragen stellen und den Antworten vertrauen: Welche Rentenkohorten lösten früh auf? Welche Kundensegmente waren tatsächlich profitabel, wenn die korrekte NPV-Logik die angenäherte ersetzte, gegen die alle geplant hatten? Zwei Segmente, die wir jahrelang als marginal bepreist hatten, erwiesen sich als komfortabel profitabel. Ein grösseres Segment, das wir als gesund angesehen hatten, war es nicht.
Solche Erkenntnisse gewinnt man nicht aus einem Migrationsprojekt. Man gewinnt sie, wenn man endlich dreissig Jahre eigene Daten vertrauen — und befragen — kann.
Warum wir endlich neu bauen konnten
Hier liegt der Kern dessen, was die Migration schliesslich freigab. Sobald der KI-Managed-Service hinter dem Legacy-Bestand stand — ihn abstimmte, erklärte, das regulatorische Bild laufend korrekt hielt, unter einem SLA, der garantierte, dass Legacy-Daten so lange verfügbar und korrekt interpretierbar bleiben würden, wie wir sie brauchten — hörte mein Architekturteam auf, vierzig Jahre akkumulierter Logik zu migrieren. Das mussten wir nicht mehr.
Wir migrierten genau zwei Dinge: die Legacy-Daten selbst und die Eröffnungssalden, die die neue Plattform für den Go-live brauchte. Jede Workaround-Lösung, jeder undokumentierte Patch, jede «vorübergehende» Korrektur, 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 tatsächlich wollten, anstatt ein detailgetreues, überkonstruiertes Abbild von vierzig Jahren technischer Schulden. Keine Schattenlogik zum Reverse-Engineering. Keine Stored Procedures, die «as-is» reimplementiert werden mussten, wenn niemand beweisen konnte, was «as-is» je bedeutet hatte. Nur ein sauberer Kern, Eröffnungssalden, die von Tag eins stimmten, und eine Legacy-Umgebung, die still im Hintergrund wartete — unter SLA antwortfähig, falls jemand je eine weitere Frage stellen musste.
Es war nie wirklich ein Migrationsproblem. Es war ein «Wissen wir überhaupt, was unsere eigenen Zahlen bedeuten?»-Problem. Ich habe die Migration am Ende freigegeben — die vollständige Plattform, nicht einen Patch. Mein Name steht drauf. 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 zu dem Tag, an dem die Logik sich geändert hatte. Sobald das gelöst war, war der Rest nur noch Engineering.