Releasemanagement unter neuem Vorzeichen
Wer mich kennt, weiß ja, dass ich schon immer ein Freund von Releasemanagement war und das auch immer wieder Kunden gegenüber in Workshops und Beratungstagen mitteile. Leider fällt es mir gar nicht so leicht, Anwender in Workshops und Beratertagen davon zu überzeugen.
Die üblichen Gegenargumente sind, der Fachbereich könne nicht auf die Anforderungen warten, sondern muss diese umgehend, wenn sie fertig sind, auch produktiv gesetzt bekommen.
Bohrt man tiefer nach, stellt sich heraus, dass der Fachbereich beim Test mitunter doch sehr lange warten konnte. In Summe sind wir es im SAP-Umfeld leider aus unserer Historie gewohnt, fast täglich Änderungen zu importieren.
Einige SAP-Anwender sprechen dann in diesem Kontext gerne von einem „täglichen Release“. Während wir es in anderen Anwendungen gewohnt sind, auf Releases oder Support Packages zu warten – keiner würde einzelne Features in seinem Office wahlfrei installieren –, ist dies im SAP für Anwender und IT-Abteilungen oft ein neuer Gedanke.
Dies hat dazu geführt, dass die „Normale Korrektur“ meist von Kunden nicht genutzt wurde, da die „Dringende Korrektur“ praktischer ist. Man muss keine Releases planen, sondern kann immer einzelne Changes produktiv setzen – wenn es der Fachbereich wünscht.
Der Übergang von einem „continuous development“ zu einem Release gelingt natürlich nicht sofort und auf Knopfdruck. Die organisatorisch notwendigen Änderungen sind meist viel tiefgreifender.
Bislang war das Releasemanagement auch immer sehr starr. Ich bekam immer die Frage gestellt, was wohl passiert, wenn während der Umsetzung entschieden wird, dass bestimmte Anforderungen nicht live gesetzt werden sollen oder auf das nächste Release verschoben werden.
SAP hat auf all diese Themen reagiert. Während es früher unterschiedliche Solution-Manager-Projekte gab, denen einzelne Changes zugeordnet werden, gibt es im 7.2 ein echtes Release.
Früher musste man jede Änderung, die über einen Workflow beantragt und genehmigt wurde, bereits vor der Freigabe einem Projekt zuordnen. Wehe dem, der hier eine Änderung einem Projekt falsch zugeordnet hatte.
Dies konnte, sobald der Change bereits in Entwicklung war, nur mit hohem manuellen Aufwand wieder geradegerückt werden. Zum Teil haben sich die Kunden auch mit Add-ons beholfen, um den Change in ein anderes Projekt zu übernehmen.
Die Releasebildung findet nun glücklicherweise dann statt, wenn wir über eine echte Produktivsetzung sprechen. Ganz konform, wie wir das im Non-SAP- Umfeld kennen, ist das nun nicht. Aber wohl eine der Möglichkeiten, um Anwender vom Releasemanagement im SolMan zu überzeugen. Ein organisatorischer Wandel ist ja immer noch vonnöten.
Die IT ist gefordert, mit den Fachabteilungen zu sprechen, eine Releaseplanung zu erstellen und auch eine echte Unterscheidung zwischen dringenden Anforderungen und Änderungen, die in ein Release gehören, abzustimmen.
Ich habe immer wieder Kunden, die genau diesen Konflikt scheuen und dann anfänglich damit beginnen, die Projekte zu bündeln als Release. Alles, was kein Projekt ist, also im Umfang einen bestimmten Aufwand nicht überschreitet, wird als „Dringende Änderung“ gehandhabt.
Im ersten Schritt klingt dies einfach. Beachtet man jedoch den Hintergrund der Transportsteuerung, ist der Sachverhalt deutlich komplizierter.
Da „Dringende Änderungen“ auch immer einem Projekt zugeordnet werden müssen, werden diese bei der Produktivsetzung nochmals importiert, um die Synchronität sicherzustellen. Dies bedeutet aber, dass Kunden, die mehrere Projekte parallel betreiben, alle „Dringenden Änderungen“ immer dem Projekt zuordnen müssen, das als Nächstes produktiv geht.
In der Praxis ist das mehr als kompliziert. Wie ein begossener Pudel steht dann der Change-Manager da, wenn kurzfristig zwei Projekte Rochade spielen. Dann müssen nämlich Changes umgehängt werden, was so heute in der Version 7.1 eben nicht auf Knopfdruck geht.
Mit dem SolMan 7.2 kann nun der Kunde entweder vollständig „dringend“ entwickeln und alles immer produktiv setzen oder er kann zum Produktivsetzungszeitpunkt eine echte Releasebildung vornehmen.
In Summe ist dies eine echte und wahnsinnig wertvolle Erweiterung. Die Herausforderung für IT-Verantwortliche liegt nun darin, die Release-Denkweise auch im SAP- Kontext im eigenen Unternehmen zu verankern.
