Clean Core vs. Customizing: Was in S/4HANA wirklich noch erlaubt ist

„Kein Custom Code mehr.“ Ein Satz, der in Projekten regelmäßig fällt – und sich in der Praxis so gut wie nie in dieser Absolutheit hält. Die Realität ist differenzierter, und das ist auch gut so. Denn Clean Core bedeutet nicht das Ende jeglicher Anpassung. Es bedeutet das Ende von unkontrollierter Anpassung.

Die entscheidende Frage lautet deshalb nicht: „Darf ich noch anpassen?“ Sondern: „Welches Customizing ist strategisch sinnvoll – und welches nicht mehr?“

Die drei Ebenen von SAP-Anpassungen im Clean-Core-Kontext

Um diese Frage zu beantworten, lohnt sich eine klare Unterscheidung zwischen drei Typen von Anpassungen – denn nicht alle sind gleich zu bewerten.

Ebene 1: Konfiguration – weiterhin erlaubt und notwendig

Die klassische SAP-Konfiguration im IMG (Implementation Guide) ist kein Widerspruch zu Clean Core. Im Gegenteil: Sie ist der vorgesehene Weg, um SAP-Systeme an organisatorische und prozessuale Anforderungen anzupassen.

Typische Beispiele sind:

• Buchungskreise und Unternehmensstruktur: Organisationseinheiten, Kostenstellen, Controlling-Kreise
• Kontenlogik und Kontenfindung: Kontenrahmenzuordnungen, automatische Buchungsregeln
• Prozessparameter: Toleranzgrenzen, Workflow-Einstellungen, Ausgabesteuerung

Diese Art der Anpassung berührt keinen Programmcode, ist vollständig dokumentiert und wird von SAP-Releases übernommen. Sie bleibt in einem Clean-Core-Umfeld nicht nur erlaubt, sondern ist zwingend notwendig, um SAP überhaupt betriebsfähig zu machen.

Ebene 2: Erweiterungen – der bevorzugte Weg für darüber hinausgehende Anforderungen

Wenn die reine Konfiguration nicht ausreicht, sind Erweiterungen der strategisch saubere nächste Schritt. SAP bietet dafür ein breites Werkzeugspektrum:

In-App Extensibility (Key User Extensibility): Felder hinzufügen, Logiken anpassen, Formulare gestalten – direkt im System, ohne Programmieraufwand, und vollständig upgrade-sicher. Diese Werkzeuge sind bewusst für Anpassungen konzipiert, die innerhalb des SAP-Standards bleiben.

Side-by-Side-Erweiterungen auf SAP BTP: Für komplexere Anforderungen – eigene Applikationen, externe Prozesslogiken, Integrationsszenarien – bietet die SAP Business Technology Platform eine saubere Entkopplung vom Core. Die Erweiterung läuft außerhalb des SAP-Systems und kommuniziert über stabile, versionierte APIs.

Beide Wege sind Clean-Core-konform, weil sie keine direkten Eingriffe in den SAP-Standard erfordern. Der Preis: höhere Komplexität in der Architektur und ein erhöhter Initialaufwand gegenüber einem direkten Core-Eingriff. Langfristig zahlt sich dieser Mehraufwand jedoch aus – vor allem bei Upgrades und beim Wechsel auf neue SAP-Releases.

Ebene 3: Modifikationen – nur in begründeten Ausnahmefällen

Klassische Modifikationen – also direkte Änderungen am SAP-Standardcode oder implizite Enhancements ohne stabile API-Grundlage – sind im Clean-Core-Ansatz das letzte Mittel, nicht das erste. Der Grund liegt auf der Hand: Jede Modifikation muss bei einem Release-Upgrade geprüft, angepasst und neu getestet werden. In Systemen mit Hunderten von Modifikationen summiert sich dieser Aufwand zu erheblichen Projektkosten.

Das bedeutet nicht, dass Modifikationen grundsätzlich verboten sind. Es bedeutet, dass sie eine bewusste Ausnahmeentscheidung sein müssen – mit dokumentierter Begründung, Lifecycle-Planung und klarer Verantwortlichkeit.

Die eigentliche Entscheidungslogik: nicht „Ist es erlaubt?“ sondern „Was kostet es uns in drei Jahren?“

Der häufigste Fehler in der Bewertung von Anpassungsentscheidungen ist die Kurzfristperspektive. Ein direkter Core-Eingriff löst das Problem heute in zwei Stunden. Die saubere Erweiterung braucht zwei Wochen. Also fällt die Entscheidung zugunsten des schnellen Wegs.

Was dabei nicht eingerechnet wird: die Folgekosten. Jede Modifikation, die heute ohne Lifecycle-Betrachtung eingebaut wird, erscheint beim nächsten Upgrade als ungebetener Gast. Und wenn es nicht nur eine ist, sondern hundert, wird aus einem technischen Problem ein strategisches.

Die richtige Entscheidungsfrage lautet deshalb: Was kostet uns diese Anpassung in drei Jahren? Das schließt Upgrade-Aufwand, Wartungskosten, Testaufwand und das Risiko ein, bei neuen SAP-Funktionen ausgesperrt zu bleiben, weil der Standard zu stark verändert wurde.

Typische Fehlentscheidungen in der Praxis

Aus Projekterfahrung lassen sich drei Muster beobachten, die immer wieder zu unnötigem Mehraufwand führen:

Kurzfristige Prozessoptimierung auf Kosten der Upgradefähigkeit. Eine Prozessverbesserung, die einen direkten Core-Eingriff erfordert, mag fachlich sinnvoll sein. Wenn sie aber dazu führt, dass das nächste SAP-Release nicht mehr eingespielt werden kann, ohne erheblichen Anpassungsaufwand, ist die Kosten-Nutzen-Rechnung oft negativ.

Fehlende Dokumentation von Erweiterungen. Erweiterungen, die ohne Dokumentation eingebaut werden, werden zum Risiko – nicht beim Einbau, sondern zwei Jahre später, wenn niemand mehr weiß, warum sie existieren und was sie tun. Gute Clean-Core-Governance beginnt mit sauberer Dokumentationspflicht.

Keine Lifecycle-Betrachtung. Jede Erweiterung sollte mit einer Antwort auf die Frage verbunden sein: Wie lange brauchen wir diese Anpassung, wer ist verantwortlich, und was passiert, wenn SAP diese Anforderung irgendwann im Standard abdeckt?

Best Practice aus S/4HANA-Projekten

Erfolgreiche Projekte, die Clean Core konsequent umsetzen, arbeiten mit drei zentralen Prinzipien:

Extension-First-Strategie: Bevor eine Modifikation beschlossen wird, muss nachgewiesen sein, dass die Anforderung sich nicht über Konfiguration oder die vorhandenen Erweiterungsmodelle abbilden lässt. Nicht die Modifikation ist die Ausnahme – sie ist der Ausschluss, wenn alles andere nicht funktioniert.

Klare Architekturprinzipien: Ein schriftlich fixiertes Regelwerk, das definiert, welche Erweiterungstypen für welche Anforderungsklassen zulässig sind, schafft Konsistenz und verhindert, dass jede Anforderung neu diskutiert werden muss. Dieses Regelwerk muss vor Projektstart existieren, nicht nach dem ersten Konflikt.

Bewertung jeder Abweichung mit Business Case: Wer eine Abweichung vom Standard beantragt, trägt die Beweislast. Nicht technisch, sondern wirtschaftlich: Was ist der Nutzen der Anpassung, was sind die langfristigen Kosten, und überwiegt der Nutzen? Diese Disziplin senkt die Zahl der Erweiterungen deutlich – ohne fachliche Anforderungen zu übergehen.

Fazit: Clean Core ist ein Governance-Thema

Customizing ist nicht das Problem. Unkontrolliertes Customizing ist es.

Clean Core ist kein technisches Verbot, sondern eine strategische Haltung gegenüber Anpassungen. Konfiguration bleibt uneingeschränkt möglich. Erweiterungen sind der bevorzugte Weg, wenn der Standard nicht ausreicht. Modifikationen sind die begründete Ausnahme, nicht die bequeme Abkürzung.

Wer das versteht, erkennt: Clean Core ist vor allem eine Frage der Governance – der bewussten, dokumentierten und lifecycle-bewussten Steuerung aller Anpassungsentscheidungen. Unternehmen, die diese Governance ernst nehmen, schaffen sich ein S/4HANA-System, das nicht nur heute funktioniert, sondern auch in fünf Jahren noch wartbar, upgradefähig und anpassbar ist.

Ihre Anpassungsstrategie Clean-Core-konform ausrichten?

Wir unterstützen Sie bei Architektur und Entscheidungsfindung. Von der Definition Ihrer Erweiterungsstrategie über die Einführung geeigneter Governance-Strukturen bis hin zur Bewertung konkreter Anpassungsszenarien – gemeinsam finden wir den richtigen Rahmen für Ihr S/4HANA-Vorhaben.

Jetzt Kontakt aufnehmen und Ihre Clean-Core-Strategie auf ein solides Fundament stellen.

Bis bald und viel Erfolg!

Euer amotIQ solutions Team