Umgang mit benutzerdefiniertem Code

In den ersten zwei Teilen dieser Blogreihe habe ich mich mit folgenden Aspekten bei der Einführung von S/4HANA befasst:

• Teil 1 – Definieren eines ganzheitlichen Ansatzes für Ihr Unternehmen
• Teil 2 – Vermeiden eines Moratoriums/Änderungsstopps

In diesem letzten Teil spreche ich über den Umgang mit benutzerdefiniertem Code und die Entwicklung und Bereitstellung von Änderungen in der S/4-Landschaft.

Benutzerdefinierter SAP-Code

SAP ist in vielen Bereichen marktführend, da sich die Lösungen flexibel und relativ einfach erweitern oder an die Anforderungen der einzelnen Kunden anpassen lassen. Ermöglicht wurde dies durch die integrierte Programmiersprache ABAP. Bei vielen der weltweit größten SAP-Kunden wurden zehn- oder hunderttausende benutzerdefinierter Objekte angelegt und Millionen von Zeilen mit benutzerdefiniertem Code geschrieben.

Dies hat sich jedoch als zweischneidiges Schwert erwiesen. Bei ihrem Wechsel zu S/4 stehen die Kunden heute vor einer großen Herausforderung, da der benutzerdefinierte Code, der während der ersten Bereitstellung und laufender kontinuierlicher Verbesserungen erforderlich war, zu einer der größten Hürden für eine einfache S/4-Transformation geworden ist.

Der benutzerdefinierte Code könnte sogar ein Schlüsselfaktor bei der Entscheidung sein, welcher Transformationsansatz für die jeweilige Kundenlandschaft der richtige ist. Große Mengen an relevantem benutzerdefinierten Code, wegen dem der Kunde seine Geschäftsprozesse nicht umstellen oder zu den Standardeinstellungen zurückkehren möchte, wären ein Grund, sich für den Brownfield- oder Hybrid-Ansatz zu entscheiden (Weitere Informationen hierzu finden Sie in Teil 1 dieser Reihe). Umgekehrt könnten eine große Menge an fehleranfälligem benutzerdefinierten Code mit schlechter Dokumentation und der damit verbundene Wissensverlust Gründe dafür sein, noch einmal neu anzufangen und den Greenfield-Ansatz zu wählen, mit dem Ziel, wo immer möglich, die SAP-Best-Practices anzuwenden.

SAP ist sich der Bedeutung von benutzerdefiniertem Code und der Tatsache bewusst, dass er häufig eine Hürde für die Einführung von S/4 ist. Daher umfasst das Angebot von SAP verschiedene Werkzeuge, mit denen Kunden ermitteln können, was benutzerdefinierter Code ist, ob er verwendet wird (wenn ja, wie häufig und von wem), ob die Qualität stimmt und ob er auch in der SAP-S/4HANA-Landschaft funktioniert.

Umgang mit benutzerdefiniertem Code

Wenn Sie den Ansatz für Ihre Landschaft ausgewählt haben, müssen Sie entscheiden, wie Sie mit benutzerdefiniertem Code umgehen. Wenn Sie mit dem Greenfield-Ansatz arbeiten, ist es häufig am einfachsten und kostengünstigsten nach dem Motto zu arbeiten: „Was nicht kaputt ist, muss auch nicht repariert werden“. Ignorieren Sie diesen Code im ECC-System oder überarbeiten/bereinigen Sie nur die kundenspezifischen Lösungen, die gepflegt werden müssen. Sie können in das neue S/4-Entwicklungssystem übertragen werden.

Wenn Sie jedoch eine Umstellung gemäß Brownfield- oder Hybrid-Ansatz (basierend auf der Anlage einer Shell) planen, dann müssen Sie Ihren benutzerdefinierten Code kennen und bereinigen. Mit bereinigen meine ich das Entfernen von nicht benötigtem Code. Die meisten Unternehmen verwenden nur < 40 % des von ihnen erstellten Codes und selbst dann kann es noch Codeteile geben, die nicht mehr relevant sind.

Wenn Sie eine Shell anlegen, können Sie die Bereinigung im neuen Shell-System durchführen. Beim Brownfield-Ansatz muss sie jedoch in der aktuellen Landschaft erfolgen, wobei zumindest die nicht mehr benötigten Objekte entfernt werden sollten. Hier gilt: je früher, desto besser. Dies könnte Monate dauern und wird Ihre S/4-Transformation verzögern, daher ist es am besten, wenn Sie möglichst früh damit beginnen.

Erfolgreiche Umsetzung in S/4

Um ein funktionierendes S/4-System mit benutzerdefiniertem Code zu erhalten, der ursprünglich für das ECC-System entwickelt und geschrieben wurde, müssen Sie drei Aspekte bei Ihrem Transformationsprojekt berücksichtigen, unabhängig von der Herangehensweise und der Menge an benutzerdefiniertem Code, der übernommen werden soll.

Funktionen – Sie müssen sicherstellen, dass der benutzerdefinierte Code weiterhin mit dem Kernsystem funktioniert und nicht durch Änderungen an der Lösung, die SAP in der SAP S/4HANA Simplification List dokumentiert, beeinträchtigt wurde. Funktionale Änderungen können nicht automatisiert durchgeführt werden und müssen analysiert werden, um sie unter Berücksichtigung ihres ursprünglichen Zwecks und den Funktionen des neuen Systems für diesen Prozess anzupassen.

Technologie – HANA selbst ist eine der offensichtlicheren erforderlichen technischen Änderungen. Wenn Native SQL verwendet wurde oder aufgrund der Antwort der DB eine bestimmte Reihenfolge angenommen wird, können Änderungen erforderlich sein.

Performance – Um von den Vorteilen einer Ausführung auf einer In-Memory-Datenbank zu profitieren, kann der Code neu geschrieben oder angepasst werden. Dann können einige der Funktionen auf DB-Ebene ausgeführt werden (Code-Pushdown), damit das volle Potenzial der neuen Plattform ausgeschöpft wird.

Weitere Informationen finden Sie in diesem SAP-Blogbeitrag.

Abhängig von der Menge an benutzerdefiniertem Code, den Auswirkungen der Vereinfachungsdatenbank und dem gewählten Ansatz könnte der Arbeitsaufwand für die Anpassung des benutzerdefinierten Codes sehr umfangreich ausfallen. Zum Glück gibt es Dienste, die dies erheblich beschleunigen/automatisieren können, wie smartShift. Für eine Fehlerbehebung bei benutzerdefiniertem Code, für eine aufwendige duale Wartung und bei einer hohen Anzahl an Änderungen benötigen Sie eine Automatisierungslösung für die Änderungskontrolle und Governance wie ActiveControl von Basis Technologies. ActiveControl kann mit smartDeploy von smartShift integriert werden, um ECC-Code und korrigierten S/4-Code während der S/4-Transformation zusammenzuführen.

Komplexität und Umfang der zukünftigen S/4-Landschaft

Meiner Meinung nach werden die nachfolgend beschriebenen Treiber in zukünftigen S/4-Landschaften eine Rolle spielen. Durch sie steigt die Anzahl an Veränderungen, die entsprechend für mehr Mitarbeiter verwaltet werden müssen. Dies wiederum führt zu einem erhöhten Orchestrierungsbedarf.

SAP veröffentlicht immer schneller Updates für SAP S/4HANA. Aufgrund der jährlichen Releases (1511, 1610, 1709, 1809, 1909, …) und halbjährlichen Feature Pack Stacks (FPS) sind effiziente Aktualisierungsprozesse und aktuelle Versionen für die Kunden wichtiger denn je. Eventuell müssen Sie sogar ein Upgrade während Ihrer S/4-Migration in Erwägung ziehen.

Die Verwendung aktueller Versionen sorgt auch dafür, dass sich die Menge an benutzerdefiniertem Code reduziert, da SAP hoffentlich neue S/4-Funktionen so entwickelt, dass keine kundenspezifischen Lösungen mehr geschrieben werden müssen.

Agilität wird in zukünftigen S/4-Systemen trotz der steigenden Anzahl an Änderungen und eines höheren Geschäftsrisikos durch mangelhafte Änderungen kontinuierlich an Bedeutung gewinnen.

Hier könnten automatisierte Regressionstests ein Schlüsselfaktor sein, um möglichst effizient auf dem aktuellen Stand zu bleiben. Basis Technologies stellt hierfür eine Lösung bereit: Testimony. Wenn Sie sich für die Auslieferung schneller, kontinuierlicher und sicherer SAP-Änderungen und -Releases interessieren, fordern Sie eine kostenlose Demonstration an, um mehr darüber zu erfahren, wie unsere Software Ihnen dabei helfen kann.

Fazit

Ich hoffe, diese Blogreihe hat relevante Informationen für Sie enthalten. Bei Fragen oder Anmerkungen stehe ich Ihnen gerne zur Verfügung. Wenn Sie Ihre spezifischen Pläne und Herausforderungen rund um Ihren Wechsel zu S/4 besprechen oder erfahren möchten, wie unsere Lösungen Ihren Umstieg und laufende Prozesse unterstützen können, senden Sie eine Kontaktanfrage.