10 Fehler bei der ERP-Modernisierung, die Sie vermeiden sollten

Die ERP-Modernisierungsfehler, die am meisten schaden, sind strategisch, nicht technisch: das Go-live als Ziellinie zu behandeln, Altprozesse ins neue System zu kopieren, Daten- und Change-Arbeit zu spät zu beginnen, alles im ERP zu bauen und Lizenzen ohne Fünfjahresmodell zu unterschreiben. Sie zeigen sich selten in Echtzeit. Sie treten nach dem Go-live zutage, wenn die versprochenen Effizienzgewinne ausbleiben und die Workarounds zurückkehren.

Das hier ist für CIOs, CFOs und Programmleiter, die eine S/4HANA- oder andere ERP-Modernisierung planen oder retten. Zu jedem Fehler unten gehören das Erscheinungsbild in der Praxis und die Korrektur, danach eine einseitige Frühwarn-Checkliste und was die SAP-Änderungen von 2026 bedeuten.

Ich habe gut finanzierte Projekte mit erfahrenen Teams und einer vollen Bank an Beratern erlebt, die dennoch hinter den Erwartungen zurückblieben. Die Ursache ist selten das System. Es sind Lücken bei Verantwortung, Integrationsplanung und Kommunikation zwischen Teams, die Entscheidungen treffen, die voneinander abhängen.

1. Das Go-live als Ziellinie behandeln

Sobald das System live ist, nehmen viele Teams an, die Hauptarbeit sei erledigt. Dann beginnt der eigentliche Druck: Tagesgeschäft, sich verändernde Anforderungen und das reale Nutzerverhalten drücken gegen das Design.

Ich habe Projekte erlebt, in denen sich der Lenkungsausschuss unmittelbar nach dem Go-live auflöst. Sechs Monate später stagniert die Akzeptanz, und niemand besitzt den Backlog.

Die Lösung: Finanzieren Sie eine Governance-Phase von 6 bis 12 Monaten nach dem Go-live. Verlängern Sie das Mandat des Lenkungsausschusses. Überwachen Sie die Prozessakzeptanz, nicht nur die Verfügbarkeit. Legen Sie Quality Gates nach dem Go-live mit benannten Verantwortlichen fest.

2. Altprozesse migrieren, ohne sie zu überdenken

Ich habe erlebt, wie ganze Freigabeketten genau so neu gebaut wurden, wie sie waren, selbst wenn die Hälfte der Beteiligten mit dem aktuellen Prozess nichts zu tun hatte. Niemand hatte gefragt, ob die Schritte noch nötig sind. Das Ergebnis war ein modernes ERP mit alten Workflows: eine teurere Version dessen, was sie schon hatten.

Die S/4HANA-Variante davon: kundeneigene Batch-Jobs, die unverändert aus ECC übernommen wurden und auf Tabellenstrukturen aufbauen, die es nicht mehr gibt. Die Migration ist technisch sauber. Die Geschäftslogik ist kaputt.

Die Lösung: Gestalten Sie die Prozesse vor dem Build neu. Gehen Sie mit Operations, Finanzwesen und Delivery-Teams jeden Workflow gemeinsam durch und hinterfragen Sie jeden Schritt.

Altbereich	Was oft schiefgeht	Was Sie stattdessen tun
Kundeneigener Code aus ECC	Ungenutzter Eigencode wird nach S/4HANA übernommen	Nutzungsanalyse und die Custom-Code-Prüfungen von SAP durchführen; ungenutzten Code stilllegen
Alte Workflows	Freigabeabläufe werden nachgebaut, obwohl Automatisierung inzwischen möglich ist	Mit den Fachverantwortlichen neu bewerten; Standard-Fiori-Apps oder SAP Build Process Automation nutzen
Nicht standardkonforme Stammdaten	Flexible Altkonstellationen scheitern an der S/4HANA-Validierung	Vor der Migration bereinigen und harmonisieren, wo sinnvoll mit SAP MDG
Reports auf Alttabellen	Direkter Tabellenzugriff passt nicht zum Datenmodell von S/4HANA	Auf CDS Views neu aufbauen
Versteckte manuelle Workarounds	Nebenprozesse tauchen nach dem Go-live wieder auf	Vor der Migration Process Mining einsetzen und die Lücken digitalisieren

3. Mit der Datenmigration zu spät beginnen

Schlechte Daten in ein neues ERP zu verschieben, ist wie umzuziehen, ohne etwas auszusortieren. Das Gerümpel zieht mit um, und in einem strukturierten System ist es schwerer wieder loszuwerden.

Ich habe einmal ein Go-live scheitern sehen, weil niemand bemerkt hatte, dass ein zentraler Datenbestand Einträge aus fünf verschiedenen Geschäftseinheiten enthielt, jede mit eigener Kodierlogik. Die technische Migration war korrekt. Die Daten waren nicht brauchbar. Reports brachen, die Anwender verloren das Vertrauen, und die Bereinigung unter einem Live-System dauerte Monate.

Die Lösung: Machen Sie Daten zu einem Workstream mit fachlicher Verantwortung. Weisen Sie Prozessverantwortliche zu, nicht nur technische Berater. Entscheiden Sie vor Migrationsbeginn, was übernommen, archiviert oder neu aufgebaut wird. Fahren Sie mindestens zwei vollständige Mock-Loads, mit einer Abhängigkeitskarte für die Ladereihenfolge und einem definierten Rollback je Ladevorgang. Mehr dazu in meinem Beitrag über die Gründe für das Scheitern von SAP-Datenmigrationen.

4. Change-Management als Nebenaufgabe behandeln

Die übliche Version: Change-Management sei „bereits erledigt“, was heißt: ein paar Folien, eine Demo und eine Schulung vor dem Go-live.

Menschen wehren sich nicht, weil sie Veränderung nicht mögen. Sie wehren sich, wenn niemand erklärt, warum sich etwas ändert oder was es ihnen bringt. Sie folgen dem System gerade so weit, dass die Checkliste erfüllt ist, und kehren dann zu den Tabellenkalkulationen zurück.

Der übliche Auslöser ist Termindruck: Schulungen werden gekürzt, um Zeit aufzuholen, die Anwender sind beim Go-live überfordert, und die zusätzliche Hypercare kostet mehr als die gestrichene Schulung.

Die Lösung: Geben Sie dem Change-Management von Anfang an ein eigenes Budget, einen eigenen Zeitplan und einen Senior-Verantwortlichen. Erfassen Sie die Rollen früh, finden Sie lokale Fürsprecher und verfolgen Sie Akzeptanz-KPIs neben den technischen Meilensteinen. Mein Leitfaden zum Change-Management-Plan zeigt die Struktur.

5. Nach den Roadmaps der Anbieter planen

Ich habe Teams erlebt, die ihre Integrationsstrategie auf ein künftiges Release eines Anbieters stützten, das dann um 12 Monate verschoben wurde. In der Zwischenzeit saßen sie fest und bauten temporäre Workarounds, und die Workarounds wurden dauerhaft.

Anbieter bauen Roadmaps für breite Kundengruppen. Ihr Unternehmen steht selten im Zentrum dieses Designs.

Die Lösung: Behandeln Sie die Roadmap als einen Input. Entwerfen Sie nach dem, was heute allgemein verfügbar ist, testen Sie neue Funktionen in einer Sandbox, bevor Sie auf ihnen aufbauen, und rechnen Sie Roadmap-Nutzen als Upside, nicht als Budget.

6. Kein Stilllegungsplan für Altsysteme

Ich habe einmal ein Unternehmen gesehen, das sechsstellige Beträge pro Jahr dafür zahlte, ein altes System für sechs Anwender am Laufen zu halten, die zweimal im Jahr Reports ziehen mussten. Niemand hatte einen Stilllegungsplan erstellt.

Die Lösung: Nehmen Sie die Stilllegung von Tag eins an in die Projektcharta auf, unter Einbeziehung von Recht, Compliance und Daten-Governance, nicht nur der IT. Vereinbaren Sie vor dem Go-live Aufbewahrungsfristen und ein Archivierungskonzept, erfassen und trennen Sie jede Schnittstelle zum Altsystem und geben Sie einem Team die Aufgabe, es abzuschalten.

7. Die Komplexität der Integration unterschätzen

Wenn die Integration scheitert, merkt es der Fachbereich vor der IT, weil Workflows mitten im Prozess in der Produktion stehen bleiben, nicht in einem Testsystem.

Das übliche Muster: IT und Fachbereich nehmen jeweils an, der andere habe die Integrationsanforderungen definiert. Keiner hat es getan. Bis die Lücken im Test auffallen, bleibt keine Zeit mehr für ein Redesign.

Die Lösung: Beginnen Sie das Integrationsdesign im Blueprint. Definieren Sie jedes Szenario, die Middleware, das Mapping und die Nachrichtenvolumen und klären Sie je Schnittstelle mit dem Fachbereich Echtzeit gegenüber Batch. Benennen Sie vor dem Go-live einen Schnittstellenverantwortlichen mit SLA. Für neue SAP-Programme ist die Middleware SAP Integration Suite; SAP PI/PO verlässt Ende 2027 die Mainstream-Wartung.

8. Annehmen, das ERP könne alles

Ich habe an Projekten gearbeitet, in denen Teams komplexe Service-Workflows (IT-Tickets, Anfragen für Betriebsmittel, Eskalationsrouting) ins ERP zwangen, weil sie keine externen Systeme wie ServiceNow einbinden wollten. Das Ergebnis waren überall kundeneigene Felder, manuelle Workarounds und Anwender, die in einem Prozess steckten, der nie passte.

ERP ist gut bei strukturierten, transaktionalen, finanziell verankerten Prozessen. Spezialisierte Plattformen können IT-Serviceanfragen, Workflow-Orchestrierung und Wissensmanagement besser.

Die Lösung: Entscheiden Sie bewusst, was Sie nicht im ERP bauen. Nutzen Sie Side-by-Side-Erweiterungen auf SAP BTP für Ausnahmen und ServiceNow oder Ähnliches für die Orchestrierung außerhalb des transaktionalen Kerns. Mein Artikel zur ERP-Modernisierung mit SAP und ServiceNow behandelt diese Aufteilung.

9. Die langfristigen Lizenzkosten unterschätzen

Ich kenne ein Team, das seine Lizenzausgaben im zweiten Jahr verdoppelte, weil es eine einzige Funktion brauchte, die hinter einer höherwertigen Lizenz lag. Der Business Case hatte nur die Kosten bis zum Go-live gerechnet.

ERP-Lizenzen berechnen Anwender, Module, Transaktionen und API-Nutzung, und die Kosten wachsen mit dem Geschäft, ob Sie es eingeplant haben oder nicht. Bei SAP bedeutet das Digital-Access-Modell, dass Belege, die von Drittsystemen erzeugt werden, Lizenzkosten tragen können, die im ursprünglichen Kommerzmodell nicht enthalten waren. Unter RISE und SAP GROW wächst die Zahl der Full User Equivalents (FUE) mit der Akzeptanz.

Die Lösung: Bauen Sie vor der Unterschrift ein Lizenzmodell über drei bis fünf Jahre. Ordnen Sie Rollen den Lizenztypen zu, modellieren Sie das FUE-Wachstum auf einer realistischen Akzeptanzkurve, verstehen Sie den indirekten Zugriff, bevor Sie externe Systeme anbinden, und prüfen Sie nach dem Go-live inaktive Anwender.

10. ERP als IT-Projekt behandeln

Das häufigste und schädlichste Muster. Die Planung beginnt in der IT, wird von der IT geleitet und löst IT-Probleme.

Ich habe Teams erlebt, die auf dem Papier jeden Meilenstein erreichten, während der Fachbereich weiter fragt, warum sich nichts besser anfühlt. Das heißt meist, dass das ERP für die Prozesse von gestern gebaut wurde, ohne Führungskräfte aus Operations, Finanzwesen oder dem kaufmännischen Bereich im Design.

Die Lösung: Setzen Sie Führungskräfte aus dem kaufmännischen Bereich, dem Finanzwesen und Operations von Anfang an in den Lenkungsausschuss. Schreiben Sie die strategische Ausrichtung in die Charta, nicht nur den technischen Scope. Prüfen Sie die Programmziele gegen Ergebnisse auf Vorstandsebene, bevor das Design beginnt.

Nutzen Sie sie in jedem Lenkungsausschuss. Ist ein Warnzeichen vorhanden, berichtet der benannte Verantwortliche darüber, bis es verschwunden ist.

1. ChartaVerantwortung und KostenKeine Führungskraft aus Operations oder Finanzwesen, kein Fünfjahres-Lizenzmodell, kein Stilllegungstermin
2. BlueprintProzess- und IntegrationsdesignHeutiger Prozess kopiert, Schnittstellen noch nicht entworfen
3. Erster Mock-LoadDatenNoch kein Datenqualitätsbericht
4. Go-liveWas danach passiertKeine finanzierte Governance für die folgenden 12 Monate

Fehler	Frühes Warnzeichen	Verantwortlich
1. Go-live als Ziellinie	Kein finanzierter Governance-Plan für die 12 Monate nach dem Go-live	Sponsor
2. Kopierte Altprozesse	Design-Workshops starten bei den Screens „So machen wir es heute“	Prozessverantwortliche
3. Späte Datenarbeit	Kein Datenqualitätsbericht vor dem ersten Mock-Load	Leiter Datenmigration
4. Change als Nebenaufgabe	Der Change-Plan ist ein Schulungskalender	Change Lead
5. Abhängigkeit von der Roadmap	Eine Designentscheidung wartet auf eine Funktion, die nicht freigegeben ist	Lösungsarchitekt
6. Keine Stilllegung	Kein Abschalttermin für irgendein Altsystem in der Charta	PMO
7. Integration unterschätzt	Schnittstellen sind bis Ende des Blueprints nicht entworfen	Integrationsleiter
8. ERP für alles	Eigene Objekte für nicht transaktionale Workflows	Enterprise-Architekt
9. Lizenzen	Kein Fünfjahres-Lizenzmodell im Business Case	CFO
10. Reines IT-Programm	Der Lenkungsausschuss hat keine Führungskraft aus Operations oder Finanzwesen	Sponsor

Bereitstellung. Für neue SAP-Programme ist der Standard RISE with SAP auf SAP Cloud ERP Private oder SAP GROW auf der Public Edition (SAP Cloud ERP) für mittelgroße Unternehmen. Neue On-Premise-Einführungen sind selten. ECC-Kunden stehen vor dem Ende der Mainstream-Wartung am 31. Dezember 2027, was die Zeit verkürzt, um die Fehler 2, 3 und 7 zu beheben.

Clean Core. SAP bewertet Erweiterungen jetzt auf vier Clean-Core-Stufen, von A (nur freigegebene APIs, Side-by-Side auf BTP oder In-System mit ABAP Cloud) bis D (nicht sauber). Die Public Edition erlaubt nur Stufe A, was das Gespräch hinter Fehler 2 erzwingt. Die Private Edition erlaubt weiterhin klassische Erweiterungen, die Disziplin muss also aus der Governance kommen. Klassischer Eigencode macht jedes Upgrade zu einem Projekt. Mein Beitrag zur Clean-Core-Strategie geht weiter.

KI im Delivery-Tooling. Joule sitzt jetzt in SAP Cloud ALM und im SAP Activate Roadmap Viewer, und SAP Build Code nutzt Joule für die Erweiterungsentwicklung. Fragen Sie Partner, wie sich KI-Tooling in ihrer Rate Card niederschlägt. Tut es das nicht, ist entweder der Preis hoch oder die Ersparnis geht in deren Marge.

Lifecycle-Tooling. SAP Cloud ALM ist das Lifecycle-Management-Werkzeug für Cloud-Programme. Solution Manager 7.2 verlässt Ende 2027 die Mainstream-Wartung, Landschaften, die beide betreiben, brauchen also einen Plan für den Umstieg.

Die zehn Fehler haben sich nicht geändert. Die Kosten, sie falsch zu machen, schon. In einem RISE-Programm werden die Clean-Core-Entscheidung, das Bereitstellungsmodell und das FUE-Modell in den ersten Wochen der Mobilisierung festgelegt. Das Zeitfenster, darauf Einfluss zu nehmen, ist kurz.

Warum bleiben ERP-Modernisierungen nach dem Go-live hinter den Erwartungen zurück?

Die meisten Teams planen bis zum Go-live und hören dann auf. Niemand verantwortet Erweiterungen, Feedback, Prozesskorrekturen oder den Backlog. Die Auflösung des Lenkungsausschusses zum Go-live ist das verlässlichste Zeichen für Ärger. Finanzieren Sie von Tag eins an 6 bis 12 Monate Governance nach dem Go-live.

Welches Risiko birgt es, Altprozesse in ein neues ERP zu kopieren?

Das neue System erbt die alten Ineffizienzen zu höheren Kosten. Speziell bei S/4HANA-Migrationen funktionieren Eigencode und Batch-Jobs, die für ECC-Tabellen gebaut wurden, oft nicht. Die Migration kann also technisch sauber sein, während die Geschäftslogik kaputt ist.

Wie schadet schlechte Datenqualität einer ERP-Modernisierung?

Doppelte Lieferanten, inkonsistente Stammdaten, Altcodes und unvollständige Datensätze wandern ins neue System, wenn sie nicht vorher jemand bereinigt. Reports brechen, die Anwender verlieren das Vertrauen in die Zahlen, und die Bereinigung unter einem Live-System dauert Monate.

Warum wird Change-Management in ERP-Projekten so oft unterschätzt?

Weil es im Projektplan nicht so sichtbar ist wie die Konfiguration. Führungskräfte nehmen an, ein paar Schulungen reichten. Change-Management heißt, Menschen vor dem Go-live auf das vorzubereiten, was sich in ihrer täglichen Arbeit tatsächlich ändert. Digital-Adoption-Werkzeuge wie WalkMe, das inzwischen SAP gehört, helfen mit Anleitung in der Anwendung, ersetzen aber nicht die Erklärung des Warum.

Warum laufen Altsysteme noch Jahre nach dem ERP-Go-live weiter?

Weil niemand geplant hat, sie abzuschalten. Alle konzentrieren sich darauf, das neue ERP live zu bekommen, und die alten Systeme bleiben für Compliance, Referenz oder aus Bequemlichkeit. Die Stilllegung muss von Tag eins an im Scope sein, unter Einbeziehung von Recht und Compliance.

Wie verändern RISE with SAP und Clean Core diese Fehler?

In der Public Edition machen die Clean-Core-Regeln tiefgreifende Anpassungen unmöglich, was das Prozessgespräch hinter Fehler 2 erzwingt. In der Private Edition sind klassische Erweiterungen weiterhin erlaubt, Clean Core hängt also von der Governance ab. Die Integration wandert zu SAP Integration Suite, da die Wartung von PI/PO endet. Lizenzierung wird zu einer Frage des FUE-Wachstums. Die Stilllegung wird dringlicher, weil der Parallelbetrieb von Altsystemen zusätzlich zu einem mehrjährigen Abonnement Kosten verursacht.