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 Business und Auditoren unterschreiben), schon. Diesen Nachweis haben wir verantwortet: die automatisierte Datenmigrations-Validierung auf Basis von Tricentis Tosca: Tricentis Data Integrity (Tosca DI) für den Datenabgleich, klassisches Tosca für die Prüfungen auf GUI-Ebene.

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, mappt und führt Datensätze unterwegs zusammen. Dazu reale Grössenordnung (hunderte Standard- und Custom-Objekte, Milliarden Datensätze über viele Rechtsträger) und ein Accounting-Go-Live, der an den Jahreswechsel gebunden ist und ohne ein ganzes Jahr Wartezeit nicht verschoben werden kann. Verifikation muss schnell, verlässlich und auditierbar zugleich sein.

Ein naiver Feld-für-Feld-Vergleich scheitert sofort, denn die Daten sollen sich ändern. Ein sinnvoller Abgleich bettet dieselben Geschäftsregeln ein, die die Migration angewandt hat, damit erwartete Abweichungen nie als Falschmeldung 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 echten Defekt klassifizieren. Genau diese Unterscheidung ist entscheidend: Sie lässt das Team die 'failed-but-expected'-Fälle bewusst abnehmen, statt tausenden berechtigten Abweichungen hinterherzujagen.

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 ziehen wiederverwendbare Templates (eine Header/Item-Validierung mit Substitutions-Mechanismus) dieselbe Logik über jede Einheit, ohne einen einzigen Test neu zu bauen: der Unterschied zwischen einer Validierung, die auf Dutzende Buchungskreise skaliert, und einer, die es nicht tut.

Jedes Objekt erzeugt einen automatisierten Evidenzreport. Abweichungen werden mit Business und Migrationsteam triagiert, 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ückenlosem Trail vom Migrationslauf bis zur Abnahme je Einheit. In einer regulierten Bank ist ein Abgleich nicht fertig, wenn die Zahlen stimmen; er ist fertig, wenn jemand Verantwortliches unterschrieben hat, dass sie stimmen, mit belastbarer Evidenz.

Der Ansatz ist geprobt, nicht improvisiert: aufeinanderfolgende Migrationsläufe und UAT-Zyklen, die späteren Runden gegen produktionsnahe Daten als Generalproben. Selbst dann sind die Fenster brutal: Für manche Objekte muss der komplette Abgleich inklusive Abnahme in rund 30 Minuten fertig sein, über Nacht gefahren, sobald Läufe abgeschlossen sind, oft ab etwa 22 Uhr bis in die frühen Morgenstunden. Automatisierte Prüfungen und sofortige Evidenz sind die einzige Art, einen solchen Zeitplan zu überstehen.

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 spiegeln, mit wiederverwendbaren Templates skalieren und Evidenz sowie Freigabe je Einheit zur Priorität machen.