Die h\u00e4ufigste Reaktion auf Clean Core in gewachsenen SAP-Systemen: \u201eBei uns liegen zwanzig Jahre Eigenentwicklung im System \u2013 wo sollen wir da \u00fcberhaupt anfangen?“ Die Antwort ist unspektakul\u00e4r, aber wirkungsvoll: mit einer sauberen Bestandsaufnahme. Denn bevor irgendetwas migriert, abgel\u00f6st oder neu gebaut wird, braucht es Transparenz dar\u00fcber, was tats\u00e4chlich im System liegt, wie es sich auf die Clean-Core-Levels A\u2013D verteilt \u2013 und was davon \u00fcberhaupt noch genutzt wird.<\/p>\n\n\n\n
Das ABAP Test Cockpit (ATC) bringt daf\u00fcr alles mit, was man braucht. Mit den Cloud-Readiness-Checks l\u00e4sst sich der gesamte Custom Code automatisiert daraufhin pr\u00fcfen, welche Objekte nicht freigegebene SAP-Schnittstellen nutzen, direkt auf SAP-Tabellen zugreifen oder auf Modifikationen basieren. Erg\u00e4nzend zeigt das Cloudification Repository, welche Standardobjekte freigegeben sind \u2013 die Grundlage, um Findings den Levels zuzuordnen.<\/p>\n\n\n\n
Das Ergebnis ist keine Flei\u00dfarbeit f\u00fcr Wochen, sondern ein Lauf \u00fcber Nacht: eine vollst\u00e4ndige Liste aller Findings, kategorisiert nach Objekt und Schweregrad. Damit ist die Frage \u201eWie viel Level D liegt bei uns im System?“ keine Sch\u00e4tzung mehr, sondern ein Report.<\/p>\n\n\n\n
Der zweite Blick ist mindestens so wertvoll wie der erste: die Nutzungsdaten. \u00dcber das Usage Procedure Logging (SUSG\/SCMON) l\u00e4sst sich \u00fcber mehrere Monate mitschreiben, welche Eigenentwicklungen tats\u00e4chlich aufgerufen werden. Die Erfahrung aus unseren Projekten ist dabei erstaunlich konstant: Ein erheblicher Teil des Custom Codes \u2013 oft 30 bis 60 Prozent \u2013 wird schlicht nicht mehr verwendet.<\/p>\n\n\n\n
Diese Erkenntnis ver\u00e4ndert die gesamte Rechnung. Toter Code muss nicht klassifiziert und nicht migriert werden, er muss nur stillgelegt werden. Wer die Nutzungsanalyse \u00fcberspringt, plant Migrationsaufwand f\u00fcr Objekte, die niemand vermissen w\u00fcrde.<\/p>\n\n\n\n
Aus Findings, Level-Zuordnung und Nutzungsdaten entsteht ein klarer Handlungsplan. Ungenutzter Code wird stillgelegt \u2013 unabh\u00e4ngig vom Level. Genutzte B-Objekte bleiben, wie sie sind; sie m\u00fcssen nur sauber gehalten werden. Genutzte C-Objekte werden nicht hektisch migriert, sondern in einen kontrollierten Pr\u00fcfprozess \u00fcberf\u00fchrt: Vor jedem Upgrade wird gegen die \u00c4nderungshistorie der genutzten SAP-Objekte gepr\u00fcft \u2013 so werden sie \u201econditionally clean“. Und die D-Objekte \u2013 Modifikationen und schwere Verst\u00f6\u00dfe \u2013 landen priorisiert nach fachlicher Kritikalit\u00e4t auf der eigentlichen Abl\u00f6se-Roadmap.<\/p>\n\n\n\n
Das ist der zentrale Unterschied zum Big-Bang-Denken: Clean Core im Brownfield ist kein Projekt mit Enddatum, sondern eine Richtungsentscheidung mit priorisierter Abarbeitung. Jedes Upgrade wird dadurch messbar g\u00fcnstiger \u2013 und das System Schritt f\u00fcr Schritt zukunftsf\u00e4hig.<\/p>\n\n\n\n
Eine belastbare Bestandsaufnahme inklusive Level-Auswertung dauert erfahrungsgem\u00e4\u00df wenige Tage bis zwei Wochen \u2013 die Nutzungsmessung l\u00e4uft parallel im Hintergrund mit. Am Ende steht kein hundertseitiges Konzept, sondern eine priorisierte Liste mit Aufwandsindikation. Genau das braucht die Gesch\u00e4ftsf\u00fchrung, um Clean Core nicht als Glaubensfrage, sondern als Investitionsentscheidung zu behandeln.<\/p>\n\n\n\n
secat f\u00fchrt Clean-Core-Assessments mit ATC-, Level- und Nutzungsanalyse als kompaktes Festpreispaket durch. Sprechen Sie uns an \u2013 wir zeigen Ihnen, wo Ihr System heute steht.<\/em><\/p>\n\n\n\n SAP S\/4HANA System Conversion \u2013 Custom Code Adaptation Process<\/a> <\/p>\n\n\n\n Custom Code Adaptation for SAP S\/4HANA \u2013 FAQ<\/a> <\/p>\n\n\n\n SUSG: How to Aggregate and Analyze the Results of SCMON ABAP Call Statistics<\/a> <\/p>\n\n\n\n