Ein Katalysator für Veränderungen
Dieselbe Umfrage ergab allerdings auch, dass “74 Prozent der DSAG-Mitglieder und 13 Prozent der ASUG-Mitglieder glauben, dass die Einführung Auswirkungen auf die Geschäftsprozesse haben wird”. Es dürfte sich also um eine Transformation handeln, die weit über bloße technische Belange hinausgeht und nach dem Go-live noch lange anhält.
Das ist einer der Gründe, warum viele Firmen ihre S/4-Migration als Anlass nutzen, eingefahrene Ansätze für das Management von SAP-Systemen erneut auf den Prüfstand zu stellen, und sich bei dieser Gelegenheit fragen, wie ein optimaler (oder für das jeweilige Unternehmen optimaler) Ansatz aussehen könnte – angesichts technologischer Entwicklungen, fragmentierter Toolchains und wachsender Ansprüche auf Kundenseite.
In dieser Reihe untersuche ich drei Veränderungen, die von der S/4-Migration forciert oder ermöglicht werden, auch wenn sie aus technischer Sicht keine zwingende Voraussetzung für Erfolg sind.
SAP-Teams nutzen zunehmend moderne Konzepte der Softwareentwicklung. Die Vorteile von CI/CD und DevOps werden weithin anerkannt. In dem Zusammenhang ergab eine neue Google-Umfrage, dass die Branchenbesten neuen Code beeindruckende 6570-mal schneller als die Schlechtesten bereitstellen können. Ähnliche Vorteile lassen sich zweifelsohne auch von SAP-Teams erzielen.
Ein S/4-Transformationsprojekt bietet die ideale Rechtfertigung für das Ausloten neuer Arbeitsweisen – nicht nur, um das Projekt zu beschleunigen, sondern auch, um für größere Agilität und Produktivität zu sorgen, wenn das System erst einmal läuft. Vo-rausschauende Unternehmen beschließen unter Umständen sogar, im Rahmen ihres S/4-Projekts vor dessen Beginn DevOps einzuführen, damit die neue Arbeitsweise bereits verankert ist und wertschöpfend wirksam werden kann, wenn der Umstieg auf S/4 vollzogen wird.
Automatisierung ist die entscheidende Voraussetzung für den Erfolg von DevOps – ganz gleich, ob im Rahmen einer S/4-Transformation oder nicht. In beiden Fällen benötigen Sie eine Automatisierung, die auf die technische Architektur von SAP zugeschnitten ist. Software dieser Art – wie -ActiveControl von Basis Technologies – sollte auch die Flexibilität, Agilität und schlanke Verwaltung bieten, die eine schnelle Reaktion auf sich weiterentwickelnde DevOps-Prozesse ermöglicht.
Vielleicht wichtiger noch: Eine SAP-DevOps-Automatisierung muss bestehende Werkzeugketten miteinander verknüpfen, um den Änderungsprozess im Zuge des Aufbaus und der Optimierung von S/4-Systemen noch stärker vor Verschwendung und Risiken zu schützen. Das können so einfache Dinge wie die automatische Aktualisierung der in Jira oder ServiceNow verwalteten Anforderungen statt ihrer manuellen Neueingabe oder komplexe Vorgänge wie die Integration von SAP in eine orchestrierte und mehrere Anwendungen umfassende Auslieferungspipeline über Produkte wie Jenkins oder GitLab sein.
Die Wertstromanalyse ist in der DevOps-Welt ein brandaktuelles Thema. Es handelt sich dabei um den Prozess des Definierens jedes einzelnen Schrittes, der Teil der Änderungs- und Informationsflüsse ist, die für den gesamten Weg eines Softwareprodukts vom Entwurf bis zur Auslieferung nötig sind. Daher sollte sie bei der Konzipierung Ihrer Software-Auslieferungspipeline ein wichtiger Input sein. DevOps-Automatisierung erleichtert nicht zwangsläufig das Definieren von Wertströmen, spielt aber mit Sicherheit eine zentrale Rolle bei ihrer Steuerung – durch Toolchain-Integration, Orchestrierung der Softwareauslieferung, Über-wachung von KPIs und mehr.
Trotz der potenziellen Vorteile von DevOps für SAP sehen manche Firmen darin einen Zustand, den es zu erreichen gilt, sobald die Herausforderung der S/4-Migration mit ihrer ganzen Komplexität gemeistert wurde. Die agile Entwicklung ist für sie hingegen ein einfacher zu realisierender erster Schritt. In der nächsten Ausgabe untersuche ich, wie die agile Entwicklung SAP-Teams helfen kann.
