{"id":33651,"date":"2023-09-22T08:53:45","date_gmt":"2023-09-22T06:53:45","guid":{"rendered":"https:\/\/www.blue.works\/?p=33651"},"modified":"2026-02-17T13:04:19","modified_gmt":"2026-02-17T12:04:19","slug":"alm-kaffeekraenzchen-v-dual-landscape-teil-5","status":"publish","type":"post","link":"https:\/\/www.blue.works\/de\/alm-kaffeekraenzchen-v-dual-landscape-teil-5\/","title":{"rendered":"ALM Kaffeekr\u00e4nzchen V – Dual Landscape Teil 5"},"content":{"rendered":"\n

Praxis<\/h2>\n\n\n\n

Post-Cutover<\/h3>\n\n\n\n

Eine Funktion fehlt noch. Mit ihr vollenden wir den Master \u201eDuale Landschaft\u201c: Kaum, dass wir unser Projekt-Major-Release Live gesetzt haben, m\u00fcssen wir n\u00e4mlich die Wartungslandschaft synchronisieren, d.h. alle \u00c4nderungen, die das Major Release produktiv gesetzt hat, m\u00fcssen sofort<\/span> in die Wartungslandschaft verteilt werden.<\/p>\n\n\n\n

\"\"
Abbildung 12 Die Vollendung: Duale Landschaft mit Retrofit und Post-Cutover<\/figcaption><\/figure>\n\n\n\n

Es bietet sich hier an, die nette FB Standalone Extension \u201eCutover Checks and Post-Cutover Activities<\/a>\u201c zu verwenden, die auch in diesem Blog<\/a> beschrieben ist. Sie packen die produktiv gegangenen Transporte aus dem Projekt, die hoffentlich s\u00e4mtliche 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\u00e4ndert, damit zuk\u00fcnftige Korrekturen nicht als \u201eReparaturen\u201c unter der Fuchtel des Modification Assistants gelten.<\/p>\n\n\n\n

Empfehlenswert ist es, die angebotenen Cutover-\u00dcberpr\u00fcfungen sp\u00e4testens die Woche vor dem Go-Live des Releases intensiv zu studieren. Sie sind zum Teil deckungsgleich mit den \u00dcberpr\u00fcfungen der sehr n\u00fctzlichen Transaktion \/SDF\/TRCHECK.<\/p>\n\n\n\n

Der Upgrade Fall<\/h3>\n\n\n\n

Einen Sonderfall steht der System-Upgrade dar, bei dem eine h\u00f6here Version der jeweiligen SAP Anwendung eingef\u00fchrt wird.<\/p>\n\n\n\n

Hier kann man aus offensichtlichen Gr\u00fcnden 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\u00fchren, 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\u00e4lt.<\/p>\n\n\n\n

Ich empfehle hier ausnahmsweise die Synchronisation der Wartungslandschaft per Datenbank-Kopie aus dem Produktivsystem durchzuf\u00fchren, durchaus auch des Wartungs-Entwicklungssystems, obwohl Hinweis 2259615 \u201eChaRM\/QGM: Correct Procedure of Refreshing a System Managed by a SAP Solution Manager System\u201c<\/a> einem davon abr\u00e4t, denn das \u00dcberschreiben des Entwicklungssystem der Wartung ist beherrschbar (Gute Idee f\u00fcr ein zuk\u00fcnftiges Kaffeekr\u00e4nzchen<\/em>). Auch muss man das Originalsystem der Workbench-Objekte \u00e4ndern. Wir helfen hier gerne.<\/p>\n\n\n\n

W\u00e4hrend die Wartungslandschaft per Datenbank-Kopie synchronisiert wird, muss ausnahmsweise die Projektlandschaft dringend notwendige Fehlerkorrekturen \u00fcbernehmen. Perfektionisten werden f\u00fcr 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\u00f6nnen.<\/p>\n\n\n\n

Operations<\/h3>\n\n\n\n

Die Post-Cutover Synchronisation bewirkt, dass das Wartungs-Entwicklungssystem dieselben Versionen wie das Produktivsystem hat. Somit k\u00f6nnen wir gleich nach Release Go-Live s\u00e4mtliche auftretenden Fehlerkorrekturen am Release wie gewohnt \u00fcber die Wartungslandschaft durchf\u00fchren.<\/p>\n\n\n\n

Dies hat auch den Vorteil, dass der normale Incident Prozess (\u201eDetect to Correct\u201c) hier weiterverwendet wird: Ab Go-Live werden ja die \u201enormalen\u201c Anwender \u00fcber noch unentdeckte Fehler stolpern, nicht mehr das Projektteam. Dieses hatte ja seine Chance bei den Integrations- und Regressionstests gehabt.<\/p>\n\n\n\n

\"\"
Abbildung 13 Variante 3: Duale Landschaft<\/figcaption><\/figure>\n\n\n\n

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<\/a> naheliegender, man bleibt unter sich und kann die \u00dcbergabe an das Wartungsteam mit Ruhe angehen.<\/p>\n\n\n\n

Aber auch hier zeigen sich die Vorteile der dualen Landschaft. Machen wir uns nichts vor. Die nicht technische (Cutover, Go-Live) sondern fachliche \u00dcbergabe des Projekt-Outputs an das Wartungsteam (Betriebsdokumentation, Schulung des Maintenance Teams) f\u00e4llt 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 \u00dcbergabe in trockene T\u00fccher zu bringen, doch je l\u00e4nger die Hypercare-Phase dauert, desto schwieriger wird dies.<\/p>\n\n\n\n

\u00dcber eine zweite Eigenart des Fix-Pace Prozesses, bei dem eigentlich nur Fehler<\/span> per FB Urgent Correction (UC, S1HF) korrigiert werden sollen, dass n\u00e4mlich 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\u00e4chste Release zu verschieben, m\u00f6chte ich den Mantel des Schweigens ausbreiten1<\/a><\/sup>.<\/p>\n\n\n\n

In der empfohlenen Variante 3 hingegen ist man von vornherein gezwungen, die \u00dcbergabe 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\u2026), und die notwendige Kollaboration der zwei Teams in den Tagen nach Go-Live erh\u00f6ht die Qualit\u00e4t der Wartung.<\/p>\n\n\n\n

Fazit<\/h2>\n\n\n\n

Die duale Landschaft mit Retrofit und Post-Cutover als der Master des Change Managements: Ich hatte nicht zu viel versprochen.<\/p>\n\n\n\n

Ja, es ist ein Kraftakt! Doch diese Herakles<\/a>tat lohnt sich, denn als Ergebnis hat man eine vertiefte Zusammenarbeit der Teams, dadurch eine erh\u00f6hte Software-Qualit\u00e4t, dadurch geringere Wartungskosten und schliesslich geringere Verluste durch teure Fehler im Produktivsystem.<\/p>\n\n\n\n

Dieser Kraftakt lohnt sich!<\/p>\n\n\n\n

Haben sie den vorherigen Teil verpasst? dann k\u00f6nnen sie diesen hier <\/a>lesen.<\/p>\n\n\n\n

\n\n\n
  1. [1] Ein Qualit\u00e4tsmanagement kann solche missbr\u00e4uchlichen Urgent Corrections leicht identifizieren. Da der UC den \u201eechten\u201c Transport beim Statuswechsel auf \u201eToBeTested\u201c frei gibt, ist eine hohe Anzahl von Transporten in einem UC ein sicheres Indiz, dass hier mitnichten eine reine Fehlerkorrektur durchgef\u00fchrt wurde, sondern eine neue Funktionalit\u00e4t m\u00fchsam im trial-and-error<\/em> Stil weiter entwickelt wurde. \u21a9\ufe0e<\/a><\/li><\/ol>","protected":false},"excerpt":{"rendered":"

    Eine Funktion fehlt noch. Mit ihr vollenden wir den Master \u201eDuale Landschaft\u201c: Kaum, dass wir unser Projekt-Major-Release Live gesetzt haben, m\u00fcssen wir n\u00e4mlich die Wartungslandschaft synchronisieren, d.h. alle \u00c4nderungen, die das Major Release produktiv gesetzt hat, m\u00fcssen sofort in die Wartungslandschaft verteilt werden.<\/p>\n","protected":false},"author":16,"featured_media":33659,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":"[{\"content\":\"[1] Ein Qualit\u00e4tsmanagement kann solche missbr\u00e4uchlichen Urgent Corrections leicht identifizieren. Da der UC den \u201eechten\u201c Transport beim Statuswechsel auf \u201eToBeTested\u201c frei gibt, ist eine hohe Anzahl von Transporten in einem UC ein sicheres Indiz, dass hier mitnichten eine reine Fehlerkorrektur durchgef\u00fchrt wurde, sondern eine neue Funktionalit\u00e4t m\u00fchsam im trial-and-error<\/em> Stil weiter entwickelt wurde.\",\"id\":\"9e8b1528-1f72-42e4-a7bc-35438f2c93ac\"}]"},"categories":[344],"tags":[336],"class_list":["post-33651","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-alm-kaffeekraenzchen-das-alm-magazin","tag-kaffeekraenzchen"],"acf":[],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/www.blue.works\/wp-content\/uploads\/2023\/09\/shawnanggg-zpjoLJnR2OE-unsplash-scaled.jpg","_links":{"self":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33651","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/comments?post=33651"}],"version-history":[{"count":6,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33651\/revisions"}],"predecessor-version":[{"id":45173,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/33651\/revisions\/45173"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media\/33659"}],"wp:attachment":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media?parent=33651"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/categories?post=33651"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/tags?post=33651"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}