Laut des kürzlich erschienenen DSAG-Investitionsreports planen in den nächsten Jahren bis zu 80 Prozent der Unternehmen, ihre SAP-Systeme auf S/4HANA umzustellen. Ein sportliches Unterfangen, das ist sicher. Um den internen Aufwand zu minimieren, empfiehlt sich daher, bereits vor der Migration Altlasten loszuwerden, die beispielsweise in Form von ABAP-Eigenentwicklungen daherkommen.

Das folgende Interview zwischen Helge Sanden (Chefredakteur IT-Onlinemagazin) und Patrick Boch (Produktmanager SAST SOLUTIONS) ist erstmals am 10. Januar 2019 im IT-Onlinemagazin erschienen.

Beim Umstieg auf S/4HANA muss der eigene ABAP-Code aufgeräumt werden. Scannt man den ABAP-Code auf herkömmlichem Weg, können dabei hunderttausend Findings und Bereinigungszeiten von mehreren tausend Tagen herauskommen – mehr als das ganze Erwerbsleben eines Entwicklers.

Von Patrick Boch (Produktmanager SAST SOLUTIONS bei der akquinet AG) wollte ich wissen, wie man die Migrationszeit für Custom Code auf ein realistisches Pensum reduzieren kann und wie trotz Änderungen im produktiven Code der operative Betrieb nicht eingeschränkt wird.

Herr Boch, warum ist die Migration der Custom-Codes eine zeitliche Herausforderung beim S/4HANA-Umstieg?

Die erste Herausforderung, vor der Unternehmen beim Umstieg auf S/4HANA stehen ist die schiere Masse des Codings. Im Schnitt haben SAP-Kunden 2 Millionen Zeilen eigenen Code entwickelt! Diesen auf eine neue Plattform zu hieven bedeutet einen enormen Aufwand – der zusätzlich zum Aufwand anfällt, den Unternehmen sowieso betreiben müssen, um auf HANA umzusteigen. Die Versuchung, den Code mehr oder weniger ungeprüft in S/4HANA zu integrieren, ist da natürlich groß.

Damit steht dann auch die zweite Herausforderung fest: Code, der auf „alten“ NetWeaver-Systemen läuft, funktioniert nicht unbedingt reibungslos auf S/4HANA. Das heißt, es ist zwingend notwendig, diesen Code zu testen.

Unserer Erfahrung nach ist das Testen von Code – egal ob bei einer Migration oder im „normalen“ Entwicklungsumfeld – immer das, was die meiste Zeit beansprucht. Und diese Zeit haben die Unternehmen in S/4 Migrations-Projekten meist nicht.

Welche Ansätze gibt es, den Aufwand zu reduzieren?

Unternehmen tun gut daran, den Code vor der Migration zu überprüfen. Bei den eingangs genannten Mengen sollte man dazu einen Code-Scanner verwenden. Der Aufwand dafür ist zwar überschaubar, im Ergebnis werden aber eine Menge Fehler im Code auftauchen – sechststellige Fehlermengen sind hier keine Seltenheit, sondern im Gegenteil eher die Regel.

Diese Fehlermengen sinnvoll zu reduzieren ist dann die Herausforderung, dies es zu bewältigen gibt. Dazu gibt es verschiedene Thematiken, die wir in unserem Webinar auch ansprechen werden. Um nur ein Beispiel zu nennen: Unserer Erfahrung nach sind 60-90% des kundeneigenen Codings obsolet. Das beinhaltet Anwendungen, die vor Jahren entwickelt wurden und inzwischen durch den SAP-Standard oder geänderte Prozesse ersetzt worden sind, oder aber Programme, die für einen einmaligen Einsatz oder im Zuge von Entwicklungstests entstanden sind und ebenfalls nicht mehr benötigt werden. Dieses Coding sollten Kunden gar nicht erst zu S/4 migrieren.

Welche Umstellungszeiten sind erreichbar?

Gerade bei Projekten, bei denen Code „aufgeräumt“ werden muss, sind die Projektzeiten stark kundenabhängig, eine Pauschalisierung kann man hier also nur bedingt treffen.

Verbindet man aber einen durchdachten Projektplan mit den Ansätzen zur Reduzierung des Aufwandes, wie beispielsweise das eben erwähnte Deaktivieren von obsoletem Code, können bis zu 75% des Aufwandes eingespart werden.

Was muss man beachten, um gleichzeitig den operativen Betrieb sicherzustellen?

Das Problem ist, wie schon erwähnt, der enorme Testaufwand, der eingeplant werden muss, um sicherzugehen, dass der kundeneigene Code tatsächlich wie geplant funktioniert. Und, ganz wichtig: Kunden sollten sich nicht nur auf funktionale Tests beschränken, das Thema „sicherer“ Code sollte mindestens mit gleicher Priorität behandelt werden. Gerade in einem System wie S/4HANA, das mit vielen weiteren Systemen verbunden wird und oft sogar aus dem öffentlichen Internet erreichbar ist, muss die Sicherheit des eigenen Codes unbedingt gewährleistet sein.

Die traditionelle Herangehensweise mit umfangreichen Testszenarien birgt dabei zwei Probleme: erstens werden viele Ressourcen gebunden. Zweitens wird man in solchen Testszenarien nicht jede Eventualität abdecken können.

Wir haben daher einen alternativen Ansatz gewählt, bei dem wir das alte Coding auf Knopfdruck wieder „zuschalten“ können, wenn Probleme auftauchen. Der große Vorteil dieses Ansatzes ist, dass die Testphase quasi komplett entfällt und der operative Betrieb zu keiner Zeit eingeschränkt ist.

Mit einem Satz ausgedrückt: Was wird für Sie in den kommenden 12 Monaten das dominierende Thema in der SAP-Community?

Wir haben in den letzten Monaten schon ein großes Kundeninteresse zum Thema S/4 Migration erlebt. Zwar deutet sich an, dass die Cloud mittelfristig zu einem der größten, wenn nicht dem größten, Thema im SAP-Umfeld wird, aber für die nächsten 12 Monate wird die S/4 Migration die meisten Kunden beschäftigen.

Vielen Dank für das Gespräch.

Die Fragen stellte Helge Sanden, Chefredakteur des IT-Onlinemagazins.

TIPP: Sie wollen noch tiefer in das Thema einsteigen? Dann empfehlen wir Ihnen das Webinar zum Thema, welches im Rahmen der IT-Onlinekonferenz des IT-Onlinemagazins stattgefunden hat. Den Link zur Webinaraufzeichnung können Sie hier anfordern: Webinaraufzeichnung „Wie migriert man SAP Custom Code schnell nach S/4HANA?“

Patrick Boch (Produktmanager SAST SOLUTIONS)

Helge Sanden (Chefredakteur IT-Onlinemagazin)

 

Verwandte Beiträge im SAST BLOG

SAP Security 2018: Zwischen Plattformsicherheit, Berechtigungsmanagement und S/4 HANA-Migration.

Hängen Sie an Ihren ABAP-Sicherheitslücken oder können die weg?