SAP S/4HANA Projekte: Warum scheitern Projekte

Warum scheitern SAP S/4HANA-Projekte häufig? Projektsponsoren stellen diese Frage zunehmend dann, wenn Statusberichte kein verlässliches Bild mehr zeichnen, Meilensteine sich verschieben und das Budget davonläuft. Die Antwort überrascht viele Verantwortliche noch immer: Das Problem ist kein technisches. Es ist ein Führungsproblem.

Technologie versagt selten in sich selbst. Systeme liefern das, was man ihnen vorgibt. Studien aus der DACH-Region zeigen, dass Governance-Versagen und unzureichende Projektvorbereitung weit häufiger als Systemfehler die eigentlichen Ursachen sind. Scheitern beginnt früher: in unklaren Entscheidungsstrukturen, fehlender Datenvorbereitung und einem Change-Management, das als Kommunikationsaufgabe behandelt wird statt als strategische Führungsverantwortung.

Dieser Artikel zeigt die tatsächlichen Ursachen für das Scheitern von S/4HANA-Projekten: belegt durch aktuelle Daten aus der DACH-Region, geordnet nach Wirkhebel und ergänzt durch konkrete Maßnahmen, die Sponsoren sofort einsetzen können.

60 Prozent aller S/4HANA-Projekte in der DACH-Region reißen Budget und Zeitplan, so das Ergebnis der Horváth-Studie 2025. Nur 8 Prozent der Unternehmen schließen ihr Projekt ohne Zeitplanüberschreitung ab. 65 Prozent melden erhebliche Qualitätsmängel nach dem Go-Live (Horváth/Techconsult). Das ist kein Randphänomen, das ist der Regelfall.

Diese Projekte scheitern selten vollständig. Die meisten erreichen irgendwann den Go-Live. Doch der Unterschied zwischen „formal abgeschlossen“ und „wirklich erfolgreich“ ist groß. Im Schnitt überschreiten Projekte, die das Budget sprengen, dieses um 32 Prozent, so die ASUG-Studie 2024. Bei einem Viertel aller Projekte fällt die Überschreitung noch drastischer aus.

Was steckt dahinter? Laut Techconsult liegen 41 Prozent der Ursachen bei schwachem Projektmanagement, 39 Prozent bei mangelnder Projektvorbereitung. Technische Probleme rangieren weit dahinter. Wer diese Zahlen liest und trotzdem zuerst an das ERP-System denkt, analysiert am falschen Ort.

Lenkungsausschüsse, die nicht lenken

Ein Lenkungsausschuss, der keine entscheidbaren Vorlagen bekommt, ist kein Steuerungsgremium. Es ist eine Informationsveranstaltung. Wenn IT und Fachbereiche aneinander vorbeireden, Prioritäten täglich neu verhandelt werden und Entscheidungen unbeantwortet im Raum bleiben, liegt das an fehlenden Strukturen, nicht an fehlendem Personal.

Bei derProject-Enabler GmbH hat sich daher eine kleine, handlungsfähige Kerngruppe bewährt: CEO, CFO oder  CIO gemeinsam mit den zentralen Prozessverantwortlichen, die Budgetabweichungen, Bereichskonflikte und technische Richtungsentscheidungen verbindlich beschließen können. Keine Beobachter, keine Berater ohne Mandat.

Klare Verantwortlichkeiten als Fundament

Feste Vollzeit-Projektrollen, eine dokumentierte Entscheidungsmatrix und abgestimmte Eskalationspfade sind nachweislich die wirksamsten Governance-Maßnahmen. In über 25 Jahren SAP-Projektbegleitung zeigt sich bei Project-Enabler dasselbe Bild: Wer die Führungsstruktur nicht klärt, bevor er technische Entscheidungen trifft, kämpft die gesamte Projektlaufzeit gegen die Folgen dieser Versäumnisse.

Warum mehr Personal das Führungsproblem nicht löst

Die gängige Reaktion auf Projektverzögerungen ist das Aufstocken von Kapazitäten. Das verschlimmert das Problem in der Regel. Mehr Beteiligte in einem ungesteuerten Projekt bedeuten mehr Abstimmungsbedarf, mehr Konflikte und weniger Klarheit. Was fehlt, sind keine Hände, sondern Projektsteuerung.

Datenmüll: Das Problem, das kurz vor dem Go-Live explodiert

Datenbestände mit Dubletten, falschen Stammdaten und inkonsistenten Strukturen werden in der Vorbereitungsphase systematisch unterschätzt. Die häufigste Ursache für Migrationsabbrüche sind keine technischen Fehler, sondern Datenqualitätsprobleme. Wer die Stammdatenbereinigung als IT-Aufgabe behandelt statt als fachliche Verantwortung der Fachbereiche, erkennt dieses Problem erst dann, wenn die Korrektur am teuersten ist. Eine fehlende Bereinigungsstrategie gehört zu den am einfachsten vermeidbaren Risiken in S/4HANA-Projekten. Stammdatenbereinigung gehört als eigenständiges Teilprojekt in den Projektplan, mit benannten Datenverantwortlichen und klaren Qualitätskriterien, bevor die Migrationsstrategie steht.

Eigenentwicklungen: Die Komplexität, die man mitschleppt

56 Prozent der Unternehmen nennen den Umfang ihrer Eigenentwicklungen als größte Herausforderung für die Migrationsdauer. In einem typischen ECC-System machen individuelle Z-Entwicklungen 20 bis 40 Prozent des gesamten Codes aus. Wer diesen Code nicht frühzeitig analysiert, schleppt die gesamte gewachsene Prozesslogik unreflektiert ins neue System. Dabei ist ein Großteil dieser Eigenentwicklungen verzichtbar: 25 bis 40 Prozent können vor der Migration stillgelegt werden. Trotzdem planen 15 Prozent der Unternehmen 40 bis 50 Prozent ihres Gesamtbudgets allein für die Anpassung von Eigenentwicklungen ein. Wer früh analysiert, spart erheblich und verkürzt die Projektlaufzeit.

S/4HANA als Transformation begreifen, nicht als technisches Upgrade

Wer S/4HANA nur als Systemwechsel behandelt, nimmt alle alten Probleme mit. Der Wert der Migration liegt nicht im Datenbankwechsel, sondern in der Möglichkeit, Prozesse zu standardisieren und Komplexität abzubauen. In der Praxis zeigt sich: Unternehmen, die Prozesse konsequent auf den SAP-Standard ausrichten, reduzieren ihre Eigenentwicklungsquote um 30 bis 50 Prozent, und damit auch den Folgeaufwand für zukünftige Upgrades. Diese Gelegenheit nutzen nur Projekte, die S/4HANA von Anfang an als Transformationsvorhaben führen.

Ohne Führungscommitment scheitert jede Transformation

Die Unternehmensführung muss nicht nur hinter dem Projekt stehen, sondern aktiv am Veränderungsprozess teilnehmen. Projekte, in denen das Top-Management die Transformation nicht sichtbar mitträgt, erzeugen Widerstand auf jeder Ebene: im mittleren Management, in den Fachbereichen und in der IT. Diesen Widerstand durch Schulungen zu überwinden, ist teurer als ihn durch klare Signale von oben zu verhindern.

Mitarbeiter früh einbinden, nicht erst beim Go-Live

Veränderungsverantwortliche und Schlüsselanwender müssen in der Vorbereitungsphase benannt und begleitet werden, nicht erst kurz vor der Einführung. Vier Maßnahmen haben in deutschen S/4HANA-Rollouts nachweislich Wirkung gezeigt: Information, Kommunikation, Coaching und laufendes Monitoring. Wer diese vier Elemente strukturiert umsetzt, erreicht eine Nutzerakzeptanz von über 90 Prozent innerhalb von 60 Tagen nach dem Go-Live.

Der Standardisierungsvorrang als Schutz vor Komplexität

Lokale Anpassungen und Sonderlösungen erhöhen den Migrationsaufwand überproportional. In der DACH-Region haben 75 Prozent der erfolgreichen Unternehmen ihre Prozesse standardisiert statt den SAP-Standard an bestehende Abläufe anzupassen. Das klingt wie ein technisches Prinzip, es ist in Wirklichkeit eine Führungsentscheidung. Denn jede Abweichung vom Standard entsteht, weil jemand im Unternehmen sie bewilligt hat.

Governance: Entscheidungsstrukturen zuerst klären

Setzen Sie den Lenkungsausschuss mit verbindlichen Entscheidungskompetenzen und klaren Eskalationspfaden auf, bevor das Projekt startet. Benennen Sie Vollzeit-Projektrollen, dokumentieren Sie die Entscheidungsmatrix und führen Sie Statusformate ein, die entscheidbare Vorlagen liefern, keine Präsentationen ohne Handlungsoptionen. Projekte, die diese Struktur erst aufbauen, wenn sie bereits in Schieflage sind, zahlen einen deutlich höheren Preis.

Datenqualität: Vor dem ersten Testzyklus, nicht danach

Behandeln Sie die Stammdatenbereinigung als eigenständiges Teilprojekt. Benennen Sie Datenverantwortliche aus den Fachbereichen und definieren Sie Bereinigungskriterien, bevor die Migrationsstrategie steht. Wer das erst im Testzyklus angeht, entdeckt Qualitätsprobleme genau zu dem Zeitpunkt, an dem sie den größten Schaden anrichten.

Change-Management: Budget und Verantwortung explizit einplanen

Behandeln Sie Change-Management nicht als Kommunikationsaufgabe, sondern als Projektrolle mit eigenem Budget, eigenem Zeitplan und messbaren Zielen. Das Führungscommitment muss schriftlich und sichtbar verankert sein: in Projektdokumenten, in Auftaktveranstaltungen und in der täglichen Projektkommunikation.

Wann externe Unterstützung sinnvoll ist

Wenn die Projektsteuerung verloren gegangen ist oder Entscheidungsstrukturen fehlen, wirkt externe Führungsunterstützung schneller als internes Aufstocken. Project-Enabler konzentriert sich ausschließlich auf Führung, Struktur und Entscheidungsfähigkeit in SAP- und S/4HANA-Projekten, ohne Interesse am Verkauf von Tools oder Implementierungsleistungen. Das unterscheidet den Ansatz von klassischen Systemhäusern: Der Fokus liegt vollständig auf der Wiederherstellung von Projektsteuerung.

Die eigentlichen Ursachen dafür, warum S/4HANA-Projekte häufig scheitern, liegen in Governance-Versagen, mangelnder Datenvorbereitung und fehlendem Führungscommitment beim Change-Management. Das sind keine unvorhersehbaren Risiken, das sind behebbare Strukturprobleme.

Laut Horváth schließen nur 8 Prozent aller S/4HANA-Projekte in der DACH-Region ohne Zeitplanüberschreitung ab. Wer Governance, Datenqualität und Change-Management vor Projektstart strukturiert klärt, verbessert die Erfolgsaussichten gegenüber der großen Mehrheit der Projekte erheblich. Wenn Sie sich gerade in einer Schieflage befinden oder präventiv handeln wollen, bevor Fehler entstehen, die sich kaum noch korrigieren lassen: Project-Enabler unterstützt seine Kunden genau in dieser Situation, mit über 25 Jahren SAP-Erfahrung und ohne Interessenkonflikt.