Clean Core scheitert auf Entscheidungsebene

Stand: Oktober 2026 · David Riederich · Aus dem englischen Original maschinell übersetzt

Viele SAP-Clean-Core-Initiativen beginnen an der technischen Oberfläche: Custom Code, Modifikationen, Erweiterungen, Schnittstellen und Upgradefähigkeit. Das ist nachvollziehbar. Diese Dinge sind sichtbar. In den meisten Organisationen sind sie jedoch nicht die eigentliche Ursache. Sie sind das Ergebnis von Entscheidungen, die nie sauber strukturiert wurden.

Clean Core ist daher nicht primär eine technische Aufräumübung. Clean Core ist eine Disziplin für die Frage, wann man im Standard bleibt, wann man erweitert und wann eine Ausnahme die langfristigen Folgen wert ist.

Das verbreitete Missverständnis

Clean Core wird häufig als technisches Prinzip verstanden: Custom Code reduzieren, Modifikationen vermeiden, SAP BTP nutzen, den Core sauber halten.

Nichts davon ist falsch. Aber es ist unvollständig.

Ein System wird nicht komplex, weil ein Entwickler eine einzelne Erweiterung schreibt. Es wird komplex, wenn sich viele lokale Ausnahmen, dringende Workarounds und undokumentierte Abweichungen über längere Zeit ansammeln.

Die entscheidende Frage lautet daher nicht nur:

„Wie reduzieren wir Custom Code?“

Die bessere Frage lautet:

„Warum erzeugen wir immer wieder die Entscheidungen, die Custom Code notwendig machen?“

Custom Code ist oft nur das Symptom

Custom Code entsteht selten isoliert. In vielen SAP-Landschaften ist er der technische Ausdruck organisatorischer Muster.

Typische Beispiele sind:

• lokale fachliche Ausnahmen, die schleichend dauerhaft werden
• historisch gewachsene Prozessvarianten, die niemand mehr hinterfragt
• Anforderungen, die unter Zeitdruck ohne Architekturprüfung freigegeben werden
• unklare Verantwortung zwischen Fachbereich, IT und Implementierungspartnern
• temporäre Workarounds, die jahrelang im System bleiben
• Schnittstellen, die gebaut werden, weil niemand einen gemeinsamen Prozess entscheiden wollte

In solchen Fällen ist das technische Artefakt real. Aber die Ursache ist nicht technisch. Die Ursache ist eine fehlende Entscheidungsstruktur.

Vier Entscheidungen, die den Core verschmutzen

Aus Clean-Core-Perspektive sind die relevantesten Entscheidungen meist nicht die großen Architekturentscheidungen, die einmalig im Programm getroffen werden. Es sind wiederkehrende Entscheidungen, die im Moment harmlos erscheinen.

1. Die lokale Ausnahme

Ein Werk, eine Verkaufsorganisation, ein Buchungskreis oder eine Region benötigt eine spezifische Abweichung. Der fachliche Grund kann nachvollziehbar sein. Ohne klare Bewertung der langfristigen Folgen wird die Ausnahme jedoch Teil der dauerhaften Systemlogik.

Eine Ausnahme ist selten das Problem. Zehn Ausnahmen über verschiedene Standorte hinweg werden zum Betriebsmodell.

2. Der dringende Workaround

Ein Projekt steht unter Druck. Der Go-live rückt näher. Ein Fehler muss schnell gelöst werden. Der Workaround wird akzeptiert, weil er das Projekt voranbringt.

Das Risiko liegt nicht im Workaround selbst. Das Risiko liegt darin, dass niemand die Entscheidung verantwortet, ihn später wieder zu entfernen, neu zu gestalten oder zu regeln.

3. Die politisch akzeptierte Abweichung

Manche Abweichungen sind gar keine technischen Entscheidungen. Sie sind politische Kompromisse. Ein Stakeholder möchte einen bestimmten Prozess, ein Partner schlägt eine pragmatische Lösung vor, und die architektonische Auswirkung wird akzeptiert, ohne sie explizit zu machen.

Genau hier scheitert Clean Core oft leise: nicht weil niemand es besser wusste, sondern weil niemand das Mandat hatte, Nein zu sagen.

4. Die kleine Änderung im Betrieb

Viele Clean-Core-Risiken entstehen nach dem Go-live, wenn kleine operative Änderungen nicht mit derselben Sorgfalt geprüft werden wie Projektentscheidungen. Ein lokales Feld, eine Workflow-Anpassung oder eine kleine Erweiterung können harmlos wirken, aber über die Zeit genau jene Komplexität wieder einführen, die eine Transformation eigentlich reduzieren sollte.

Das Problem ist nicht die Größe der Änderung. Das Problem ist, dass operative Änderungen oft nicht die architektonische Aufmerksamkeit bekommen, die sie verdienen.

Warum BTP das Governance-Problem nicht löst

SAP BTP kann ein wichtiger Bestandteil einer Clean-Core-Strategie sein. Die Plattform ermöglicht Erweiterungen außerhalb des digitalen Core und kann den Bedarf an direkten Modifikationen reduzieren.

Aber Komplexität aus dem Core herauszuschieben bedeutet nicht automatisch, dass sie verschwindet. Schlecht gesteuerte Erweiterungen bleiben Komplexität. Sie befinden sich lediglich an einer anderen Stelle.

Eine schlechte Entscheidung, die auf BTP umgesetzt wird, bleibt eine schlechte Entscheidung. Sie mag aus Upgrade-Sicht sauberer sein, kann aber trotzdem Integrationsschulden, unklare Verantwortung und operative Risiken erzeugen.

Clean Core braucht daher mehr als eine technische Erweiterungsstrategie. Es braucht ein Entscheidungsmodell dafür, wann eine Erweiterung gerechtfertigt ist, wem sie gehört, wie sie betrieben wird und welche Konsequenzen sie erzeugt.

Der Clean-Core-Entscheidungsfilter

Bevor eine Abweichung vom Standard freigegeben wird, sollte eine Organisation einige einfache Fragen beantworten können.

1. Welches Problem lösen wir wirklich?

Viele Anforderungen beschreiben bereits eine bevorzugte Lösung, nicht das eigentliche Problem. Clean Core verlangt, fachlichen Bedarf von Umsetzungsvorlieben zu trennen.

2. Ist der Standard tatsächlich unzureichend?

Fit-to-Standard bedeutet nicht, jeden SAP-Standard blind zu akzeptieren. Es bedeutet aber, dass Abweichungen begründet werden müssen – und nicht einfach vorausgesetzt werden dürfen.

3. Was kostet die Abweichung langfristig?

Jede Abweichung hat einen Lebenszyklus: bauen, testen, dokumentieren, betreiben, upgraden, überwachen und irgendwann ersetzen. Wenn diese Kosten nicht sichtbar sind, ist die Entscheidung unvollständig.

4. Wer verantwortet die Entscheidung nach dem Go-live?

Wenn niemand die Abweichung nach dem Go-live verantwortet, wurde keine Architekturentscheidung getroffen. Es wurde zukünftige Unklarheit erzeugt.

5. Unter welchen Bedingungen würden wir sie wieder entfernen?

Eine Abweichung ohne Ausstiegskriterium wird leicht dauerhaft. Clean-Core-Disziplin bedeutet daher nicht nur zu definieren, warum etwas entsteht, sondern auch, wann es wieder hinterfragt werden muss.

Wie Clean-Core-Governance in der Praxis aussieht

Wirksame Clean-Core-Governance muss nicht bürokratisch sein. In vielen Organisationen reichen bereits wenige praktische Mechanismen, um einen deutlichen Unterschied zu machen.

• Eine klare Abweichungsrichtlinie: was in den Core darf, was außerhalb gelöst werden sollte und was gar nicht gebaut werden sollte.
• Ein Impact Assessment: eine kurze Bewertung operativer, architektonischer, integrativer und upgradebezogener Konsequenzen.
• Klare Entscheidungsverantwortung: nachvollziehbare Verantwortung für Freigabe und Pflege von Abweichungen.
• Architektur-Reviews als Routine: regelmäßige Prüfung von Erweiterungen, Schnittstellen und Varianten.
• Ein Variantenregister: Transparenz über lokale Abweichungen und deren fachliche Begründung.

Ziel ist nicht, Projekte zu verlangsamen. Ziel ist, zu verhindern, dass kleine Entscheidungen große langfristige Folgen erzeugen.

Clean Core braucht die richtige Art von Disziplin

Disziplin bedeutet nicht, jede Anforderung abzulehnen. Sie bedeutet, den Trade-off sichtbar zu machen.

Manche Abweichungen sind gerechtfertigt. Manche Erweiterungen sind notwendig. Manche fachlichen Anforderungen lassen sich nicht sinnvoll im Standard lösen.

Das Problem beginnt dort, wo solche Entscheidungen ohne gemeinsame Bewertungslogik getroffen werden. Dann entscheidet jedes Projekt, jeder Standort oder jeder Partner anders. Über die Zeit wird die SAP-Landschaft zu einer Sammlung lokaler Entscheidungen statt zu einem kohärenten System.

Clean Core ist nicht die Abwesenheit von Erweiterungen. Clean Core ist die Anwesenheit disziplinierter Entscheidungen.

Was Organisationen vermeiden sollten

Drei Missverständnisse schwächen Clean-Core-Initiativen immer wieder.

• „Weniger Code bedeutet weniger Komplexität.“
  Weniger Code hilft, aber Komplexität kann auch in Integrationen, Prozessen, Datenflüssen und unklarer Verantwortung liegen.
• „BTP macht uns automatisch Clean Core.“
  BTP kann den Core schützen, ersetzt aber weder Architektur noch Governance noch operative Verantwortung.
• „Der Standard gewinnt immer.“
  Standard sollte der Ausgangspunkt sein, nicht ein Dogma. Entscheidend ist, dass Abweichungen bewusst begründet werden.

Fazit: Clean Core ist Entscheidungsqualität

Clean Core scheitert nicht daran, dass Organisationen keine technischen Optionen haben. Clean Core scheitert, wenn Entscheidungen über Anforderungen, Ausnahmen, Erweiterungen und Varianten ohne ausreichende Struktur getroffen werden.

ABAP, BTP, Schnittstellen und Erweiterungen sind sichtbar. Entscheidungsqualität ist weniger sichtbar. Aber sie ist meist der entscheidende Faktor.

Organisationen, die Clean Core als Governance- und Architekturdisziplin verstehen, schaffen SAP-Landschaften, die leichter zu upgraden, leichter zu betreiben und leichter zu verändern sind.

Clean Core ist keine Code-Hygiene. Clean Core ist eine Art, SAP-Entscheidungen verantwortungsvoll zu treffen.

Häufige Fragen zu SAP Clean Core

Was bedeutet Clean Core im SAP-Kontext?

Clean Core bedeutet, den digitalen SAP-Core stabil, upgradefähig und nah am Standard zu halten. In der Praxis braucht es dafür klare Governance, architektonische Leitplanken und einen disziplinierten Umgang mit Erweiterungen und Abweichungen.

Geht es bei Clean Core hauptsächlich um die Reduktion von Custom Code?

Nein. Die Reduktion von Custom Code ist ein sichtbarer Teil von Clean Core, aber nicht das ganze Konzept. Wichtiger ist die Frage, wie Anforderungen, Ausnahmen und Erweiterungen bewertet werden, bevor sie zu technischen Artefakten werden.

Welche Rolle spielt SAP BTP bei Clean Core?

SAP BTP kann helfen, Erweiterungen außerhalb des Core zu halten. BTP ersetzt jedoch keine Governance. Auch Erweiterungen brauchen Verantwortung, Architekturprüfung, operative Zuständigkeit und einen klaren Grund, warum es sie geben sollte.

Wie sollte ein Unternehmen eine Clean-Core-Initiative starten?

Ein pragmatischer Startpunkt ist die Bewertung von bestehendem Custom Code, Erweiterungen, Schnittstellen und Varianten. Danach sollten Entscheidungskriterien für künftige Abweichungen definiert werden. Der erste Schritt ist also nicht nur Aufräumen, sondern ein besseres Entscheidungsmodell.

Zurück zu den Insights