S/4HANA-Migration: Verzögerung vorprogrammiert?
SAP S/4HANA-Transformationen sind äußerst komplex und verlaufen oft nicht wie geplant – oder scheitern sogar ganz. Lässt sich das verhindern?
Obwohl ein integriertes Qualitätsmanagement die Migration begleiten sollte, spielt das Thema im aktuellen Diskurs rund um die SAP S/4HANA-Transformation oftmals noch eine Nebenrolle. Warum scheitern oder verzögern sich S/4HANA-Migrationen?
Roman Zednik: Es gibt eine Reihe von Herausforderungen, an denen S/4HANA-Transformationen scheitern können – die schiere Komplexität in Kombination mit hochgradig individualisierten Altsystemen etwa oder aufgrund einer mangelnden Change-Management-Strategie. Aber auch ein fehlender Fokus auf Qualitätssicherung und Testautomatisierung ist ein häufiger Grund. Die Migrationsprojekte laufen minimal über mehrere Monate, oftmals jedoch über mehrere Jahre hinweg, in denen Alt- und Neusystem parallel in Betrieb sind und stetig aktualisiert und überprüft werden müssen. Der Testaufwand erhöht sich sogar, da notwendige Veränderungen während dieses Zeitraums in beiden Systemen vorgenommen werden müssen. Dies bindet wertvolle Ressourcen bei den beteiligten Mitarbeitern – und der Aufwand wird zumeist deutlich unterschätzt. Auch kontinuierlich Vergleichs- und Integrationstests durchzuführen, ist elementar. Nur so lässt sich sicherstellen, dass geschäftskritische Prozesse zu jedem Zeitpunkt stabil laufen. Wer die Transformation tatsächlich ohne Qualitätssicherung und Testautomatisierung durchführt, fährt ein sehr hohes Risko – das ist, als würde man ein Flugzeug ohne Radar fliegen.
Warum fällt es Unternehmen so schwer, den Wert von Quality Engineering bei SAP-Transformationen zu sehen?
Roman Zednik: Qualitätssicherung wird häufig noch als Pflichtübung und nicht als essenzieller Bestandteil der Transformation betrachtet. Die Umstellung auf S/4HANA ist ein ganz anderes Kaliber als frühere Migrationen. Es reicht nicht mehr aus am Ende eine Testphase einzuplanen. Die Architektur ist komplexer, stärker vernetzt und verlangt eine gründliche Planung. Wenn Sie Quality Engineering als Nebensache betrachten, riskieren Sie, im laufenden Betrieb auf unerwartete Schwierigkeiten zu stoßen. Das kann nicht nur in Produktionsausfällen enden, sondern auch geschäftskritische Prozesse ins Stocken bringen.
Ab wann sollte Quality Assurance bei der Migration Thema sein?
Roman Zednik: Am sinnvollsten ist, sie von Anfang an zu integrieren. Das gilt unabhängig davon, welchen Transformationsansatz das Unternehmen verfolgt – ob Greenfield, Brownfield oder Bluefield. Schon in der Planungsphase geht es darum, die QA-Strategie klar festzulegen: Welche Tests brauchen wir? Wer im Team bringt die nötigen Skills mit? Und wo und wann wird Testautomatisierung eingesetzt? Durch den Einsatz von wiederverwendbaren Testfällen lässt sich vieles vereinfachen. Fehler sollen frühzeitig gefunden werden, was die traditionelle Hypercare-Phase nach dem Go-Live nicht mehr notwendig macht, um Probleme in der Produktion nachträglich auszubügeln.
Wie hoch ist der Testaufwand für die Unternehmen?
Roman Zednik: Laut Expertenschätzungen entfallen fast ein Drittel der Transformationskosten auf qualitätssichernde Maßnahmen. Auch das bestehende ERP-System muss bis zur Abschaltung weiter gepflegt und regelmäßig getestet werden. Das alleine bringt schon einen höheren Testaufwand mit sich. Aufwendig sind auch die notwendigen Vergleichstests. Schließlich muss gewährleistet bleiben, dass Geschäftsprozesse nach der Migration noch das richtige Ergebnis liefern. Um das zu überprüfen, baut man zunächst einen Testfall im Altsystem auf und überträgt diesen anschließend in die S/4HANA-Umgebung. Die Ergebnisse können dann automatisiert verglichen werden.
Und dann sind da noch die Regressionstests, die sicherstellen, dass alle Geschäftsprozesse nach Änderungen stabil bleiben. Die Vielzahl der Abhängigkeiten im SAP-Umfeld kann leicht zu Tausenden von Testfällen führen. Hier lohnt sich eine Automatisierung besonders: Die Tests können dann regelmäßig nach Veränderungen am System über Nacht laufen – ohne zusätzlichen Aufwand für das Team.
Wie kann KI im Quality Engineering unterstützen?
Roman Zednik: Wie in vielen Bereichen ist KI auch in der Qualitätssicherung ein Werkzeug mit enormem Potenzial, das es zu nutzen gilt. Ihre Stärke liegt in der Analyse und bei repetitiven Aufgaben. Zum Beispiel kann sie Testfälle automatisch priorisieren, helfen die richtigen Testfälle zu selektieren und Testfälle automatisch ergänzen, die wir vielleicht übersehen hätten. Auch in der Wartung von Testfällen kann KI unter anderem durch Self-Healing-Ansätze unterstützen. Aber wir sollten nicht erwarten, dass sie uns die Verantwortung für ein durchdachtes Qualitätsmanagement abnimmt. KI hilft uns, das Ruder besser im Griff zu haben, aber das Steuern müssen wir selbst erledigen.
Wie geht es nach der erfolgreichen Transformation weiter?
Roman Zednik: Der ROI für Testautomatisierung rechnet sich bereits nach sechs bis zwölf Monaten – und auch nach der S/4HANA-Migration bleibt sie ein Muss. Das neue Cloud-ERP bringt schnellere Release-Zyklen mit sich, und die regelmäßigen Updates und Anpassungen brauchen ein zügiges Testing. Manuelle Prozesse wären hier einfach zu langsam und zu teuer. Die QA-Teams wären schnell wieder überlastet.
Testautomatisierung mit vorgelagerter Change-Impact-Analyse hilft, genau das zu testen, was verändert wurde und was geschäftskritisch ist. In vielen Projekte wird entweder zu wenig oder teilweise sogar zu viel getestet. Auch das ist Teil einer integrierten Qualitätssicherungsstrategie. Hier kann KI ebenfalls unterstützen: Sie repariert Testfälle, wenn sich in der Entwicklung etwas ändert, erstellt neue Testfälle und identifiziert Risiken – ein echter Boost für die Qualitätssicherung.
Ihr wichtigster Rat für Unternehmen, die vor der SAP-Transformation stehen?
Roman Zednik: Setzen Sie Quality Engineering von Anfang an als strategisches Element ein. Es sollte direkt in die Planungsphase einfließen – ob bei Greenfield-, Brownfield- oder Bluefield-Ansätzen. Sinnvoll ist auch, das Know-how von erfahrenen externen Experten in Anspruch zu nehmen. SAP-Transformationen sind kein Spielplatz für Trial-and-Error. Die richtigen Partner, klare Strukturen und gezielte Automatisierung sparen Zeit, Geld und Nerven.
Roman Zednik
ist Field CTO bei Tricentis.