Transformation auf SAP S/4 Hana: Agilität braucht Automatisierung
Kein Thema beschäftigt die SAP-Abteilungen zurzeit mehr als der Umstieg auf SAP S/4 Hana: Sollen Daten, Prozesse und Customizing unverändert in die neue Welt übernommen werden?
Oder lässt sich mit der Einführung ein Neustart auf der grünen Wiese wagen? Und welche der vielen Abstufungen zwischen den beiden extremen Ansätzen Brownfield und Greenfield passt zur jeweiligen Kundensituation am besten?
Einfache Antworten auf diese grundsätzlichen Fragen gibt es nicht. Schließlich haben die Unternehmen viel Zeit und Geld in das Customizing investiert. Zudem sind sie aus geschäftlichen Gründen auf Funktionalitäten angewiesen, die erst mit den kommenden S/4-Versionen verfügbar sein werden.
Viele SAP-Bestandskunden werden den Weg in die neue Welt daher wohl schrittweise vollziehen: zuerst ihre verschiedenen SAP-ERP/ECC-6.0-Systeme konsolidieren, dann auf die Hana-Datenbank umstellen und schließlich erste S/4-Anwendungen implementieren.
Als Folge davon werden sie beide Softwaregenerationen parallel betreiben. Bei dieser „Dual Maintenance“ müssen SAP-Teams Änderungen und Innovationen für beide Welten entwickeln, testen und implementieren sowie Updates in beiden Umgebungen einspielen.
Außerdem sind die Templates für die SAP-ERP/ECC- wie S/4-Systeme zu schützen und zu pflegen, um Schwierigkeiten durch unterschiedliche Änderungen an ein und derselben Konfiguration in beiden Welten zu vermeiden.
Damit diese Komplexität nicht zulasten der Agilität geht, prüfen SAP-Manager verstärkt die Umstellung ihrer Prozesse auf DevOps. Zu deutlich sind die damit verbundenen Vorteile, durch die enge Verzahnung von Entwicklung und Betrieb schneller auf die Anforderungen des Geschäfts reagieren und Innovationen bereitstellen zu können.
Gerade bei großen Projekten wie der Einführung von SAP S/4 darf jedoch nichts schiefgehen, müssen Systemstillstände und damit Geschäftsausfälle unter allen Umständen vermieden werden.
Kontrolle versus Risiko – vor diese Wahl gestellt halten noch immer zahlreiche SAP-Manager am bewährten Wasserfallmodell fest. Und das, obwohl sie das DevOps-Konzept nicht per se infrage stellen und auch SAP viel dazu beiträgt, um ihre Kunden von den DevOps-Vorzügen zu überzeugen.
So werden bereits seit 2010 agile Methoden im SAP SolMan unterstützt und bilden seit 2015 den Kern von SAP Activate, der Einführungsmethodik für S/4. Speziell bei der Implementierung der Anforderungen sieht SAP Activate eine Umsetzung nach dem Vorbild der agilen Vorgehensweise Scrum in kurzen, iterativen Zyklen – sogenannten Sprints – durch kleine, schlagkräftige und interdisziplinäre Teams von Entwicklern, Administratoren und Qualitätsmanagern vor.
Um das Komplexitätsproblem auf dem Weg hin zu S/4 in den Griff zu bekommen und vom Wasserfallmodell auf modernere Methoden wie SAP Activate oder ganz auf DevOps umzusteigen, liegt die Lösung für SAP-Teams in der Automatisierung.
Davon profitieren nicht nur die Entwicklungs- und Delivery-, sondern auch die Testprozesse. Das gilt gleichermaßen für das Testen neuer Funktionen im Rahmen der Migration wie für Regressionstests bestehender Prozesse in SAP ECC.
Wegen der Größe und Komplexität alter wie neuer SAP-Umgebungen lassen sich derart umfassende Testverfahren nur mittels Automatisierung realisieren. Umgekehrt gilt: Erfolgen Transporte und Änderungen manuell und mit hoher Schlagzahl, ist das kontinuierliche Integrieren und Bereitstellen mit Risiken verbunden.
In der Tat schafft in SAP-Landschaften nur die Automatisierung das nötige Vertrauen in DevOps. Und je höher der Automatisierungsgrad bei Continuous Delivery, Continuous Integration und Continuous Testing, desto schneller gelingt die Migration und Transformation auf S/4.
Damit die SAP-Verantwortlichen auf diesem Weg nicht mehr wählen müssen zwischen Kontrolle und Risiko, ist folglich eine integrierte und hochautomatisierte Tool Chain für alle Phasen der Migration inklusive Dual Maintenance erforderlich.
