ALM Kaffeekränzchen V – Dual Landscape Teil 1

Die Universität des ChaRMs – eine Lektion mit Praxisbezug 

Abbildung 1 Konfuzius

Ich liebe dieses Zitat von Konfuzius, weil es in ganz prägnanter Form das auf den Punkt bringt, was ich so oft bei Unternehmen und Behörden gesehen habe: die hartnäckige Bevorzugung des bitteren dritten Weges, das eine magische Anziehungskraft zu besitzen scheint.

Ich hoffe, mit dieser Blog-Serie die Befolgung des ersten oder wenigstens des zweiten Weges zu inspirieren.

Der Weg aus der Erfahrung…

Wir haben in einem der vorherigen Blogs hervorgehoben, dass eine ChaRM Einführung einen massiven Wechsel in der Kultur des Change Managements bedeutet. Dieser neue Change-Prozess muss erstmal reifen.

Mit der Zeit, mit der natürlichen Gewöhnung an die neuen strukturierten Prozesse, mit der Entdeckungs-Freude neuer Möglichkeiten wächst nicht nur die Beherrschung der neuen Vorgehensweisen und Werkzeuge. Es entfalten sich ebenso neue Bedürfnisse.

Neben dem echten, unplanbaren Bug-Fixing („Detect to Correct“), den wir hier nicht gross berücksichtigen, gibt es in jedem Unternehmen in der Regel eine Mischung von kleineren Erweiterungen (Erweiterungen im Rahmen von „Request to Fulfill“) und grösseren Einführungsprojekten („Requirement to Deploy“). Diese zwei planbaren Prozesse sind leider ziemlich unterschiedlich strukturiert und man riskiert eine inkongruente Taktung der Phasen (Entwicklung, Testen, Go-Live, Hypercare).

Abbildung 2 Change Prozesse

Als unverdrossene Fans des Lernens durch Erfahrung wird man eine Zeitlang, wie gewohnt, mit ein und derselben Transport-Landschaft (Entwicklungssystem, Testsystem, Produktivsystem) alle Änderungen verwalten wollen.

Mit dieser einen Landschaft wird man so versuchen, gleichzeitig den schnellen und den langsamen Änderungs-Prozess zu bedienen.

Einige denken, sie schaffen es, mit einem einzigen Änderungs-Zyklus und viel Status-Akrobatik zurande zu kommen, andere versuchen, sich mit zwei und mehr parallelen Zyklen zu behelfen, denn jeder Zyklus erlaubt eigene Termine für die Go-Live Phase (Cutover).

Denn man möchte ja Ressourcen (sprich: SAP Systeme) sparen – koste es, was es wolle!

Doch SAP transportierbare Objekte sind in der Regel hochkomplex, voller gegenseitiger Abhängigkeiten. Die automatische Änderungs-Aufzeichnung sperrt jede transportierbare Änderung in einen Transportauftrag, jede weitere Änderung an diesem Objekt wird automatisch in diesen Transportauftrag aufgezeichnet.

Da ein Transportauftrag nur einem Zyklus angehören kann, verknoten sich immer wieder Änderungen, die eigentlich zu unterschiedlichen Zyklen gehören sollten, in dem Transportauftrag, der zufällig als erster die Sperre erhalten hat.

Das ist tragisch, denn ab da kann ein Zyklus nicht mehr konsistent live gehen.

Immer wieder müssen also hochbezahlte Experten sich die Ärmel hochkrempeln und versuchen, manuell (d.h. per Versionsverwaltung, Sperren/Entsperren, Umhängen, Zusammenführen, Löschen, die Ziel-Importqueue Manipulieren) die hässlichen Knoten wieder auflösen.

… zur Erkenntnis

Nach mehreren Feuerwehr-Einsätzen verdichtet sich langsam die Erkenntnis, dass man mit einer einfachen Systemlandschaft, trotz aller Tricks, trotz allen Aufwandes und aller Aufwände, unweigerlich und wiederholt im Sumpf der Abhängigkeiten und Überholer stecken bleibt, Man lernt leidvoll, dass diese einfache Lösung die niedrigsten Einführungskosten aber den höchsten TCO hat.

Gibt es Jemanden, der diesen Blog liest und dann gleich freudig nickend den dornenreichen Weg des Lernens durch Erfahrung vermeidet?

Dies ist meine Hoffnung! Denn jetzt öffnen wir das leuchtende Tor zur Universität des Change Management: die duale Landschaft mit Release Management und laden zur ersten Vorlesung ein.

Duale Landschaft bedeutet, es gibt für dasselbe Produktivstem zwei Transportlandschaften mit zwei Quell-Systemen für Entwicklung und Customizing: Die Wartungs-Schiene und parallel dazu die Projekt-Schiene (siehe Abbildung 4).

Mit der dualen Landschaft erreichen wir einen Höhepunkt des Change Managements! Wir können jetzt zum Beispiel bei den DSAG Technologietagen mit einem T-Shirt mit dem Slogan „Dual Landscape: we did it!“ stolz herumlaufen.

Bei der Projektlandschaft konzentrieren wir uns in diesem Blog auf das SAP Solution Manager Add-on Focused Build (FB). Natürlich kann man auch mit dem klassischen Solution Manager Release Management arbeiten, aber die Vorteile von FB überwiegen. Es sei hier auf den sehr gelungenen openSAP Kurs „Agile Project Delivery with Focused Build for SAP Solution Manager“ verwiesen.

Vorlesung

“Zwar wollen alle, dass alles immer besser wird, aber verändern darf sich bitteschön nichts.“

Annette Kehnel I

Es sei nicht verschwiegen, dass nach dem Kultur-Schock der ChaRM Einführung das Release Management in einer dualen Landschaft die zweite, noch grössere Erschütterung bedeuten wird. Denn es greift tief in die Organisation und Durchführung der Projekte ein, und setzt klare Ansprüche an die Kommunikation zwischen allen Beteiligten.

Wirklich gelebt, setzt die duale Landschaft mit Release Management den Silos ein Ende. Dies wollen wir doch alle, oder?

Anfangs wird es viele Betroffene geben, die sich die Zeit nehmen und die Mühe nicht scheuen zu beweisen, dass es „bei uns“ nicht funktionieren kann. Hier muss man anfangs viel Überzeugungsarbeit leisten, auch braucht man eine starke Governance.

Ein erfahrener Partner, der so etwas bereits bei mehreren Unternehmen und Behörden implementiert und eingeführt hat, könnte sehr hilfreich sein, um diesen Kulturwandel zu erleichtern und zu beschleunigen. Hm, schauen Sie sich doch hier um, vielleicht erraten Sie, an wen ich gerade denke, kann ich da nur mit einem einladenden Lächeln sagen.

Am besten, man wartet auf ein schönes neues Einführungsprojekt mit viel Budget und – wegen der grossen organisatorischen Transformation – sogenannter Management-Attention, und setzt die Einführung von Release Management mit Focused Build davor.


[i] „Woher nur dieser Unwille zur Veränderung? Woher nur diese Schockstarre, das reflexartige ‚Gemach, Gemach! Lassen Sie uns nichts überstürzen, junge Frau!‘. In der Psychologie spricht man in diesem Fall von kognitiver Dissonanz, in der Verhaltensökonomie vom ‚Status-quo-Bias‘. Heisst: Zwar wollen alle, dass alles immer besser wird, aber verändern darf sich bitteschön nichts.“

Annette Kehnel, Futur Zwei Nr. 18|2021, S.55


Riccardo Escher

Riccardo ist seit R/2 Zeiten Basis-Entwickler und ABAP/4 Development Support für die Kollegen bei der OSRAM GmbH. Sein Interesse an Middleware brachte ihn zum SAP Solution Manager. Seit 2002 hat er die Entfaltung dieses mächtigsten aller ALM Werkzeuge begleitet, besonders intensiv mit Eigenentwicklungen bei dem ChaRM und der Test Suite. Seit 2006 engagiert er sich bei der DSAG. 2012 gründete er mit Björn Gelhausen die AG Testmanagement und wirkt als stellvertretender Sprecher.

blueworks Logo

Certified
Business Transformation
Professionals.


© blueworksgroup 2023. Alle Rechte Vorbehalten.

blue.works® und alm360® sind eingetragene Marken in der Europäischen Union und in der Schweiz.
SAP ist eine eingetragene Marke der SAP SE.