SAP S/4HANA-Upgrades ohne Code-Freeze in der Produktionsumgebung
Viele SAP-Kunden verwenden immer noch Releases und Service-Packs für ECC, die weitaus älter sind als die aktuellen Versionen. Zu den Zeiten dieser Releases liefen dazu passende Supportangebote nicht so schnell aus. Und außerdem gab und gibt es ja Optionen wie die Wartung durch Drittanbieter oder änderungsstabile Systeme. Uralter Code funktioniert immer noch, irgendwie.
Für die meisten S/4-Kunden sind solche Altsysteme jedoch kein akzeptabler Ansatz.
Bei S/4 ist die Geschwindigkeit, mit der neue Releases eingeführt werden und Supportangebote auslaufen, wesentlich höher. S/4-Instanzen befinden sich mittlerweile häufig in der Cloud oder sind sogar über Integrationen mit einem öffentlichen Front-End zugänglich, was Sicherheits- und Funktionspatches noch wichtiger macht. S/4-Kunden wissen, dass es besser ist, immer auf dem aktuellen Stand zu sein.
Der etwas veraltete Ansatz für Upgrades – das Einfrieren von Änderungen (Code-Freeze) in der Produktionsumgebung – ist heute nicht mehr zeitgemäß. Der laufende Betrieb toleriert keine Ausfallzeiten mehr, vor allem angesichts der immer häufiger erfolgenden Upgrades. Und schließlich verbringt niemand gerne seine Wochenenden bei Cutovers im Büro. Wegen eines Upgrades die Produktion zu stoppen, ist für die meisten Unternehmen keine gangbare Option: Bei Rund-um-die-Uhr-Schichtbetrieb stellt jede Änderung eine beträchtliche Herausforderung dar. Doch auch für Unternehmen, die mit geplanten Stillstandzeiten leben können, sind umfangreiche oder komplexe Upgrade-Projekte zumeist nicht praktikabel.
SAPs integrierter Ansatz für parallel durchgeführte Änderungen – bekannt als Projektlandschaft, Parallel Track oder N+1 – kann umständlich und bisweilen riskant sein. Insbesondere dann, wenn während eines Upgrade-Projekts Änderungen an Produktionslandschaften vorgenommen werden. Zu verhindern, dass beim Cutover versehentlich eine veraltete Software eingeführt wird, wird zu einem manuellen Excel-Alptraum zwischen Bangen und Hoffen.
Aber das muss nicht sein.
Was, wenn sich Upgrades über Wochen oder Monate erstrecken könnten, ohne dazu allerdings Änderungen an der Produktionsumgebung einfrieren zu müssen? Dadurch hätten die Teams Zeit für umfangreiche Analysen, Tests und das Planen des Cutovers auf eine Produktionsumgebung, ohne jedoch den Regelbetrieb für die Dauer eines Upgrades einfrieren zu müssen.
Der parallele Ansatz geriet bei einigen Unternehmen in Verruf, weil er zu Konflikten zwischen den Projekt- und Produktionssystemen führen kann, wenn aufgrund von Geschäftsanforderungen in beiden Landschaften Änderungen an den gleichen Objekten vorgenommen werden müssen. Um dieses Problem zu entschärfen, hat SAP die systemübergreifende Objektsperre eingeführt; diese verschärft jedoch das Problem eigentlich nur, weil sie in erster Linie den eigentlichen Zweck der Projektlandschaft untergräbt: Die Möglichkeit paralleler Änderungen!
Wenn man die Probleme der Bestandstools rund um SAP einmal außen vorlässt, sind die Vorteile des parallelen Ansatzes so zahlreich wie offensichtlich: Projekt- und Wartungsbetrieb laufen nebeneinander, ohne sich gegenseitig zu stören. Es ist völlig unerheblich, wie viel Zeit das Projekt in Anspruch nimmt, weil Produktionsänderungen und Verfügbarkeit nicht beeinträchtigt werden. Auf diese Weise lassen sich in der Mehrzahl der Fälle geplante Stillstandszeiten und Übergangszeiten gänzlich vermeiden, weil die neue Umgebung vor dem Go-Live vollständig bereitgestellt und getestet werden kann. Mit einem Code-Freeze Ansatz wäre das kaum möglich.
Was, wenn es die richtigen Tools gäbe, um die Herausforderungen eines zweigleisigen Ansatzes zu bewältigen? Wenn Änderungen zwischen Produktions- und Projektlandschaft automatisch miteinander abgeglichen werden könnten, dann wären die Horrorgeschichten von Excel-Arbeitsblättern voller Objekt- und Programmnamen nur noch vage Erinnerungen. Die Synchronisation der Produktions- und Upgrade-Systeme während eines Upgrade-Projekts würde automatisiert ablaufen; Konflikte oder Risiken würden so automatisch erkannt und Änderungen, Konflikterkennung und automatisiertes Retrofit auf beiden Systemen kontinuierlich sichergestellt werden.
Wenn Ihnen die Vorstellung einfacher und risikoarmer Upgrades zusagt, sehen Sie sich ActiveControl von Basis Technologies an. Mit den richtigen Tools sind vollständig parallele Projekte mit vollautomatischer Retrofit- und Konflikterkennung auch für SAP schon jetzt möglich. Wenn Sie für Ihr nächstes Upgrade mehr Informationen zu diesem Ansatz benötigen, kontaktieren Sie uns hier für eine Demo oder Entdeckungstour.
