Z-Programme auf SAP S/4HANA übertragen

Was sind Z-Programme?

Die Begriffe Z-Programme und Z-Entwicklungen sind Sammelbegriffe für Transaktionen, Code, Funktionsbausteine und Programme.

Es handelt sich dabei um Anwendungen, die zusätzlich zu den Originalprogrammen der SAP betrieben werden – also außerhalb der Standards. Diese Add-ons bilden individuelle Prozesse von Unternehmen ab und bieten Lösungen, die über den Standard hinausgehen.

Sammeln sich im Laufe der Jahre allerdings viele Z-Programme an – wie dies in vielen Unternehmen unter SAP ECC der Fall war –, führt dies mit der Zeit zu einer immer komplexeren IT-Architektur.

Daraus resultieren gleich mehrere Probleme:

• Der Aufwand für Wartung und Service steigt.
• Die Reaktionsfähigkeit der IT nimmt ab.
• Zudem müssen Unternehmen bei jedem Upgrade des SAP-Systems dafür sorgen, dass ihre individuellen Lösungen noch weiter funktionieren.

Wofür steht das „Z“ in Z-Programme?

Die meisten Anwendungen der SAP sind in der proprietären, also der SAP-eigenen Programmiersprache ABAP geschrieben. Das Akronym ABAP steht für „Advanced Business Application Programming“. Entwickler können SAP-Anwendungen in ABAP verändern oder erweitern.

Um erkennen zu können, zu welchem Modul oder Bereich im SAP ein Programm gehört, gelten bestimmte Namenskonventionen.

Maßgeblich sind dabei die so genannten Pakete. Die Pakete beinhalten innerhalb von ABAP definierte Objekte (wie zum Beispiel Datentypen, Datenobjekte oder Klassen) und ermöglichen die bessere Strukturierung von ABAP.

Zur Zuordnung und Unterscheidung werden die Pakete im Rahmen der Namensgebung – unter anderem – mit bestimmten Anfangsbuchstaben gekennzeichnet. Pakete mit den Anfangsbuchstaben A bis S und U bis X sind zum Beispiel den Objekten des SAP-Standards vorbehalten.

Kundeneigene Objekte dagegen können mit den Anfangsbuchstaben Z oder Y angelegt werden – das sind die bekannten Z-Programme, Z-Entwicklungen oder auch Y-Programme.

Welche Möglichkeiten der Anpassung von SAP-Systemen gibt es?

Das SAP Customizing bezeichnet die grundlegenden Einstellungen und Anpassungen eines SAP-Systems. Führt ein Unternehmen ein neues ERP-System wie SAP S/4HANA ein, müssen die SAP-Experten zunächst immer unternehmensspezifische Grundeinstellungen vornehmen.

Neben dem SAP Customizing hat ein Unternehmen – das ein SAP-ERP-System einführt oder betreibt – verschiedene weitere Möglichkeiten, das SAP-System an seine individuellen Anforderungen anzupassen. Experten bezeichnen diese Lösungen als kundenspezifische ABAP-Entwicklungen.

Unternehmen können zum Beispiel die Originalprogramme verändern. Dazu nehmen Entwickler Änderungen am originalen Quellcode vor.

SAP spricht in diesem Fall von Modifikationen. Solche Modifikationen sollten eher die Ausnahme sein. Das Problem ist, dass die Modifikationen bei späteren Releases auf neue Versionen stets angepasst oder sogar komplett neu eingespielt werden müssen. Das aber ist aufwendig und kostet meist viel Zeit.

Eine Lösung für dieses Problem bietet das SAP Erweiterungskonzept (siehe auch Enhancement Framework).

Im Rahmen dessen fügen Unternehmen ihren kundeneigenen Code (Quelltext-Plug-Ins) als Erweiterung an von SAP vorgegeben und geeigneten Stellen im Quellcode ein.

Die Erweiterungen erfordern – im Vergleich zu den Modifikationen – im Falle eines Upgrades zwar einen deutlich geringeren Aufwand. Aber auch Erweiterungen sollten mit Bedacht genutzt werden. Es gibt keine Garantie für eine Weiterverwendung im Falle eines Releasewechsels.

Darüber hinaus ist es möglich, individuelle Lösungen zu entwickeln, die außerhalb des Standards angesiedelt sind. Diese Eigenentwicklungen werden dann mit den Originalprogrammen verbunden. Experten sprechen von Z-Programmen oder Z-Entwicklungen.

Was sind Erweiterungsoptionen, was Erweiterungsimplementierungen?

SAP unterscheidet bei seinem SAP Erweiterungskonzept zwischen Erweiterungsoptionen und Erweiterungsimplementierungen.

Erweiterungsoptionen sind reine Möglichkeiten der Erweiterung. Sie werden entweder explizit definiert (also als potenziell günstige Orte für Erweiterungen) oder sind bereits implizit vorhanden.

Die impliziten Erweiterungsoptionen existieren an allen Stellen in ABAP-Programmen, die eindeutig beschrieben werden können (also zum Beispiel der Anfang oder das Ende eines bestimmten Abschnitts des Codes).

Erweiterungsimplementierungen hingegen sind die eigentlichen Erweiterungen – also die an einer bestimmten Stelle im Quellcode eingefügten Quelltextfragmente.

Was ist das Enhancement Framework?

Das Enhancement Framework ist ein Werkzeug für Entwickler. Mit diesem Werkzeug können sie die Standard-Software von SAP um eigene Funktionen erweitern.

SAP hat das Enhancement Framework vor allem entwickelt, um die eingangs beschriebenen Erweiterungs- und Modifikationskonzepte teilweise zu integrieren und zu ersetzen. Zudem ist das Framework bereits für neue Technologien wie SAP Fiori geeignet.

Das Framework bietet die Möglichkeit, modifikationsfreie Erweiterungen von Datenobjekten und Prozessen zu realisieren – durch das Hinzufügen von benutzerdefinierten Feldern, kundenindividueller Verarbeitungslogik ebenso wie durch die Erstellung von globalen Klassen und benutzerdefinierten Businessobjekten.

Mit dem SAP Standard deckt SAP bereits die meisten Prozesse und Anforderungen von Unternehmen ab – unter SAP S/4HANA sogar so viele wie nie zuvor. Im Grunde ist dies mit einem Baukasten vergleichbar, der passende Bausteine für alle relevanten Anforderungen bereitstellt.

Implementiert ein Unternehmen SAP S/4HANA im Standard, dann unterscheidet sich das System nicht von Systemen anderer Unternehmen. Im Standard sind alle Systeme gleich.

Häufig ist es aber erforderlich, den Standard um individuelle Lösungen zu erweitern. Dies ist der Fall, wenn bestimmte Anforderungen eines Unternehmens erfüllt werden müssen – etwa dann, wenn ein Unternehmen eine ganz eigene Lösung in der Logistik oder Produktion abbilden muss.

SAP bietet zur Erweiterung des Standards verschiedene Möglichkeiten: die Modifikationen des Quellcodes innerhalb des Originalprogramms, User Exits, Business Addins (BAdIs) oder auch kundeneigene Programmierungen, die Z-Programme.

Wo liegen die Vorteile von Z-Programmen?

Der SAP Standard kann nicht immer alle Anforderungen von Unternehmen erfüllen. Die Z-Programme sind daher eine Möglichkeit, individuelle Anforderungen durch eigene Lösungen abzubilden. So kann jedes SAP-System optimal an die eigenen Bedürfnisse angepasst werden.

Eigenentwicklungen helfen zum Beispiel dabei, bestimmte Prozesse in Unternehmen zu vereinfachen. So können Unternehmen beispielsweise wiederkehrende Aufgaben mit ihrer Hilfe automatisieren.

Warum ist es beim Umstieg auf SAP S/4HANA zeitlich so aufwendig, den kundeneigenen Code zu migrieren?

Gerade die Migration der kundeneigenen Codes kann enorm viel Zeit in Anspruch nehmen. Das liegt allein schon an der großen Menge an Code, die in den meisten Unternehmen vorhanden ist.

Zwei Millionen Zeilen Code – allein so viel eigenen Code hat zum Beispiel jeder SAP-Kunde im Schnitt selbst entwickelt. Dass allein schon der Umzug dieser Datenmengen in ein neues System einen erheblichen Aufwand bedeutet, dürfte daher klar sein.

Und es kommt noch etwas hinzu: Der Code muss vor der Migration noch getestet werden, weil er sonst im neuen System zu Inkonsistenzen führen kann.

Code daher mehr oder weniger ungeprüft zu übernehmen, ist ein Risiko, das die gesamte Migration gefährden kann. Denn Code, der auf alten Systemen reibungslos läuft, muss dies noch lange nicht im neuen SAP-S4/HANA-System tun.

Um den Migrationsaufwand zu reduzieren, lassen sich technische Hilfsmittel nutzen. Code-Scanner eignen sich zum Beispiel dazu, den Code zu testen. Sie suchen den Code automatisch nach Fehlern und Inkonsistenzen ab.

Allerdings entsteht dadurch eine neue Herausforderung, die bewältigt werden muss. Denn die gefundenen Fehlermengen sind oft erheblich – sechsstellige Fehlermengen sind eher die Regel als die Ausnahme.

Reduzieren lässt sich die Menge an Code (und damit auch die Zahl möglicher Fehler) aber allein schon dadurch, dass nicht mehr benötigter Code entfernt wird.

Häufig befindet sich noch Code im System, der mittlerweile obsolet ist: Anwendungen sind längst durch neue Standards ersetzt worden oder gehören zu Testprogrammen, die nur einmalig genutzt wurden.

Wer diesen Code entfernt und sein System grundlegend bereinigt, schafft die Voraussetzung für eine reibungslose Migration. Auf diese Weise ist er auch für künftige Anforderungen besser gerüstet. Klar ist: Je besser die Datenqualität im Ausgangssystem ist, desto besser klappt auch die Migration – es treten weniger Fehler auf und die Qualität der geladenen Daten ist höher.

Was tun beim Wechsel zu S/4HANA? Können Z-Programme übernommen werden?

Wenn ein Unternehmen zu SAP S/4HANA wechselt, können auch Eigenentwicklungen (Transaktionen, Programme, Funktionsbausteine, u. a.) in der Regel mit übernommen werden. Ob dies sinnvoll ist, ist aber eine andere Frage.

Denn zum einen bildet SAP S/4HANA für viele Branchen und Industrien mit seinen SAP-Best-Practice-Standards die meisten relevanten Anforderungen heute bereits ab. Ob eine individuelle Entwicklung noch notwendig oder nicht doch schon verzichtbar geworden ist, muss im Einzelfall analysiert werden.

Im Rahmen einer System Conversion werden Z-Programme auf ihren Anpassungsbedarf an die SAP HANA Datenbank Technologie geprüft.

Zum Beispiel sind Selektionsergebnisse auf SAP HANA Datenbanktabellen per Definition nicht automatisch nach den Schlüsselfeldern sortiert. Werden solche Fehler nicht behoben, kann das unter Umständen zu Folgefehlern in der Verarbeitung der Daten führen. Außerdem werden Konflikte im Abgleich mit der SAP S/4 HANA Simplification List analysiert.

Wenn Unternehmen SAP S/4HANA neu implementieren, haben sie zum anderen die Möglichkeit, ihre individuellen Anforderungen mit Hilfe von Fiori-Apps abzubilden. Dazu stehen bereits Tausende von Apps zur Verfügung. Zudem können eigene Apps entwickelt werden.

Die Erweiterungsmöglichkeiten durch individuelle Apps sind nahezu grenzenlos. Sie machen die Z-Programme heute im Grunde überflüssig.

Hinzu kommt, dass die Migration zu SAP S/4HANA die Möglichkeit bietet, sich von der über Jahre oft sehr komplex gewordenen IT-Landschaft zu trennen und einen Neuanfang mit SAP S/4HANA anzugehen.

Für Unternehmen besteht hier die seltene Chance, sich auf einen Schlag von obsolet gewordenen Daten oder fehlerhaftem Code zu trennen und zu einem schlanken und effizienten System im Standard zu kommen. Häufig werden auch nicht mehr alle im System vorhandenen Z-Programme benötigt. Bei jedem Upgrade können diese aber unter Umständen zu Mehraufwand führen.

Für einen Neuanfang mit SAP S/4HANA müssen Unternehmen die Migration nach dem Greenfield-Ansatz vornehmen. Es handelt sich dabei – anders als beim Brownfield-Ansatz – nicht nur um eine 1:1-Kopie des vorhandenen Systems. SAP S/4HANA wird vielmehr komplett neu aufgesetzt.

Jedes einzelne mit zu SAP S/4HANA übernommene Z-Programm im Rahmen einer System-Conversion (Brownfield) hingegen sorgt für mehr Komplexität und meist einen höheren Wartungsaufwand – und reduziert damit auch den Nutzen, der von SAP S/4HANA ausgeht.