Clean Core im ERP
Was der Begriff von SAP meint, warum das Prinzip für jedes Cloud-ERP gilt und wie Sie Anpassungen so bauen, dass der nächste Release-Wechsel planbar bleibt
Kernaussagen
- Clean Core heißt nicht, auf Anpassungen zu verzichten. Der vom Hersteller gelieferte Kern bleibt unverändert, und eigene Erweiterungen greifen nur über freigegebene, upgradestabile Schnittstellen zu [1][3].
- Der Begriff stammt von SAP, das Prinzip gilt für jedes Cloud-ERP: Wo alle Kunden dieselbe Codebasis nutzen, ist für individuelle Eingriffe in den Kern kein Platz [1][4].
- Ein sauberer Kern macht Release-Wechsel planbar und verschiebt den Aufwand. Dafür braucht jede Erweiterung einen Betrieb außerhalb des Kerns und jemanden, der sie bei jedem Update testet.
- In der Auswahl entscheidet, wie viele Anforderungen der Standard und die vorgesehenen Erweiterungswege abdecken und ob Lösungen von Partnern den Kern verändern.
Der Begriff stammt von SAP, das Prinzip gilt herstellerübergreifend
Clean Core ist ein Begriff von SAP und die Antwort auf ein altes Problem [1]. Über Jahrzehnte konnten Kunden ihre installierten SAP-Systeme an vorgesehenen Stellen erweitern, Objekte des Herstellers direkt ändern oder kopieren und dabei fast jede Tabelle und Funktion des Systems nutzen. Das trug, solange jedes System im Rechenzentrum des Kunden lief und der Kunde selbst entschied, wann er ein Update einspielt. Jede Änderung am Herstellercode musste nach einem Upgrade erneut gründlich getestet werden [1].
In der Cloud geht das nicht mehr. Alle Kunden nutzen dieselbe Codebasis, und Änderungen des Herstellers gehen bei allen gleichzeitig live. Für individuelle Eingriffe in den Kern ist dort kein Platz. Erweiterungen bleiben möglich, aber nach neuen Regeln: strikt getrennt vom Standard und nur über definierte, upgradestabile Schnittstellen [1].
Andere Hersteller folgen derselben Logik unter eigenem Namen. Microsoft begründet für Dynamics 365 Finance and Operations den Wechsel vom Überschreiben des Herstellercodes zu reinen Erweiterungen mit dem Umzug in die Cloud und häufigeren Updates; Änderungen direkt im Herstellercode unterstützt das System nicht mehr [4]. Clean Core ist deshalb in Projekten zum Sammelbegriff für dieses Prinzip geworden, auch bei Systemen anderer Hersteller. Wie unscharf der Begriff dabei bleibt, beschreibt die Deutschsprachige SAP-Anwendergruppe (DSAG): Clean Core werde „unterschiedlich verstanden, interpretiert und gelebt“ [3].
Hersteller und Anwender fassen Clean Core unterschiedlich weit
| Quelle | Definition (sinngemäß, englische Quellen übersetzt) | Schwerpunkt |
|---|---|---|
| SAP Learning [1] | Clean Core ist ein Konzept und ein Vorgehen für ein modernes, cloudfähiges System. Zum Kern zählen Prozesse, Daten, Integration, Betrieb und Erweiterungen. Erweiterungen bleiben strikt vom Standard getrennt und greifen auf Geschäftsobjekte nur über definierte, upgradestabile Schnittstellen zu | das ganze System, über den Programmcode hinaus |
| Hois, Panda, Pietsch (2025), SAP News Center: Reifegradmodell [2] | Jede Erweiterung wird einer von vier Stufen zugeordnet. Stufe A nutzt nur öffentlich freigegebene Schnittstellen mit Stabilitätszusage. Stufe D umfasst Modifikationen und Schreibzugriffe auf Tabellen des Herstellers und gilt nicht als sauber | Einstufung jeder einzelnen Erweiterung |
| DSAG, ABAP-Leitfaden [3] | Streng genommen sollen System-Upgrades keinen Einfluss auf Kundenerweiterungen haben; deshalb sind nur freigegebene Schnittstellen erlaubt. Dazu kommen zwei Aufgaben: neue Entwicklungen nach festen Regeln bauen („Keep the core clean“) und den Bestand schrittweise umbauen („Make the core clean“) | Weg dorthin und Umgang mit dem Bestand |
SAP fasst den Kern weit und zählt Datenqualität und Betrieb dazu. Das Reifegradmodell macht aus dem Leitbild eine Einstufung, die sich für jede Erweiterung prüfen lässt. Die DSAG beschreibt aus Sicht der Anwender, dass ein sauberer Kern bei gewachsenen Systemen ein Weg ist und kein Schalter. Gemeinsam ist allen drei Quellen der Maßstab: Ein Release-Wechsel darf eigene Erweiterungen nicht brechen.
Unser Verständnis
Wir verstehen Clean Core herstellerneutral als Zustand des ERP-Kerns. Code und Datenmodell des Herstellers bleiben unverändert, und jede eigene Erweiterung nutzt nur Wege, deren Stabilität der Hersteller über Releases hinweg zusagt: Konfiguration, vorgesehene Erweiterungspunkte im System und freigegebene Schnittstellen für Anwendungen daneben. Customizing im Sinne unseres Glossars bleibt damit erlaubt, ausgeschlossen ist der Eingriff in den Herstellercode. Das Ziel ist ein Release-Wechsel, bei dem keine eigene Erweiterung umgebaut werden muss. Je standardnäher die Erweiterungen, desto planbarer die Upgrades. Ein sauberer Kern wird nicht einmal hergestellt, sondern bei jeder neuen Anforderung neu entschieden. Die Kurzdefinition steht im Glossar unter Clean Core.
Im Beispiel braucht keine Anforderung einen Eingriff in den Kern
Ein Großhändler für Elektrotechnik beliefert Installationsbetriebe und Bauprojekte. Sein bisheriges ERP hat er über die Jahre an fünf Stellen angepasst. Bei der Einführung eines neuen Systems setzt er dieselben Anforderungen mit sauberem Kern um:
| Anforderung | im bisherigen System | mit sauberem Kern | beim Release-Wechsel |
|---|---|---|---|
| Projektnummer des Kunden auf Auftrag, Lieferschein und Rechnung | eigenes Feld direkt in der Auftragstabelle des Herstellers | Zusatzfeld über die vorgesehene Felderweiterung, Formulare über die Vorlagen | nichts zu tun |
| Projektpreise mit Laufzeit und Mengenstaffel | Preisfindung im Herstellercode geändert | zuerst die Konditionen des Standards prüfen; reichen sie nicht, eigene Regel am Erweiterungspunkt der Preisfindung | Regel im Testsystem prüfen |
| Freigabe durch die Vertriebsleitung bei überschrittenem Kreditlimit | eigenes Programm setzt den Auftragsstatus direkt in der Datenbank | Freigabeablauf des Standards eingestellt | nichts zu tun |
| Lieferavis an die Baustellen-App des Kunden | die App liest Lieferungen direkt aus den Tabellen des ERP | Dienst neben dem ERP reagiert auf das Ereignis „Lieferung gebucht“ und nutzt eine freigegebene Schnittstelle | Verbindung prüfen, wenn die Schnittstelle eine neue Version bekommt |
| Deckungsbeitrag je Bauprojekt | eigener Bericht liest Tabellen des Herstellers direkt | Auswertung über freigegebene Datensichten | nichts zu tun, solange die Datensicht freigegeben bleibt |
Lehrbeispiel, kein Kundenprojekt.
Im bisherigen System musste der Händler vor jedem Release-Wechsel alle fünf Stellen prüfen und oft nachziehen, weil jede davon Code oder Tabellen des Herstellers berührt. Mit sauberem Kern bleiben zwei Prüfpunkte, die Projektpreise und das Lieferavis, und keiner verlangt, Herstellercode erneut anzupassen. Die Projektpreise zeigen auch die Reihenfolge: Erst wird geprüft, ob der Standard die Anforderung trägt, dann, ob eine Einstellung reicht, und erst danach wird erweitert.
So glatt gelingt der Umzug nicht immer. Die DSAG weist darauf hin, dass über Jahrzehnte gewachsene Lösungen beim Übergang teilweise vollständig neu gebaut werden müssen, was eine hohe Investition bedeutet [3].
Die Forschung beschreibt den Weg vom Programmcode zur Schnittstelle
Abendroth, Bender und Gronau haben 2024 auf der International Conference on Enterprise Information Systems (ICEIS) die technischen Möglichkeiten der ERP-Anpassung systematisch untersucht [5]. Ausgangspunkt ist eine Beobachtung aus der Praxis: Unternehmen passen ihr ERP an, weil ihre besonderen Prozesse oft ihren Wettbewerbsvorteil ausmachen. Die Begriffe dafür sind in der Fachliteratur aber veraltet oder mehrdeutig. Die Autoren werteten 137 Definitionen aus 26 Arbeiten aus und ordneten die Arten der technischen Anpassung neu.
Das Ergebnis beschreibt eine Verschiebung. In On-Premise-Systemen wurde vor allem der Programmcode des ERP geändert, in Cloud-ERP-Systemen wird über Schnittstellen und Integration angepasst. Dazu kommen neue Werkzeuge, mit denen Kunden und Key User Anpassungen selbst vornehmen [5]. Clean Core ist die Antwort der Hersteller auf diese Entwicklung. Wer heute ein ERP wählt, wählt damit auch die Wege, auf denen es sich anpassen lässt.
Für Erweiterungen, die auf einer Low-Code-Plattform neben dem ERP entstehen, liefert eine zweite Arbeit einen Prüfpunkt. Abendroth und Bender gehen davon aus, dass sich die Eignung einer solchen Plattform vor allem am Angebot fertiger Erweiterungen in ihrem Add-on-Store entscheidet, und entwickeln dafür ein Messinstrument, erprobt an 1.483 Add-ons aus drei Add-on-Stores [6]. Läuft ein Teil der eigenen Anforderungen künftig auf einer solchen Plattform, gehört dieses Angebot deshalb in die Bewertung.
Clean Core ist kein anderes Wort für Customizing oder Fit-to-Standard
Fünf Begriffe fallen in Gesprächen über Anpassungen oft durcheinander. Sie beantworten unterschiedliche Fragen.
| Begriff | Leitfrage | Verhältnis zu Clean Core |
|---|---|---|
| Konfiguration | Welche vorgesehenen Einstellungen nutzen wir? | immer vereinbar |
| Customizing | Was passen wir über die Konfiguration hinaus an? | vereinbar, solange vorgesehene Erweiterungspunkte oder freigegebene Schnittstellen genutzt werden |
| Kernmodifikation | Ändern wir Code oder Datenmodell des Herstellers? | nicht vereinbar |
| Fit-to-Standard | Wie viel unserer Abläufe übernimmt der Standard? | verringert die Zahl der Erweiterungen, regelt aber nicht, wie die übrigen gebaut werden |
| Composable ERP | Welche Prozesse laufen im Kern, welche in eigenen Bausteinen? | setzt einen sauberen Kern voraus |
Einordnung von Find-Your-ERP auf Grundlage von [1], [3] und dem ERP-Glossar.
Beim Customizing lohnt ein genauer Blick auf das Wort. Das Gabler Wirtschaftslexikon versteht darunter die Anpassung einer Standardsoftware an kundenindividuelle Anforderungen und zählt schon die Auswahl und Parametrisierung von Funktionen dazu [7]. Wir verwenden den Begriff wie im Glossar unter Customizing für Anpassungen, die über die reine Konfiguration hinausgehen. In beiden Lesarten verträgt sich Customizing mit einem sauberen Kern. Unvereinbar ist allein der Eingriff in Code und Datenmodell des Herstellers. Welche Stufen dazwischen liegen, von der Regel an einem Erweiterungspunkt bis zum Dienst neben dem ERP, zeigt das Stufenmodell im Beitrag zum ERP-Customizing.
Fit-to-Standard und Clean Core ergänzen sich. Der Abgleich mit dem Standard klärt, welche Anforderungen überhaupt eine Erweiterung brauchen, und die Fit-Gap-Analyse bewertet die verbleibenden Lücken. Clean Core legt fest, wie diese Lücken geschlossen werden. Composable ERP baut auf einem sauberen Kern auf: Ein Kern, der mit eigenständigen Bausteinen über Schnittstellen zusammenarbeiten soll, muss jedes Update unbeschadet überstehen. Ein sauberer Kern ohne Bausteine ist dagegen eine standardnah genutzte Suite.
Ein sauberer Kern heißt nicht, auf Anpassungen zu verzichten
In Auswahl- und Umstiegsprojekten begegnen uns vier Missverständnisse immer wieder.
Das erste: Clean Core bedeute, nichts mehr anzupassen. SAP betont das Gegenteil, Erweiterungen bleiben ausdrücklich vorgesehen und werden nur anders gebaut [1]. Wer seine Besonderheiten aufgibt, um den Kern sauber zu halten, hat das Ziel verfehlt. Wann sich der Prozess dem Standard anpasst und wann das System dem Prozess, bleibt eine fachliche Entscheidung.
Das zweite: Clean Core sei ein Thema nur für SAP-Kunden in der Cloud. Das Prinzip gilt bei anderen Herstellern ebenso [4], und auch im eigenen Rechenzentrum wird jede Modifikation beim nächsten Release-Wechsel teurer. Die DSAG hält Clean Core gerade für On-Premise-Systeme und die Private Cloud für relevant, weil die Public Cloud ohnehin keine anderen Wege zulässt [3].
Das dritte: Was neben dem ERP läuft, sei automatisch sauber. Ein Dienst außerhalb des Systems, der direkt in Tabellen des Herstellers schreibt oder interne, nicht freigegebene Objekte nutzt, bricht beim Update genauso wie eine Modifikation. SAP ordnet Schreibzugriffe auf Herstellertabellen der untersten Stufe D zu und Zugriffe auf interne Objekte der Stufe C [2]. Entscheidend ist der Zugriffsweg, nicht der Ort des Codes.
Das vierte: Einmal sauber, immer sauber. Jede neue Anforderung kann den Kern wieder belasten. Die DSAG hält deshalb ein Gremium für Pflicht, das die Regeln für Erweiterungen pflegt und durchsetzt [3]. Wie ein solches Entscheidungsgremium zusammengesetzt ist und nach welchen Prinzipien es entscheidet, beschreibt der Beitrag zum ERP-Customizing im Abschnitt zur Governance.
Wie weit Clean Core reicht, entscheidet auch das Betriebsmodell
In der Public Cloud zieht der Hersteller die Grenze selbst. Wer etwa die öffentliche Cloud-Ausgabe von SAP S/4HANA nutzt, kann nur noch über freigegebene Wege erweitern; die DSAG nennt diese Ausgabe „per definitionem ‚clean‘“ [3]. In der Private Cloud und im eigenen Rechenzentrum entscheidet das Unternehmen weitgehend selbst, wie sauber es seinen Kern hält [3]. Diese Freiheit bezahlt es beim nächsten Release-Wechsel.
| Betriebsmodell | Wer zieht die Grenze | Folge für den Release-Wechsel |
|---|---|---|
| Public Cloud | der Hersteller; Eingriffe in den Kern sind technisch nicht möglich | Updates im Takt des Herstellers; jede Erweiterung muss jede neue Version überstehen |
| Private Cloud | Unternehmen und Betreiber; der Betreiber kann Modifikationen einschränken | Termin mit dem Betreiber abgestimmt; der Aufwand wächst mit jeder Modifikation |
| On-Premise und Hosting | das Unternehmen | Termin frei wählbar; wer lange nicht aktualisiert, vergrößert den Abstand zum Standard |
Einordnung von Find-Your-ERP auf Grundlage von [1], [3] und dem ERP-Glossar.
Ein sauberer Kern heißt nicht, dass beim Release-Wechsel nichts mehr getestet wird. Getestet werden die eigenen Erweiterungen und die Prozessketten, an denen sie hängen, nachgezogen wird kein Herstellercode. Bei Systemen, deren nächster Wechsel einer Neueinführung nahekommt, liefert die Bestandsaufnahme der Erweiterungen die Grundlage für die Frage, ob ein Upgrade oder eine Ablösung der bessere Weg ist. Dazu der Beitrag ERP-Upgrade oder Ablösung; wie sich Cloud und eigener Betrieb sonst unterscheiden, steht unter Cloud vs. On-Premise und im Glossar unter Cloud-ERP.
In der Auswahl zählt, wo Ihre Anforderungen landen
Für jede Muss-Anforderung, die der Standard nicht abdeckt, sollte vor der Entscheidung feststehen, auf welchem Weg sie umgesetzt wird. Lassen Sie sich das in der Demo zeigen, wie es das Drehbuch für Anbieterpräsentationen beschreibt, und geben Sie dafür eine echte Anforderung vor, etwa die Projektpreise aus dem Beispiel. Diese Prüffragen trennen ein System mit tragfähigen Erweiterungswegen von einem, das nur offen für Programmierung ist:
| Prüffrage | Woran Sie es erkennen |
|---|---|
| Welche Erweiterungswege bietet das System? | Der Anbieter legt in der Demo ein Zusatzfeld an und hinterlegt eine eigene Regel, ohne Herstellercode zu ändern |
| Welche Schnittstellen sind freigegeben, und was sagt der Hersteller zu ihrer Stabilität zu? | Eine dokumentierte Liste freigegebener Schnittstellen mit Versionierung und Fristen für abgekündigte Versionen |
| Wie läuft ein Release-Wechsel ab? | Ein Release-Kalender mit Vorlaufzeit, in der eigene Erweiterungen in einem Testsystem geprüft werden |
| Wie werden eigene Erweiterungen geprüft? | Ein Prüfwerkzeug meldet Zugriffe auf nicht freigegebene Objekte, bevor eine Erweiterung produktiv geht |
| Greifen Branchenlösungen oder Add-ons des Partners in den Kern ein? | Der Partner sagt schriftlich, welche Erweiterungswege seine Lösung nutzt und wann sie für ein neues Release vorliegt |
| Was kostet die Plattform für Erweiterungen neben dem ERP? | Lizenz und Betriebskosten stehen im Angebot, auch wenn nach Nutzung abgerechnet wird |
| Wer pflegt die Erweiterungen nach dem Go-Live? | Zuständigkeit und Tests bei Updates stehen im Angebot des Implementierungspartners |
Wo Erweiterungen in der Zielarchitektur hingehören und welche Anforderungen besser in den Standard zurückgehen, erarbeiten wir mit Unternehmen in der Leistung ERP-Strategie und Roadmap.
Häufige Fragen
Woran erkennt man, wie sauber der Kern eines bestehenden Systems ist?
An einer Bestandsaufnahme aller Eigenentwicklungen: wo sie laufen, worauf sie zugreifen und ob sie noch genutzt werden. SAP ordnet jede Erweiterung einer von vier Stufen zu, von freigegebenen Schnittstellen bis zur Modifikation [2]. Die DSAG empfiehlt, jede Eigenentwicklung nach vier Möglichkeiten zu bewerten: weiterverwenden, stilllegen, überarbeiten oder auf eine andere Plattform verlagern [3]. Erfahrungsgemäß lässt sich ein Teil der Eigenentwicklungen ersatzlos stilllegen, weil ihn niemand mehr nutzt.
Was gilt für Add-ons und Branchenlösungen von Partnern?
Sie zählen mit, auch wenn das Unternehmen sie nicht selbst entwickelt hat. Eine Branchenlösung, die Herstellercode ändert, belastet den Kern wie eine eigene Modifikation. SAP zertifiziert Add-ons nach Angaben der DSAG nur noch, wenn sie nach den Clean-Core-Vorgaben gebaut sind; bei Add-ons ohne Zertifizierung rät die DSAG, rechtzeitig vor einem Upgrade beim Partner nachzufragen [3]. Bei anderen Herstellern gehört dieselbe Frage ins Angebot.
Wird die Einführung durch Clean Core teurer?
Bei der Umstellung eines gewachsenen Systems häufig ja. Die DSAG nennt sie eine hohe Investition, teilweise mit vollständigem Neubau bestehender Lösungen, und verweist auf das neue Wissen, das Entwicklung und Beratung dafür brauchen [3]. Bei einer Neueinführung entstehen Kosten vor allem für die Erweiterungsplattform und für die Arbeit, Anforderungen auf den Standard abzustimmen. Zurück kommt der Aufwand bei jedem Release-Wechsel, an dem keine Erweiterung umgebaut werden muss.
Dürfen Fachbereiche Erweiterungen selbst bauen?
Die Hersteller sehen das vor, etwa mit Werkzeugen für Key User direkt im System [1], und die Forschung beschreibt diese Werkzeuge als neuen Weg der Anpassung [5]. Damit der Kern sauber bleibt, braucht es eine Absprache, was Fachbereiche selbst anlegen dürfen, etwa Felder und einfache Prüfregeln, und was über die IT läuft. Die Rolle der Key User beschreibt das Glossar unter Key User.
Weiterlesen
Kurzdefinitionen zu Clean Core, Customizing, Konfiguration, Release-Wechsel und Cloud-ERP.
Das Stufenmodell von der Konfiguration bis zur Kernmodifikation, mit Bewertungsrahmen und Governance für Erweiterungen.
Wann das bestehende System mit vertretbarem Aufwand aktuell bleibt und wann ein Neustart der bessere Weg ist.
Betriebsmodelle im Vergleich, mit Folgen für Updates und die Abhängigkeit vom Anbieter.
Zielarchitektur, ERP-zentriert oder modular, mit priorisiertem Umsetzungspfad: unser Beratungsangebot.
Für SAP-ECC-Anwender: Wege nach S/4HANA und welche Rolle der saubere Kern im Umstieg spielt. Alternativen zu S/4HANA zeigt unsere Seite SAP ECC ablösen.
Quellen
[1] SAP Learning: Introducing the Clean Core Approach. Kurs „Practicing Clean Core Extensibility for SAP S/4HANA Cloud“. Abgerufen am 9. November 2026.
[2] Hois, R.; Panda, P.; Pietsch, S. (2025): Discover How to Extend SAP S/4HANA Cloud the Right Way. SAP News Center, 12. August 2025. Abgerufen am 9. November 2026.
[3] DSAG, Deutschsprachige SAP-Anwendergruppe e. V. (2026): SAP-Leitfaden ABAP, Kapitel 3 „Clean Core“, S. 33–47. Stand 2026/Q1. Abgerufen am 9. November 2026.
[4] Microsoft Learn: Extensibility home page, Finance and Operations. Stand 27. März 2026. Abgerufen am 9. November 2026.
[5] Abendroth, A.; Bender, B.; Gronau, N. (2024): The Evolution of Original ERP Customization: A Systematic Literature Review of Technical Possibilities. Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024), S. 17–27.
[6] Abendroth, A.; Bender, B. (2024): Ein Werkzeug zur Analyse von Komplexität von Low-Code und No-Code Add-ons: Ein Design Science Ansatz. HMD Praxis der Wirtschaftsinformatik 61 (5), S. 1180–1212.
[7] Lackes, R.; Siepermann, M.: Customizing. Gabler Wirtschaftslexikon online. Abgerufen am 9. November 2026.
Herstellerquellen belegen allgemeine Prinzipien und sind keine Produktempfehlung.
Dr. Benedict Bender
Co-Founder der Sectorlens GmbH
Besprechen Sie Ihre Erweiterungen mit einem ERP-Berater
Im Gespräch klären Sie mit einem Berater, welche Ihrer Anpassungen in den Standard zurückkönnen, welche an vorgesehene Erweiterungspunkte gehören und was das für die Auswahl oder den nächsten Release-Wechsel bedeutet. 30 Minuten, kostenlos und unverbindlich. Anbieterneutral: Kein Anbieter kann seine Platzierung kaufen oder beeinflussen.
Sie haben eine Frage? Dann schicken Sie uns gern eine Nachricht.