S/4HANA-Programme scheitern selten an der Technik — sie scheitern an unentdeckten Fehlern in Prozessen, Schnittstellen und Daten. Genau dort entscheidet sich, ob der Go-Live ein Stichtag oder ein Störfall wird.
Warum Testen hier anders ist
Eine S/4HANA-Transformation ist kein Releasewechsel, sondern ein Eingriff in das betriebswirtschaftliche Fundament: vereinfachtes Datenmodell, geänderte Transaktionen, Fiori statt GUI, dazu oft Custom-Code-Bereinigung und Prozess-Redesign. Das Testportfolio muss deshalb mehr abdecken als „funktioniert die neue Version“: Prozessketten Ende-zu-Ende, Schnittstellen, Berechtigungen, Datenmigration und Performance — über mehrere Testzyklen hinweg.
Die vier teuersten Fehler
- Testumfang nach Bauchgefühl: Ohne risikobasierte Priorisierung wird zu viel Unkritisches und zu wenig Geschäftskritisches getestet.
- Migrationstests zu spät: Datenqualität ist der häufigste Go-Live-Blocker — Migrationsläufe gehören in jeden Testzyklus, nicht in die letzte Woche.
- Schnittstellen unterschätzt: Umsysteme, EDI-Partner und Behördenschnittstellen brauchen eigene Testfenster und Partnertermine.
- Keine Cutover-Probe: Wer die Umstellung nicht generalprobt hat, erfährt die tatsächliche Downtime erst im Ernstfall.
Was sich bewährt hat
In unseren Programmen hat sich ein Vorgehen durchgesetzt: eine Teststrategie als Steuerungsinstrument (nicht als Pflichtdokument), risikobasierte Priorisierung gemeinsam mit den Fachbereichen, frühe Automatisierung der Regression für wiederholte Zyklen, ein belastbares Testdatenkonzept und mindestens zwei vollständige Cutover-Proben mit Zeitmessung. Ebenso wichtig: ein Berichtswesen, das dem Lenkungskreis nicht Testfall-Zahlen, sondern Geschäftsrisiken zeigt.
Fazit
Das Testkonzept ist im S/4HANA-Programm kein Anhängsel, sondern das Frühwarnsystem des gesamten Vorhabens. Wer es ernst nimmt, gewinnt Planbarkeit — wer es kürzt, bezahlt nach dem Go-Live.
Sie planen eine S/4HANA-Transformation? Unser Testmanagement begleitet Programme dieser Größenordnung — sprechen Sie uns an.