Freitag, 22:30 Uhr. Du sitzt im Release-Fenster. Der Fachbereich sagt: „Wir haben doch alles getestet.“ Basis sagt: „System ist grün.“ Und trotzdem: Der erste Prozess hängt, ein Batch-Job läuft endlos, ST22 zeigt den nächsten Dump. Alle schauen auf ratlos zu dir und ja: Das ist ein SAP-Dirty Core Problem. Der Auslöser ist fast immer derselbe: Z-Code. Und die Lösung ist der Aufbau einer Clean Core.
Spoiler: Es ist selten „der neue Z-Code“. Es ist der alte. Der vergessene. Der nicht dokumentierte. Der, der nachts läuft und tagsüber niemandem gehört. Der, wo der Entwickler schon lange nicht mehr da ist. Genau deshalb wird in diesem Artikel Z-Code = Zombie-Code gleich gesetzt: Custom Code, der fachlich vergessen ist, technisch aber als Zombie weiterlebt.
Warum ist das problematisch? Im Jahr 2026 ist Clean Core nunmal Voraussetzung, wenn du vorhast, Dein SAP System in einer Private Cloud oder Public Cloud wirklich updatefähig zu betreiben. In diesem Beitrag bekommst Du deshalb hier eine einfache Erklärung, echte SAP-Beispiele – und eine Roadmap mit konkreten Werkzeugen, wie Du Z-Code sichtbar machst und eliminierst.
Inhaltsverzeichnis
- 1. Was ist nochmal Clean Core?
- 2. Z-Code = Zombie-Code: Warum das im SAP-Core so gefährlich ist
- 3. Private Cloud vs. Public Cloud: Wo Z-Code dir am schnellsten um die Ohren fliegt
- 4. Kurz erklärt: Was ist die SAP BTP – und warum ist sie der Clean-Core-Hebel?
- 5. Governance: So verhinderst du, dass aus Anforderungen neue Zombies werden
- 6. Praxis-Roadmap: Z-Code sichtbar machen, stilllegen, verhindern – mit konkreten Tools
- 7. Nächster Schritt: Clean Core strategisch absichern
- Fazit
- FAQ
1. Was ist nochmal Clean Core?
Clean Core im Jahr 2026 bedeutet: Du hältst den SAP-Core so standardnah und stabil wie möglich, damit Updates, Security Patches und Releases kein Krisenmodus sind.
Die wichtigste Klarstellung: Clean Core heißt nicht „keine Erweiterungen“. Die wird es durchaus noch länger geben.
Es heißt:
- Dein SAP-Core bleibt upgrade-stabil.
- Erweiterungen sind erlaubt – aber bitte kontrolliert und dokumentiert.
- Differenzierung entsteht über freigegebene Erweiterungswege oder entkoppelt daneben. Daneben heißt mit SAP BTP. Mehr dazu später.
Dein Schnelltest
Wenn Du vor jedem SAP Update denkst: „Hoffentlich fällt uns kein Z-Enhancement auf die Füße“, dann ist dein Core wahrscheinlich nicht clean – dann ist dein Update-Prozess von Z-Code-Risiken abhängig.
2. Z-Code = Zombie-Code: Warum das im SAP-Core so gefährlich ist
Du kennst die Szene: SM37 zeigt einen Job, der „nur monatlich“ läuft. Der Job hängt in einem Z-Programm mit Jahreszahl im Namen. Niemand weiß mehr, wer es gebaut hat. Der Fachbereich sagt: „Brauchen wir nicht mehr.“ Und trotzdem hängt dein Release-Fenster daran.
Hier ist die Definition, die du ab jetzt konsequent nutzen kannst:
Z-Code ist Zombie-Code.
Fachlich oft vergessen – technisch aktiv – und genau deshalb das größte Risiko für Updates im SAP-Core.
Warum Z-Code im SAP-Kontext so häufig eskaliert
Weil SAP-Landschaften „lange leben“ und Z-Code dabei oft keinen Lebenszyklus hat:
Heißt, es gibt:
- kein Owner (wer entscheidet über Änderung/Stilllegung?)
- keine Dokumentation (was macht das Ding – und warum?)
- keine Tests (was muss nach einem Update sicher funktionieren?)
- keine Nutzungstransparenz (läuft es wirklich – oder nur theoretisch?)
- keine Stilllegungsroutine (wie wird aus „kann weg“ wirklich „ist weg“?)
Drei typische Z-Code-Zombie-Muster (die du sofort wiedererkennst)
- Batch-Zombies (SM36/SM37)
„Nur ein Abgleich-Report.“ Läuft nachts. Verarbeitet viel. Niemand testet ihn im UAT, weil „nicht fachlich sichtbar“. Und genau der blockiert dann Folgejobs. - Enhancement-Zombies (BAdI/User-Exit)
Feuern nur in Sonderpfaden. Genau diese Sonderpfade tauchen im Test nicht auf. Ergebnis: produktive Seiteneffekte nach Update. - Integrations-Zombies (RFC/IDoc/Dateiablage)
„Historisch gewachsen.“ Im Ausnahmefall wird doch noch der alte Weg genutzt. Dann bricht’s – und du suchst den Fehler zwischen SAP-Core, Middleware und Partner. Total nervig.
Wichtig: „Dein Dirty Core beeinflusst die Qualität deines SAP-Core“ und wird dann zu deinem Problem…
Nicht im Sinne „SAP ist schuld“, sondern im Sinne von: Das Risiko materialisiert sich im SAP-System – in Performance, Dumps, Prozessabbrüchen, Berechtigungs- und Datenflüssen. Clean Core im Jahr 2026 heißt deshalb: Du behandelst den SAP-Core wie ein Produkt, nicht wie einen Werkzeugkasten.
3. Private Cloud vs. Public Cloud: Wo Z-Code dir am schnellsten um die Ohren fliegt
ERP Cloud erlöst uns nicht von Z-Code. Cloud zwingt dich nur früher, ihn zu beherrschen.
Public Cloud
- Standardnähe ist Betriebsmodell
- Freiheiten im Core sind sehr stark begrenzt
- „Schnell mal im Core“ existiert nicht mehr als Option
Private Cloud
- mehr Flexibilität – und damit mehr Versuchung
- Z-Code Altlasten lassen sich leichter mitnehmen
- Risiko: Du schleppst den Zombie-Code mit, zahlst später aber mit mehr Testaufwand und längeren Upgrade-Zyklen. Ewig grüßt das Murmeltier!
Wenn du Clean Core im Jahr 2026 erreichen willst, ist die Frage nicht „Private oder Public?“, sondern: Wie konsequent kannst du Z-Code aus deinem SAP-Core entkoppeln? Die Lösung: SAP BTP.
4. Kurz erklärt: Was ist die SAP BTP – und warum ist sie der Clean-Core-Hebel?
SAP BTP (Business Technology Platform) ist SAPs Baukasten für Erweiterungen, Integration, Automatisierung und Applikationsentwicklung – also der Ort, an dem du zusätzliche Fähigkeiten bauen kannst, ohne den SAP-Core zu verbiegen. Ausserhalb des SAP ERP Systems.
Warum SAP BTP in Clean-Core-Architekturen so wichtig ist
Weil du damit „Neben-dem-Core“ (Side-by-Side) umsetzen kannst:
- eigene Apps und Oberflächen
- Workflows und Genehmigungen
- Integrationen (statt Punkt-zu-Punkt)
- Regeln, Validierungen, Zusatzlogik
Kurz: Du differenzierst – ohne das Upgrade-Risiko in den SAP-Core zu pressen.
Einfache Faustregel
- kleine, vorgesehene Anpassungen → In-App/Key User
- eigene Prozesse/Apps/Integration → Side-by-Side auf SAP BTP
- Eingriff in Standardobjekte → nur mit Ausnahme + Rückbauplan
5. Governance: So verhinderst du, dass aus Anforderungen neue Zombies werden
Clean Core im Jahr 2026 scheitert fast nie am Know-how. Er scheitert daran, dass „nur kurz“ zum neuen Standard wird. Aus alter Gewohnheit.
Du brauchst also Governance, die den Alltag leichter macht:
- Decision Tree für jede neue Anforderung
Standard/Prozess → In-App → Side-by-Side (BTP) → Ausnahme - Quality Gate als Default
Kein neuer Z-Code ohne definierte Checks (und ohne Teststrategie). - Ownership & Lebenszyklus
Jedes Z-Objekt hat Owner, Zweck, Tests, Doku – oder es wird stillgelegt. - „No new Z-Code-Zombies“ als Prinzip
Neue Sonderlogik im SAP-Core ist nicht mehr der Normalfall.
6. Praxis-Roadmap: Z-Code sichtbar machen, stilllegen, verhindern – mit konkreten Tools
Du willst keine Theorie, du willst Handgriffe. Hier ist die Roadmap, die in echten SAP-Programmen funktioniert.
Phase 1: Z-Code sichtbar machen (2–6 Wochen)
Ziel: Du willst harte Nutzungsdaten statt Bauchgefühl.
SAP Bordmittel, die du dafür einsetzen kannst:
- UPL (Usage & Procedure Logging): Nutzungsdaten für ABAP-/Custom-Code ohne aufwendige Instrumentierung.
- SCMON (ABAP Call Monitor): Detaillierte Aufzeichnung, welche ABAP-Objekte tatsächlich ausgeführt werden.
- SAP Solution Manager 7.2 – Custom Code Management: Zentrale Sicht auf Custom Code inkl. Usage-Daten (je nach Setup).
- ATC (ABAP Test Cockpit): Technische Qualitäts- und Risikoanalyse (z. B. kritische Statements, S/4-Relevanz, Code Smells).
- Where-Used / Call Hierarchies (ABAP-Workbench/ADT): Ergänzend, um Eintrittspunkte zu finden (Menü, RFC, Jobs, Enhancements).
Praktischer Ablauf (einfach, aber wirksam):
- Aktiviere UPL oder SCMON im produktiven System (oder repräsentativer Produktivkopie, wenn organisatorisch nötig).
- Sammle Daten über einen ausreichend repräsentativen Zeitraum (mindestens mehrere Wochen; ideal über Abschluss-/Sonderzyklen).
- Erzeuge eine Top-Liste: „Meistgenutzt“, „Kritisch im Prozess“, „Performance-lastig“, „Unklarer Owner“.
- Ergänze die Liste um „Einstiegspunkte“: Welche Jobs, Transaktionen, RFCs, Enhancements triggern diese Objekte?
Dein Deliverable nach Phase 1:
Ein Z-Code-Portfolio, das du priorisieren kannst – nicht nach Lautstärke, sondern nach faktischer Nutzung + Risiko.
Phase 2: Z-Code stilllegen (4–12 Wochen)
Ziel: Stilllegung ohne Produktionsüberraschungen.
Werkzeuge & Maßnahmen – konkret:
- Job-basiert stilllegen:
- Prüfe Jobkette in SM37/SM36
- Stoppe Scheduling (nicht nur „Job abbrechen“)
- Entferne Folgeabhängigkeiten, die automatisch neu starten
- Transaktions-/UI-basiert stilllegen:
- Entferne Menüeinträge/Role-Zuweisungen (PFCG), damit niemand „aus Versehen“ startet
- Leite ggf. auf Nachfolgerprozess um
- Schnittstellen-basiert stilllegen:
- Deaktiviere alte RFC-Destinationen/Partnerprofile nur kontrolliert (inkl. Fallback)
- Baue „Schalter“: neuer Pfad aktiv, alter Pfad read-only/monitoring-only
- Enhancement-/BAdI-basiert stilllegen:
- Deaktiviere Implementierungen gezielt (nicht „im Code auskommentieren“)
- Dokumentiere, welche Business-Events betroffen sind
- Stilllegung technisch absichern:
- Nutze SCMON/UPL weiter, um zu prüfen: Wird der Code wirklich nicht mehr ausgeführt?
- Führe eine „Silent Phase“ ein: 2–4 Wochen ohne Ausführung, dann endgültige Entfernung
- Endgültige Entfernung (Cleanup):
- Nutze (wo verfügbar) Custom Code Retirement / Decommissioning Cockpit als methodischen Rahmen
- Lösche/archiviere Objekte transportiert und nachvollziehbar (inkl. Doku im ChaRM/Change-Prozess)
Wichtig: „Nicht mehr genutzt“ ist keine technische Aussage. Es ist eine Hypothese. Die belegst du mit UPL/SCMON – und erst dann löschst du.
Phase 3: Verhindern, dass neue Z-Code-Zombies entstehen (ab sofort)
Ziel: Clean Core im Jahr 2026 als Betriebsstandard.
Konkrete Controls:
- ATC als Pflicht-Gate vor Merge/Transport
- Architekturentscheidung pro Anforderung (Decision Tree)
- Side-by-Side Default für neue Logik, sobald sie über „kleine Anpassung“ hinausgeht
- Owner + Sunset-Regel: jedes neue Z-Objekt bekommt Review/Abkündigungstermin
- KPIs: Anteil Z-Code im Kern, Anzahl Ausnahmen, Release-Durchlaufzeit, Defect-Rate nach Updates
7. Nächster Schritt: Clean Core strategisch absichern
Wenn du Clean Core im Jahr 2026 nicht dem Zufall überlassen willst, brauchst du vor allem zwei belastbare Ergebnisse:
1. Clean-Core-Assessment
Transparenz darüber, wo Z-Code (Zombie-Code) heute konkret Updates, Tests und Betriebsstabilität blockiert – faktenbasiert, nicht nach Bauchgefühl.
2. BTP-Blueprint & Governance-Modell
Eine klare Architektur- und Entscheidungslogik, die festlegt,
welche Anforderungen im SAP-Core zulässig sind,
welche konsequent Side-by-Side über SAP BTP umgesetzt werden
– und welche ab 2026 nicht mehr erlaubt sind.
Weitere Informationen und vertiefende Inhalte findest Du hier:
- SAP Business Technology Platform | Integration & Innovation – Fink IT-Solutions
- SAP BTP Lizenzmodell erklärt: Innovation, Cloud & Strategie
Fazit
Clean Core im Jahr 2026 ist deine Versicherung gegen Release-Chaos im SAP-Core. Du erreichst ihn nicht durch „einmal aufräumen“, sondern durch ein strukturiertes System:
- Z-Code sichtbar machen (UPL/SCMON, Custom Code Management)
- Z-Code stilllegen (Jobs, Enhancements, Schnittstellen – kontrolliert)
- Z-Code-Zombies verhindern (ATC-Gates, Decision Tree, Side-by-Side mit SAP BTP)
Der letzte Spoiler: Die Freitagnächte verschwinden nicht, wenn du den größten Zombie erschlägst. Sie verschwinden, wenn du keine neuen Zombies mehr entstehen lässt.
FAQ
Was bedeutet Clean Core im Jahr 2026?
Du hältst den SAP-Core standardnah und updatefähig und setzt Erweiterungen kontrolliert um – bevorzugt entkoppelt (z. B. Side-by-Side über SAP BTP).
Warum sagst du Z-Code = Zombie-Code?
Weil Z-Code in vielen SAP-Landschaften faktisch „vergessene“ Logik ist: ohne Owner, ohne Tests, ohne Nutzungsnachweis – aber technisch aktiv und damit ein Upgrade-Risiko.
Wie mache ich Z-Code sichtbar?
Über Nutzungs- und Ausführungsdaten, z. B. mit UPL oder SCMON, ergänzt um technische Analyse mit ATC und Eintrittspunktanalyse (Jobs, Transaktionen, Enhancements, Schnittstellen).
Wie lege ich Z-Code sicher still?
Nicht durch „löschen und hoffen“, sondern durch kontrolliertes Abschalten (Jobs/Transaktionen/Schnittstellen/Enhancements), Monitoring über UPL/SCMON und erst danach die endgültige Entfernung.
Was ist SAP BTP in einem Satz?
SAP BTP ist die Plattformschicht, auf der du Erweiterungen, Integrationen und Automatisierungen bauen kannst, ohne den SAP-Core zu destabilisieren – und damit ein Schlüssel für Clean Core im Jahr 2026.