Clean Core in SAP: Realität oder Illusion? Erfahrungen aus echten S/4-Projekten

„Keep the Core clean“ – wer sich mit SAP S/4HANA beschäftigt, kennt diesen Satz. Er klingt einleuchtend, fast selbstverständlich. Und doch ist Clean Core in der Praxis einer der größten Zielkonflikte, mit dem Projektteams täglich ringen. Dieser Artikel wirft einen ehrlichen Blick auf die Realität hinter dem Konzept – ohne Marketingsprache, aber mit konkreten Erfahrungen aus laufenden S/4-Projekten.

Was Clean Core wirklich bedeutet

Clean Core ist mehr als ein technisches Konzept. Es ist ein Paradigmenwechsel in der Art, wie Unternehmen SAP-Systeme betreiben und weiterentwickeln. Die Kernaussage: Statt den SAP-Standard durch direkte Codemodifikationen zu verändern, sollen Erweiterungen sauber abgekapselt werden – über definierte APIs, Side-by-Side-Erweiterungen auf der SAP Business Technology Platform (BTP) oder In-App-Extensibility-Mechanismen innerhalb des ABAP-Stacks.

Das Ziel dahinter ist nachvollziehbar:

• Upgrade-Fähigkeit: Ein sauberer Core lässt sich einfacher auf neue SAP-Releases heben.
• Wartbarkeit: Weniger Eigenentwicklung bedeutet weniger technische Schulden.
• Standardkonformität: Unternehmen profitieren stärker von SAP-Innovation, wenn sie nah am Standard bleiben.

In der Theorie klingt das überzeugend. In der Praxis ist es deutlich komplizierter.

Wo Clean Core in Projekten regelmäßig scheitert

1. Fachbereiche akzeptieren den Standard nicht – und das hat oft gute Gründe

SAP-Standardprozesse decken in der Regel 70 bis 80 Prozent der fachlichen Anforderungen ab. Die verbleibenden 20 bis 30 Prozent sind jedoch selten trivial. Sie umfassen häufig:

• Regulatorische Anforderungen: Branchenspezifische Compliance-Vorgaben, länderspezifische Gesetzgebung oder interne Audit-Anforderungen, die SAP im Standard schlicht nicht vollständig abbilden kann.
• Historisch gewachsene Prozesse: Abläufe, die über Jahre optimiert wurden und an denen ganze Organisationseinheiten hängen – inklusive Schulungsunterlagen, Berechtigungskonzepten und Schnittstellen zu Drittsystemen.
• Wettbewerbsdifferenzierende Logiken: Prozesse, die dem Unternehmen echten Marktvorsprung verschaffen und deshalb bewusst nicht standardisiert werden sollen.

Genau an diesen Stellen entstehen Erweiterungen – und das ist oft keine Faulheit, sondern eine bewusste Geschäftsentscheidung.

2. Die Erweiterungsmodelle stoßen an ihre Grenzen

SAP bietet ein breites Spektrum an Erweiterungsmöglichkeiten: BTP-Side-by-Side-Erweiterungen, RAP (RESTFUL Application Programming Model), Key User Extensibility oder klassische Enhancement Spots. In vielen Szenarien sind diese Werkzeuge ausreichend und die richtige Wahl.

Aber es gibt Situationen, in denen sie nicht reichen:

• Performance-kritische Prozesse: Wenn massenhaft Daten in Echtzeit verarbeitet werden müssen, kann ein Aufruf über externe APIs oder BTP-Services einen erheblichen Mehraufwand bedeuten – sowohl in der Latenz als auch in der Systemkomplexität.
• Tiefe Eingriffe in Kernlogik: Manche fachlichen Anforderungen erfordern Eingriffe in Ablaufsteuerungen, Buchungslogiken oder Datenbankzugriffe, die sich über saubere Erweiterungspunkte schlicht nicht sauber abbilden lassen.

In diesen Fällen entsteht ein echter Zielkonflikt: Hält man den Core sauber und akzeptiert fachliche Einschränkungen – oder weicht man für das bessere Ergebnis vom Ideal ab?

3. Zeitdruck besiegt Architekturqualität

Dies ist vielleicht die unbequemste Wahrheit: Clean Core braucht Zeit. Zeit für saubere Architekturentscheidungen, Zeit für die Abstimmung mit Fachbereichen, Zeit für die Entwicklung und den Test von sauberen Erweiterungen.

Unter dem Druck eines laufenden Projekts – mit festen Go-Live-Terminen, begrenzten Budgets und parallelen Workstreams – gewinnt häufig die schnelle Lösung. Ein direkter Core-Eingriff ist in 2 Stunden umgesetzt; die saubere BTP-Erweiterung benötigt 2 Wochen Analyse, Architekturentscheid und Abstimmung.

Das Ergebnis: Technische Schulden, die sich im nächsten Upgrade-Projekt rächen.

Die unbequeme Wahrheit über Clean Core

Clean Core ist kein Zustand, den man einmal erreicht und dann gehalten hat. Es ist ein kontinuierlicher Kompromiss – zwischen dem Ideal des unberührten Standards und der Realität fachlicher Anforderungen, Projektbedingungen und wirtschaftlicher Zwänge.

Projekte, die Clean Core als absolutes Dogma behandeln, scheitern an der Realität. Projekte, die Clean Core gar nicht erst ernst nehmen, schaffen sich einen Wartungsalptraum für die nächsten Jahre.

Der Schlüssel liegt zwischen diesen beiden Extremen.

Wie Clean Core trotzdem gelingt – Erfahrungen aus der Praxis

Erfolgreiche S/4HANA-Projekte haben eines gemeinsam: Sie behandeln Clean Core nicht als Selbstzweck, sondern als Gestaltungsprinzip mit klaren Leitplanken.

Eine Erweiterungsstrategie vor Projektstart definieren

Wer erst im Projektverlauf entscheidet, wie mit Abweichungen vom Standard umgegangen wird, verliert wertvolle Zeit und riskiert inkonsistente Entscheidungen. Eine frühzeitig definierte Erweiterungsstrategie legt fest:

• Welche Erweiterungsmechanismen grundsätzlich erlaubt sind
• Nach welchen Kriterien über Abweichungen entschieden wird
• Wer die Entscheidungshoheit hat (Architektur-Board, Solution Architect, etc.)

Jede Abweichung konsequent bewerten

Nicht jede Anforderung, die nicht im Standard abbildbar ist, rechtfertigt eine Erweiterung. Ein strukturierter Bewertungsprozess hilft, die wirklich notwendigen von den nur gewünschten Abweichungen zu trennen. Bewährte Fragen dabei:

• Ist diese Anforderung regulatorisch verpflichtend oder nur „nice to have“?
• Kann der Prozess so angepasst werden, dass er im Standard funktioniert?
• Was sind die langfristigen Kosten dieser Erweiterung (Wartung, Upgrade-Aufwand)?

Technische Leitplanken und Governance etablieren

Clean Core braucht Governance. Das bedeutet: automatisierte Code-Checks, die direkte Modifikationen identifizieren, regelmäßige Architecture Reviews und klare Eskalationspfade, wenn Standards abgewichen werden sollen. Tools wie der SAP Custom Code Migration App oder ABAP Test Cockpit helfen dabei, den Überblick zu behalten.

Mut zur Standardisierung entwickeln

Der vielleicht wichtigste Faktor: Projektteams brauchen den Rückhalt, fachliche Anforderungen kritisch zu hinterfragen und Stakeholdern klarzumachen, dass Standardisierung kein Qualitätsverlust ist – sondern oft ein Gewinn. Das erfordert Kommunikationsstärke, Fingerspitzengefühl und manchmal auch unbequeme Gespräche.

Fazit: Clean Core als Zielbild, nicht als Dogma

Clean Core ist erreichbar – aber nicht als absolutes Ziel, sondern als kontinuierliches Streben nach der bestmöglichen Balance. Unternehmen, die es als Ideal statt als starres Regelwerk verstehen, werden erfolgreicher sein: Sie treffen bewusstere Architekturentscheidungen, akkumulieren weniger technische Schulden und halten ihre S/4HANA-Systeme langfristig upgrade-fähig.

Die Illusion ist nicht Clean Core selbst – die Illusion ist die Vorstellung, es sei einfach.

Sie planen ein S/4HANA-Projekt?

Wir helfen Ihnen, Clean Core realistisch umzusetzen. Mit einer klaren Erweiterungsstrategie, bewährten Governance-Strukturen und dem Erfahrungsschatz aus zahlreichen S/4-Projekten begleiten wir Sie dabei, die richtige Balance zwischen Standardisierung und fachlicher Anforderung zu finden.

Jetzt Kontakt aufnehmen und gemeinsam die Grundlage für ein zukunftsfähiges S/4HANA-System schaffen.

 

Bis bald und viel Erfolg!

Euer amotIQ solutions Team