In einem weit entfernten Land da begab es sich einst, dass ein SAP-Basis-Team eine sehr große Kalkulationstabelle hatte und ein sehr großes Projekt ausliefern sollte …

Es steht ein großes SAP-Projekt an. Es könnte etwas Technisches sein, etwa ein Release Wechsel. Oder vielleicht steht eine große betriebliche Veränderung an, etwa die Aufteilung eines Geschäftsbereichs. Oder vielleicht ist es auch nun an der Zeit, in den sauren Apfel zu beißen und endlich mit der Umstellung auf S/4HANA zu beginnen.

Aber das herkömmliche Änderungsmanagement ist bereits schwierig. Selbst ohne die Komplexität eines Großprojekts gibt es in der Regel eine große Kalkulationstabelle, die festlegt, was wo, wann und in welcher Reihenfolge geändert werden muss. Und die Pflege dieser Tabelle ist alles andere als schnell oder einfach zu erledigen. Selbst alltägliche Änderungen risikolos in die Produktion zu überführen, ist mit viel Arbeit verbunden.

Das stellt Ihr SAP-Team vor ein Dilemma, wenn es um die Durchführung eines Großprojekts geht.

Wir brauchen eine größere Tabelle…

Manche Projekte lassen sich einfach nicht in einer traditionellen, eingleisigen Landschaft verwalten. Technische Upgrades und sogar einige Großprojekte erfordern ein separates Entwicklungssystem, damit Sie die Möglichkeit haben, kritische Korrekturen oder SAP-Hinweise von einem System aus anzuwenden, das sich auf der gleichen Ebene wie die Produktion befindet. Weitreichende Änderungen an Stammdaten oder der Konfiguration können ebenfalls getrennte Entwicklungs- und Testsysteme erforderlich machen. Solche Situationen führen zu einem zweigleisigen bzw. N+1-Szenario.

Auch wenn dies logisch und manchmal sogar notwendig ist, stellen zweigleisige Landschaften eine neue Herausforderung dar, auch wenn sie nur vorübergehend sind. Jetzt müssen wir die beiden Landschaften so aufeinander abstimmen, dass der Projektübergang (Cutover) nicht Monate oder Jahre angesammelter anderer Änderungen zunichte macht, mit allen damit verbundenen Unterbrechungen, die sich daraus ergeben würden. Ein Ansatz zur Minimierung des Risikos oder der Komplexität wäre die Einführung eines Änderungsstopp (auch bekannt als “Change Freeze”), das die Änderungen in der projektfremden Landschaft auf ein Minimum beschränkt, bis Ihr Projekt abgeschlossen ist. Natürlich ist dies heutzutage etwas, was die meisten Unternehmen nicht dulden oder akzeptieren können, vor allem, wenn das Projekt Monate oder sogar Jahre dauern wird.

Was können Sie also tun? Wie kann dieser zweigleisige Abgleich gehandhabt werden?

Nun, die große Tabellenkalkulation kann natürlich helfen. Aber sie wird noch größer und komplizierter werden müssen. Die Organisation wird mehr Zeit in Anspruch nehmen, und Sie werden wahrscheinlich mehr Leute einbeziehen müssen. Und es ist nicht von der Hand zu weisen, dass die zusätzliche Komplexität das Risiko von Problemen in der Produktion nach einer Einführung erhöht. Schließlich ist es schon schwierig genug, dafür zu sorgen, dass alle Projektbeteiligten dieselbe Version einer Tabellenkalkulations-Datei verwenden, ganz zu schweigen vom Inhalt!

Zur Veranschaulichung: Eine typische S/4HANA-Migration kann bis zu 2.000 Transporte pro Monat mit bis zu 10.000 Objekten umfassen. Stellen Sie sich vor, Sie müssten herausfinden, wie sich die täglichen ECC-Änderungen darin einfügen.

Es gibt einen Weg

An dieser Stelle kommt die Idee des Continuous Retrofit ins Spiel. Es handelt sich dabei um eine leistungsstarke Funktion der SAP DevOps-Automatisierung wie in ActiveControl. Damit müssen Sie sich keine Gedanken mehr darüber machen, wie Sie Code und Konfiguration über verschiedene Landschaften hinweg angleichen – selbst, wenn diese technisch unterschiedlich sind.

Continuous Retrofit stellt sicher, dass alle in Ihren SAP-Systemen vorgenommenen Änderungen gemäß den von Ihnen festgelegten Regeln und Workflows automatisch in parallele Entwicklungs-Tracks übernommen werden – vielleicht sogar täglich. In der Regel bedeutet dies, dass Änderungen aus der Produktion in andere Entwicklungssysteme zurückgeführt werden, aber das Konzept ist leistungsstark und äußerst flexibel.

Ein effektives Continuous-Retrofit-System basiert auf einer leistungsstarken Analyse, die ermittelt, welche Änderungen ohne Konflikte oder Fehler zusammengeführt werden können, und die proaktiv potenzielle Probleme für die Entwicklungsteams aufzeigt, die diese lösen müssen. Kunden von Basis Technologies haben berichtet, dass mehr als 90 % der Änderungen, die in Produktionssystemen bereitgestellt werden, automatisch in die Projekt-Tracks zurückgeführt werden können, und zwar mit minimalem (oder ganz ohne) Benutzereingriff.

Ein echtes Continuous-Retrofit-System ermöglicht es Ihnen außerdem, dank der dynamischen Konflikterkennung ohne systemübergreifende Objektsperren zu arbeiten, so dass Entwicklungsteams wirklich unabhängig und parallel arbeiten können, was zu noch größeren Zeit- und Effizienzvorteilen führt.

Einige Unternehmen, die ActiveControl im Einsatz haben, sind sogar dafür bekannt, dass sie damit erfolgreich und automatisch Änderungen über N+10 Landschaften hinweg synchronisieren (ja, Sie haben richtig gelesen – Produktionssupport plus zehn weitere gleichzeitige Entwicklungssysteme!)

Wie funktioniert das?

Schauen wir uns ein kurzes Beispiel an.

Das folgende Diagramm zeigt ein ziemlich typisches Szenario während der Projektentwicklung, insbesondere für nicht-technische Projekt-Tracks.

Hier werden Änderungen, die im Produktionssupport-Track (gekennzeichnet als BAU oder Business As Usual) in die Produktion überführt wurden, anschließend automatisch mit dem Projektentwicklungssystem zusammengeführt. Dadurch wird das Projekt so sauber wie möglich gehalten, da alle BAU-Arbeiten, die noch nicht geliefert wurden (oder nicht mehr geliefert werden), ausgeklammert werden. Sogar das Retrofit kann selektiv erfolgen – vielleicht gibt es ja Dinge, die Sie durch Ihre Projektarbeit ersetzen wollen und deshalb lieber nicht wieder zusammenführen wollen. Oder es gibt technische Unterschiede, die berücksichtigt werden müssen.

Nach dem Cutover können Sie den Retrofit-Prozess dann auch nutzen, um Ihre Produktionssupportlandschaft zu aktualisieren (vorausgesetzt, Sie wollen nicht einfach den Projekt-Track in den neuen Produktionssupport umwandeln).

Wie könnte das in der Praxis aussehen? Der Basis Technologies-Kunde Vistaprint nutzte genau dieses Konzept, um den Aufbau und den Cutover zu S/4HANA als Teil seines Brownfield-Migrationsprojekts zu ermöglichen. Continuous Retrofit half dem Unternehmen, den Migrationsprozess zu beschleunigen, indem es den Aufwand für das Transportmanagement verringerte und das Risiko eines „Big Bang“-Cutovers reduzierte, als S/4 als Ersatz für ECC in Betrieb ging.

Ein Konzept – viele Konfigurationen

Dies ist nur ein Beispiel für die vielen Einsatzmöglichkeiten von Continuous Retrofit zur Unterstützung der SAP-Projektentwicklung.

Vielleicht haben Sie gleichzeitig noch ein zweites Projekt, das Sie managen müssen? Und Sie möchten dieses nicht nur synchronisieren, sondern auch Änderungen aus dem ersten Projekt schrittweise in die Produktion übernehmen? Das ist zwar ungewöhnlich, aber auch das haben wir schon erlebt:

Oder vielleicht stehen Sie, wie ein BTI-Kunde, vor der Herausforderung eines mehrjährigen S/4HANA-Dual-Maintenance-Projekts, bei dem sowohl ECC- als auch S/4HANA-Systeme gleichzeitig in Betrieb sind und Sie die Bereitstellung von Änderungen an beiden Produktionssystemen nicht nur abgleichen, sondern auch synchronisieren müssen:

Sie haben ein SAP-Projekt? DevOps Automatisierung kann helfen

Viele der SAP-Kunden, mit denen wir weltweit zusammenarbeiten, nutzen die Leistungsfähigkeit und Flexibilität der Continuous-Retrofit Funktionen von ActiveControl – und all die anderen erweiterten Funktionen, die damit verbunden sind –, um größere SAP-Projekte schneller und effizienter auszuliefern, ohne dabei die tägliche Innovation zu behindern.

Warum setzen Sie sich nicht einfach mit unserem SAP-Expertenteam in Verbindung, und besprechen Sie, wie ActiveControl Ihrem Unternehmen helfen kann?