ALM Kaffeekränzchen V – Dual Landscape Teil 5

Praxis

Post-Cutover

Eine Funktion fehlt noch. Mit ihr vollenden wir den Master „Duale Landschaft“: Kaum, dass wir unser Projekt-Major-Release Live gesetzt haben, müssen wir nämlich die Wartungslandschaft synchronisieren, d.h. alle Änderungen, die das Major Release produktiv gesetzt hat, müssen sofort in die Wartungslandschaft verteilt werden.

Es bietet sich hier an, die nette FB Standalone Extension „Cutover Checks and Post-Cutover Activities“ zu verwenden, die auch in diesem Blog beschrieben ist. Sie packen die produktiv gegangenen Transporte aus dem Projekt, die hoffentlich sämtliche retrofittete Wartungs-Korrekturen mitenthalten, in ToCs, die dann in die Vorsysteme (QA und Entwicklung) der Wartungslandschaft importiert werden. Dabei wird das Originalsystem der Workbench-Objekte auf das Entwicklungssystem der Wartung umgeändert, damit zukünftige Korrekturen nicht als „Reparaturen“ unter der Fuchtel des Modification Assistants gelten.

Empfehlenswert ist es, die angebotenen Cutover-Überprüfungen spätestens die Woche vor dem Go-Live des Releases intensiv zu studieren. Sie sind zum Teil deckungsgleich mit den Überprüfungen der sehr nützlichen Transaktion /SDF/TRCHECK.

Der Upgrade Fall

Einen Sonderfall steht der System-Upgrade dar, bei dem eine höhere Version der jeweiligen SAP Anwendung eingeführt wird.

Hier kann man aus offensichtlichen Gründen nicht einfach die produktiv gesetzten Transporte in die Maintenance-Landschaft verteilen. Auch dauert es zu lange, dasselbe Upgrade nach allen Regeln der Kunst in der Wartungslandschaft durchzuführen, um es vor dem Produktivsystem abzubrechen, das ja bereits auf dem neuen SAP-Release Stand steht. Hier drohen Inkonsistenzen, es reicht schon, wenn ein SAP Hinweis eine neue Version erhält.

Ich empfehle hier ausnahmsweise die Synchronisation der Wartungslandschaft per Datenbank-Kopie aus dem Produktivsystem durchzuführen, durchaus auch des Wartungs-Entwicklungssystems, obwohl Hinweis 2259615 „ChaRM/QGM: Correct Procedure of Refreshing a System Managed by a SAP Solution Manager System“ einem davon abrät, denn das Überschreiben des Entwicklungssystem der Wartung ist beherrschbar (Gute Idee für ein zukünftiges Kaffeekränzchen). Auch muss man das Originalsystem der Workbench-Objekte ändern. Wir helfen hier gerne.

Während die Wartungslandschaft per Datenbank-Kopie synchronisiert wird, muss ausnahmsweise die Projektlandschaft dringend notwendige Fehlerkorrekturen übernehmen. Perfektionisten werden für diese kurze Phase neue, kurzlebige Zyklen anlegen, bei denen die Retrofit-Richtung umgekehrt wird. Pragmatiker werden hingegen die notwendigen Korrekturen einfach priorisieren und nur die wirklich dringenden implementieren und diese in einer einfachen Liste dokumentieren, damit sie nach dem Erfolg der Systemkopie in der Wartungslandschaft nachgezogen werden können.

Operations

Die Post-Cutover Synchronisation bewirkt, dass das Wartungs-Entwicklungssystem dieselben Versionen wie das Produktivsystem hat. Somit können wir gleich nach Release Go-Live sämtliche auftretenden Fehlerkorrekturen am Release wie gewohnt über die Wartungslandschaft durchführen.

Dies hat auch den Vorteil, dass der normale Incident Prozess („Detect to Correct“) hier weiterverwendet wird: Ab Go-Live werden ja die „normalen“ Anwender über noch unentdeckte Fehler stolpern, nicht mehr das Projektteam. Dieses hatte ja seine Chance bei den Integrations- und Regressionstests gehabt.

Es sei nicht verschwiegen, dass diese dritte Variante eine organisatorische Herausforderung bedeutet, denn vom Projekt aus gesehen ist Variante 2 mit Hypercare-Phase und Fix-Pace naheliegender, man bleibt unter sich und kann die Übergabe an das Wartungsteam mit Ruhe angehen.

Aber auch hier zeigen sich die Vorteile der dualen Landschaft. Machen wir uns nichts vor. Die nicht technische (Cutover, Go-Live) sondern fachliche Übergabe des Projekt-Outputs an das Wartungsteam (Betriebsdokumentation, Schulung des Maintenance Teams) fällt liebend gern unter den Tisch: Das Projektbudget ist aufgebraucht, das Projekt Team bricht auseinander, alle haben bereits neue, ganz ganz wichtige Aufgaben in neuen Projekten, ein verzweifelter Projektleiter versucht noch, die Übergabe in trockene Tücher zu bringen, doch je länger die Hypercare-Phase dauert, desto schwieriger wird dies.

Über eine zweite Eigenart des Fix-Pace Prozesses, bei dem eigentlich nur Fehler per FB Urgent Correction (UC, S1HF) korrigiert werden sollen, dass nämlich diese UCs von Entwicklern gerne missbraucht werden, um nicht fertig gewordene Funktionen noch mal schnell (und ohne Regressionstests!!!) nach dem Release-Go-Live nachzuschieben, statt sie regelkonform in das nächste Release zu verschieben, möchte ich den Mantel des Schweigens ausbreiten¹.

In der empfohlenen Variante 3 hingegen ist man von vornherein gezwungen, die Übergabe an das Wartungsteam bereits vor dem technischen Go-Live zu gestalten. Dies erzwingt die Kommunikation zwischen den zwei Silos (ops, jetzt habe ich es gesagt…), und die notwendige Kollaboration der zwei Teams in den Tagen nach Go-Live erhöht die Qualität der Wartung.

Fazit

Die duale Landschaft mit Retrofit und Post-Cutover als der Master des Change Managements: Ich hatte nicht zu viel versprochen.

Ja, es ist ein Kraftakt! Doch diese Heraklestat lohnt sich, denn als Ergebnis hat man eine vertiefte Zusammenarbeit der Teams, dadurch eine erhöhte Software-Qualität, dadurch geringere Wartungskosten und schliesslich geringere Verluste durch teure Fehler im Produktivsystem.

Dieser Kraftakt lohnt sich!

1. [1] Ein Qualitätsmanagement kann solche missbräuchlichen Urgent Corrections leicht identifizieren. Da der UC den „echten“ Transport beim Statuswechsel auf „ToBeTested“ frei gibt, ist eine hohe Anzahl von Transporten in einem UC ein sicheres Indiz, dass hier mitnichten eine reine Fehlerkorrektur durchgeführt wurde, sondern eine neue Funktionalität mühsam im trial-and-error Stil weiter entwickelt wurde. ↩︎