Clean Core ist ein Standard, den man hält, kein Projekt, das man abschließt — die am wenigsten invasive der drei SAP-Stufen. VISCAP hält ihn: Assessment, Bereinigung, Erweiterungsarchitektur, Release-Governance.
Acht Fähigkeitsbereiche, benannt noch vor jedem Tool — jeweils ein Ergebnis, keine Richtlinie, Lizenz oder Reifegradbewertung.
SAP S/4HANA In-App-ErweiterbarkeitKey-User-Tools
Die erste Stufe, die man ausprobiert — nichts verlässt die freigegebenen Erweiterungspunkte, daher übersteht sie jedes Upgrade.
ABAP CloudSAP S/4HANA Entwicklererweiterbarkeit
Über die Key-User-Werkzeuge hinaus — dieselbe Sprache, ein engerer Vertrag.
SAP BTP ABAP environmentSAP Build CodeSAP Business Application StudioSAP Cloud Application Programming Model
Für alles Substanzielle: Logik außerhalb des Kerns, mit eigenem Release-Zyklus.
SAP Build AppsSAP Build Process AutomationSAP Build Work Zone
Governance zählt mehr als das Werkzeug — ungesteuertes Low-Code baut die Schulden nur woanders wieder auf.
SAP Integration SuiteAPI ManagementSAP Event Mesh
Punkt-zu-Punkt-Integrationen, die bis in die Kerntabellen reichen, sind nicht clean.
SAP Custom Code-AnalyseTransport- und Lifecycle-Management
Nutzungsanalysen finden häufig Objekte, die seit Jahren ungenutzt sind — sie stillzulegen ist die günstigste Clean-Core-Arbeit, die es gibt.
Clean Core gelingt als Disziplin, nicht als Anweisung von oben — VISCAP deckt den gesamten Bogen ab, vom Bestand der Custom-Objekte bis zur Release-Governance, die den erneuten Aufbau von Schulden verhindert. Hier sehen Sie, wohin jede Phase gehört und was wir übernehmen.
Clean Core betrifft nahezu jeden Teil einer SAP-Landschaft — Code, Schnittstellen, Release-Kalender, die Art, wie gebaut wird. Diese acht decken das ab.
Alle VISCAP-ServicesClean-Core-Position bewerten: Customizing, technische Schulden, Erweiterbarkeit, Upgrade-Bereitschaft.
Clean-Core-Standard bei neuen Implementierungen und Rollouts einhalten.
Custom-Code-Bestand, Nutzungsanalyse, Stilllegung, Bereinigung und Neuaufbau als Side-by-Side-Erweiterungen.
Clean-Core-Integration: Schnittstellenkonsolidierung, Punkt-zu-Punkt-Verbindungen auf gesteuerte APIs und Events überführt.
Individuelles Reporting von modifizierten Kernobjekten auf freigegebene Views und gesteuerte Analytics verlagert.
Erweiterungsbestand, Transport- und Lifecycle-Kontrollen sowie die Leitplanken für Neuentwicklungen betreiben.
Bewertung der Release-Auswirkungen, Nachverfolgung veralteter Funktionen, Regressionsumfang und Upgrade-Rückstand.
Key User und Entwickler zu den Erweiterbarkeitsstufen befähigen, damit die richtige Stufe selbstständig gewählt wird.
HR und Talentprozesse über Werks- und Konzernteams hinweg standardisiert — ein Modell für die Belegschaft der Glasproduktion.
Der gesamte Employee Lifecycle auf einer SuccessFactors-Ebene über verteilte Agrar- und Bio-Produkte-Standorte hinweg.
Wohin Erweiterungslogik gehört, wenn der Kern tabu ist, und was Side-by-Side auf SAP BTP im Betrieb kostet.
Der Report liefert eine Zahl — nicht, welche Objekte relevant, tot oder einen Neuaufbau wert sind.
Clean Core bedeutet, dass der Kern Standard bleibt: Customizing nutzt freigegebene Erweiterungspunkte statt Modifikationen. Upgrades bleiben Routine, da Ihre Logik nie mit veränderlichen internen Strukturen in Berührung kommt.
Nein — Customizing findet weiterhin statt, nur über das Wo: Key-User-Tools, ABAP Cloud oder Side-by-Side auf SAP BTP, nie durch die Modifikation von Standardcode.
Drei Stufen, von am wenigsten bis am stärksten invasiv: In-App für Key User, Entwicklererweiterbarkeit über ABAP Cloud, Side-by-Side auf SAP BTP. Bleiben Sie bei der frühesten Stufe, die funktioniert.
ABAP Cloud ist das eingeschränkte Entwicklungsmodell für modernes SAP: dieselbe Sprache, begrenzt auf freigegebene APIs und Objekte — upgrade-sicher, wobei vorhandene ABAP-Kenntnisse weiter genutzt werden können.
Eine freigegebene API oder ein freigegebenes Event ist SAPs veröffentlichter, stabiler Vertrag. Bauen Sie gegen freigegebene Objekte, nicht gegen Tabellen, um Erweiterungen upgrade-sicher zu halten.
SAP BTP beherbergt Side-by-Side-Erweiterungen — die ABAP-Umgebung, SAP Build Code und SAP Build Apps bauen individuelle Anwendungen auf SAP-Daten über gesteuerte Schnittstellen auf und werden unabhängig vom Kern released.
Ein Kern mit Dutzenden Punkt-zu-Punkt-Schnittstellen bis in seine Tabellen ist nicht clean. Integration Suite überführt diese auf gesteuerte APIs und Events — ein veröffentlichter Vertrag statt einer verborgenen Abhängigkeit.
Nicht vollständig, aber Inventarisierung und Stilllegung im Vorfeld sind meist günstiger: Nutzungsanalysen finden häufig seit Jahren ungenutzte Objekte — darüber entscheidet man besser vor dem Umstieg als mitten in der Konvertierung.
Wir beginnen mit einem Bestand der Eigenentwicklungen und einer Nutzungsanalyse: was existiert, läuft und von nicht freigegebenen Objekten abhängt — ein Bild der technischen Schulden, eine Baseline der Upgrade-Bereitschaft und eine Gap-Liste als Grundlage für Erweiterbarkeitsstrategie und Bereinigungsplan.
Ja — das ist sogar der häufigere Fall, da die meisten S/4HANA-Landschaften nach dem Go-Live abdriften. Gleiche Arbeitsweise: Inventarisierung, Bereinigung, Neuaufbau der Logik side-by-side, Konsolidierung der Schnittstellen und Governance, um die Position zu halten.
Sprechen Sie mit den SAP-Architekten von VISCAP über Ihre Custom-Code-Position, Ihren Upgrade-Zyklus und wie viel vom Kern Sie noch modifizieren.