Die drei häufigsten Fehler in S/4HANA-Projekten

Drei wiederkehrende Muster, die über Erfolg oder Misserfolg von ERP-Transformationen entscheiden

Für die meisten Unternehmen gehört die Migration auf SAP S/4HANA zu den größten Einzelinvestitionen der vergangenen Jahre. Angesichts des enormen Aufwands sind die Erwartungen entsprechend hoch: bessere Datenbasis für Reporting und Steuerung, schlankere Abschlussprozesse, mehr Transparenz über Segmente und Kostentreiber – das sind keine unrealistischen Versprechen, sondern legitime Ziele, die das System technisch ermöglicht.

Doch in der Realität läuft ein Großteil der Projekte nicht wie geplant. Zeitpläne verschieben sich, Budgets werden überschritten. Der erwartete Nutzen bleibt aus. Was auf den ersten Blick nach technischen Schwierigkeiten aussieht, ist bei näherer Betrachtung meist ein strukturelles Problem. In der Praxis zeigen sich unabhängig von Unternehmensgröße oder Branche drei Muster immer wieder.

01Ausgangslage

Hohe Erwartungen, ernüchternde Realität

S/4HANA-Projekte sind in ihrer Breite kaum mit klassischen IT-Vorhaben vergleichbar. Sie betreffen Kernbereiche über die gesamte Wertschöpfungskette und ersetzen nicht ein Teilsystem, sondern die zentrale Systemlandschaft Dabei werden Prozesse, Datenstrukturen und Organisationsrollen in einem Zug verändert. Beteiligt sind interne IT-Abteilungen, Finance-Teams, Fachbereiche und externe Implementierungspartner. Sie alle bringen unterschiedliche Prioritäten, unterschiedliche Arbeitsweisen und ein unterschiedliches Verständnis von Erfolg mit.

Dabei liegt in dieser Komplexität eine echte Chance. Richtig aufgesetzt, kann S/4HANA Monatsabschlüsse beschleunigen, Steuerungslogik modernisieren, Reporting-Strukturen konsolidieren und Finance-Teams von manuellen Zwischenschritten entlasten. Das Potenzial ist real, aber es erfordert weit mehr als die technische Einführung.

Was sich in der Praxis immer wieder zeigt: Die kritischsten Weichenstellungen liegen nicht in der eigentlichen Umsetzungsphase. Sie liegen früher: im Projektaufbau, in der Zieldefinition, in der Klärung, wer was mit welchem Auftrag steuert. Und sie liegen am Ende, in der Frage, wie die Transformation wirklich abgeschlossen und in den Regelbetrieb überführt wird. Diese beiden Phasen werden typischerweise unterschätzt. Daraus entstehen Muster, die sich in den meisten S/4HANA-Projekten in ähnlicher Form wiederholen. Drei davon treten besonders häufig auf.

02Einordnung

Fehler 1: Das Projekt startet als IT-Vorhaben

Fehlendes fachliches Zielbild

Ein häufiger und besonders folgenreicher Fehler liegt bereits in der Einordnung: S/4HANA-Transformationen werden als IT-Projekte gestartet – mit technischem Auftrag, technischer Projektlogik und oft auch technischer Führung. Was dabei fehlt, ist ein fachliches Zielbild. Zu Projektbeginn ist nicht definiert, wie Finance-Prozesse nach der Migration aussehen sollen. Welche Steuerungslogik gilt künftig? Wie verändert sich das Controlling? Welche Anforderungen stellt das Unternehmen an sein künftiges Reporting – nicht technisch, sondern inhaltlich? Bleiben diese Fragen offen, werden sie im Verlauf der Umsetzung aus IT-Sicht beantwortet. Konfigurationsentscheidungen werden implizit zu Prozessentscheidungen und setzen sich ohne fachliche Führung durch.

Die Folgen zeigen sich meist schnell: Anforderungen bleiben unscharf und Prioritäten verschieben sich mit jedem Quartal. Das Projekt verliert seinen Fokus und mit jeder neuen Herausforderung wandelt sich eine aktive Steuerung zu einer reaktiven Problembehebung.

Systemlogik ersetzt Business-Logik

Mit der IT als Treiber rücken vor allem Funktionen im System, Customizing-Entscheidungen und technische Schnittstellen in den Vordergrund. Das ist nachvollziehbar: Es sind die Themen, die sich im Projekt unmittelbar bearbeiten lassen. Was dabei zu kurz kommt, ist die Frage, wie das Unternehmen künftig tatsächlich arbeiten und steuern will.

Genau hier wird die zentrale Lücke zwischen IT und Business sichtbar: IT denkt in Systemen, Anforderungsdokumenten und Deployments. Finance denkt in Prozessen, Steuerungslogik und alltäglichem Nutzen. Wenn diese Perspektiven nicht bewusst zusammengeführt werden, fehlt die gemeinsame Grundlage für Anforderungen und Entscheidungen.

Als Konsequenz werden bestehende Prozesse im neuen System abgebildet – inklusive ihrer Ineffizienzen. Es entstehen Lösungen, die technisch funktionieren, aber nicht zur Steuerungslogik des Unternehmens passen. Prozesse laufen im System, aber nicht im Alltag. Im Projektverlauf häufen sich Nachbesserungen, mit wachsendem Frust in der IT ebenso wie in den Fachbereichen.

Fachliche Steuerung von Beginn an verankern

Projekte, die ohne klare fachliche Leitplanken starten, setzen von Beginn an falsche Prioritäten. Die Orientierung fehlt, und spätere Korrekturen sind nicht nur aufwendig, sondern auch teuer: Je später ein Steuerungsdefizit sichtbar wird, desto tiefer hat es sich bereits in Projektentscheidungen eingeschrieben.

Was hilft, ist eine frühzeitige Verankerung im Business: ein klares fachliches Zielbild, eine aktive Rolle des CFO von Beginn an und eine tragfähige Steuerungslogik, bevor zentrale Systementscheidungen getroffen werden. Diese fachliche Klärung darf keinesfalls unterschätzt werden, denn sie ist die Voraussetzung für alle weiteren Projektentscheidungen.

03Vorbereitung

Fehler 2: Die Vorbereitung wird unterschätzt

Der zweite häufige Fehler hängt mit dem ersten zusammen, ist aber eigenständig: Projekte starten, bevor die fachlichen, organisatorischen und wirtschaftlichen Grundlagen ausreichend geklärt sind. Die Vorbereitung wird als notwendige Formalität behandelt und nicht als kritische Phase, die über den Projekterfolg entscheidet.

Unklare Planungsgrundlage

Zielbild, Roadmap und Projektumfang sind zu Beginn oft nicht hinreichend konkretisiert. Der gewählte Transformationsansatz – etwa Greenfield versus Brownfield – ist nicht ausreichend validiert. Zentrale Annahmen zu Prozessen, Daten und systemischen Abhängigkeiten sind nicht geprüft. Projektauftrag und Ziele sind nicht verbindlich definiert. Hinzu kommt: Auch Projektmethodik, Governance und die Rolle des Implementierungspartners sind zu diesem Zeitpunkt in vielen Fällen noch nicht ausreichend geklärt. Wird der Implementierungspartner zu spät oder ohne klare Bewertungslogik ausgewählt, fehlt dem Projekt von Beginn an eine belastbare Steuerungsstruktur.

Was folgt, ist absehbar: Umfang und Prioritäten werden im Projektverlauf ständig angepasst, wodurch die Planung ihre Stabilität verliert. Entscheidungen werden situativ statt strukturiert getroffen – weil die Grundlage fehlt, auf der sie fundiert getroffen werden könnten.

Business Case ohne Substanz

Erwartete Nutzen wie Effizienzgewinne, bessere Steuerungsfähigkeit oder höhere Transparenz werden häufig benannt, aber nicht konkret quantifiziert. Potenziale im Business werden nicht systematisch analysiert, und Zielkonflikte zwischen Bereichen bleiben ungelöst.

Das hat praktische Konsequenzen: Wenn im laufenden Projekt wirtschaftliche Abwägungen notwendig werden – Scope-Entscheidungen, Priorisierungen, Kostenverschiebungen – fehlt die belastbare Grundlage, um diese Entscheidungen nachvollziehbar zu treffen. Diskussionen über Zielrichtung und Nutzen beginnen erst dann, wenn sie eigentlich längst geklärt sein sollten. Für den CFO bedeutet das: Er kann Kosten, Nutzen und Prioritäten im Projekt schwer steuern, weil die Referenzgröße fehlt.

Prozesse, Daten und Methodik

Bestehende Prozesse werden nicht systematisch analysiert und hinterfragt. Verantwortung für Prozesse und End-to-End-Zusammenhänge ist weder inhaltlich noch organisatorisch klar definiert. Die Kapazitäten von Prozessspezialisten in den Fachbereichen sind nicht gesichert – obwohl genau diese Personen das operative Wissen mitbringen, das das Projekt braucht.

Erschwerend kommt hinzu, dass ohne klare Methodik für Prozessanalyse und Prozessdesign häufig ein gemeinsamer Rahmen fehlt, um Anforderungen zu strukturieren, End-to-End-Zusammenhänge sichtbar zu machen und Prozessentscheidungen belastbar vorzubereiten. Gerade weil S/4HANA unterschiedliche Bereiche wie Finance, Logistik und weitere Funktionen berührt, braucht es eine methodische Klammer, die fachliche Unterschiede berücksichtigt, ohne die Gesamtsteuerung zu verlieren.

Zwei weitere Themen werden regelmäßig zu spät adressiert: Datenqualität und Stammdaten. Data Cleansing und eine klare Migrationsstrategie für Stammdaten fehlen häufig in der Vorbereitungsphase – und treten dann kurz vor dem GoLive als akutes Problem auf, wenn der Zeitdruck am größten ist.

Unrealistische Zeit-, Budget- und Ressourcenplanung

Aufwand und Komplexität werden zu Beginn fast immer zu optimistisch eingeschätzt. Interne Ressourcen sind nicht ausreichend eingeplant, da die Mitarbeitenden, die Prozesswissen mitbringen und Entscheidungen im Projekt treffen müssen, gleichzeitig im Tagesgeschäft gebunden sind. Ihre Erreichbarkeit ist eingeschränkt, obwohl genau sie bei Problemen gefragt sind. Abhängigkeiten zwischen Workstreams und Risiken werden unterschätzt.

In der Folge werden Zeitpläne nicht eingehalten und Budgets steigen. Die Organisation ist über lange Strecken des Projekts hoch belastet – was die Qualität der Ergebnisse zusätzlich erschwert.

Das eigentliche Problem dabei ist nicht, dass Probleme entstehen, das ist in komplexen Projekten unvermeidlich. Das Problem ist, dass viele dieser Probleme in der Vorbereitungsphase identifizierbar und beherrschbar gewesen wären. In der Umsetzung werden sie sichtbar, aber deutlich schwerer zu lösen.

Vorbereitung als eigene Erfolgsphase verstehen

Vorbereitung ist keine Vorleistung, die man minimieren sollte, um schneller in die Umsetzung zu kommen. Sie ist die Phase, in der die Weichen für alles Weitere gestellt werden. Operative Probleme, die sich durch den Projektverlauf ziehen – steigende Kosten, sinkende Planbarkeit, reaktive Entscheidungen – haben ihren Ursprung fast immer hier.

04Verankerung

Fehler 3: Erfolg wird am GoLive gemessen

Der dritte strukturelle Fehler tritt am Ende auf: Die Phase nach dem GoLive wird nicht konsequent als Teil der Transformation geplant. Der technische GoLive markiert in vielen Projekten faktisch den Abschluss. Das System ist produktiv, die Projektorganisation löst sich auf, Verantwortung geht zurück in die Linie. Damit gilt das Projekt als abgeschlossen. Was dabei übersehen wird: Der GoLive ist kein Endpunkt, er ist vielmehr der Beginn der eigentlichen Nutzung.

Organisation nicht ausreichend vorbereitet

Mitarbeitende wurden geschult, aber nicht auf den realen Arbeitsalltag vorbereitet. Neue Prozesse sind dadurch nicht ausreichend eingeübt. Der Unterschied zwischen Testumgebung und tatsächlicher Nutzung im laufenden Betrieb wird in der Regel unterschätzt. Rollen, Verantwortlichkeiten und Zusammenarbeit sind nach dem GoLive oft noch ungeklärt. Und ein aktives Business-seitiges Management organisatorischer Veränderungen – das, was unter dem Begriff Change Management oft firmiert – fehlt in vielen Projekten weitgehend.

Das führt unweigerlich dazu, dass Prozesse im Alltag nicht stabil funktionieren, was wiederum zu Frust unter den Mitarbeitenden führt. Im schlimmsten Fall greifen diese wieder auf alte Arbeitsweisen zurück – ein kritischer Zustand, weil das Unternehmen dann das neue System betreibt, aber nach der alten Logik arbeitet. Die erwarteten Effizienzgewinne können dadurch nicht erreicht werden.

Stabilisierung und nachhaltige Verankerung

Hypercare-Phasen sind zeitlich begrenzt und adressieren vor allem akute Systemprobleme. Was sie nicht leisten, ist die nachhaltige Verankerung neuer Prozesse und Arbeitsweisen in der Organisation. Die eigentliche Herausforderung liegt in den Monaten nach dem GoLive – wenn neue Prozesse unter realen Betriebsbedingungen etabliert werden müssen, während der Betrieb läuft.

Häufig fehlt für diese Phase ein klarer Plan, und Prozessverantwortlichkeiten für den Regelbetrieb sind nicht definiert. Eine Prozessmanagementorganisation, die den laufenden Betrieb steuert und Weiterentwicklungen koordiniert, wird nicht aufgebaut. Das ist mehr als ein organisatorisches Detail: SAP S/4HANA wird kontinuierlich weiterentwickelt. Neue Funktionen und Features müssen aktiv eingeführt werden. Wer dafür keine Strukturen aufbaut, schöpft das System dauerhaft nur zu einem Bruchteil seiner Möglichkeiten aus.

Probleme, die in der Hypercare-Phase noch verborgen bleiben, treten erst im laufenden Betrieb vollständig zutage. Prozesse und Arbeitsweisen werden nicht nachhaltig angepasst. Der Projekterfolg bleibt hinter dem zurück, was möglich gewesen wäre.

GoLive als Übergang in die Nutzung planen

Das System ist produktiv, aber Prozesse sind ineffizient oder instabil, und der erwartete Nutzen bleibt aus. Zusätzlicher Aufwand entsteht, Frustration wächst. Was als Erfolg verbucht wurde, entpuppt sich rückblickend als halbfertiger Zustand.

Die Praxis zeigt: Cutover, GoLive und Ramp-up müssen frühzeitig gemeinsam mit dem Business geplant werden. Die Stabilisierungsphase ist kein Anhang, sondern ein eigenständiger Abschnitt mit eigenen Zielen, eigenen Verantwortlichkeiten und eigenen Steuerungsmechanismen. Dazu gehören auch ein strukturiertes Monitoring, die Priorisierung offener Themen und eine aktive Nachsteuerung im laufenden Betrieb.

Ebenso wichtig ist ein businessseitiges Change Management, das neue Prozesse, Rollen und Arbeitsweisen nicht nur kommuniziert, sondern im Alltag verankert. Cutover, Ramp-up und Post-GoLive gehören in die Projektplanung, und zwar als vollwertige Phase.

05Erfolgsfaktoren

Was erfolgreiche S/4HANA-Projekte auszeichnet

Erfolgreiche S/4HANA-Projekte unterscheiden sich von gescheiterten nicht allein durch bessere Technologie oder leistungsfähigere Implementierungspartner. Sie unterscheiden sich vor allem durch ein anderes Grundverständnis dessen, was in der Transformation stattfindet.

S/4HANA ist kein IT-Projekt mit fachlicher Begleitung. Es ist ein fachlich gesteuerter Umbau zentraler Unternehmensprozesse – mit IT als Enabler, nicht als Treiber. Daraus ergeben sich klare Prioritäten:

Damit verbunden ist eine bewusste Verschiebung des Fokus: weg von schneller Umsetzung hin zu strukturierter Vorbereitung, weg von technischer Implementierung hin zu fachlicher Steuerung, weg vom GoLive als Zielpunkt hin zur nachhaltigen Nutzung im Alltag.

S/4HANA ist kein reines Implementierungsprojekt. Es ist eine umfassende Veränderung von Prozessen, Organisation und Steuerungslogik. Wer das in der Planung, in der Governance und in der Projektführung konsequent berücksichtigt, schafft die Voraussetzungen dafür, dass der Nutzen, den das System verspricht, tatsächlich realisiert wird.

Mehr zur S/4HANA-Transformation mit 4C