Testmanagement bei S4HANA-Migration richtig steuern

Ein nicht abgestimmter Preisfindungsprozess, eine fehlende Berechtigung im Warenausgang oder eine unvollständige Übergabe an das Lagerverwaltungssystem kann den Go-Live einer S/4HANA-Transformation unmittelbar gefährden. Testmanagement bei S4HANA Migrationen ist deshalb keine nachgelagerte Qualitätssicherung. Es ist die operative Steuerungsfunktion, die nachweist, ob Geschäftsprozesse, Daten, Rollen und Integrationen unter realistischen Bedingungen tragfähig sind.

Gerade in mittelständischen Unternehmen und größeren Organisationen treffen dabei enge Zeitpläne auf gewachsene Systemlandschaften. Nicht nur das neue S/4HANA-System muss funktionieren. Entscheidend ist das Zusammenspiel mit angebundenen Anwendungen, Datenlieferanten, Berechtigungskonzepten, Druck- und Archivsystemen sowie den tatsächlichen Arbeitsabläufen der Fachbereiche. Ein belastbares Testvorgehen übersetzt diese Abhängigkeiten in prüfbare Szenarien, klare Verantwortlichkeiten und nachvollziehbare Entscheidungen.

Warum einzelne Fachtests nicht ausreichen

Viele Projekte beginnen mit positiven Ergebnissen aus Modul- oder Customizing-Tests. Das ist notwendig, aber für eine Freigabe nicht ausreichend. Ein Prozess kann im Vertrieb korrekt starten und dennoch scheitern, wenn die Kreditprüfung anders reagiert, ein Steuerschlüssel bei der Übergabe an Finance fehlt oder die Schnittstelle zum Transportdienstleister fehlerhafte Statusmeldungen erzeugt.

Die kritischen Fehler entstehen oft an Prozessgrenzen. In einer Migration aus ECC nach S/4HANA verändern sich Datenmodelle, Fiori-basierte Arbeitsweisen, Berechtigungsmuster und technische Integrationen gleichzeitig. Auch wenn ein Fachbereich seine Transaktionen geprüft hat, bleibt offen, ob ein Ende-zu-Ende-Vorgang mit realistischen Daten, Rollen und Mengen durchläuft.

Das gilt besonders für Unternehmen mit regulatorischen und betrieblichen Anforderungen. In Energieversorgung, Chemie oder Life Sciences müssen Prozessnachweise, Freigaben und Datenherkünfte häufig auch nach dem Go-Live überprüfbar bleiben. Testnachweise dienen dann nicht nur der Projektkommunikation. Sie schaffen eine belastbare Grundlage für revisionssicheres Reporting, interne Kontrollen und die Entscheidung, welche Restrisiken bewusst akzeptiert werden können.

Testmanagement bei S4HANA-Migrationen beginnt mit dem Risikobild

Der Testumfang sollte nicht allein aus einer Liste vorhandener Transaktionen entstehen. Sinnvoller ist eine risikoorientierte Betrachtung: Welche Prozesse sichern Umsatz, Lieferfähigkeit, Liquidität, Produktion oder regulatorische Pflichten? Wo bestehen viele Systemwechsel? Welche Daten wurden transformiert, bereinigt oder neu zugeordnet? Und welche Funktionen müssen am ersten Produktionstag ohne manuelle Umgehungslösungen laufen?

Aus diesen Fragen entsteht eine Testlandkarte. Sie verbindet Geschäftsprozesse mit beteiligten Organisationseinheiten, Anwendungen, Schnittstellen, Rollen, Datenobjekten und verantwortlichen Personen. Ein Auftragseingang kann beispielsweise nicht nur SD betreffen, sondern Kreditmanagement, Verfügbarkeitsprüfung, Steuerfindung, EDI, Auslieferung, Fakturierung und Buchhaltung. Erst diese Sicht macht den tatsächlichen Prüfbedarf sichtbar.

Priorisierung ist dabei unvermeidbar. Nicht jedes historische Sonderverfahren rechtfertigt denselben Testaufwand. Ein selten genutzter Bericht lässt sich anders behandeln als die tägliche Auftragsabwicklung oder der Monatsabschluss. Die Projektleitung braucht hierzu transparente Kriterien: Schadenshöhe bei Fehlern, Eintrittswahrscheinlichkeit, Änderungsgrad, Integrationsdichte und Möglichkeiten zur manuellen Kompensation. So wird erkennbar, welche Szenarien zwingende Freigabekriterien sind und wo ein begründetes Restrisiko vertretbar bleibt.

Testfälle müssen fachliche Ergebnisse beweisen

Ein Testfall ist erst dann aussagekräftig, wenn er nicht nur Klicks beschreibt, sondern ein erwartetes Geschäftsergebnis. Dazu gehören Ausgangsdaten, benötigte Berechtigungen, Prozessschritte, erwartete Belege und Statuswerte sowie klare Prüfpunkte in angebundenen Systemen. Bei einer Datenmigration reicht es etwa nicht aus, dass ein Debitor in S/4HANA vorhanden ist. Geprüft werden müssen auch Kontengruppen, Zahlungsbedingungen, Steuerdaten, offene Posten, Dublettenregeln und die Verwendbarkeit im Folgeprozess.

Fachbereiche sollten diese Erwartungen verantworten, während das zentrale Testmanagement Methode, Terminierung, Abdeckung und Evidenzen steuert. Werden Testfälle ausschließlich technisch formuliert, bleiben fachliche Fehlinterpretationen unentdeckt. Werden sie ausschließlich durch Fachbereiche gepflegt, fehlen häufig Systemabhängigkeiten und ein konsistenter Nachweisstandard.

Testdaten und Testsysteme sind Produktionsfaktoren

Ein häufiger Engpass liegt nicht im Schreiben von Testfällen, sondern in der Verfügbarkeit geeigneter Daten. Testdaten müssen realistisch genug sein, um Sonderfälle, Mengenstaffeln, Werk-Konstellationen, Steuerlogiken und Berechtigungsprüfungen abzubilden. Gleichzeitig dürfen personenbezogene oder vertrauliche Informationen nicht unkontrolliert in Testumgebungen übernommen werden. Hier sind klare Verfahren zur Auswahl, Maskierung, Bereitstellung und Löschung erforderlich.

Auch die Systemlandschaft muss steuerbar sein. Wenn Schnittstellen nur zeitweise verfügbar sind, Transporte ungeplant eingespielt werden oder mehrere Teams dieselben Mandanten nutzen, werden Testergebnisse kaum vergleichbar. Das Testmanagement benötigt deshalb abgestimmte Testfenster, einen definierten Transportkalender und Regeln für Daten-Resets. Für integrierte Testläufe sollte vorab feststehen, welche Schnittstellen, Batch-Jobs und externen Services aktiv sind.

Besondere Aufmerksamkeit verdienen migrierte Daten. Ein technisches Ladeprotokoll bestätigt lediglich, dass Datensätze verarbeitet wurden. Fachlich relevant wird die Migration erst, wenn Stichproben und abgestimmte Kontrollsummen belegen, dass die Daten vollständig, korrekt und im Zielprozess verwendbar sind. Bei großen Datenmengen bieten sich risikobasierte Stichproben, Summenabgleiche und gezielte Prüfungen kritischer Ausnahmen an. Welche Nachweistiefe angemessen ist, hängt von Datenvolumen, Fehlerfolgen und Kontrollanforderungen ab.

Defects steuern statt Fehler nur zu sammeln

Eine lange Fehlerliste ist kein Qualitätsindikator. Entscheidend ist, ob jedes Ticket verständlich beschrieben, fachlich priorisiert, einem Verantwortlichen zugeordnet und nach der Korrektur wirksam nachgetestet wurde. Ohne eindeutige Regeln entstehen Dubletten, falsche Schweregrade und Diskussionen darüber, ob ein Fehler ein Schulungsthema, eine Konfigurationslücke, ein Datenproblem oder ein tatsächlicher Softwaremangel ist.

Ein belastbarer Prozess unterscheidet mindestens zwischen dokumentierten Beobachtungen, validierten Fehlern, Change Requests und akzeptierten Abweichungen. Für kritische Fehler müssen Eskalationswege und Entscheidungsfristen gelten. Besonders wirksam ist ein regelmäßiges Defect-Triage mit Fachbereich, IT, Entwicklung, Integration und Projektleitung. Dort wird nicht nur der Status aktualisiert, sondern die Auswirkung auf Prozess, Terminplan und Go-Live-Entscheidung bewertet.

Kennzahlen helfen, wenn sie eine konkrete Steuerungsfrage beantworten. Aussagekräftig sind etwa die Abdeckung kritischer Szenarien, die Erfolgsquote abgeschlossener Testfälle, die Zahl offener Fehler nach Schweregrad, das Alter kritischer Tickets und die Nachtestquote. Eine einzelne Gesamtquote kann dagegen täuschen: Ein Projekt mit vielen erfolgreich getesteten Nebenprozessen kann dennoch nicht go-live-fähig sein, wenn ein kritischer End-to-End-Prozess offen bleibt.

Der Cutover braucht eigene Testbeweise

Der produktive Übergang wird häufig zu spät als Testgegenstand behandelt. Dabei ist der Cutover ein Prozess mit Abhängigkeiten, Verantwortlichkeiten und Zeitvorgaben. Datenextraktion, letzte Buchungen im Altsystem, Sperrkonzepte, Migration, Validierung, Schnittstellenaktivierung und Betriebsübergabe müssen unter Zeitdruck zusammenspielen. Ein fachlich korrektes Zielsystem reicht nicht aus, wenn der Ablauf nicht innerhalb des verfügbaren Wartungsfensters beherrscht wird.

Ein Cutover-Probelauf sollte deshalb die tatsächliche Reihenfolge, realistische Durchlaufzeiten und klar benannte Abnahmepunkte abbilden. Abweichungen sind kein Scheitern des Probelaufs, sondern verwertbare Erkenntnisse. Sie zeigen, wo Arbeitspakete parallelisiert, Datenprüfungen automatisiert, Entscheidungen vorgezogen oder Rückfalloptionen präzisiert werden müssen.

Die Go-Live-Freigabe benötigt schließlich mehr als ein grünes Statussignal. Sie sollte auf einer dokumentierten Bewertung beruhen: Sind kritische Szenarien erfolgreich durchgeführt? Welche Fehler sind noch offen, und wer trägt die Entscheidung über das Restrisiko? Sind Betriebsverantwortliche, Supportwege und Monitoring vorbereitet? Diese Transparenz schützt die Projektleitung vor einer rein terminorientierten Freigabe und schafft eine nachvollziehbare Entscheidungsbasis.

Teststeuerung als operative Projektbegleitung

Quteco unterstützt S/4HANA-Projekte mit Testmanagement, das fachliche Prozesssicht, technische Integration und Cutover-Planung zusammenführt. Ein Quick Check oder Workshop kann zunächst Testumfang, Verantwortlichkeiten, Datenlage, Defect-Prozess und Freigabekriterien bewerten. In der operativen Projektbegleitung werden daraus steuerbare Testzyklen, belastbare Testnachweise und ein Reporting, das Risiken für Projektleitung und Fachbereiche konkret sichtbar macht.

Ein guter Testabschluss ist nicht die Meldung, dass alle Fälle ausgeführt wurden. Entscheidend ist, dass die Organisation vor dem Go-Live weiß, welche Prozesse unter welchen Bedingungen belastbar funktionieren, welche Abweichungen noch bestehen und wer sie im stabilen Betrieb verantwortet.