Zum Inhalt springen

Blog für S/4HANA, SAP BTP, OpenText, E-Rechnung und Neptune

Clean Core SAP Assessment: Reifegrad, Z-Code & Level-Logik bewerten

Schlagwörter:

Clean Core SAP ist mehr als ein technisches Architekturprinzip, es ist die Grundlage dafür, SAP-Systeme langfristig upgradefähig, innovationsfähig und beherrschbar zu halten. In diesem Beitrag erfahren Sie, wie Unternehmen ihren Clean-Core-Reifegrad bewerten, welche Risiken durch Modifikationen, Z-Code und gewachsene Integrationen entstehen und warum ein strukturiertes Clean Core Assessment vor jeder S/4HANA-Transformation entscheidend ist.


Inhaltsverzeichnis


Was bedeutet Clean Core SAP?

Clean Core SAP beschreibt eine Architektur- und Betriebsstrategie, bei der der SAP-Standardkern möglichst unverändert bleibt. Anpassungen, Erweiterungen und Integrationen sollen nicht tief im Kernsystem verankert werden, sondern über freigegebene Erweiterungspunkte, stabile APIs, saubere Datenmodelle und entkoppelte Architekturen erfolgen.

Das Ziel ist dabei nicht, jede Individualisierung zu verhindern. Vielmehr geht es darum, individuelle Anforderungen dort umzusetzen, wo sie echten geschäftlichen Mehrwert schaffen – ohne künftige Releases, Upgrades oder Innovationen unnötig zu blockieren.

Ein sauberer SAP-Kern ist damit die Voraussetzung für:

  • stabile Release- und Upgradefähigkeit
  • schnellere Innovationszyklen
  • bessere Wartbarkeit
  • klarere Governance
  • mehr Flexibilität bei S/4HANA, RISE with SAP, SAP BTP und Cloud-ERP-Szenarien

SAP beschreibt Clean Core als Ansatz, mit dem geschäftskritische Systeme flexibel, kosteneffizient und bereit für Innovationen bleiben sollen. Dafür betrachtet SAP fünf zentrale Dimensionen: Prozesse, Erweiterungen, Daten, Integrationen und Betrieb.

Gemeint sind damit standardnahe Geschäftsprozesse, sauber umgesetzte Extensions, konsistente Datenmodelle, stabile Schnittstellen sowie kontrollierte Betriebsstrukturen. Dadurch wird deutlich: Clean Core ist kein reines Entwicklungsthema. Vielmehr betrifft der Ansatz die gesamte SAP-Landschaft.

Viele SAP-Landschaften sind über Jahre oder Jahrzehnte gewachsen. Es gibt kundeneigene Tabellen, User-Exits, BAdIs, Modifikationen an SAP-Objekten, Reports, Workarounds, direkte Datenbankzugriffe und Schnittstellen, deren fachlicher Zweck heute nicht mehr eindeutig dokumentiert ist.

Genau hier setzt ein Clean Core Assessment an.

Warum ist ein Clean Core Assessment notwendig ist

Ein Clean Core Assessment ist die strukturierte Bestandsaufnahme des aktuellen SAP-Kerns. Es beantwortet nicht nur die Frage, ob ein System „sauber“ oder „unsauber“ ist.

Entscheidend ist eine differenzierte Bewertung. Ein Clean Core Assessment zeigt,

  • ob Anpassungen die Upgradefähigkeit gefährden,
  • wie sauber Erweiterungen umgesetzt wurden,
  • wo Integrationen technische Abhängigkeiten erzeugen,
  • welche Z-Entwicklungen geschäftskritisch sind,
  • welche Altlasten Wartungsaufwand ohne echten Nutzen verursachen,
  • und welche Themen vor einer S/4HANA-Transformation priorisiert werden sollten.

Gerade vor einer S/4HANA-Conversion, einem Brownfield-Projekt, einer Selective Data Transition oder dem Wechsel in ein Cloud-ERP-Modell ist diese Transparenz entscheidend.ner Selective Data Transition oder einem Wechsel in ein Cloud-ERP-Modell ist diese Transparenz entscheidend.

Denn wer erst im eigentlichen Transformationsprojekt erkennt, dass zentrale Prozesse tief im Custom Code verankert sind, verliert Zeit, Budget und Entscheidungsfreiheit.

Ein frühes Clean Core Assessment verschiebt diese Erkenntnisse nach vorne. Es macht sichtbar, welche technischen Schulden bereinigt, modernisiert oder bewusst akzeptiert werden sollten.

Clean-Core-Reifegrad: Wie sauber ist Ihr SAP-Kern?

Der Clean-Core-Reifegrad einer SAP-Landschaft lässt sich nicht allein an der Anzahl der Z-Objekte messen.

Ein Unternehmen mit vielen sauber dokumentierten, API-basierten Erweiterungen kann reifer sein als ein Unternehmen mit wenigen, aber hochkritischen Modifikationen am SAP-Standard.

Entscheidend ist die Kombination aus:

  • technischer Umsetzung
  • fachlicher Relevanz
  • Upgrade-Risiko
  • Dokumentation
  • Testabdeckung
  • Integrationsarchitektur
  • Governance
  • Betriebsmodell

Ein praxistaugliches Reifegradmodell kann vier Stufen unterscheiden:


Stufe 1: Kritisch

Der SAP-Kern ist stark modifiziert und nur eingeschränkt upgradefähig.

Typische Merkmale:

  • viele Modifikationen am SAP-Standard
  • direkte Tabellenzugriffe
  • unklare technische Abhängigkeiten
  • geringe Dokumentation
  • hohe Abhängigkeit von Einzelwissen
  • manuelle Tests ohne klare Abdeckung

Bewertung: Hoher Handlungsdruck. Risiken sollten vor größeren Transformationsvorhaben transparent gemacht und priorisiert werden.


Stufe 2: Kontrolliert

Die wesentlichen Risiken sind bekannt, aber noch nicht systematisch reduziert.

Typische Merkmale:

  • Custom Code wurde teilweise analysiert
  • kritische Modifikationen sind bekannt
  • erste Prioritäten bestehen
  • Governance ist vorhanden, aber nicht konsequent etabliert
  • technische Schulden werden punktuell bearbeitet

Bewertung: Gute Ausgangsbasis, aber noch kein nachhaltiger Clean-Core-Zustand.


Stufe 3: Modernisiert

Erweiterungen folgen weitgehend freigegebenen Mechanismen.

Typische Merkmale:

  • Nutzung von BAdIs, APIs, RAP, ABAP Cloud oder SAP BTP
  • reduzierte Modifikationen
  • dokumentierte Schnittstellen
  • klare technische Leitlinien
  • definierte Architekturprinzipien
  • saubere Trennung von Standard und Erweiterung

Bewertung: Die Landschaft ist deutlich zukunftsfähiger und besser auf S/4HANA-Innovationen vorbereitet.


Stufe 4: Kontinuierlich sauber

Clean Core ist fest in Architektur, Entwicklung und Betrieb verankert.

Typische Merkmale:

  • automatisierte Checks
  • regelmäßige Architektur-Reviews
  • klare Transport- und Entwicklungs-Governance
  • dokumentierte Integrationsstrategie
  • Testautomatisierung
  • kontinuierliches Lifecycle-Management

Bewertung: Clean Core ist kein Projekt mehr, sondern Teil des Betriebsmodells.


Wichtig ist: Clean Core ist kein einmaliger Zielzustand. Ein SAP-System kann heute sauber sein und in zwei Jahren wieder technische Schulden aufbauen, wenn neue Erweiterungen ohne Architekturprüfung, API-Strategie oder Governance umgesetzt werden.

Deshalb sollte ein Clean Core Assessment nicht nur vor Transformationsprojekten stattfinden, sondern regelmäßig als Teil der SAP-Roadmap.

Modifikationen bewerten: Wo wurde der SAP-Standard verändert?

Modifikationen sind im Clean-Core-Kontext besonders kritisch, weil sie direkt in den SAP-Standard eingreifen.

Während Customizing und freigegebene Erweiterungspunkte grundsätzlich vorgesehene Anpassungsmechanismen sind, verändern Modifikationen Standardobjekte selbst. Das kann bei Upgrades, Support Packages oder Releasewechseln zu Konflikten führen.

Ein Clean Core Assessment sollte deshalb alle Modifikationen identifizieren und nach Risiko klassifizieren.

Dabei geht es nicht nur um die technische Anzahl. Entscheidend ist die fachliche Bedeutung.

Eine Modifikation in einem selten genutzten Report ist anders zu bewerten als eine Änderung in einem zentralen Buchungs-, Beschaffungs- oder Produktionsprozess.

Für jede Modifikation sollten mindestens folgende Fragen beantwortet werden:

  • Welcher fachliche Zweck steckt hinter der Modifikation?
  • Gibt es inzwischen einen SAP-Standard, der die Anforderung abdeckt?
  • Kann die Logik über einen freigegebenen Erweiterungspunkt abgebildet werden?
  • Wie häufig wird die betroffene Funktion genutzt?
  • Welche Auswirkungen hätte ein Fehler nach einem Upgrade?
  • Ist die Modifikation dokumentiert und testbar?
  • Wer ist fachlicher Owner der Anpassung?

Die entscheidende Haltung dabei: Modifikationen sind keine technische Schuldzuweisung. Viele entstanden, weil der damalige SAP-Standard bestimmte Anforderungen nicht abbilden konnte.

Für die Zukunft sind sie jedoch ein Risiko, das bewusst bewertet und, wo sinnvoll, reduziert werden sollte.

Clean Core bedeutet daher nicht Rückbau um jeden Preis, sondern Risikotransparenz und bewusste Architekturentscheidungen.

Z-Code analysieren: Was ist geschäftskritisch, was ist Ballast?

Z-Code ist in vielen SAP-Landschaften der sichtbarste Ausdruck individueller Anforderungen.

Kundeneigene Reports, Programme, Tabellen, Funktionsbausteine, Klassen, Transaktionen und Schnittstellenlogiken haben über Jahre geholfen, Prozesse passgenau abzubilden.

Gleichzeitig ist Z-Code häufig der Bereich, in dem technische Schulden besonders stark wachsen.

Im Assessment sollte Z-Code deshalb nicht pauschal als schlecht bewertet werden. Die bessere Frage lautet:

Ist dieser Code noch notwendig, sauber umgesetzt und zukunftsfähig?

Ein geschäftskritischer Z-Report mit klarer Ownership, Testfällen und freigegebenen Schnittstellen kann sinnvoller sein als eine schlecht dokumentierte Standardumgehung, die niemand mehr versteht.

Eine fundierte Z-Code-Bewertung kombiniert technische Analyse und fachliche Validierung.

Technisch geprüft werden unter anderem:

  • Nutzungshäufigkeit
  • Abhängigkeiten
  • Syntaxrisiken
  • nicht freigegebene Objekte
  • direkte Tabellenzugriffe
  • Performance-Risiken
  • S/4HANA-Kompatibilität
  • Testbarkeit
  • Dokumentationsstand

Fachlich muss geklärt werden:

  • Besteht die ursprüngliche Anforderung noch?
  • Wird der Code aktiv genutzt?
  • Gibt es heute einen SAP-Standard dafür?
  • Ist eine Side-by-Side-Erweiterung über SAP BTP sinnvoller?
  • Kann die Logik modernisiert oder stillgelegt werden?

Für Unternehmen bedeutet das: Z-Code sollte nicht einfach migriert werden, nur weil er existiert.

Jedes Objekt braucht eine klare Entscheidung:

  • Behalten
  • Modernisieren
  • Ersetzen
  • Entkoppeln
  • Stilllegen

Genau hier entsteht einer der größten Hebel eines Clean Core Assessments.

Das neue SAP Clean-Core-Level-Konzept: Custom Extensions von A bis D bewerten

Ein zentraler Bestandteil eines modernen Clean Core Assessments ist die Bewertung von Kundenerweiterungen. SAP ordnet Custom Extensions zunehmend nicht mehr nur nach dem früheren 3-Tier-Modell ein, sondern anhand von vier Stufen: Level A, B, C und D.

Diese Klassifizierung macht sichtbar, wie upgrade-stabil, cloud-fähig und architektonisch sauber eine Erweiterung umgesetzt ist. Dadurch entsteht eine klare Entscheidungsgrundlage: Welche Erweiterungen können bleiben, welche sollten modernisiert werden und welche stellen ein Risiko für den Clean Core SAP dar?

Level A beschreibt den Zielzustand. Erweiterungen sind vollständig upgrade-stabil, cloud-kompatibel und nutzen ausschließlich freigegebene Schnittstellen. Technologisch erfolgt die Umsetzung entweder On-Stack mit ABAP Cloud oder Side-by-Side über die SAP Business Technology Platform, zum Beispiel mit SAP Build oder CAP. Für Neuentwicklungen sollte Level A grundsätzlich die erste Wahl sein.

Level B umfasst Erweiterungen, die kompatibel sind, aber noch klassische SAP-Technologien nutzen. Dazu zählen etwa freigegebene BAPIs, Standard-IDocs, klassische BAdIs oder RFC-Funktionsbausteine. In bestehenden Landschaften sind solche Lösungen oft weiterhin tragfähig. Dennoch sollten neue Anforderungen möglichst direkt nach Level A umgesetzt werden.

Bei Level C besteht ein erhöhtes Upgrade-Risiko. Diese Erweiterungen greifen auf interne oder nicht offiziell freigegebene SAP-Objekte zu, etwa interne Tabellen, unreleased CDS Views oder nicht freigegebene Funktionsbausteine. Sie funktionieren häufig im aktuellen System, können aber bei S/4HANA-Upgrades oder Releasewechseln Probleme verursachen.

Level D markiert den roten Bereich. Hier verändern Erweiterungen den SAP-Standard direkt, zum Beispiel durch Modifikationen, problematische Implicit Enhancements, Overwrite-Exits oder direkte Schreibzugriffe auf SAP-Datenbanktabellen. Solche Eingriffe widersprechen dem Clean-Core-Prinzip und sollten im Assessment mit höchster Priorität bewertet werden.

Damit wird das Level-Konzept zu einem praktischen Steuerungsinstrument: Level A ist das Zielbild, Level B meist akzeptabel, Level C risikobehaftet und Level D aktiv zu bereinigen.

Warum das Level-Konzept für das Clean Core Assessment so wichtig ist

Das A-bis-D-Modell macht technische Risiken verständlicher. Fachbereiche, IT-Leitung und Management erhalten eine gemeinsame Sprache.

Das Modell schafft eine klare Risikologik:

  • Level D markiert nicht empfohlene Eingriffe in den SAP-Standard.
  • Level A umfasst saubere und zukunftssichere Erweiterungen.
  • In Level B fallen akzeptable klassische Erweiterungen.
  • Bei Level C besteht ein klares Upgrade-Risiko.

Damit wird das Clean Core Assessment handlungsorientierter. Unternehmen können ihre Erweiterungen clustern, priorisieren und konkrete Maßnahmen ableiten. Die entscheidende Frage lautet also nicht mehr nur: „Wie viel Z-Code haben wir?“ Viel wichtiger ist: „Auf welchem Clean-Core-Level befinden sich unsere Erweiterungen?“

Integrationen prüfen: API-first statt Punkt-zu-Punkt-Abhängigkeit

Integrationen sind häufig die unterschätzte Dimension von SAP Clean Core.

Ein SAP-System kann im Kern vergleichsweise sauber sein und trotzdem durch starre Punkt-zu-Punkt-Schnittstellen, direkte Datenbankzugriffe oder historisch gewachsene Middleware-Logiken schwer modernisierbar bleiben.

Gerade bei S/4HANA-Transformationen werden Integrationen schnell zum kritischen Pfad, weil sie Prozesse über Systemgrenzen hinweg verbinden.

Eine Clean-Core-konforme Integrationsarchitektur folgt dem API-first-Prinzip.

Das bedeutet:

  • Systeme werden über stabile und dokumentierte Schnittstellen verbunden
  • Datenflüsse sind nachvollziehbar
  • technische Abhängigkeiten werden reduziert
  • direkte Zugriffe auf interne Tabellenstrukturen werden vermieden
  • Schnittstellen haben klare fachliche und technische Owner
  • Integrationen sind für S/4HANA, SAP BTP und Cloud-Szenarien geeignet

Im Assessment sollten Integrationen nach folgenden Kriterien bewertet werden:

KriteriumLeitfrage
KopplungsgradWie stark hängt die Schnittstelle von internen SAP-Strukturen ab?
TechnologieWird eine freigegebene API, ein Event, IDoc, OData-Service oder proprietäre Logik genutzt?
StabilitätWie fehleranfällig ist die Integration im Betrieb?
DokumentationSind Datenflüsse, Verantwortlichkeiten und Fehlerszenarien dokumentiert?
GeschäftskritikalitätWelche Prozesse stehen still, wenn die Integration ausfällt?
ZukunftsfähigkeitIst die Schnittstelle für S/4HANA, Cloud ERP oder SAP BTP geeignet?

Besonders kritisch sind Integrationen, die auf interne Tabellenstrukturen zugreifen oder implizites Wissen über alte Datenmodelle nutzen.

Was in ECC über Jahre funktioniert hat, kann in S/4HANA durch veränderte Datenmodelle, neue APIs oder andere Betriebsmodelle zum Risiko werden.

Deshalb sollten Integrationen nicht erst im technischen Migrationstest betrachtet werden, sondern frühzeitig im Clean Core Assessment.

Bewertungsmatrix für ein Clean Core Assessment

Ein gutes Clean Core Assessment führt technische Fakten und geschäftliche Prioritäten zusammen.

Die folgende Matrix eignet sich als pragmatischer Startpunkt:

BewertungsbereichLeitfrageTypische Maßnahmen
ModifikationenWurde SAP-Standard verändert?Rückbau, Ersatz durch BAdI/API, Standardprozess prüfen
Z-CodeIst kundeneigener Code noch genutzt, dokumentiert und upgradefähig?Nutzungsanalyse, Refactoring, Stilllegung, Modernisierung mit ABAP Cloud/RAP
IntegrationenSind Schnittstellen stabil, dokumentiert und entkoppelt?API-first-Strategie, Middleware-Bereinigung, eventbasierte Integration prüfen
DatenSind Stammdaten, Bewegungsdaten und historische Daten transformierbar?Datenbereinigung, Archivierung, Governance-Modell, Datenqualitätsregeln
ProzesseWie nah liegen Prozesse am SAP-Standard?Fit-to-Standard-Workshops, Prozessharmonisierung, Varianten reduzieren
OperationsGibt es Governance, Tests und automatisierte Kontrollen?ATC-Checks, Architekturboards, Transport-Governance, Testautomatisierung

Wichtig ist: Die Bewertung sollte nicht nur eine Ampellogik erzeugen.

Rot bedeutet nicht automatisch „sofort löschen“.
Rot bedeutet: hohes Risiko, hohe Aufmerksamkeit, klare Entscheidung erforderlich.

Grün bedeutet nicht „nie wieder prüfen“.
Grün bedeutet: derzeit sauber, aber weiterhin unter Governance halten.

Der Mehrwert entsteht durch eine priorisierte Entscheidungsgrundlage.

Von der Analyse zur Clean-Core-Roadmap

Der größte Fehler nach einem Clean Core Assessment wäre, die Ergebnisse als reine Dokumentation abzulegen.

Der eigentliche Wert entsteht erst durch eine konkrete Clean-Core-Roadmap.

Diese Roadmap sollte Maßnahmen nach folgenden Kriterien priorisieren:

  • technisches Risiko
  • Business Impact
  • Transformationsrelevanz
  • Aufwand
  • Abhängigkeiten
  • Quick-Win-Potenzial
  • Auswirkungen auf S/4HANA, RISE, SAP BTP oder Cloud ERP

In der Praxis bietet sich eine Dreiteilung an:


1. Quick Wins

Dazu gehören Themen, die mit überschaubarem Aufwand bereinigt werden können:

  • ungenutzter Z-Code
  • obsolete Schnittstellen
  • doppelte Reports
  • veraltete Eigenentwicklungen ohne Nutzung
  • dokumentationsarme Altobjekte ohne fachliche Relevanz

Diese Maßnahmen schaffen schnell Transparenz und reduzieren unnötige Komplexität.


2. Transformationskritische Themen

Hier liegen die größten Risiken für S/4HANA-Programme.

Typische Beispiele:

  • Modifikationen in Kernprozessen
  • nicht S/4HANA-kompatible Entwicklungen
  • direkte Tabellenzugriffe
  • Integrationen mit hohem Kopplungsgrad
  • Eigenentwicklungen ohne Testabdeckung
  • zentrale Prozesse mit hoher Custom-Code-Abhängigkeit

Diese Themen sollten früh priorisiert werden, da sie Projektlaufzeit, Budget und Migrationsstrategie beeinflussen können.


3. Strategische Modernisierung

Hier geht es um den langfristigen Zielzustand.

Typische Maßnahmen:

  • Aufbau einer SAP-BTP-Erweiterungsstrategie
  • Nutzung von ABAP Cloud und RAP
  • Umstellung auf freigegebene APIs
  • Einführung von Architektur-Governance
  • Aufbau automatisierter Checks
  • klare Regeln für neue Erweiterungen
  • Integration von Clean Core in das Betriebsmodell

Unternehmen sollten dabei nicht versuchen, den gesamten SAP-Kern auf einmal zu bereinigen.

Erfolgreicher ist ein fokussierter Ansatz:

  1. Transparenz schaffen
  2. Risiken priorisieren
  3. Entscheidungen treffen
  4. Maßnahmen in Wellen umsetzen
  5. Governance dauerhaft etablieren

Clean Core ist kein kosmetisches IT-Projekt. Es ist ein strategisches Architekturprogramm.

Es entscheidet darüber, wie schnell ein Unternehmen künftig Innovationen aus SAP S/4HANA, SAP BTP, Automatisierung und KI übernehmen kann.

Fazit: Clean Core SAP schafft Entscheidungsfähigkeit

Clean Core SAP ist kein Dogma und kein Verzicht auf Individualität.

Im Gegenteil: Ein sauberer SAP-Kern schafft die Voraussetzung dafür, dass Unternehmen dort individuell bleiben können, wo es wirklich wettbewerbsrelevant ist.

Der Unterschied liegt in der Art der Umsetzung.

Statt Modifikationen, unkontrolliertem Z-Code und starren Integrationen braucht es:

  • freigegebene Erweiterungspunkte
  • stabile APIs
  • entkoppelte Architekturen
  • saubere Datenmodelle
  • klare Governance
  • automatisierte Checks
  • regelmäßige Architekturentscheidungen

Ein Clean Core Assessment macht sichtbar, wo ein SAP-System heute steht. Es bewertet Reifegrad, Modifikationen, Z-Code, Integrationen, Daten, Prozesse und Betrieb nicht isoliert, sondern im Zusammenhang.

Daraus entsteht eine belastbare Roadmap für S/4HANA, RISE with SAP, SAP BTP, Cloud ERP und künftige Innovationszyklen.

Die wichtigste Erkenntnis lautet:

Clean Core beginnt nicht erst im Migrationsprojekt. Clean Core beginnt mit der Entscheidung, technische Schulden transparent zu machen und Architektur wieder aktiv zu steuern.

Wer diese Arbeit früh leistet, reduziert Risiken, senkt langfristig Komplexität und gewinnt Spielraum für Innovation.

Clean Core Assessment mit Fink IT-Solutions starten

Sie möchten wissen, wie sauber Ihr SAP-Kern wirklich ist?

Fink IT-Solutions unterstützt Sie dabei, Modifikationen, Z-Code, Integrationen und technische Schulden strukturiert zu analysieren – mit klarem Blick auf Ihre konkrete Systemlandschaft, Ihre Transformationsziele und Ihre SAP-Roadmap.

Unser Clean Core Assessment hilft Ihnen dabei:

  • Risiken vor einer S/4HANA-Transformation frühzeitig sichtbar zu machen
  • Custom Code und Modifikationen fachlich und technisch zu bewerten
  • Integrationen auf Zukunftsfähigkeit zu prüfen
  • Quick Wins und kritische Maßnahmen zu priorisieren
  • eine belastbare Clean-Core-Roadmap aufzubauen
  • Governance für künftige Erweiterungen zu etablieren

Sprechen Sie mit den SAP-Experten von Fink IT-Solutions und schaffen Sie die Grundlage für eine upgradefähige, innovationsfähige und beherrschbare SAP-Landschaft.

Nutzen Sie gerne unser Kontaktformular, um mit Fink IT-Solutions ins Gespräch zu kommen:
Kontaktformular | Fink IT-Solutions – IT-Beratung & Lösungen in Würzburg – Fink IT-Solutions

FAQs zu Clean Core SAP

Was bedeutet Clean Core SAP?

Clean Core SAP bedeutet, den SAP-Standardkern möglichst unverändert zu halten und Erweiterungen über freigegebene Schnittstellen, APIs, Erweiterungspunkte oder entkoppelte Plattformen wie SAP BTP umzusetzen. Ziel ist eine upgradefähige, wartbare und innovationsbereite SAP-Landschaft.

Heißt SAP Clean Core, dass kein Z-Code mehr erlaubt ist?

Nein. Z-Code bleibt möglich, sollte aber bewusst bewertet, dokumentiert, getestet und möglichst über stabile, freigegebene Mechanismen umgesetzt werden. Entscheidend ist nicht die Existenz von Custom Code, sondern dessen Qualität, Notwendigkeit und Upgradefähigkeit.

Was wird in einem Clean Core Assessment geprüft?

Ein Clean Core Assessment prüft typischerweise Modifikationen, Z-Code, Schnittstellen, Datenqualität, Prozessnähe zum Standard, Erweiterungsarchitektur, technische Schulden, Dokumentation, Testbarkeit und Governance. Ziel ist eine priorisierte Roadmap zur Bereinigung und Modernisierung.

Warum sind Modifikationen im SAP-Standard kritisch?

Modifikationen verändern SAP-Standardobjekte und können bei Upgrades, Support Packages oder Releasewechseln Konflikte erzeugen. Deshalb sollten sie identifiziert, fachlich bewertet und wenn möglich durch Standardfunktionen, Customizing, BAdIs oder APIs ersetzt werden.

Welche Rolle spielen Integrationen im SAP Clean Core?

Integrationen sind zentral, weil sie häufig starke Abhängigkeiten zwischen Systemen erzeugen. Clean-Core-konforme Integrationen setzen auf dokumentierte, stabile und freigegebene APIs statt auf direkte Datenbankzugriffe oder schwer wartbare Punkt-zu-Punkt-Verbindungen.

Wann sollte ein Clean Core Assessment durchgeführt werden?

Idealerweise vor einer S/4HANA-Transformation, vor größeren Releasewechseln, im Rahmen einer SAP-Roadmap oder regelmäßig als Architektur-Review. Je früher Risiken sichtbar werden, desto besser lassen sich Aufwand, Budget und Transformationspfad steuern.