Das Clean CORE Dogma

Michael Kozlowski • 9. Januar 2026

Kritische Analyse des SAP Clean Core-Konzepts

Clean Core verstehen

Das Clean Core-Konzept bei S/4HANA-Transformationen betont die Beibehaltung des SAP-Standardsystems mit minimalen Modifikationen und verlagert Anpassungen auf Erweiterungspunkte, Side-by-Side-Architekturen und SAP-genehmigte Modifikationsframeworks (BAdIs, Enhancement Spots, Key User Extensibility).


Kritische Einschränkungen von Clean Core

1. Idealismus vs. Geschäftsrealität Clean Core geht davon aus, dass sich Geschäftsprozesse den SAP Best Practices anpassen können, aber viele Organisationen haben legitime, wettbewerbsvorteilsgetriebene Prozesse, die nicht zum SAP-Standard passen. Ein erzwungenes Anpassen erzeugt operative Reibungsverluste.

2. Verlagerung versteckter Komplexität Anstatt Komplexität zu eliminieren, verlagert Clean Core sie oft auf Integrationsschichten, Side-by-Side-Systeme und Middleware, wodurch verteilte Komplexität entsteht, die schwerer zu analysieren und zu warten ist.

3. Intensivierung der Herstellerabhängigkeit Das Paradigma erhöht die Abhängigkeit von SAPs Erweiterungs-Framework und BTP (Business Technology Platform), schränkt die Flexibilität ein und erhöht die langfristigen Kosten.

4. Performance-Overhead API-basierte Erweiterungen und Side-by-Side-Architekturen führen Latenz und Integrationspunkte ein, die die Echtzeit-Transaktionsperformance beeinträchtigen können.

5. Verstärkung der Qualifikationslücke Teams benötigen Expertise über mehrere Technologien hinweg (BTP, CAP, RAP, Fiori, ABAP Cloud) anstelle konsolidiertem ABAP-Wissen, was Schulungskosten erhöht und Talentknappheit verschärft.

6. Innovationseinschränkungen Erweiterungs-Frameworks limitieren das technisch Mögliche im Vergleich zu Kernmodifikationen und können die Innovation in der Prozessoptimierung behindern.


Alternative: Controlled Core-Strategie

Kernprinzipien

Strategische Modifikations-Klassifizierung - Anpassungen nach Geschäftswert und Lebenszyklus klassifizieren, selektive Kernmodifikationen bei Rechtfertigung erlauben und gleichzeitig Disziplin wahren.

Modifikations-Governance-Framework - Klare Kriterien, Genehmigungsprozesse und Dokumentationsstandards für Kernänderungen etablieren statt pauschales Verbot.

Hybrid-Architektur - Maßvolle Kernmodifikationen mit modernen Erweiterungen kombinieren und den richtigen Ansatz pro Anwendungsfall wählen.

Implementierungs-Framework

Stufe 1: Geschützter Standard (Keine Modifikationen)

  • Finanzbuchhaltungs-Kern
  • Standard-Beschaffung
  • Basis-HR-Lohnabrechnung

Stufe 2: Gesteuerte Modifikationen (Mit Genehmigung erlaubt)

  • Branchenspezifische Prozesse
  • Wettbewerbsdifferenzierungsmerkmale
  • Performance-kritische Workflows
  • Komplexe Integrationen, bei denen API-Overhead nicht vertretbar ist

Stufe 3: Bevorzugte Erweiterungen (Standard-Ansatz)

  • Reporting und Analytics
  • User Experience-Verbesserungen
  • Add-on-Funktionalitäten
  • Nicht-kritische Prozessvarianten


Vergleichende Analyse

Clean Core

Vorteile:

  • Einfachere SAP-Upgrades und Patch-Anwendung
  • Reduzierter Regressionstestumfang
  • Bessere SAP-Support-Qualität
  • Cloud-fähige Architektur
  • Geringere Akkumulation technischer Schulden

Nachteile:

  • Rigide Geschäftsprozess-Einschränkungen
  • Höhere initiale BTP/Erweiterungs-Kosten
  • Performance-Overhead durch Integrationen
  • Steile Multi-Technologie-Lernkurve
  • Potenzieller Verlust der Wettbewerbsdifferenzierung
  • Komplexes verteiltes Debugging

Kostenprofil: Niedrigere langfristige Wartung, höhere initiale Implementierungs- und Lizenzkosten

Controlled Core

Vorteile:

  • Flexibilität und Optimierung der Geschäftsprozesse
  • Erhalt von Wettbewerbsvorteilen
  • Bessere Echtzeit-Performance für kritische Prozesse
  • Nutzt vorhandene ABAP-Expertise
  • Niedrigere initiale Implementierungskosten
  • Vereinfachte Architektur für Kernoperationen

Nachteile:

  • Komplexere Upgrade-Prozeduren
  • Umfangreichere Regressionstestanforderungen
  • Potenzial für technische Schulden bei schlechter Governance
  • Modifikationskonflikte bei Patches
  • Erfordert starke Governance-Disziplin
  • Kann Cloud-Migration verkomplizieren

Kostenprofil: Niedrigere Initialkosten, potenziell höhere Wartung bei Governance-Versagen


Empfehlung: Risikoadjustierter Hybrid-Ansatz

Für die meisten Organisationen: Mit Controlled Core-Tendenz beginnen


  • Assessment-Phase: Modifikations-Wertanalyse durchführen
  • Aktuelle Anpassungen auf Geschäftswert mappen
  • Echte Differenzierungsmerkmale vs. technische Schulden identifizieren
  • Performance-Auswirkung der Externalisierung berechnen
  • Governance-Implementierung:Modifikations-Review-Board erstellen
  • Klare Genehmigungskriterien etablieren (ROI > X, Geschäftskritikalität, Performance-Anforderungen)
  • Umfassende Dokumentation vorschreiben
  • Automatisiertes Modifikations-Tracking implementieren
  • Strategische Allokation:Clean Core für 60-70% der Funktionalität nutzen
  • Kernmodifikationen für High-Value-Szenarien reservieren (20-30%)
  • Modifikations-Auslauf-Richtlinien etablieren
  • Kontinuierliche Verfeinerung:Jährliche Modifikationsportfolio-Review
  • Schrittweise Externalisierung von Low-Value-Anpassungen
  • Upgrade-Impact-Metriken überwachen


Wann Clean Core sinnvoll ist:

  • Greenfield-Implementierungen mit Standardprozessen
  • Branchen mit hoher SAP-Standard-Passung (Großhandel, Basisfertigung)
  • Cloud-First-Strategie-Mandate
  • Organisationen mit begrenzten technischen Teams

Wann Controlled Core überlegen ist:

  • Brownfield-Transformationen mit wertvollem bestehendem IP
  • Stark differenzierte Geschäftsmodelle
  • Performance-sensitive Operationen (Hochfrequenzhandel, Echtzeit-Fertigung)
  • Komplexe regulatorische Anforderungen mit tiefer Integration


Fazit

Clean Core ist ein wertvolles Konzept, sollte aber als Leitprinzip und nicht als Dogma behandelt werden. Die Controlled Core-Strategie bietet pragmatische Balance und erkennt an, dass Wettbewerbsvorteile oft in operativer Einzigartigkeit liegen. Der Schlüssel ist nicht Modifikationsvermeidung, sondern Modifikationsdisziplin – zu wissen, wann Anpassungen Wert schaffen versus technische Schulden.

Erfolgsformel: Strategische Flexibilität + Starke Governance + Kontinuierliche Optimierung


Teilen

Visualisierung:Verstecke Architektursteuer
von Michael Kozlowski 7. Januar 2026
Sie lesen eine verkürzte Version unserer strategischen Analyse der Option "Auf ECC bleiben, am Edge innovieren". 1. Executive Summary Das Narrativ des „Composable ERP“ gewinnt bei SAP ECC-Kunden, die die Kosten einer S/4HANA-Migration scheuen, zunehmend an Bedeutung. Das Versprechen klingt verlockend: Einen stabilen, abgeschriebenen Legacy-Kern beibehalten und gleichzeitig durch Best-of-Breed-Integrationen, KI-Tools von Drittanbietern und Cloud-native Anwendungen am „Edge“ innovieren. Diese Strategie birgt jedoch versteckte Risiken, die sich letztlich als kostspieliger erweisen können als die vermiedene Migration. Dieses Whitepaper untersucht die strategischen Folgen eines Aufschubs der S/4HANA-Einführung und beleuchtet die Wettbewerbsnachteile durch das Fehlen nativer Innovationen wie SAP Joule, eingebetteter KI/ML-Funktionen und integrierter Analyseplattformen. Führungskräfte müssen verstehen, dass Composable ERP keine risikofreie Alternative ist, sondern ein völlig anderes Risikoprofil darstellt. 2. Die Logik des Composable ERP Die Strategie basiert auf fünf Kernprämissen: 1. Stabilität des Kerns: ECC-Systeme, die heute funktionieren, werden dies auch morgen tun. Der Transaktionskern benötigt kaum Weiterentwicklung. 2. Innovation am Rand (Edge): Moderne Funktionen (KI, Analytics) können über APIs um den Legacy-Kern herum aufgebaut werden. 3. Vermeidung von Kosten: Der Verzicht auf S/4HANA eliminiert massive Transformationskosten und Geschäftsunterbrechungen. 4. Anbieterunabhängigkeit: Best-of-Breed-Tools erhöhen die Flexibilität und verhindern einen Vendor Lock-in. 5. Kontrolle über den Zeitplan: Das Unternehmen behält die Souveränität über den Zeitpunkt der Transformation. Für die Geschäftsführung adressiert dieser Ansatz legitime Schmerzpunkte: Die Sorge des CFO um den ROI, die Bedenken des CIO hinsichtlich technischer Komplexität und das Risiko des CEO bezüglich Betriebsunterbrechungen. 3. Die versteckte „Architektur-Steuer“ 3.1 Die Integrationsfalle Moderne APIs lassen die anfängliche Integration einfach erscheinen, doch jede weitere Komponente erhöht die Komplexität exponentiell: ● Datensynchronisation: Konsistenz in Echtzeit zwischen ECC und Edge-Systemen erfordert permanente Überwachung. Eine einzige Stammdatenänderung kann Updates in 5–10 Systemen auslösen. ● Versionierung: Updates von Drittanbietern erfordern ständige Kompatibilitätstests im gesamten Ökosystem. ● Semantische Abweichungen: Systeme entwickeln unterschiedliche Definitionen von „Kunde“ oder „Produkt“, was zu einem dauerhaften operativen Abstimmungsaufwand führt. Praxisbeispiel: Ein Fertigungsunternehmen mit ECC-Kern und sieben Edge-Systemen wendet ca. 18–25 % seines IT-Budgets allein für die Wartung dieser Integrationen auf – Geld, das für echte Innovation fehlt. 3.2 Die API-Illusion APIs eliminieren die zugrunde liegende Komplexität nicht: ● Latenz: Jeder Integrationsschritt addiert Verzögerungen, was Prozesse im Vergleich zu nativen Workflows träge macht. ● Fehlerfortpflanzung: Die Fehlersuche über mehrere Ebenen dauert im Schnitt 3- bis 4-mal länger als in integrierten Systemen. ● Sicherheitsrisiken: Jede Schnittstelle vergrößert die Angriffsfläche. 4. Der Innovationsverlust 4.1 Joule und Embedded AI: Ein Paradigmenwechsel Viele Führungskräfte halten SAP Joule für eine reine Benutzeroberfläche. In Wahrheit ist Joule tief in das Datenmodell und die Geschäftslogik von S/4HANA eingebettet: ● Kontextwissen: Joule versteht die semantischen Zusammenhänge – wie Verkaufsaufträge die Produktionsplanung beeinflussen oder Materialbewegungen den Einkauf triggern. ● Proaktive Intelligenz: Da Joule innerhalb von S/4HANA agiert, kann es Prozesse in Echtzeit überwachen und Anomalien melden. Externe KI-Tools arbeiten immer nur mit verzögerten Datenkopien. ● Vollwertige Workflows: Joule kann Transaktionen ausführen und Genehmigungen innerhalb des SAP-Sicherheitsframeworks einleiten. 4.2 Die Analyse-Lücke In S/4HANA gibt es dank der In-Memory-Architektur (HANA) keine Trennung mehr zwischen Transaktion und Analyse. Daten stehen ohne Zeitverlust für Echtzeit-Entscheidungen bereit. Im Gegensatz dazu benötigt ECC separate Data Warehouses und ETL-Prozesse, wodurch Daten oft Stunden oder Tage alt sind, wenn sie analysiert werden. Dies kann bei schnellen Marktveränderungen zu entscheidenden Umsatzverlusten führen. 5. Der wirtschaftliche Vergleich (TCO über 7 Jahre) Die Annahme, Composable ERP sei günstiger, ist oft ein Trugschluss:
von Michael Kozlowski 6. Januar 2026
Warum klassische S/4HANA‑Transformationen oft am Mehrwert scheiterN