Die häufigsten Fehler nach einer S/4HANA-Migration

Die technische Migration ist abgeschlossen, das System läuft — und trotzdem beginnen jetzt die eigentlichen Probleme. Das ist keine Ausnahme, das ist der Regelfall. Wer S/4HANA-Projekte begleitet, kennt das Muster: In den ersten Wochen nach Go-Live häufen sich die Supportanfragen, die Frustration bei den Anwendern steigt, und manchmal stellt sich heraus, dass Entscheidungen aus der Projektphase nun teuer werden. Dieser Artikel zeigt, wo die häufigsten Fehler entstehen — und was sich daraus lernen lässt.

1. Change & Adoption: der unterschätzte Erfolgsfaktor

Das auffälligste Symptom nach dem Go-Live ist meistens die Oberfläche: Anwender kommen mit SAP Fiori nicht zurecht. Aber Fiori ist nicht das eigentliche Problem — es ist das sichtbare Ergebnis eines tieferliegenden Versäumnisses: fehlendes Change Management.

Eine S/4HANA-Migration verändert nicht nur das System. Sie verändert Arbeitsabläufe, Rollen, Verantwortlichkeiten und das tägliche Bedienkonzept. Wer diese Veränderung nicht aktiv kommuniziert, begleitet und trainiert, darf sich nicht wundern, wenn die Akzeptanz ausbleibt. Die Fiori-Probleme, die nach Go-Live sichtbar werden, sind dann häufig nur der Ausdruck einer tieferen Orientierungslosigkeit:

Das Bedienkonzept ist grundlegend verändert — nicht nur optisch.
Geschäftsprozesse wurden vereinfacht oder umstrukturiert, was zunächst als Erschwernis wahrgenommen wird.
Was früher in einer Transaktion erledigt wurde, ist heute auf mehrere Apps verteilt — und umgekehrt.
In vielen Systemen läuft eine Mischung aus modernen Fiori-Apps und eingebetteten GUI-Transaktionen. Das erzeugt Inkohärenz und Orientierungslosigkeit.
Das Berichtswesen funktioniert anders — Berichte werden anders aufgebaut, gefiltert und exportiert.
Die Fiori-Oberfläche ist weniger kontrastreich als die klassische GUI, was gerade für ältere Anwender oder bei ungünstiger Bildschirmeinstellung ein reales Nutzungsproblem darstellt.

Was das für Entscheider bedeutet:
Fiori-Akzeptanzprobleme sind kein Zeichen schlechter Anwender — sie sind ein Zeichen unzureichender Vorbereitung. Change Management ist kein „weiches" Thema. Es ist ein messbarer Erfolgsfaktor mit direktem Einfluss auf Produktivität, Fehlerquoten und Supportaufwand nach Go-Live.

2. Datenqualität: der eigentliche Migrationsentscheider

Stammdatenqualität gehört zu den wichtigsten Erfolgsfaktoren einer S/4HANA-Migration — und gleichzeitig zu den am häufigsten unterschätzten. Nicht die Technologie, nicht der Systemintegrator, nicht das Projektbudget entscheiden darüber, ob eine Migration reibungslos verläuft. Die Qualität der Stammdaten tut es.

Schlechte Stammdaten aus ECC landen unbereinigt in S/4HANA. Doppelte Kreditoren, veraltete Debitorenstammsätze, inkonsistente Anlagendaten, fehlerhafte Kostenstellenstrukturen — all das wird durch eine Migration nicht bereinigt, sondern mitgenommen. Und im neuen System, mit den neuen Prozessen und der neuen Datenarchitektur, werden diese Schwächen sichtbarer als je zuvor.

Ein häufiger Denkfehler:
Stammdatenbereinigung wird als „IT-Hausaufgabe" betrachtet und in der Projektplanung zu spät oder zu knapp angesetzt. Tatsächlich ist sie eine fachliche Aufgabe, die Zeit, Ressourcen und Entscheidungskompetenz aus den Fachbereichen erfordert — nicht nur aus der IT.

Wer Datenqualität ernst nimmt, beginnt mit der Bereinigung nicht kurz vor der Migration, sondern deutlich früher — und behandelt sie als eigenständigen Workstream mit klaren Verantwortlichkeiten in den Fachbereichen.

3. Trainingsstrategie: zu früh geschult, zu spät nachgeschult

Das Muster ist in fast jedem S/4HANA-Projekt dasselbe: Anwender erhalten ihre Schulung vier bis sechs Wochen vor dem Go-Live. Dann vergehen diese Wochen mit Systemtests, Datenmigration und letzten Konfigurationsarbeiten. Am Tag des Go-Live ist ein Großteil des Schulungsinhalts bereits verblasst — und die Probleme beginnen genau dann, wenn das System live ist und echte Buchungen erwartet werden.

Der Grund liegt in der Natur des Lernens: Wissen verankert sich durch Anwendung. Wer vier Wochen nach einer Schulung zum ersten Mal tatsächlich mit dem Produktivsystem arbeitet, steht häufig vor denselben Fragen wie am ersten Schulungstag.

Was wirklich hilft:
Gezieltes Nachschulen zwei bis acht Wochen nach Go-Live — dann, wenn die Anwender konkrete Erfahrungen mit dem System gemacht haben und wissen, wo ihre tatsächlichen Fragen liegen. Ein bewährtes Format dafür ist die regelmäßige FI-Sprechstunde: ein niedrigschwelliges, praxisnahes Gesprächsformat, in dem Anwender ihre konkreten Alltagsprobleme einbringen können und gezielt Antworten erhalten — kein Frontalunterricht, sondern situatives Lernen am realen Bedarf.

Für Entscheider bedeutet das: Das Trainingsbudget sollte nicht vollständig vor dem Go-Live verplant werden. Ein gezielter Nachschulungsanteil in den ersten Wochen nach Go-Live ist keine Zusatzkosten — er ist eine Absicherung des Projekterfolgs.

4. Clean Core: Z-Programme mitschleppen statt überdenken

In gewachsenen SAP-Landschaften gibt es sie in jedem Unternehmen: kundenspezifische Entwicklungen, sogenannte Z-Programme. Sie wurden gebaut, weil SAP Standard damals etwas nicht konnte — oder weil der damalige Berater es so empfohlen hat. Manche davon sind unverzichtbar. Viele davon sind es nicht mehr.

Ein häufiger Fehler im Migrationsprojekt ist es, diese Z-Programme unreflektiert in S/4HANA zu übernehmen. Das kostet Aufwand bei der Migration, erhöht die Komplexität im neuen System und verhindert genau das, was S/4HANA ermöglichen soll: schlanke, standardnahe Prozesse.

Clean Core als Leitprinzip:
SAPs Konzept des Clean Core empfiehlt, den SAP-Kern so standardnah wie möglich zu halten und Erweiterungen über definierte Schnittstellen zu realisieren — statt direkt in den Kern zu programmieren. Für Migrationsprojekte bedeutet das: Jedes Z-Programm sollte aktiv hinterfragt werden. Kann der SAP-Standard das heute abbilden? Gibt es eine Fiori-App, die die Funktion ersetzt? Jede unnötige Eigenentwicklung, die mitgenommen wird, erhöht langfristig Upgrade-, Wartungs- und Testaufwand — und bindet Ressourcen, die anderswo gebraucht werden.

Das ist keine technische Frage — es ist eine strategische. Und sie gehört auf die Agenda von Entscheidern und Projektleitern, nicht nur auf die der Entwickler.

5. Hypercare: der Go-Live ist kein Projektende

In vielen Projekten wird der Go-Live als Zieleinlauf behandelt. Das Projektteam löst sich auf, die externen Berater verlassen das Unternehmen, und die Fachbereiche werden mit dem neuen System weitgehend allein gelassen. Genau das ist einer der folgenreichsten Fehler in S/4HANA-Projekten.

Der Go-Live ist kein Ende — er ist der Beginn der kritischsten Phase. In den ersten Wochen danach treten die meisten Probleme auf: Prozesse, die im Test funktioniert haben, scheitern im Echtbetrieb an Randbedingungen. Key-User sind überlastet, weil sie gleichzeitig ihrem Tagesgeschäft nachgehen und als erste Anlaufstelle für alle Anwenderfragen dienen. Eine funktionierende Supportorganisation steht oft noch nicht.

Was Entscheider einplanen sollten:
Eine strukturierte Hypercare-Phase von typischerweise vier bis acht Wochen nach Go-Live — mit klaren Verantwortlichkeiten, ausreichend Kapazität bei Key-Usern und einer definierten Eskalationsstruktur. Wer diese Phase unterschätzt, riskiert, dass der anfängliche Frust der Anwender sich festsetzt und die Akzeptanz des neuen Systems dauerhaft beschädigt wird.

Für HR-Verantwortliche ist das besonders relevant: Key-User-Rollen müssen in der Hypercare-Phase real entlastet werden — durch temporäre Kapazitätserweiterung, klare Priorisierung oder externe Unterstützung. Wer erwartet, dass Key-User diese Phase nebenbei stemmen, wird feststellen, dass weder das Tagesgeschäft noch die Anwenderbetreuung gut funktionieren.

Die fünf Fehlerfelder auf einen Blick

Was diese Fehler gemeinsam haben

Alle fünf Fehlerfelder haben eine gemeinsame Ursache: Sie entstehen nicht im System, sondern in der Projektplanung. Change-Management-Probleme sind das Ergebnis unterschätzter Veränderungskommunikation. Datenqualitätsprobleme sind das Ergebnis zu spät angesetzter Bereinigung. Schulungsprobleme entstehen durch ein Trainingskonzept, das am falschen Zeitpunkt ansetzt. Unnötige Z-Programme überleben, weil niemand aktiv entschieden hat, sie zu hinterfragen. Und Hypercare-Probleme entstehen, weil der Go-Live als Ziel statt als Übergang verstanden wird.

S/4HANA-Projekte scheitern selten an der Technologie. Sie scheitern an der Vorbereitung und an der Nachsorge. Beides liegt im Einflussbereich von Entscheidern, Key-Usern und Projektverantwortlichen — lange bevor der erste Anwender das neue System öffnet, und noch Wochen danach.

Go-Live gelingt mit dem richtigen Trainingskonzept

Wenn Sie ein S/4HANA-Projekt planen oder bereits in der Hypercare-Phase sind — sprechen Sie mich an. Ich unterstütze Sie mit einem Trainingskonzept, das auf den tatsächlichen Lernbedarf nach Go-Live ausgerichtet ist: von der Anwenderschulung bis zur FI-Sprechstunde für den laufenden Betrieb.

Trainingskonzept anfragen