Z-Code durch CAP-Applikationen ablösen

Z-Code ist nicht das Problem an sich. Z-Code 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.

Das Problem ist nicht, dass Z-Code geschrieben wurde. Das Problem ist, was mit ihm über die Zeit passiert:

● 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 dem ehemaligen Asset wird, was die deutschsprachige SAP-Community treffend als "Zombie-Code" beschreibt: technisch lebendig, fachlich vergessen, organisatorisch verwaist.

Drei Entwicklungen treffen gerade zusammen und machen Z-Code-Aufräumen vom "Should" zum "Must":

Das Wartungsende rückt näher. Die Mainstream-Wartung für SAP ECC 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. Level A entspricht ABAP Cloud oder Side-by-Side-Extensions auf BTP. 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, dass die BTP – als Plattformfundament für CAP- und Side-by-Side-Entwicklung – mit 39 Prozent geplanter hoher und mittlerer Investitionen die strategischen Cloud-Lösungen im SAP-Portfolio anführt. Anwendungsentwicklung und Automatisierung auf BTP haben sich von 17 Prozent (2024) auf 27 Prozent geplante Investitionen weiterentwickelt. Die Branche stimmt mit dem Budget ab.

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. 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 On-Stack-Variante, RAP ist der Weg für Fiori-nahe Erweiterungen. Aber für die meisten neuen Anforderungen, insbesondere wenn Sie Plattform-übergreifend und cloud-native bauen wollen, ist CAP 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, das ist der CAP-Sweetspot.

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.

Aus realen Projekten kristallisieren sich für einen ersten produktiven CAP-Use-Case typischerweise 8 bis 12 Wochen heraus – abhängig von Komplexität und Integrationstiefe. Eine bewährte Struktur:

Phase 1: Discovery und Architektur. Wir vermessen die fachliche Anforderung und das bestehende Z-Code-Umfeld. 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. Authentifizierung über 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 Workflow 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 der Anfang, nicht das Ziel. 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.

Das Versprechen von CAP ist nicht "alles wird billiger". Das Versprechen ist: Ihre Erweiterungen werden upgrade-stabil und bleiben anschlussfähig an Cloud-Updates. Das hat Wert, der sich aber erst über mehrere Releases zeigt.

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, Trust-Beziehungen zwischen Ihren BTP-Subaccounts und S/4HANA – das ist Setup-Arbeit, die 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, baut keine Brandmauer, sondern eine Brücke: Von einem Bestandssystem, das funktioniert, zu einer 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.