SAP Solution Manager 7.2 Change and Release Management (ChaRM)

Im SAP Solution Manager 7.1 Change Request Management gab es eine unüberwindbare Hürde, die ein Release Management unmöglich gemacht hat: Es gab keine Möglichkeit zur Releaseplanung. Zu jedem Projekt gab es stets nur einen aktiven Änderungszyklus. Wir konnten also nie eine Änderung einem zukünftigen Zyklus im Sinne einer Planung zuordnen. Ganz abgesehen davon, dass Änderungsanträge generell keinem Zyklus zugeordnet werden konnten.

Das ist nun mit SAP Solution Manager 7.2 Geschichte: Endlich können wir eine Kette von Releasezyklen planen und nutzen. Dabei dürfen wir sogar verschiedene Branches (z.B. für Major- und Minor-Releases) kombinieren.‎ Unfertige Entwicklungen werden wie gewohnt in den Folgezyklus (der gleichen Branch) umgehangen, sofern diese nicht von Anfang an mit dem Folgezyklus verknüpft waren. Ein Zyklus darf nur produktiv gehen, wenn der Vorgänger produktiv ist. Der Aufgabenplan vom Vorgängerzyklus wird für den Nachfolger (der gleichen Branch) wiederverwendet. Änderungsanträge werden ebenfalls den Zyklen zugeordnet. Und es besteht optional die Möglichkeit, die Transportsteuerung komplett zu deaktivieren, falls lediglich der ChaRM-Workflow genutzt werden soll.

Was aber entgegen der schönen Bilder von SAP SE nicht gehen wird, ist dass verschiedene parallel laufende ChaRM-Releasezyklen bzw. QGM-Szenarien unabhängig voneinander gestartet und ggf. getestet werden, die Go-Lives dann aber synchronisiert durchgeführt werden. Ein releasezyklusübergreifender Aufgabenplan für die gesamte Change-Control-Landschaft ist nämlich aktuell leider nicht vorgesehen. Irgendwie hat SAP SE aber trotzdem nicht geschummelt bzw. gelogen. SAP SE geht nämlich einfach davon aus, dass Projekte zukünftig stets über SAP IT Portfolio and Project Management (SAP ITPPM) gesteuert werden. Und mehrere ITPPM-Projekte lassen sich sehr wohl einem Release(zyklus) zuordnen.

Übrigens gibt es alternativ noch den „Kontinuierlichen Zyklus“ (nur relevant, wenn ausschließlich mit Dringenden Änderungen gearbeitet wird – SAP1 wem das was sagt) und den „Phasenzyklus“ (entspricht nahezu dem alten Implementierungs- bzw. Wartungszyklus mit seinem bekannten Nachteil der Unplanbarkeit). Wir werden folglich in 99% der Fälle mit dem Releasezyklus arbeiten wollen.

Wo Licht ist, da ist auch Schatten: Die Integration von Change Request Management und Quality Gate Management, die ja erst kürzlich eingeführt wurde, wurde nun wieder aufgehoben. Sprich: Keine Übersicht mehr über parallel laufende Projekte inkl. Status und Meilensteinen. Keine Quality Gates mehr für die einzelnen Systeme der Landschaft.

Der Verlust ist aber wahrscheinlich verschmerzbar. Zum einen hat diese Kombination kaum einer genutzt(, weil sie ja noch so neu war). Und zum anderen kann die neue Release-Planungs-Funktion des ChaRM das irgendwie auch.

Völlig offen ist zur Zeit noch die Frage, wie mit Planänderungen umgegangen wird. Aktuell ist nämlich nur das Anlegen von neuen und Löschen von geplanten Releasezyklen vorgesehen. Doch was passiert, wenn sich der GoLive eines Major-Releases verschiebt und ein weiteres Minor-Release eingeschoben werden muss?

Hoffen wir einfach, dass dieser Fall in der Praxis niemals eintreten wird. 😉

PS: Ob SAP SE wohl mit SAP Solution Manager 7.2 das ChaRM endlich in „Change and Release Management“ umbenennen wird? Sinnvoll wäre es. Denn „Change Request Management“ bzw. die deutsch Übersetzung „Verwaltung von Änderungsanträgen“ war und ist mehr als irreführend.