SAP S/4HANA-Migration: Warum Tests für eine erfolgreiche Migration unverzichtbar sind

Da der Support für SAP ECC und SAP R/3 im Jahr 2027 ausläuft, wächst für viele Unternehmen der Druck, ihre ERP-Landschaft zu modernisieren. Für die meisten führt dabei kaum ein Weg an SAP S/4HANA vorbei.

Der Wechsel zu S/4HANA ist jedoch alles andere als geradlinig. Viele Projekte überschreiten dabei das Budget, versäumen Fristen oder liefern nicht den erwarteten geschäftlichen Nutzen, und das, obwohl das ERP-System für fast alle Unternehmen geschäftskritisch ist. Woran liegt das? Bei der Migration handelt es sich nicht nur um ein technisches Upgrade, sondern um eine tiefgreifende geschäftliche und organisatorische Transformation. Beispielsweise scheitern viele Unternehmen daran, ihre bestehenden Geschäftsprozesse kritisch zu hinterfragen oder neu zu gestalten. Sie übertragen stattdessen alte Ineffizienzen in die neue Systemlandschaft. Ohne eine  solide QA-Strategie und den Einsatz von Automatisierung drohen nicht nur technische Risiken, sondern auch kostspielige Unterbrechungen im laufenden Betrieb.

In diesem Artikel zeigen wir Ihnen die häufigsten Testlücken, die zu Verzögerungen und Mehrkosten führen, und wie Sie eine QS-Strategie entwickeln, die Ihr Projekt absichert und Ihr Unternehmen schützt.

Das versteckte Risiko: Unterschätzung der Tests

Ein zentraler Grund für Schwierigkeiten bei S/4HANA-Migrationen ist oft fehlendes oder verspätetes Testing.

Zu oft konzentrieren sich Unternehmen vor allem auf die Überführung der bestehenden Geschäftsprozesse von der alten auf die neue Version sowie die Migration der Bestandsdaten. Dabei gehen nicht nur Chancen zur Prozessoptimierung verloren, auch die strukturierte Qualitätssicherung wird häufig vernachlässigt: Dokumentationen bleiben unvollständig, Tests erfolgen meist manuell, und klare Qualitätskriterien fehlen oft.

Die Folgen können gravierend sein:

• Der Geschäftsbetrieb wird unerwartet unterbrochen.
• Der Kundenservice gerät ins Stocken.
• Die Genauigkeit der Finanzberichterstattung leidet.

Dies sind nicht nur IT-Probleme - es sind kritische Geschäftsrisiken. Angesichts der Dringlichkeit der ECC-Frist können es sich Unternehmen nicht leisten, das Testen als nachträgliche Maßnahme zu behandeln.

Die Herausforderung verstehen

SAP-Landschaften sind selten einfach. Im Laufe der Jahre sammeln sich in den Systemen Schichten von benutzerdefiniertem Code, Integrationen von Drittanbietern und teamspezifische Workarounds an. In den meisten Unternehmen berührt SAP nahezu jede Geschäftsfunktion - von Finanzen und Logistik bis hin zu Personalwesen, Vertrieb und Produktion. Die Migration dieses Ökosystems auf S/4HANA ist kein simples Copy-Paste-Unterfangen. Das neue System bringt architektonische Vereinfachungen, funktionale Umgestaltungen und aktualisierte Best Practices mit sich. Dies erfordert ein sorgfältiges Überdenken der Art und Weise, wie die Geschäftslogik ausgeführt wird und wie sie getestet werden sollte.

Wo es anfängt, schief zu laufen: Keine Teststrategie beim Kick-off

Viele S/4HANA-Projekte beginnen mit einem starken Fokus auf Infrastruktur, Systemdimensionierung und Datenmigration. In den Kick-off-Meetings geht es um Zeitpläne, Go-Live-Ziele und Ressourcenzuweisung. Das Testen wird jedoch oft übersehen - oder als etwas behandelt, das „später“ erledigt werden kann.

Dies führt häufig zu mehreren Fallstricken:

• Testteams werden zu spät hinzugezogen, und ohne, dass sie die Geschäftsprozesse ausreichend verstehen.
• Die Quality Gates sind nicht klar definiert, so dass es schwierig ist, die Systemreife zu messen.

Statt strukturierter Testpläne verlassen sich Teams auf ungeplante, ad-hoc durchgeführte Tests, die weder dokumentiert noch wiederholbar sind – was zu Inkonsistenzen und vermeidbaren Risiken führt.

Typische Annahmen – oft zu kurz gedacht:

„Wir übernehmen einfach, was das alte System gemacht hat.“

Das führt häufig dazu, dass veraltete Prozesse übernommen werden und potenzielle Quick Wins ungenutzt bleiben.

„Die Anwender kennen die Prozesse.“

Ohne gründliche Analyse bleiben Lücken und Widersprüche bestehen. Anwender kennen in der Regel nur ihren eigenen Funktionsbereich und überblicken nicht die übergeordneten Zusammenhänge.

Diese vereinfachten Annahmen ignorieren eine wichtige Tatsache: Migrationen erfordern ein verifiziertes Verständnis sowohl des IST- als auch des SOLL-Zustands. Ohne dieses Verständnis ist es unmöglich, effektive Tests zu planen – und der Erfolg bleibt unklar.

Dokumentation ist nicht optional - sie ist grundlegend

Eine ordnungsgemäße Dokumentation wird oft als Zusatzaufwand abgetan - bei SAP-Transformationsprojekten ist sie jedoch nicht verhandelbar. Man kann nicht testen, was man nicht beschreiben kann. Die Dokumentation ist die Blaupause für jeden Test, den Sie durchführen, und hier ist, was eine gute QA-Dokumentation enthalten sollte:

1. Zentrale Test-Assets:

• Testpläne, die den Umfang, die Verantwortlichkeiten und die Einstiegs- und Ausstiegskriterien definieren
• Testfälle, die auf realen Nutzungsszenarien basieren (nicht nur positive Pfade)
• Nachvollziehbarkeitsmatrizen, die die Geschäftsanforderungen mit den Tests verbinden

2. Prozess- und Systemwissen:

• AS-IS- und TO-BE-Prozessabläufe
• Schnittstellendiagramme zur Darstellung der Systeminteraktionen
• Datenflussdokumentation und Transformationslogik

3. Wie man dies effizient aufbaut:

• Durchführung von Dokumentations-Workshops mit den Geschäftsverantwortlichen
• Extrahieren Sie Klickpfade direkt aus bestehenden SAP-Umgebungen
• Verwendung von Reverse-Engineering-Tools wie Solution Manager oder Signavio

Ohne diese Grundlage müssen die QA-Teams raten, was und wie sie testen sollen. Das führt zu unvollständiger Validierung, Hektik in letzter Minute und zu Fehlern, die erst in der Produktion auffallen. Das Ergebnis? Verzögerungen, kostspielige Nacharbeit und Beeinträchtigung der Geschäftsabläufe.

Die Realität von kundenspezifischem Code und neuen Prozessen

Die meisten ausgereiften SAP-Systeme sind voll von kundenspezifischen Entwicklungen. Diese Elemente überstehen die Migration selten unverändert. In S/4HANA müssen viele von ihnen neu geschrieben oder aufgrund von Architekturänderungen angepasst werden. Allerdings wird der benutzerdefinierte Code oft ohne angemessene Unit-Tests migriert. Das führt zu schwer erkennbaren Fehlern, die erst spät auffallen und dann kritische Prozesse wie Rechnungsstellung, Gehaltsabrechnung oder die Ausführung der Lieferkette zum Erliegen bringen können. Gleichzeitig werden mit S/4HANA neue standardisierte Prozesse eingeführt, die auf Best Practices basieren. Diese werden jedoch oft nur isoliert validiert – mit Testdaten, nicht mit echten migrierten historischen Daten. Die Folge ist, dass Workflows in der Produktion nicht funktionieren, weil wichtige Datenfelder fehlen oder sich anders verhalten als erwartet.

Daten- und Integrationsrisiken sind oft unsichtbar

Selbst wenn die Codemigration korrekt durchgeführt wird, bleiben Daten- und Schnittstellentests gefährliche Schwachstellen.

• Versteckte Daten-Mapping-Fehler: Die Datenumwandlung während der Migration erfolgt nicht immer 1:1. Wenn die Mapping-Regeln nicht vollständig validiert sind, können wichtige Felder ausgelassen oder falsch ausgefüllt werden. Diese Fehler bleiben oft unbemerkt - bis sie in nachgelagerten Prozessen zu größeren Fehlern führen.

• Fragile Schnittstellen: S/4HANA arbeitet selten in stand alone. Es ist mit Tools von Drittanbietern verbunden. Dazu gehören WMS-Systeme, Zahlungs-Gateways, Logistikanbieter und HR-Plattformen. Das Testen dieser Schnittstellen erfordert jedoch Koordination, Testumgebungen und Planung. Viele Teams unterlassen dies und gehen davon aus, dass die Dinge „einfach so“ weiterlaufen wie bisher.

• Siloed Testing = Broken End-to-End Flows: Das Testen erfolgt oft Modul für Modul. Aber Geschäftsprozesse wie Order-to-Cash oder Procure-to-Pay erstrecken sich über mehrere Bereiche. Ohne funktionsübergreifende Zusammenarbeit werden diese Abläufe selten vollständig getestet. Dies kann nach der Migration zu Betriebsstörungen führen.

Warum manuelle Tests nicht ausreichen

Manuelle Tests haben ihren Platz - aber S/4HANA-Migrationen erfordern mehr. End-to-End-Workflows in SAP umfassen oft mehrere Module, Teams und externe Systeme. Diese Abläufe manuell zu simulieren ist:

• zeitaufwändig
• fehleranfällig
• unmöglich konsistent zu wiederholen

Wo die Testautomatisierung den größten geschäftlichen Nutzen bringt

Regressionstests

Automatische Validierung von benutzerdefiniertem Code und Standardfunktionen nach jeder Aktualisierung. Tester können sich dadurch auf spezifische (neue) Funktionen konzentrieren und es wird eine höhere Testabdeckung erreicht.

Datenabgleich

Automatisierter Vergleich von Legacy- und S/4HANA-Daten über Tausende von Datensätzen hinweg. Dadurch werden Dateninkonsistenzen frühzeitig identifiziert und Risiken bei der Produktivsetzung minimiert.

End-to-End-Flows

Simulation realitätsnaher, modulübergreifender Prozesse wie Order-to-Cash oder Procure-to-Pay. Dies erhöht die Prozesssicherheit und hilft, Integrationsprobleme vor dem Go-Live zu erkennen.

UI-Automatisierung

Automatisierte Interaktion mit SAP GUI oder Fiori-Anwendungen mithilfe von Tools wie CBTA, Tricentis Tosca oder Selenium. Auf diese Weise wird die Durchführung von Tests beschleunigt und die Konsistenz über Benutzeroberflächen hinweg sichergestellt.

Performance-Skripte

Durchführung synthetischer Lasttests für kritische Batch-Prozesse wie Gehaltsabrechnungen oder Monatsabschlüsse. So werden mögliche Performance-Engpässe sichtbar, bevor sie den Betrieb stören.

Durch die Automatisierung dieser Prozesse können Unternehmen die Testzyklen von Wochen auf Tage reduzieren, ohne dabei Abstriche bei der Abdeckung machen zu müssen. Unternehmen, die nicht in die Testautomatisierung investieren, entdecken kritische Fehler oft erst während der Inbetriebnahme oder, schlimmer noch, nachdem Kunden und Geschäftsanwender bereits betroffen sind.

Die fehlende Zutat: Testautomatisierung

Ein eindrucksvolles Beispiel liefert unser Proof of Concept bei ALDI SÜD, einem der weltweit größten Lebensmittelhändler. Dort haben wir gezeigt, dass End-to-End-Testszenarien selbst in hochkomplexen, internationalen SAP-Systemen automatisiert werden können. Das PoC beweist: Testautomatisierung ist machbar und wirksam.

Dieses Beispiel kann anderen SAP-Kunden als Orientierung dienen, denn die meisten Unternehmen stehen vor typischen Herausforderungen:

• Keine Regression Suite Die meisten Teams verlassen sich auf manuelle Regressionstests, die sich nicht skalieren lassen. Ohne automatisierte Tests werden Aktualisierungen mit der Zeit immer riskanter - und jede kleine Änderung erfordert einen vollständigen manuellen Test.

• Ungenutzte SAP-Testtools  SAP bietet Tools wie CBTA und Tricentis, die für das Testen von Geschäftsprozessen entwickelt wurden. Aufgrund von Zeitdruck, fehlenden Kenntnissen oder mangelndem Bewusstsein werden diese jedoch oft ignoriert. Das ist eine verpasste Gelegenheit: Sie können das Verhalten alter und neuer Systeme schnell vergleichen und Unstimmigkeiten erkennen, bevor sie zu Problemen werden.

• Überspringen von Leistungstests Schließlich simulieren nur wenige Projekte Spitzenbelastungen - wie den Monatsabschluss, den schwarzen Freitag oder das Quartalsende. Wenn die Leistungs-Peaks nicht im Voraus simuliert und getestet wird, kann es zu unterwarteten Ausfällen und Verlangsamungen kommen, genau dann, wenn die Zuverlässigkeit am wichtigsten ist.

Fazit: Testen ist der entscheidende Faktor

Für eine erfolgreiche S/4HANA-Migration sind vielseitige Anforderungen zu berücksichtigen, von der IT-Infrastruktur und Performance, über Prozesse und Datenmodell bis hin zu Rollen-Modellen, Schnittstellen und vieles mehr. Sie erfordert gleichzeitig aber auch eine begleitende QA-Strategie mit Fokus auf:

1. Ein skalierbares Testkonzept vom ersten Tag an
2. Strukturierte, dokumentierte Validierung von Customizing- und Standardprozessen
3. Automatisierung zur Durchführung von Regressions- und Leistungstests
4. Real-World-Tests mit Live-Daten und vollständigen Workflows

Die Vernachlässigung von Tests mag in den frühen Phasen Zeit sparen - sie ist jedoch der Hauptgrund, warum SAP-Migrationen schieflaufen.

Wir von andagon helfen SAP-Kunden, kostspielige Versäumnisse beim Testen zu vermeiden durch:

• Entwurf einer auf die S/4HANA-Architektur zugeschnittenen Teststrategie
• Testautomatisierung mit CBTA, Tricentis und darüber hinaus
• Integrationsvalidierung in komplexen Umgebungen
• Leistungssimulationen vor dem Auftreten von Spitzenzeiten

Kontaktieren Sie uns  für eine SAP QA-Bewertung - und lassen Sie uns das Risiko Ihrer Migration senken, bevor es zu spät ist.