SAP Clean Core: Bedeutung, Level A bis D und Governance

SAP Clean Core bedeutet, Ihr S/4HANA-System so nah am SAP-Standard zu halten, wie Ihr Geschäft es zulässt. Alles, was Sie ergänzen, wird über Schnittstellen gebaut, die SAP freigegeben hat und stabil zu halten zusagt. So brechen Upgrades nichts.

Die kurze Antwort: Clean Core ist eine Disziplin dafür, wie Sie SAP erweitern und steuern. Eigene Logik läuft On-Stack mit ABAP Cloud oder Side-by-Side auf SAP BTP, und SAP bewertet jede Erweiterung von Level A (am saubersten) bis Level D (Modifikationen, die weg müssen). Der Gewinn sind schnellere Upgrades: Ich habe Unternehmen gesehen, die ihre Upgrade-Zeiten so um 40 % verkürzt haben.

Wenn Ihr System voller Modifikationen an SAP-Standardobjekten ist, wird jedes Release zum Regressionsprojekt. Wenn Ihre eigene Logik hinter freigegebenen Schnittstellen liegt, werden Upgrades zur Routinewartung.

Ich habe Unternehmen gesehen, die ihre Upgrade-Zeiten um 40 % verkürzt haben, indem sie die Clean-Core-Prinzipien angewandt haben. Sie haben Anpassungen auf das Minimum beschränkt und die verbliebenen konsequent gesteuert.

2024 ersetzte ein europäischer Konsumgüterhersteller seine alte Preislogik durch eine modulare Fiori-App, die außerhalb des Kerns auf SAP BTP gebaut wurde. Damit entfielen die Regressionstests für diese Logik vollständig.

Auch ein Clean-Core-ERP können Sie anpassen. Die Anpassung muss Schnittstellen nutzen, die SAP freigegeben hat und stabil zu halten zusagt. SAP bietet dafür zwei Wege:

• On-Stack, mit ABAP Cloud. Erweiterungen laufen in S/4HANA, nutzen aber nur freigegebene APIs und Erweiterungspunkte.
• Side-by-Side, auf SAP BTP. Erweiterungen laufen als eigene Anwendungen und sprechen über APIs oder Events mit S/4HANA.

SAP beschreibt seinen Ansatz als BTP-first und entscheidet je Anwendungsfall. Meiner Erfahrung nach ist weniger wichtig, wo der Code läuft, als ob die Anforderung überhaupt Code braucht.

Einen „schmutzigen“ Kern erkennt jeder, der ECC betrieben hat: modifizierte Standardprogramme, Z-Tabellen mit direkten Schreibzugriffen, Schnittstellen, die SAP-Interna lesen, implizite Erweiterungen, die niemand dokumentiert hat. Nichts davon war falsch, als es gebaut wurde. Es war nur nicht für ein System gebaut, das alle ein bis zwei Jahre ein Upgrade bekommt.

Ich behandle dieses Thema auch in einem Video auf meinem YouTube-Kanal (auf Englisch).

SAP ordnet Clean Core fünf Leitprinzipien zu. So beschreibt SAP jedes davon, und darauf schaue ich zuerst:

Prinzip	Was SAP meint	Was ich zuerst prüfe
Prozesse	So nah wie möglich am SAP-Standardprozess bleiben	Welche Prozessvarianten es nur gibt, weil „wir das immer so gemacht haben“
Erweiterbarkeit	Erweiterungen über freigegebene APIs vom Kern entkoppelt, mit Governance darüber, welche Option genutzt wird	Wie viel Eigenentwicklung es gibt, wie viel davon genutzt wird und auf welchem Level sie liegt
Daten	Saubere, regelkonforme Daten mit einem etablierten Governance-Modell	Doppelte und unvollständige Stammdaten, Kundenfelder, die niemand erklären kann
Integrationen	Standardisierte, sichere Verbindungen auf unterstützten Technologien	Punkt-zu-Punkt-Schnittstellen, die Tabellen direkt lesen
Betrieb	Governance, Menschen, Prozesse und Werkzeuge, die die anderen vier absichern	Wer eine Erweiterung genehmigt und was die nächste Modifikation verhindert

Die meisten Teams beginnen und enden bei der Erweiterbarkeit, weil sie sich am leichtesten messen lässt. Meiner Erfahrung nach verursachen Prozesse und Daten mehr Verzögerung. Eigenentwicklung ist meist das Symptom, der Prozess dahinter die Ursache.

Im August 2025 hat SAP sein früheres dreistufiges Erweiterbarkeitsmodell durch das Clean-Core-Level-Konzept ersetzt. Jede Erweiterung wird danach bewertet, wie sie gebaut ist, wie stark sie vom Kern entkoppelt ist und wie sicher sie ein Upgrade übersteht. Wenn Sie ältere SAP-Unterlagen lesen, die von Stufen (Tiers) sprechen: Das hier hat sie abgelöst.

Level ALevel BLevel CLevel D

Was es nutztLevel ANur öffentlich freigegebene, stabile SchnittstellenLevel BZusätzlich die klassischen APIs von SAPLevel CInterne SAP-ObjekteLevel DModifikationen, Schreibzugriffe auf SAP-Tabellen, implizite Erweiterungen

Upgrade-RisikoLevel AAm niedrigsten, durch Stabilitätszusagen abgesichertLevel BIn der Regel upgrade-stabilLevel CMuss bei jedem Upgrade geprüft werdenLevel DAm höchsten

Was zu entscheiden istLevel ADer Standard für alles NeueLevel BAkzeptieren, mit dokumentierter BegründungLevel CMit Begründung akzeptieren, bei jedem Upgrade neu prüfenLevel DZuerst entfernen oder auf B oder C heben

Quelle: SAP Clean-Core-Level-Konzept, SAP News, August 2025

Level A nutzt nur öffentlich freigegebene Schnittstellen mit Stabilitätszusagen, gebaut mit SAP Build, ABAP Cloud oder BTP. Level B nimmt die klassischen APIs von SAP hinzu. Level C greift auf interne SAP-Objekte zu, und SAP plant dafür ein Änderungsprotokoll, das bei der Upgrade-Planung hilft.

Level D umfasst Modifikationen, Schreibzugriffe auf SAP-Tabellen, implizite Erweiterungen und andere Techniken, die SAP nicht empfiehlt. Das ist nützlicher als die alte Debatte „sauber oder nicht sauber“, weil Sie damit pro Objekt ein Ziel setzen können. Wenn Sie Ihre Level-D-Objekte vor einem Upgrade auf B oder C heben, ist das bereits eine echte Risikoreduzierung.

ABAP Cloud ist SAPs cloudfähiges ABAP-Entwicklungsmodell. Entwickler nutzen die Sprachversion „ABAP for Cloud Development“ und können nur auf freigegebenen Objekten, öffentlichen APIs und Erweiterungspunkten aufbauen. Es begann in der SAP BTP ABAP Environment und ist heute in jeder S/4HANA-Edition verfügbar (SAP ABAP Cloud FAQ).

S/4HANA Cloud bietet Ihnen drei Erweiterungswege. Die Key-User-Erweiterbarkeit deckt einfache Änderungen an Feldern, Logik und Oberfläche ab, ohne SAP-Code anzufassen. Die Entwicklererweiterbarkeit mit ABAP Cloud übernimmt eng gekoppelte Logik, und Side-by-Side-Erweiterungen auf SAP BTP übernehmen alles, was entkoppelt bleiben soll.

Die Edition bestimmt, wie viel Wahl Sie haben:

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition und On-Premise
ABAP-Entwicklung	Nur ABAP Cloud, verpflichtend für Neukunden seit Release 2208	ABAP Cloud seit 2022 empfohlen; klassisches ABAP weiterhin erlaubt
Änderungen am SAP-Code	Nicht möglich	Möglich, aber sie sind Level D
Key-User- und BTP-Side-by-Side-Erweiterungen	Verfügbar	Verfügbar
Wer Clean Core durchsetzt	Das System	Ihre Governance

Meine Regel für Kunden mit Private Edition: Behandeln Sie sie bei allem Neuen so, als wäre es die Public Edition. Klassisches ABAP ist erlaubt, aber jedes klassische Objekt, das Sie heute hinzufügen, ist eine Entscheidung, die jemand beim nächsten Upgrade verteidigen muss.

Clean-Core-Entscheidungen sollten bei einer Design Authority aus Fachbereich und IT liegen. Die IT allein genehmigt alles, was technisch möglich ist. Der Fachbereich allein will seinen alten Prozess zurück.

So würde ich sie aufsetzen:

1. Benennen Sie die Mitglieder. Prozessverantwortliche für jeden großen Bereich, dazu der Lösungsarchitekt und der leitende Entwickler. Die Prozessverantwortlichen entscheiden, ob eine Anforderung echt ist, und die IT entscheidet, wie sie gebaut wird.
2. Legen Sie die Rangfolge fest, bevor der Bau beginnt. Zuerst der Standardprozess, dann Key-User-Erweiterbarkeit, dann Level A auf ABAP Cloud oder BTP. Level B oder C braucht eine schriftliche Begründung, Level D einen Ausstiegsplan.
3. Jede Erweiterungsanforderung braucht einen Verantwortlichen und einen geschäftlichen Grund. Kein Verantwortlicher, kein Bau. Die Entscheidung und das akzeptierte Level kommen in ein einziges Register.
4. Setzen Sie ein technisches Tor vor die Transporte. Lassen Sie die Clean-Core-Prüfungen des ABAP Test Cockpit regelmäßig laufen und stoppen Sie neuen Level-D-Code, bevor er die Produktion erreicht.
5. Prüfen Sie das Register vor jedem Upgrade. Stilllegen, was niemand mehr nutzt, und alles anheben, was inzwischen ein höheres Level erreichen kann.

Früher lautete die Frage an diesem Tisch: „Warum kann das nicht auf BTP laufen?“ Heute würde ich fragen: „Warum kann das nicht Level A sein?“ Wenn es nicht geht, lautet die nächste Frage, welches Level Sie akzeptieren und warum.

Der größte Clean-Core-Fehler, den ich sehe, ist der Versuch, SAP wie Oracle arbeiten zu lassen. Übernehmen Sie die Standardprozesse von SAP, statt die Logik eines anderen Systems in Eigenentwicklung nachzubauen. Wenn Sie noch zwischen beiden wählen, vergleiche ich sie in SAP vs. Oracle.

Clean Core ist ein Change-Management-Problem, bevor es ein technisches ist. Jedes eigene Objekt existiert, weil jemand danach gefragt hat. Es zu entfernen heißt, diese Person davon zu überzeugen, dass der Standardprozess gut genug ist.

Dieses Gespräch läuft besser, wenn der Fachbereich den neuen Prozess funktionieren sieht, nicht eine Folie darüber. Es läuft auch besser, wenn Sie die Behauptung prüfen, ein Prozess sei einzigartig, denn oft ist er es nicht (siehe Schritte 4 und 5 unten).

Kompetenzen zählen so viel wie Werkzeuge. Ein ABAP-Team, das noch nicht mit ABAP Cloud oder BTP gearbeitet hat, bremst das Programm, während es lernt. Ein Hersteller, mit dem ich gearbeitet habe, hat vor dem Start seines S/4HANA-Projekts ein dreimonatiges internes BTP-Programm durchgeführt, und das hat sich in weniger Überraschungen während des Baus ausgezahlt.

Clean-Core-Compliance beschreibt, wie viel Ihres Systems die Kriterien von SAP über die fünf Prinzipien hinweg erfüllt. Ohne Zahlen können Sie sie nicht steuern, und SAP gibt Ihnen drei Stellen, an denen Sie sie bekommen.

1. Das ABAP Test Cockpit. Das SAP-Werkzeug für Prüfungen auf Code-Ebene. Es zeigt, welche eigenen Objekte nicht freigegebene Objekte, Modifikationen oder direkte Tabellenzugriffe nutzen.
2. Der SAP Readiness Check. Er ist in Ihrem Wartungsvertrag enthalten und zeigt, was ein Wechsel auf S/4HANA berührt, bevor Sie sich festlegen.
3. Das RISE with SAP Methodology Dashboard, auch Clean Core Dashboard genannt. Es läuft in SAP Cloud ALM. Seine Systemsicht prüft Ihre S/4HANA-Version, bestätigt, dass die Werkzeuge zur Datensammlung aktiv sind, und bewertet Erweiterungen vor einem Upgrade, und seine Betriebssicht verfolgt operative KPIs.

Die Zahlen, die ich der Design Authority jeden Monat vorlegen würde, sind einfach. Wie viele eigene Objekte liegen auf jedem Level, und sinkt Level D? Wie viele Ausnahmen sind offen, und hat jede einen Verantwortlichen?

Wenn Sie mich bitten würden, Ihr System nächsten Monat zu bewerten, würde ich in dieser Reihenfolge vorgehen.

1. Finden Sie heraus, was genutzt wird. Führen Sie den SAP Readiness Check aus und sammeln Sie Nutzungsdaten zu Ihrer Eigenentwicklung. In einem Programm brachte uns eine Analyse mit smartShift von 18.000 eigenen Objekten auf 3.200, weil der Großteil des Rests schlicht nicht genutzt wurde.
2. Ordnen Sie den Rest den Leveln A bis D zu. Nutzen Sie für den Code das ABAP Test Cockpit. Wenn Sie auf RISE sind, verfolgt das Clean Core Dashboard es von dort aus.
3. Entscheiden Sie Objekt für Objekt. Stilllegen, auf eine freigegebene Schnittstelle umstellen, auf BTP neu bauen oder mit dokumentierter Begründung behalten. Beginnen Sie mit Code, der jeden Tag läuft, denn ein Bericht, den ein regionales Team zweimal im Jahr nutzt, kann warten.
4. Holen Sie den Fachbereich in den Raum. Ein Finanzleiter, mit dem ich gearbeitet habe, verstand seine neue Fiori-App erst nach einer 45-minütigen Vorführung. Diese Sitzung sparte zwei Wochen Hin und Her im UAT.
5. Hinterfragen Sie „unser Prozess ist anders“. In einem Workshop mit dem Vertriebsteam eines europäischen Industrieunternehmens 2023 erwies sich der „einzigartige“ Prozess zu 80 % als überflüssige Altverwaltung. Der SAP-Standard verbesserte das Kundenerlebnis, sobald die Workarounds weg waren.
6. Beginnen Sie früh mit der Datenarbeit. Ein Einzelhandelskunde aus der GCC-Region, mit dem ich 2024 gearbeitet habe, hatte über 15.000 Kundenfelder zu sichten. Meiner Erfahrung nach macht die Datenmigration 30 bis 40 % des Einführungsaufwands aus, und mein Leitfaden zu den Kosten einer SAP-Einführung zeigt, wo das im Budget landet.
7. Setzen Sie die Governance vor dem Go-live auf. Richten Sie die oben beschriebene Design Authority ein und machen Sie sie zum einzigen Weg für eine neue Erweiterung.

Drei Fragen kommen in fast jedem Gespräch, das ich dazu führe.

Ist Clean Core unter RISE with SAP Pflicht?

Nicht als pauschale Regel. In der Public Edition erzwingt das System es, in der Private Edition und On-Premise können Sie den Kern weiterhin modifizieren.

Dort ist Clean Core eine Governance-Entscheidung, die SAP über das RISE Methodology Dashboard verfolgt. Wenn ein Systemintegrator Ihnen sagt, es sei vertraglich vorgeschrieben, bitten Sie ihn, Ihnen die Klausel zu zeigen.

Wie lange habe ich noch mit ECC?

Für SAP ERP 6.0 mit den Erweiterungspaketen 6 bis 8 endet die Mainstream-Wartung am 31. Dezember 2027. Die optionale erweiterte Wartung läuft gegen Aufpreis bis 31. Dezember 2030.

Danach deckt die Übergangsoption SAP ERP, private edition die Jahre 2031 bis 2033 ab. Sie gilt nur für große Systeme, die vor Ende 2030 bereits auf SAP ERP, private edition auf SAP HANA umgezogen sind.

Betrachten Sie 2033 als Ausnahmeweg, nicht als Planungsdatum. Mein Leitfaden zur Migration von ECC auf S/4HANA behandelt die Wahl des Wegs.

Spielt Clean Core für AI eine Rolle?

Ja. Wer beim SAP-Standard bleibt, hilft AI und Joule, besser zu funktionieren, und stark modifizierte Prozesse sind genau dort, wo ihre Einführung am schwersten ist.

SAP baut seine AI-Funktionen, darunter Joule, auf seinen Standardprozessen und seinem Datenmodell auf. Joule für Entwickler erzeugt ABAP-Cloud-Code gegen freigegebene APIs. Wie Cloud, AI und Clean Core zusammenpassen, beschreibe ich in ERP-Modernisierung.

Teams, die Clean Core auslassen, sparen sich die Arbeit nicht. Sie verschieben sie, und sie kommt zurück als blockierte Upgrades, Marathons aus Regressionstests und Eigenentwicklungen, die niemand versteht.

Bevor Sie einen S/4HANA- oder RISE-Vertrag unterschreiben, bitten Sie Ihren Systemintegrator, Ihre heutige Eigenentwicklung den Leveln A bis D zuzuordnen. Wenn er das nicht liefern kann, sagt Ihnen das etwas über die Schätzung. Buchen Sie ein Gespräch, und wir sehen uns Ihre Situation an.

Was ist Clean Core in SAP?

Clean Core bedeutet, S/4HANA nah am SAP-Standard zu halten und Erweiterungen nur über Schnittstellen zu bauen, die SAP freigegeben hat und stabil zu halten zusagt. Erweiterungen laufen entweder On-Stack mit ABAP Cloud oder Side-by-Side auf SAP BTP. Das Ziel: Upgrades brechen Ihre eigene Logik nicht.

Was sind die fünf Prinzipien von SAP Clean Core?

Die fünf Leitprinzipien von SAP für Clean Core sind Prozesse, Erweiterbarkeit, Daten, Integrationen und Betrieb. Prozesse bleiben nah am Standard, Erweiterungen nutzen freigegebene APIs, und Daten werden unter einem Governance-Modell sauber gehalten. Integrationen nutzen unterstützte Technologien, und der Betrieb umfasst die Governance, Menschen und Werkzeuge, die die anderen vier absichern.

Was sind die SAP-Clean-Core-Level A, B, C und D?

Seit August 2025 ordnet SAP Erweiterungen vier Leveln zu. Level A nutzt nur öffentlich freigegebene, stabile Schnittstellen, Level B nutzt zusätzlich klassische SAP-APIs, und Level C greift auf interne SAP-Objekte zu. Level D umfasst Modifikationen, Schreibzugriffe auf SAP-Tabellen und implizite Erweiterungen und trägt das höchste Upgrade-Risiko.

Ist Clean Core bei RISE with SAP Pflicht?

Nicht als pauschale Regel. S/4HANA Cloud Public Edition erlaubt nur ABAP Cloud und freigegebene Schnittstellen und erzwingt Clean Core damit technisch. In der Private Edition können Sie den Kern weiterhin modifizieren, daher ist Clean Core dort eine Governance-Entscheidung, die SAP über das RISE with SAP Methodology Dashboard verfolgt.

Was ist ABAP Cloud?

ABAP Cloud ist SAPs cloudfähiges ABAP-Entwicklungsmodell. Es erlaubt nur freigegebene Objekte, öffentliche APIs und Erweiterungspunkte, und das hält Eigenentwicklungen upgrade-stabil. In S/4HANA Cloud Public Edition ist es für Neukunden seit Release 2208 Pflicht, in der Private Edition und On-Premise seit 2022 empfohlen.

Wie misst man Clean Core?

Nutzen Sie das ABAP Test Cockpit für Prüfungen auf Code-Ebene und ordnen Sie eigene Objekte den Leveln A bis D zu. RISE-Kunden können die Umsetzung im RISE with SAP Methodology Dashboard, auch Clean Core Dashboard genannt, in SAP Cloud ALM verfolgen. Ich verfolge die Zahl der Objekte je Level, den Trend bei Level D und die Zahl offener Ausnahmen mit Verantwortlichem.

Wer sollte die SAP-Clean-Core-Governance verantworten?

Eine Design Authority aus Fachbereich und IT sollte jede Clean-Core-Entscheidung verantworten. Die Prozessverantwortlichen entscheiden, ob eine Anforderung echt ist, und die IT entscheidet, wie und auf welchem Level sie gebaut wird. Jede Ausnahme wird mit einem Verantwortlichen erfasst und vor jedem Upgrade überprüft.

Wann endet die Wartung für SAP ECC?

Für SAP ERP 6.0 mit den Erweiterungspaketen 6 bis 8 endet die Mainstream-Wartung am 31. Dezember 2027, mit optionaler erweiterter Wartung gegen Aufpreis bis 31. Dezember 2030. Die Übergangsoption SAP ERP, private edition läuft bis 2033, aber nur für berechtigte große Systeme, die vor Ende 2030 auf SAP ERP, private edition auf SAP HANA umgezogen sind.