S/4HANA Migration – The Beginning

Posted on by Enno Wulff

Related Post

Mannomann, jetzt steht hier schon drei Monate lang “Merry Christmas” als letzter Blogeintrag. Sonst fällt es ja nicht so auf, das muss jetzt echt mal geändert werden… Da ich im Tricktresor immer über das schreibe, was mich aktuell beschäftigt, kommt nun ein Beitrag über S/4HANA-Migration. Die letzten Monate haben meine Kollegen und Kolleginnen in verschiedenen S/4HANA-Systemen gearbeitet und viel gelernt. Einige Dinge, die vielleicht theoretisch im Vorfeld klar sind, stellen einen im konkreten Fall eventuell doch vor Fragen und Probleme. Die folgenden Themen sind mir am meisten untergekommen und haben in unterschiedlichen Konstellationen verschiedene Fragen aufgeworfen. In weiteren Beiträgen werde ich auf verschiedene Aspekte eingehen.

Nutzungsanalyse

Grundsätzlich wird bereits in einem ECC-System durch entsprechende S/4HANA-Readiness-Checks geprüft, welche Anweisungen in einem S/4HANA-System problematisch sein können. Hiermit sollte man auch rechtzeitig beginnen, denn in der Regel existiert in einem SAP-System sehr, sehr viel kundeneigenes Coding. Es gilt hier also bereits durch eine Nutzungsanalyse (Transaktion SUSG) herauszubekommen, welches Coding überhaupt verwendet wird und welches nicht. Coding, das nicht mehr benutzt wird, kann weg und frisst keine Ressourcen bei der Anpassung an S/4HANA. Je länger der Zeitraum der Nutzungsanalyse ist, desto sicherer können Sie sein, dass Objekte wirklich nicht genutzt werden. Sinnvoll ist es also, die Nutzungsanalyse auf jeden Fall über den Jahreswechsel hinaus laufen zu lassen. Zudem müssen selbstverständlich Prozesse durchgeführt werden, die eventuell nur selten zum Einsatz kommen, aber trotzdem wichtig sind.

ATC-Check: S4HANA_READINESS

Der Readiness-Check wird mit Hilfe spezieller ATC-Checks durchgeführt. Hier können bereits viele Findings, das sind die Fundstellen, die der ATC-Check findet, im ECC-System gesichtet und gegebenenfalls bearbeitet werden. Im Grunde gibt es bei einem Finding diese fünf Handlungsoptionen:

  1. Kennzeichnung mit einem Pseudo-Kommentar: Verwendung in S/4HANA ok
  2. S/4HANA-konforme Code-Änderung: z.B. SELECT-Zusatz ORDER BY
  3. Im ECC nicht bearbeitbares Coding: Zu verwendendes Objekt erst in S/4HANA verfügbar
  4. Falsch-Positiver Fund: Exemption beantragen
  5. Coding nicht relevant: Löschen

#CI_PSEUDO_COMMENT[123456]

Die meisten Stellen können wahrscheinlich durch einen entsprechenden Pseudo-Kommentar gekennzeichnet werden.

Ein Pseudokommentar besagt, dass der Befehl geprüft wurde und die Verwendung ok ist. Nach dem Pseudo-Kommentar kommt in eckigen Klammern die SAP-Hinweisnummer auf Grund derer die Code-Stelle ermittelt wurde. Das sieht dann zum Beispiel so aus:

CLEAR lv_matnr. "#EC CI_FLDEXT_OK[2215424]

Diese Stelle wird bei einem erneuten Readiness-Check nicht mehr aufgeführt. Hierbei muss man jedoch aufpassen, denn einmal gekennzeichnete Stellen werden natürlich nicht mehr gelistet und sind dann aus dem Fokus. Leider bekommt man einige Erkenntnisse erst, nachdem bereits viele Fundstellen bearbeitet wurden. Auch aus diesem Grund ist es also sinnvoll, sich möglichst früh mit der Umstellung zu beschäftigen.

S/4HANA-konforme Änderung

Einige Findings, wie zum Beispiel ein fehlender ORDER BY bei einem SELECT, können durch eine S/4HANA-konforme Code-Änderung korrigiert werden.

Nicht bearbeitbares Coding

Es gibt viele Anpassungen, die erst in einem S/4HANA-System vorgenommen werden können, da die entsprechenden Objekte erst dort vorhanden sind. Folgend eine unvollständige und beispielhafte Auflistung von typischen Objekten, die in einem ECC-System noch nicht vorhanden sind:

  • Statusfelder, die aus den Tabellen VBUK und VBUP in die Belegtabellen (VBAK, VBAP, LIKP, LIPS, VBRK, VBRP, …) verlegt wurden.
  • KONV-VAKEY
  • VBFA-STUFE
  • Statistische Warennummer STAWN

Diese Findings müssen bestehen bleiben und bearbeitet werden, wenn das SAP-System auf S/4HANA konvertiert wurde.

Ausnahmeregelungen (Exemptions)

Es gibt einige Fälle, bei denen die ATC-Checks nicht korrekt arbeiten oder die man im System für spätere Arbeiten nachhalten möchte. Hierfür sollten Exemptions eingestellt werden, so dass Ausnahmen für Findings beantragt und genehmigt werden können. Einige Findings können zwar auch mit einem Pseudo-Kommentar gekennzeichnet werden, aber eventuell ist es sinnvoller, mit einer Ausnahmeregelung zu arbeiten. Ein großer Nachteil der Pseudo-Kommentare ist aus meiner Sicht, dass sie den Quelltext sehr verunstalten und unleserlicher machen.

Es gibt zum Beispiel einen Check, der auf veraltete Transaktionen prüft. Hier werden Transaktionen wie MK01, VD02, ME51, VAP1 und andere gefunden, die in einem S/4HANA-System nicht mehr verwendet werden können. Allerdings gibt es auch die Transaktionen UPDA oder FORM, die gleichzeitig durchaus als Funktionscodes abgefragt werden können. Der Check interessiert sich nämlich nicht dafür, ob der verwendete Datentyp vom Typ SY-TCODE, TCXODE oder ähnlichen ist und erwischt deswegen auch die beiden genannten durchaus gängigen Bezeichner UPDA und FORM. Man kann diese Fundstelle zwar mit dem Pseudo-Kommentar "#EC CI_USAGE_OK[2223144] unterdrücken, aber schön ist das nicht.

Code löschen

Die einfachste und befriedigendste Möglichkeit, Findungs zu beseitigen ist es natürlich, Objekte zu löschen. In der Regel ist das auch kein Problem, denn wenn sich beim Testen herausstellt, dass bestimmte Programmteile oder Transaktionen doch noch benötigt werden, dann lassen sich diese in der Regel einfach wiederherstellen. Aufpassen muss man natürlich bei Funktionsbausteinen, die unter Umständen auch dynamisch gerufen werden können.

Wenn man etwas sanfter vorgehen möchte, dann kann man die vermeintlich nicht benötigten Objekte in ein Paket schieben, dass man von weiteren ATC-Checks ausschließt, zum Beispiel Z_DELETE oder Z_NOT_FOR_S4HANA. Beim Test sollte dann eine Nutzungsanalyse mitlaufen, die dann auf die Verwendung der entsprechenden Pakete geprüft wird. Die Änderung auf ein produktives Paket ist dann sicherlich einfacher und schneller, als die Wiederherstellung aus einem anderen System. Allerdings sollte man dann im Nachgang die Objekte in diesen Paketen auch wirklich löschen.

Fazit

Eine S/4HANA-Umstellung ist nervig, kompliziert, aufreibend, teuer, zeitaufwändig und ressourcenintensiv. Leider ist dies jedoch notwendig, wenn man sicherstellen möchte, dass die Geschäftsprozesse auch in einem S/4HANA-System reibungslos laufen.

Eine S/4HANA-Umstellung bietet viele Möglichkeiten, uraltes Coding loszuwerden und technische Schulden aufzuräumen, die sich über Jahre oder vielleicht sogar Jahrzehnte angehäuft haben. Leider ist die Aufgabe weiterhin mühselig und aufwändig. Wenn man auch nicht jedes kleine Programm genau unter die Lupe nehmen kann, sollte man das auf jeden Fall für zentrale und wichtige Applikationen tun. Denn nicht nur technische Schulden sind problematisch, sondern auch schwierige Wartbarkeit aufgrund schlecht programmierter Programme.

Wenn du Hilfe bei der Umstellung auf S/4HANA benötigst, dann wende dich gerne an Inwerken:

Enno Wulff
Letzte Artikel von Enno Wulff (Alle anzeigen)