Eine SAP-S/4HANA-Finanzmigration absichern

Eine führende Schweizer Privatbank stellte ihr Core-Finanzwesen von SAP ECC auf S/4HANA um (neuer S/4HANA-Core, Fiori-Frontend), mit einem Go-live, der fest im schmalen Fenster um den Jahresabschluss lag. Das Kopieren der Daten war nie das Risiko. Zu beweisen, dass sie korrekt angekommen sind (jede Anlage, jeder Saldo, jeder kundenspezifische Datensatz, in einer Qualität, die Fachbereich und Revision unterschreiben), schon. Diesen Nachweis haben wir verantwortet, mit einer automatisierten Validierung der Datenmigration auf Basis von Tricentis Tosca: Tricentis Data Integrity (Tosca DI) für den Datenabgleich, klassisches Tosca für Prüfungen auf der Oberfläche.

Ein Wechsel auf S/4HANA verlagert Finanzdaten nicht nur, er strukturiert sie um (das Universal Journal führt zusammen, was früher in getrennten Tabellen lag), und die Migration formatiert Datensätze um, ordnet sie neu zu und führt sie zusammen. Dazu kommen die reale Grössenordnung (Hunderte Standard- und Custom-Objekte, Milliarden Datensätze über viele Gesellschaften) und ein Go-live im Rechnungswesen, der an den Jahreswechsel gebunden ist und sich nur um ein ganzes Jahr verschieben liesse. Die Verifikation muss deshalb schnell, verlässlich und prüfbar zugleich sein.

Ein naiver Feld-für-Feld-Vergleich scheitert sofort, denn die Daten sollen sich ändern. Ein sinnvoller Abgleich wendet dieselben Geschäftsregeln an wie die Migration, damit gewollte Abweichungen nicht als Fehler erscheinen. Praktisch heisst das: Quelle gegen Ziel auf Tabellen- und Transaktionsebene vergleichen, die Transformationslogik anwenden (Buchungskreis-Remapping, Kontonummern-Umstellung auf ein neues Schema, Buchungsprinzip-Mapping, Scope-Filter nach Datum und Status sowie objektspezifische Feld-Ausschlüsse) und dann jede verbleibende Abweichung als erwartet/erklärt oder als echten Fehler einstufen. Genau diese Unterscheidung ist entscheidend: So kann das Team Fälle, die den Rohvergleich nicht bestehen, aber erwartet sind, bewusst abnehmen, statt Tausenden berechtigter Abweichungen nachzugehen.

Regulatorische Finanzberichte werden je Rechtsträger erstellt, also muss die Validierung pro Buchungskreis laufen, nicht nur auf Gruppenebene. Tests für jeden Kreis neu zu bauen wäre unbezahlbar. Stattdessen übertragen wiederverwendbare Templates (eine Header/Item-Validierung mit Substitutions-Mechanismus) dieselbe Logik auf jede Einheit, ohne einen einzigen Test neu zu bauen. Das ist der Unterschied zwischen einer Validierung, die auf Dutzende Buchungskreise skaliert, und einer, die es nicht tut.

Für jedes Objekt entsteht automatisch ein Nachweisbericht. Abweichungen werden mit Fachbereich und Migrationsteam bewertet, auf die Ursache zurückgeführt und entweder behoben oder erklärt. Die Abnahme ist pro Buchungskreis strukturiert (eine Freigabe auf Gruppenebene genügt nicht, wenn Berichte je Einheit unterschrieben werden), mit lückenloser Nachverfolgbarkeit vom Migrationslauf bis zur Abnahme je Einheit. In einer regulierten Bank ist ein Abgleich nicht fertig, wenn die Zahlen stimmen; er ist fertig, wenn eine verantwortliche Person mit belastbaren Nachweisen unterschrieben hat, dass sie stimmen.

Der Ansatz ist geprobt, nicht improvisiert: aufeinanderfolgende Migrationsläufe und UAT-Zyklen, die späteren Durchgänge mit produktionsnahen Daten als Generalproben. Trotzdem sind die Zeitfenster extrem knapp: Für manche Objekte muss der komplette Abgleich inklusive Abnahme in rund 30 Minuten fertig sein, über Nacht ausgeführt, sobald die Läufe abgeschlossen sind, oft ab etwa 22 Uhr bis in die frühen Morgenstunden. Nur mit automatisierten Prüfungen und sofort verfügbaren Nachweisen lässt sich ein solcher Zeitplan halten.

Die Quellsysteme hielten Milliarden Datensätze; Scope-Filter reduzierten das auf das Relevante, und Millionen Datensätze wurden je Objekt eins zu eins verglichen: über 25 Buchungskreise, 40+ gestaffelte Läufe und 150+ Objekte. Jedes Objekt im Scope erreichte eine Freigabe pro Buchungskreis, darunter viele, die den Rohvergleich nicht bestanden, aber als erwartete Abweichungen validiert wurden. Die Prinzipien lassen sich auf jede ECC→S/4HANA-Finanzmigration übertragen: die Migrationslogik in der Prüfung abbilden, mit wiederverwendbaren Templates skalieren und Nachweise sowie Freigabe je Einheit von Anfang an einplanen.