ERP-Modernisierung 2026: Cloud, KI und Clean Core

ERP-Modernisierung 2026 bedeutet drei Entscheidungen in dieser Reihenfolge: was Ihr ERP nicht mehr tun soll, wie sauber Sie seinen Kern halten und ob Ihre Daten gut genug sind, damit KI nützlich wird. Für SAP-Kunden steht hinter allen dreien ein hartes Datum: Die Mainstream-Wartung für ECC endet am 31. Dezember 2027, mit kostenpflichtiger erweiterter Wartung bis Ende 2030.

Dieser Text richtet sich an CIOs, CFOs und Enterprise-Architekten, die die Analyse abgeschlossen haben und nun umsetzen müssen. Er behandelt die Kräfte, die zum Handeln drängen, die Backbone-plus-Satelliten-Architektur, Clean Core, die Governance-Lücke, KI-Reife und eine Risikotabelle für die nächsten 18 Monate.

2024 kauften die meisten Führungskräfte noch Zeit: Sie studierten ECC-Zeitpläne, stritten über Hybrid oder vollständige Migration und führten Sandbox-Tests durch, ohne sich festzulegen. Dieses Zeitfenster ist geschlossen. Die technischen Schulden in ECC- und Oracle-E-Business-Suite-Landschaften sind nicht mehr theoretisch. Sie zeigen sich in fehlgeschlagenen Regressionstests nach Updates, in Prüfungsfeststellungen zu kundeneigenem Code, den niemand verantwortet, und in Daten, die 12 Stunden brauchen, um zwischen Planungs- und Ausführungssystemen zu wandern.

Der Stichtag. Nach 2027 können ECC-Kunden erweiterte Wartung bis Ende 2030 zu einer höheren Gebühr kaufen. Darüber hinaus bietet SAP für 2031 bis 2033 eine Übergangsoption für die ERP Private Edition an, aber nur über RISE, und SAP stellt klar, dass es sich um ein kostenpflichtiges Übergangsangebot handelt, nicht um eine Wartungsverlängerung. Unterdessen ergab eine Gartner-Studie, über die The Register berichtete, dass Ende 2024 nur etwa 39 % der rund 35.000 ECC-Kunden von SAP S/4HANA-Lizenzen gekauft oder abonniert hatten. Lizenziert ist nicht dasselbe wie migriert. Der Partnermarkt wird eng.

Das Budgetmodell. Cloud-ERP verlagert Ausgaben von Capex-Lizenzen zu Subscriptions. Das klingt sauberer. In der Praxis stellen CFOs fest, dass Cloud-Kosten weniger planbar sind: Unter RISE with SAP und SAP GROW erzeugen das Wachstum der Full User Equivalents (FUE), Zusatzdienste und Integrationsaufwand Kosten, die im ursprünglichen Business Case nicht enthalten waren.

Fragmentierung in Finanzwesen und Lieferkette. Finanzteams lassen KI auf der Kreditoren- und Debitorenbuchhaltung laufen, während Prüfprozesse noch Vorlagen aus einer anderen Zeit nutzen. Lieferketten sind teilweise modernisiert: SAP IBP für die Planung, ein älteres Lagerverwaltungssystem für die Ausführung, Ariba für den Einkauf, aber manuelle Wareneingänge. Der Engpass ist nicht die Technik. Es sind die Verbindungen zwischen den Systemen.

ERP ist eine Schicht, nicht der ganze Stack. ServiceNow steuert in vielen Unternehmen die Prozessorchestrierung, Salesforce die Kundenworkflows, Workday oder SuccessFactors den HR-Lebenszyklus. Das ERP ist zum finanziellen Backbone geworden, nicht zur Alles-in-einem-Prozessdrehscheibe, als die es in den 1990er Jahren verkauft wurde.

Das Modell, mit dem die meisten Enterprise-Architekten heute arbeiten, ist ein finanzielles Backbone (SAP S/4HANA oder Oracle Fusion), umgeben von spezialisierten Plattformen.

Schicht	Was hier liegt	Was nicht
Finanzielles Backbone	Hauptbuch, Controlling, Einkauf, Bestandsführung, Fertigungsausführung, gesetzlicher Abschluss	Workflow-Genehmigungen, CRM, Workforce-Management, Analytik
Workflow	ServiceNow für IT- und Betriebsprozesse, Genehmigungen, Change-Management	Transaktionale Datenhaltung
Kundeninteraktion	Salesforce oder SAP Sales and Service Cloud	Finanzverarbeitung
Personalwesen	Workday oder SAP SuccessFactors	Operative Transaktionen
Analytik	SAP Business Data Cloud, SAP Analytics Cloud, Power BI, Snowflake	Das führende System (System of Record)

Die Trennung ist gewollt. Alles zurück in SAP zu zwängen erzeugt Reibung, bremst Updates und verwischt Zuständigkeiten. CRM, Workflow, Analytik und EHS in ein System zu pressen hat frühere Programme so schmerzhaft gemacht.

Die Frage, die Sie stellen sollten: Wofür soll das ERP nicht mehr zuständig sein? Wer sie überspringt, baut denselben Monolithen auf einer neueren Lizenz wieder auf. Mein Beitrag zur ERP-Modernisierung mit SAP und ServiceNow geht eine Variante dieser Aufteilung durch.

Im August 2025 hat SAP sein dreistufiges Erweiterbarkeitsmodell durch vier Clean-Core-Stufen ersetzt. Stufe A nutzt nur freigegebene, stabile APIs, Side-by-Side auf SAP BTP oder In-System mit ABAP Cloud. Stufe B nutzt klassische APIs und Technologien, die SAP weiterhin als sauber ansieht. Stufe C greift auf interne Objekte zu und erfordert besondere Maßnahmen. Stufe D ist nicht sauber.

Die Public Edition (SAP Cloud ERP, vertrieben als SAP GROW) erlaubt nur Stufe A, sodass die Plattform Clean Core erzwingt und zwei große Releases pro Jahr aufnimmt. Die Private Edition (SAP Cloud ERP Private, unter RISE) und On-Premise erlauben weiterhin klassische Erweiterungen, daher hängt Clean Core dort von der Governance ab. So oder so macht ein stark angepasstes System jedes Upgrade zum Projekt und jeden Regressionstest zur Krise.

Das verlangt Clean Core von Ihnen:

1. Nehmen Sie ungenutzten kundeneigenen Code aus dem Kern. Jedes kundeneigene Programm, das Sie behalten, müssen Sie bei jedem Upgrade testen.
2. Bauen Sie neue Erweiterungen wo möglich auf Stufe A: auf SAP BTP, mit SAP Build oder In-System mit ABAP Cloud.
3. Nutzen Sie Standardprozesse überall dort, wo SAP sie liefert, und passen Sie nur an, wo Regulierung oder ein echter Wettbewerbsunterschied es verlangt.

Der Widerstand ist kulturell, nicht technisch. Fachbereichsleiter, die sich 15 Jahre lang auf kundeneigenen Code verlassen haben, erwarten weiterhin, dass er „einfach neu implementiert“ wird. Diese Erwartung gehört ins Jahr 2012.

Eine typische ECC-Landschaft enthält 1.500 bis 3.000 kundeneigene Objekte, gestützt auf Begutachtungen, die ich in Fertigung und Dienstleistung durchgeführt habe, und nur etwa ein Viertel davon zeigt aktive geschäftliche Nutzung. Der Rest ist historischer Ballast, der die Migrationskosten aufbläht und Prüfungsrisiken erzeugt.

Der praktische Schritt: Führen Sie jetzt einen Nutzungsscan durch. Schaffen Sie ab, was inaktiv ist. Veröffentlichen Sie eine Streichliste, bevor das Design beginnt. Teams, die Clean Core von der ersten Woche an einplanen, haben deutlich bessere Upgrade-Erfahrungen als Teams, die es als Einschränkung behandeln, die es zu umgehen gilt. Mein Artikel zur Clean-Core-Strategie geht auf die Methode ein.

Wenn das ERP eine Schicht unter vielen ist, werden Zuständigkeitsfragen entscheidend. Wer verantwortet:

1. Die API zwischen Salesforce und dem ERP?
2. Einen Workflow, der SAP und ServiceNow umspannt?
3. Konkurrierende Änderungsprioritäten, wenn beide Systeme gleichzeitig Updates brauchen?

Ich habe erlebt, dass dies Go-lives um Monate verzögert hat. Teams merken nicht, dass sie feststecken, bis der Integrationstest die Überschneidung offenlegt.

In einem Fall griffen fünf Systeme auf denselben Lieferantenstammsatz zu. Fünf. Niemand hatte ein Dokument zur Stammdatenverantwortung, und niemand hatte festgelegt, wer was in welchem System ändern darf. Das ist kein Technikversagen. Es ist ein Governance-Versagen, das die Technik offengelegt hat.

Der Nutzen von KI im ERP ist real, aber er hängt von Datenqualität und einer sauberen Architektur ab. Joule umfasst inzwischen S/4HANA, SuccessFactors, Ariba und weitere SAP-Produkte, und die Agenten von SAP laufen unter Joule-Assistenten. Agentische Anwendungsfälle auf SAP BTP sind im produktiven Einsatz, kein Folienwerk. Sie alle hängen von sauberen, konsistenten, strukturierten Daten ab.

Wenn Ihre Daten doppelt vorhanden sind, uneinheitlich kodiert oder in kundeneigenen Tabellen liegen, die S/4HANA nicht erkennt, hat KI nichts Verlässliches, womit sie arbeiten kann. Finanzteams, die KI auf der Kreditorenbuchhaltung einsetzen, merken das schnell, wenn Rechnungen dem falschen Lieferanten zugeordnet werden, weil der Kreditorenstamm nie bereinigt wurde.

Die Reihenfolge, die funktioniert: erst Clean Core, zweitens Daten-Governance, drittens Analytik, viertens KI. Schritte zu überspringen beschleunigt nichts. Es verschiebt das Problem nach hinten.

1. 01Grenze ziehenEntscheiden, was das ERP nicht mehr tun soll
2. 02Kern bereinigenUngenutzten Code stilllegen, Neues auf Stufe A bauen
3. 03Daten-Governance aufsetzenPro Datenobjekt eine verantwortliche Person
4. 04Analytik aufbauenSAP Business Data Cloud, SAC oder Power BI auf gesteuerten Daten
5. 05KI ergänzenJoule und Agenten auf verlässlicher Basis

KI mit etwas Verlässlichem zum Arbeiten

Risiko	Signal	Praktische Reaktion
Druck durch den ECC-Stichtag	Mainstream-Wartung endet im Dezember 2027; die meisten ECC-Kunden hatten Ende 2024 S/4HANA noch nicht lizenziert	Ressourcenpläne mit Partnern jetzt verbindlich festlegen; Tagessätze für Senior-Kräfte in den USA liegen bereits bei 1.800 bis 3.500 US-Dollar
Altlasten im kundeneigenen Code	1.500 bis 3.000 kundeneigene Objekte, etwa ein Viertel in aktiver Nutzung	Nutzungsscans durchführen, Streichliste veröffentlichen, Stilllegungs-Sprints starten
Störungen durch Releases	Releases kollidieren mit Finanzabschluss und Spitzenzeiten der Lieferkette	Release-Fenster abseits des Abschlusses legen; Regressionstests automatisieren
Risiko bei der Datenmigration	Späte Harmonisierung erzeugt Fehler, die Teams fälschlich als Bugs einstufen	Datenumfang früh ermitteln; Bank-, Steuer- und Compliance-Daten vor dem Design-Freeze prüfen
Lücken bei der Integrationsverantwortung	Fünf oder mehr Systeme greifen auf gemeinsame Stammdaten zu	Zuständigkeitsmatrix veröffentlichen; pro Datenobjekt eine verantwortliche Person
Zwei Lifecycle-Werkzeuge	Hybride Landschaften betreiben Solution Manager und SAP Cloud ALM parallel	Cloud ALM als Standard für Cloud-Programme; die Mainstream-Wartung von Solution Manager 7.2 endet Ende 2027

Die Variante dieser Risiken auf Umsetzungsebene finden Sie in zehn Fehlern bei der ERP-Modernisierung, die Sie vermeiden sollten, und die Migrationswege selbst im Leitfaden zur Migration von ECC auf S/4HANA.

Was ist Clean Core in SAP S/4HANA?

S/4HANA so nah wie möglich am Standard zu halten und Erweiterungen dorthin zu legen, wo Upgrades sie nicht brechen können. Seit August 2025 stuft SAP Erweiterungen von Stufe A (nur freigegebene APIs, auf SAP BTP oder In-System mit ABAP Cloud) bis Stufe D (nicht sauber) ein. Der geschäftliche Grund ist Upgrade-Schutz: Ein sauberes System nimmt Releases in Tagen auf, ein stark angepasstes macht aus jedem ein Projekt.

Was ist die Backbone-plus-Satelliten-Architektur für ERP?

Das ERP (SAP S/4HANA oder Oracle Fusion) übernimmt, wofür es gebaut ist: Finanzbuchführung, Bestandsführung, Einkauf, Fertigungstransaktionen und gesetzliche Berichte. Spezialisierte Plattformen übernehmen den Rest: ServiceNow für Workflow, Salesforce für Kundeninteraktion, Workday oder SuccessFactors für das Personalwesen und Analyseplattformen für Erkenntnisse. Wer all das ins ERP zwingt, erzeugt einen Monolithen, der sich langsam aktualisieren lässt und stark angepasst wird.

Wie sollten Unternehmen den SAP-ECC-Stichtag 2027 angehen?

Beginnen Sie mit SAP Readiness Check. Er macht kundeneigenen Code, Add-on-Abhängigkeiten und Datenmengen sichtbar, die drei Faktoren, die entscheiden, ob Sie Brownfield, Greenfield oder selektiv vorgehen. Komplexe Enterprise-Migrationen dauern typischerweise 18 bis 24 Monate von der Bewertung bis zum Go-live. Wenn Sie also bis jetzt keinen Ansatz gewählt und keine Gespräche mit Partnern begonnen haben, ist ein Go-live 2027 schon knapp. Erweiterte Wartung bis 2030 kostet mehr und verschafft Zeit, nicht Innovation.

Wann ist KI in der ERP-Modernisierung wertvoll und wann nicht?

Wenn die Daten sauber, konsistent und strukturiert sind und der Prozess klare Regeln hat: Automatisierung der Kreditorenbuchhaltung, Bedarfsprognosen und Anomalieerkennung in Finanztransaktionen sind bewährte Fälle. KI ist keine Abkürzung an schlechten Daten oder Governance-Lücken vorbei. Entscheidungen auf Basis schlechter Eingaben sind schwerer zu erkennen als manuelle Fehler. Clean Core, Daten-Governance und stabile Prozesse kommen zuerst.

Was sind die größten Fehler bei der ERP-Modernisierung?

Sie als Technikprojekt zu behandeln, sodass die Clean-Core-Debatte verloren ist, bevor die Fachbereichsleiter im Raum sind. Mit der Daten-Governance erst nach dem Design zu beginnen, obwohl Entscheidungen in Woche eins Monate an Tests gespart hätten. Nicht festzulegen, was das ERP nicht mehr tun soll, sodass der Kernumfang standardmäßig wächst, und so ist der letzte Monolith entstanden.

Was kostet eine ERP-Modernisierung?

Eine Brownfield-Konvertierung von ECC auf S/4HANA kostet für ein mittelständisches Unternehmen typischerweise 2 bis 8 Mio. US-Dollar an Implementierungskosten, plus laufende Subscription. Enterprise-Programme mit globalem Umfang, erheblicher Anpassung und vielen Gesellschaften können 20 bis 100 Mio. US-Dollar und mehr erreichen. Modellieren Sie neben Lizenzen auch Integration, Tests und Betriebssupport, und unter RISE und SAP GROW das FUE-Wachstum über die Vertragslaufzeit.