Im ersten Teil unserer Blogserie haben wir uns die Unterschiede zwischen Public- und Private-Cloud-ERP-Angeboten angesehen und untersucht, wie sich die verschiedenen SAP Private Cloud-Angebote vergleichen lassen.
In Teil 2 betrachten wir das Change Management in Cloud ERP – insbesondere während der Übergangsphase zwischen bestehenden On-Premises-Systemen und dem Cloud-Ziel.
Die meisten großen Unternehmen werden bei einer Variante von Private Cloud ERP landen. Die häufigsten Gründe dafür hängen mit der Größe und Komplexität der Migrationsprojekte dieser Unternehmen zusammen:
- Oft gibt es mehr als nur ein oder zwei Systemlandschaften zu migrieren
- Häufig gibt es umfangreiche Customizing-Anpassungen, die sich noch nicht einfach aufgeben lassen
- Eine reinrassige Greenfield-Implementierung von Public Cloud auf einem perfekt sauberen Clean Core ist zwar vielleicht das ultimative Ziel, als erster Schritt jedoch unpraktikabel
Der Wechsel in eine Private Cloud bringt jedoch einige Herausforderungen mit sich.
Haben Sie einen Ort, an dem ich mich umziehen könnte?
Haben Sie umfangreiche bestehende Customizing-Anpassungen? Haben Sie umfangreiche externe Integrationen – insbesondere zu anderen On-Premises-Systemen?
Die meisten Migrationen dauern Monate oder sogar Jahre. In dieser Zeit steht der Geschäftsbetrieb nicht still – und SAP Change auch nicht. Wenn es also nicht für die gesamte Projektdauer einen systemweiten Change Freeze gibt, müssen Änderungen im produktiven Business-System (ECC) während des Projekts vor dem Go-live in das neue System (S/4HANA) migriert werden, um funktionale Regressionen zu vermeiden.
Das ist eine typische Change-Management-Herausforderung in komplexen SAP-Umgebungen. Neue Releases, Upgrades und Migrationsprojekte benötigen oft mehr Zeit, als für einen Change Freeze in der Produktion akzeptabel ist. Daher läuft der laufende Business Support parallel zum Projekt weiter. Wenn reguläre Business-Support-Changes nicht sauber in die Projektsysteme integriert werden, werden beim Cutover Regression-Fehler erneut eingeschleppt.
Eine gute Change-Management-Lösung automatisiert einen Großteil dieses Aufwands, verschiebt Changes nahtlos zwischen bestehender Produktions- und Projekt-Systemlandschaft und steuert dabei Nachvollziehbarkeit sowie Compliance-Anforderungen, wenn Transformation oder Redevelopment erforderlich sind. Komplexe SAP-Kunden benötigen Change Management häufig über mehrere Systemlandschaften hinweg, die On-Premises- und Cloud-Umgebungen parallel betreiben – stellen Sie daher sicher, dass Ihr Ansatz diese Anforderung abdeckt.
ABAP-Code aus ECC-Systemen ist häufig kompatibel oder lässt sich leicht anpassen und ist daher mit geeignetem Change-Management-Tooling zwischen ECC und Cloud ERP transportierbar. Einige Changes erfordern jedoch eine komplexere Transformation von ECC nach S/4HANA – oder sogar ein Redevelopment von Core-ABAP hin zu BTP-Lösungen.
In beiden Fällen wird Traceability zum zentralen Thema. Es ist entscheidend, jede Änderung an bestehenden Business-Systemen sauber zu dokumentieren und nachzuverfolgen und sicherzustellen, dass im Migrationsprojekt für das neue System die richtigen Migrations-, Transformations- und Deployment-Schritte durchgeführt werden.
Wenn Ihre SAP-Landschaft mehr als nur ein paar Systemlandschaften umfasst oder Sie eine große Menge an Custom Code und Remediation managen, stellen Sie sicher, dass Sie eine Change-Management-Automation-Lösung im Einsatz haben, die über Legacy und Cloud ERP hinweg kompatibel ist. Manuelles Change Management in einem komplexen Projekt ist eine Einladung zu einem Change-bedingten Ausfall – lassen Sie das.
Change Management ist entscheidend
Mit der richtigen Change-Lösung ist es jetzt an der Zeit, loszulegen und mit der Migration zu starten. Change Management spielt in jedem komplexen ERP-Migrationsprojekt eine Schlüsselrolle – und die besten Automation-Lösungen unterstützen sowohl das laufende Management als auch die finale Auslieferung:
- Alle Customizing-Anpassungen und Migrationen identifizieren und steuern
- Build-Komponenten während des Projekts zwischen Development-, QA- und Staging-Systemen verschieben
- Import-Changes in Pre-Production- und letztlich Produktionsumgebungen stagen, priorisieren und orchestrieren – inklusive korrekter Importreihenfolge, Objektversionen und Abhängigkeiten
- Changes parallel in bestehende und neue Systeme ausliefern und dabei jede Kombination aus BTP, S/4HANA und ECC gleichzeitig aus einer einzigen Sicht unterstützen
- Inkompatible Changes mit Traceability managen und sicherstellen, dass Anpassungen auf der Zielplattform konsistent zur Funktionalität der bestehenden Anpassungen entwickelt werden
- Sicherstellen, dass Änderungen in bestehenden Business-Systemen während des Projekts vor dem Go-live korrekt per Retrofit in das neue System übernommen werden, um Funktions-Regressionen zu verhindern
Prognose: Clouds?
Was passiert, wenn Sie das nicht ernst nehmen? Das größte Risiko ist ein Fehler – falscher Code, alte Versionen, Funktionsverlust im neuen System, Compliance-Probleme und sogar Defekte oder Ausfälle. Selbst bei perfekter Ausführung ist das Management eines so großen Change-Volumens über mehrere Systeme hinweg zeitaufwendig und ineffizient – Automation amortisiert sich.
Eine typische Migration umfasst Tausende von Changes und Transport-Handling-Events. Microsoft Excel kann viele erstaunliche Dinge – SAP Change zu automatisieren gehört nicht dazu. Bei komplexen Changes und großen SAP-Landschaften ist es leicht, Retrofit und das Management der Projekt-Systemlandschaft falsch zu machen. Nehmen Sie diesen Aspekt Ihres Projekts daher ernst.
Die Ruhe vor den Hybrid-Landschaften
In Teil 3 betrachten wir die Herausforderungen und Anforderungen, um Changes über Hybrid-Landschaften hinweg erfolgreich zu managen – genau das, was Sie während des Migrationsprojekts vom heutigen On-Premises-ECC zum Cloud ERP von morgen haben werden. Es wird Sie nicht überraschen: In Standard-Tooling gibt es Lücken. Bleiben Sie dran.
