Kompatibilität und Performance bei der Migration
Vermutlich gibt es kein einziges Unternehmen, das SAP einsetzt und die Software nicht mindestens um eine Eigenentwicklung ergänzt hat. Zumindest haben wir das noch nie erlebt. Fast immer erleben wir dagegen eine ziemliche unübersichtliche Situation: Über die Jahre sind als Erweiterung zu SAP ERP hunderte, manchmal tausende Eigenentwicklungen für alle möglichen Zwecke entstanden.
Im Schnitt sitzen SAP-Kunden auf zwei Millionen Zeilen mehr oder weniger sinnvollen ABAP-Code. Denn fast immer wird nur ein Teil der Eigenentwicklungen nach wie vor regelmäßig genutzt. Viele Eigenentwicklungen werden aber schon längst nicht mehr benötigt und verstauben auf den Servern. Ähnlich sieht es übrigens auch bei den Daten aus: Der aktuellen Studie „Rethink Data: Bessere Nutzung von mehr Unternehmensdaten“ des Festplattenherstellers Seagate Technology zufolge ist lediglich ein Drittel der zur Verfügung stehenden Daten in Unternehmen tatsächlich in Verwendung – der Rest liegt brach.
Das war für manche IT-Abteilungen in der Vergangenheit vielleicht ein Ärgernis. Der Wildwuchs war aber kein richtiges Problem. Das ändert sich jetzt im Zuge des Umstiegs von SAP ERP auf SAP S/4 HANA. Denn damit stellt sich unweigerlich die Frage, was mit den ganzen Eigenentwicklungen passiert. Wer das fundiert beantworten will, muss zunächst einmal sämtliche Entwicklungen sichten und beurteilen. Angesichts der schieren Menge ist das eine Mammut-Aufgabe. Da ist die Versuchung groß, den Customer Code einfach komplett zu übernehmen. Was allerdings ein Fehler wäre: Denn die Gefahr ist groß, dass die Eigenentwicklungen nach dem Wechsel nicht mehr systemkonform sind – also nicht korrekt auf die Daten zugreifen oder gar nicht mehr funktionieren.
IT-Abteilungen stehen damit vor einem Dilemma: Sie sollten sinnvollerweise die Eigenentwicklungen vor der Migration kritisch überprüfen. Und zwar aus technischer sowie aus prozessualer Sicht. Das kostet Zeit. Und diese Zeit haben sie eigentlich nicht, weil sie voll und ganz mit der eigentlichen Transformation beschäftigt sind.
Eigenentwicklungen: Analysieren, löschen und anpassen
Eine mögliche Lösung ist, Unterstützung von einem externen Dienstleister bei der Validierung der Eigenentwicklungen in Anspruch zu nehmen. Wir haben dafür ein systematisches Vorgehen entwickelt, das unterschiedliche Tools nutzt und den Aufwand so minimiert: Zu Beginn können Unternehmen mit dem kostenlosen und Cloud-basierten SAP Readiness Check ihr SAP-System analysieren.
Damit finden sie nicht nur heraus, wie gut sich die IT-Architektur bereits für die Transformation eignet. Es werden auch alle Custom-Code-Erweiterungen identifiziert und hinsichtlich ihrer Kompatibilität mit SAP S/4HANA bewertet. Mit dem ABAP-Code-Check im ABAP Test Cockpit (ATC) lässt sich im Anschluss analysieren, inwiefern Eigenentwicklungen, User Exits, Enhancements und Modifikationen vor der Konvertierung angepasst werden müssen – beispielsweise mit Blick auf die Performance. Auch wenn technologisch damit bereits alles klar ist – durchschnittlich werden 60 Prozent der individuellen Erweiterungen nie ausgeführt. Es lohnt sich deshalb, die nicht mehr benötigten Eigenentwicklungen ausfindig zu machen und dann vor der Transformation zu entfernen. Bei der Beurteilung hilft der ABAP Call Monitor, der Nutzerdaten erfasst und daraus ableitet, wie häufig eine Eigenentwicklung im Einsatz war.
Wichtig dabei: Das Monitoring sollte über einen längeren Zeitraum laufen, um aussagekräftige Informationen zu erhalten. Relevante Codes können nach dem Monitoring mithilfe des ABAP Development Tools ABAP Quick Fixes automatisiert angepasst werden. Eigenentwicklungen, die nie oder nur selten verwendeten werden, lassen sich mit der Fiori-App Custom Code Migration einfach entfernen.
Neue Prozesse und neue Funktionen
Mit der oben beschriebenen Vorgehensweise wird jedoch lediglich die Ist-Situation im bestehenden System beurteilt. Mit dem Umstieg auf SAP S/4HANA stehen aber zum einen neue Funktionen bereit. Dadurch können Eigenentwicklungen, die unter SAP ERP regelmäßig genutzt wurden, unter den S/4HANA-Standard obsolet werden. Zum anderen werden im Rahmen der Transformationen auch Prozesse angepasst (die Einführung von SAP S/4HANA ist eben bei Weitem nicht nur ein technologisches Projekt, sondern vor allem ein strategisches). Eigenentwicklungen, die für die bestehenden Prozesse wichtig waren, spielen für die neuen Prozesse eventuell keine Rolle mehr.
Bei der Erarbeitung und Lösung der genannten Fragestellungen können Sie sich auf erfahrene Beraterinnen und Berater der UNIORG Gruppe verlassen. Diese haben bereits etliche Projekte im SAP-Umfeld erfolgreich abgeschlossen und kennen sämtliche Tücken dieser Technologie. Damit stellt UNIORG sicher, dass die Systeme für eine Umstellung auf SAP S/4HANA bestens vorbereitet sind und reibungslos laufen, während sich die IT-Abteilung um strategische Aufgaben kümmern kann.
