Mit dem Wechsel von SAP ERP (ECC) auf SAP S/4HANA stehen Unternehmen vor einer zentralen Herausforderung:
👉 Wie können bestehende Z-Programme (kundeneigene ABAP-Entwicklungen) übernommen, modernisiert oder ersetzt werden?
Denn während viele Prozesse mit dem Wechsel auf SAP S/4HANA durch Standardfunktionen abgedeckt werden, bleiben kundenspezifische Entwicklungen ein kritischer Erfolgsfaktor.
In diesem Beitrag erfährst du:
- Was bei der Migration von Z-Programmen zu beachten ist
- Warum ein „1:1-Umzug“ oft nicht sinnvoll ist
- Welche Tools, Ansätze und Best Practices sich in der Praxis bewährt haben
✅ Was sind Z-Programme überhaupt?
Z-Programme sind kundeneigene ABAP-Programme, die mit dem Präfix Z* oder Y* benannt sind. Sie wurden in früheren SAP-Systemen entwickelt, um unternehmensspezifische Anforderungen zu erfüllen, die der SAP-Standard nicht abdeckte.
Mit SAP S/4HANA ändern sich viele Dinge:
- Die technische Plattform (HANA, CDS Views, Fiori etc.)
- Die Datenmodelle (z. B. MATDOC statt MARC/MSEG)
- Die Geschäftsprozesse selbst
➡️ Das bedeutet: Z-Programme müssen auf technischer UND fachlicher Ebene überprüft werden.
🚧 Warum ein 1:1-Transfer problematisch ist
Viele Unternehmen neigen dazu, ihre Z-Programme einfach zu „übernehmen“. Doch genau das ist oft nicht zukunftssicher:
| Problem | Auswirkung |
|---|---|
| Veraltete Logik (z. B. Tabellenzugriffe auf nicht mehr vorhandene Tabellen) | Laufzeitfehler, Performance-Probleme |
| Harte Codierung statt Fiori/Services | Kein Nutzen moderner UI und UX |
| Redundanz durch neue S/4HANA-Funktion | Verpasste Chance zur Standardisierung |
🔍 Z-Programme analysieren: Der erste Schritt
Vor jeder Übernahme steht die Frage:
Welche Z-Programme braucht man wirklich noch?
Tools zur Analyse:
- SAP Readiness Check
- ABAP Test Cockpit (ATC) mit S/4HANA Checks
- Custom Code Migration App
- SAP Business Transformation Center (BTC)
Diese Tools helfen dir:
- Veraltete Coding-Strukturen zu identifizieren
- SAP-Standard-Redundanzen zu erkennen
- Aufwände für Anpassung oder Neuentwicklung zu schätzen
🔧 Optionen für die Übertragung
1. Stilllegen (Sunset)
- Nicht mehr genutzte Programme dokumentieren & archivieren
- Ressourcen für wichtigere Projekte freimachen
2. Standard ersetzen
- Viele frühere Z-Programme sind mit S/4HANA obsolet
- Beispiel: Eigene Verfügbarkeitsprüfung durch neue ATP-Funktionalität abgelöst
3. Technische Migration
- Notwendig, wenn der Geschäftsprozess gleich bleibt
- Anpassung an neues Datenmodell (z. B. MATDOC, ACDOCA)
4. Funktionale Neuentwicklung
- Mit Fiori, RAP (RESTful ABAP), CDS & modernen UI5-Komponenten
- Mehr Nachhaltigkeit, bessere User Experience
🛠️ Best Practices aus der Praxis
- Kategorisieren: Welche Z-Programme sind kritisch? Welche häufig genutzt?
- Eng mit dem Fachbereich arbeiten: Viele Z-Programme wurden für spezifische Anforderungen geschrieben, die heute nicht mehr relevant sind.
- SAP-Standard bevorzugen: Prüfen, ob heutige S/4HANA-Versionen bereits Lösungen enthalten
- Frühzeitig testen & validieren: Besonders bei komplexer Logik oder Batchprozessen
- Dokumentation aufbauen oder ergänzen: Z-Programme sind oft unzureichend dokumentiert – ein Risiko bei Migrationen
🎓 SAP empfiehlt: Clean Core statt Custom Chaos
Die „Clean Core“-Strategie von SAP bedeutet:
➡️ So viel wie möglich im Standard abbilden
➡️ Erweiterungen über SAP BTP, Key-User-Tools oder Side-by-Side-Extensions
Das gilt auch für Z-Programme:
Nur migrieren, was langfristig sinnvoll und wartbar ist.
🚀 Fazit
Die Übertragung von Z-Programmen nach SAP S/4HANA ist kein rein technisches Projekt – sie ist ein zentraler Hebel für Innovation, Vereinfachung und Zukunftssicherheit.
Ein durchdachtes Vorgehen mit Transparenz, Analyse, Priorisierung und Modernisierung zahlt sich aus – gerade in komplexen Logistik- oder Produktionsumfeldern.
