Z-Code durch CAP-Applikationen ablösen

Z-Code ist nicht das Problem. Er war über Jahrzehnte die offiziell empfohlene Antwort auf eine reale Anforderung: "Das Standardsystem deckt unseren Prozess nicht ab, also erweitern wir es." Reports, User-Exits, BAdIs, eigene Funktionsbausteine, Z-Tabellen. All das hat seine Daseinsberechtigung gehabt, und vieles davon hat über Jahre stabil gearbeitet.

Kritisch wird es erst mit der Zeit:

• Der ursprüngliche Entwickler ist nicht mehr im Unternehmen.
• Die fachliche Anforderung hat sich verschoben, der Code aber nicht.
• Es bestehen Risiken bei Anpassungen, weil keiner weiß, wo er überall greift.
• Bei jedem Upgrade müssen alle Z-Objekte gegen das neue Release verifiziert werden.
• Die Tests fehlen oder sind veraltet.

Aus einem einst nützlichen Programm wird, was die deutschsprachige SAP-Community als "Zombie-Code" beschreibt: Technisch läuft er weiter, fachlich weiß niemand mehr genau, wofür, und zuständig ist auch niemand.

Drei Entwicklungen treffen gerade zusammen und machen das Aufräumen von Z-Code von einer guten Idee zur Pflicht:

Das Wartungsende rückt näher. Die Mainstream-Wartung für SAP ECC, also das Vorgängersystem von S/4HANA, endet 2027. Danach sind nur noch kostenpflichtige Extended-Maintenance-Optionen verfügbar.

SAP zwingt zum Handeln. Mit dem im August 2025 eingeführten und Anfang 2026 weiter geschärften Clean-Core-Level-Konzept (A bis D) hat SAP eine offizielle Klassifizierung geschaffen, anhand derer jede Erweiterung eingeordnet werden kann. Clean Core meint dabei ein aufgeräumtes SAP-System ohne wild gewachsene Sonderprogrammierung. Level A entspricht ABAP Cloud oder Side-by-Side-Extensions auf BTP, also Erweiterungen, die neben dem Kernsystem laufen. Level D entspricht klassischen Modifikationen am Standard, also dem, was viele Bestandskunden im System haben. Ohne Level-A- oder B-Architektur lassen sich Cloud-Updates nicht zuverlässig konsumieren.

Die Zahlen aus dem Markt sind eindeutig. Der DSAG-Investitionsreport 2026 zeigt: Die BTP, die Entwicklungs-Plattform von SAP und das Fundament für CAP- und Side-by-Side-Entwicklung, führt mit 39 Prozent geplanter hoher und mittlerer Investitionen die strategischen Cloud-Lösungen im SAP-Portfolio an. Anwendungsentwicklung und Automatisierung auf BTP haben sich von 17 Prozent (2024) auf 27 Prozent geplante Investitionen weiterentwickelt. Die Budgets sind also bereits entsprechend eingeplant.

Und es gibt einen vierten, oft übersehenen Punkt: Ohne Clean Core keine sinnvolle KI. SAPs Joule und der Joule Studio Agent Builder setzen auf saubere, standardisierte Datenmodelle und freigegebene APIs. Wer seinen Core mit weitreichender Z-Logik erweitert hat, kann KI-Agenten nicht zuverlässig auf seine Daten zugreifen lassen.

CAP steht für Cloud Application Programming Model. Es ist das offizielle SAP-Framework, um Anwendungen und Erweiterungen außerhalb des S/4HANA-Kerns zu bauen. CAP-Applikationen werden auf der SAP Business Technology Platform bereitgestellt.

CAP ist im Kern ein deklaratives Framework: Sie modellieren Ihre Daten und Services in einer einfachen Sprache (CDS), und CAP generiert daraus automatisch OData-Services, Datenbankschemata, REST-Endpunkte und Standardlogik. OData ist dabei einer der normalen Zugangswege, die SAP ohnehin mitliefert. Eigene Geschäftslogik schreiben Sie in Node.js oder Java. Das Ergebnis läuft als entkoppelte Anwendung auf BTP und kommuniziert mit S/4HANA über offizielle, freigegebene APIs.

CAP ist dabei nicht der einzige Weg. ABAP Cloud ist die Variante direkt im SAP-System, RAP der Weg für Fiori-nahe Erweiterungen. Für die meisten neuen Anforderungen, insbesondere wenn Sie Plattform-übergreifend und cloud-native bauen wollen, ist CAP aber der natürliche Standardweg.

Bevor wir über Projektaufwand reden, eine ehrliche Einordnung. CAP ist mächtig, aber nicht jede Anforderung ist ein CAP-Projekt. In Beratungsgesprächen kommen wir oft zu drei Kategorien:

1. SAP-Standard prüfen, bevor irgendetwas gebaut wird. Viele Z-Reports sind über die Jahre obsolet geworden, weil SAP zwischenzeitlich Standardfunktionalität dafür ausgeliefert hat. Erste Frage immer: Kann der Standard die Anforderungen abbilden?

2. Standard-Extensibility nutzen, wo möglich. Key-User-Extensibility, Custom Fields, Custom Logic in Fiori. Für viele Anpassungen reicht das. Kein Code, kein Projekt.

3. CAP nutzen, wo eigene Logik wirklich nötig ist. Wenn Sie eigene Datenmodelle brauchen, eigene Services, komplexe Geschäftslogik oder Anbindungen an Drittsysteme: Genau dafür ist CAP gemacht.

Eine grobe Daumenregel: Wenn Sie heute überlegen, ein Z-Programm neu zu schreiben oder zu modernisieren, fragen Sie sich zuerst, ob Sie es überhaupt noch brauchen. Wenn ja, gehört es fast nie wieder in den Core.

In realen Projekten dauert ein erster produktiver CAP-Use-Case typischerweise 8 bis 12 Wochen, je nach Komplexität und Integrationstiefe. Eine bewährte Struktur:

Phase 1: Discovery und Architektur. Wir nehmen die fachliche Anforderung und das bestehende Z-Code-Umfeld auf. Welche Standardfunktionen ersetzen einen Teil davon bereits? Welche Daten müssen aus S/4HANA gelesen oder dorthin geschrieben werden? Welche Schnittstellen sind verfügbar? Ergebnis: Ziel-Architektur und API-Mapping.

Phase 2: Datenmodell und Services. CDS-Datenmodell, OData-Services, S/4HANA-Anbindung über released APIs. Die Anmeldung der Nutzer läuft über die BTP-Dienste XSUAA und IAS. Erste Endpunkte stehen.

Phase 3: Geschäftslogik und UI. Implementierung der eigentlichen Logik in Node.js oder Java. UI als SAPUI5/Fiori Elements oder als Custom-Frontend. Anbindung an Workflows oder Genehmigungsprozesse, falls nötig.

Phase 4: Integration und Test. Integrationstests gegen das Q-System, Performance-Prüfung, Berechtigungen, Ende-zu-Ende-Tests.

Phase 5: Go-Live und Enablement. Pilot mit definierter Nutzergruppe, schrittweiser Rollout, Schulung der Key-User, Übergabe in den Betrieb.

Wichtig: Ein einmaliges CAP-Projekt ist erst der Anfang. Der eigentliche Mehrwert entsteht, wenn Sie ein Plattform-Setup haben, in dem die nächsten Anforderungen nur noch zwei bis vier Wochen brauchen, weil Authentifizierung, CI/CD-Pipelines und Schnittstellenkataloge schon stehen.

CAP macht Entwicklung nicht automatisch billiger. Der Gewinn liegt woanders: Ihre Erweiterungen werden upgrade-stabil und bleiben anschlussfähig an Cloud-Updates. Dieser Wert zeigt sich allerdings erst über mehrere Releases.

Was Sie gewinnen:

• Entkopplung vom S/4HANA-Releasezyklus
• Echte Cloud-DevOps mit Git, CI/CD und automatisierten Tests
• Ein Codestand, der von einem neuen Team in Wochen verstanden wird, nicht in Jahren
• Einen Architekturansatz, den SAP offiziell als Clean-Core-Level A klassifiziert

Worauf Sie achten müssen:

• CAP ist Pro-Code. Sie brauchen Entwickler mit JavaScript-/TypeScript- oder Java-Skills, nicht nur ABAP-Erfahrung.
• BTP-Kosten sind nutzungsbasiert. Eine saubere Sizing- und Cost-Governance gehört von Anfang an dazu.
• Identitätsmanagement, Berechtigungen und Trust-Beziehungen zwischen Ihren BTP-Subaccounts und S/4HANA: Das ist Setup-Arbeit, die häufig unterschätzt wird.
• Der DSAG-Investitionsreport 2026 nennt fehlende Skills als eine der zentralen Hürden bei der BTP-Adoption. Nehmen Sie das ernst. Enablement gehört in jedes CAP-Projekt.

Klar gesagt: Ein CAP-Projekt ist nichts, das man mal eben mit dem bestehenden ABAP-Team nebenher macht. Es braucht entweder den Aufbau interner Cloud-Skills oder einen erfahrenen Partner, der genau das mitbringt.

Die häufigste Reaktion in der SAP-Community auf Clean-Core-Diskussionen ist Abwehr, und sie ist verständlich. Niemand möchte hören, dass die ABAP-Skills, mit denen er ein Unternehmen über zwei Jahrzehnte am Laufen gehalten hat, plötzlich "veraltet" sind. Sie sind es nicht. Klassisches ABAP wird in vielen Landschaften noch jahrelang relevant sein, und das Clean-Core-Level-Modell von SAP räumt mit der binären "clean oder dirty"-Logik bewusst auf.

Worum es wirklich geht, ist Klarheit:

• Welcher Z-Code im System ist heute noch fachlich relevant?
• Welcher davon kann durch Standard ersetzt werden?
• Was bleibt? Und gehört das in den Core, oder besser auf BTP?
• Welche neuen Anforderungen kommen, und welche Architektur ist dafür die richtige?

Wer diese Fragen 2026 beantwortet, hat eine belastbare Grundlage für die nächsten Jahre: ein Bestandssystem, das weiter funktioniert, und daneben eine Plattformarchitektur, die KI, Cloud-Updates und neue Geschäftsmodelle trägt.

Wir bei ORAI verbinden klassische SAP-Tiefe mit echter BTP- und CAP-Erfahrung. Wir helfen Ihnen, Ihren bestehenden Z-Code zu klassifizieren (was bleibt, was geht, was wird ersetzt), wir bringen den ersten produktiven CAP-Use-Case in 8 bis 12 Wochen ans Ziel, und wir bauen mit Ihnen das Plattform-Setup, das jede weitere Erweiterung beschleunigt.