Das doppelte Gesicht des Release-Managements im ITSM

Ich habe schon vor geraumer Zeit etliche Schulungen im ITSM-Umfeld hinter mich gebracht. Etwas, das ich immer wieder als irritierend empfunden habe, war der jeweilige Unterrichtsblock zum Release-Management: Release-Management [RLM] wurde dort regelmäßig als Fortsatz des Change-Managements [CHM] dargestellt. Leider findet man diese Einstellung oft auch in DevOP-nahen Zirkeln vor.
Auch etliche (klassische) Projektmanager widmen dem Change-Management mehr Zeit als der Planung von Releases.

Typisch für den ITSM-Kursbetrieb war/ist auch, dass das Change-Management zuerst besprochen wird und dass ihm deutlich mehr Raum als dem RLM gewidmet wird. Das hat ganz wesentlich mit der grundlegend defensiven Ausrichtung von ITSM zu tun; es geht hier mehr um die Bewahrung und Aufrechterhaltung des operativen IT-Betriebs als um Innovation.

Zudem findet im Kontext des ITSM-bezogenen Release-Managements eine Fokussierung auf Regeln und Verfahren zur geordneten Einführung von Releases im Sinne einer Risiko-Reduzierung statt. So werden Verfahren im Umfeld des Release-Builds, Tests (QA) und Abnahmen, Baselining zugehöriger CIs in einer CMDB , Kommunikation, kontrollierte Implementierung und Verteilung des Release, die Auflösung von Abhängigkeiten, SLA-Adaption, Back-Out-Planung und Post Implementation Review [PIR] im Detail debattiert. Das sind wahrlich alles wichtige Dinge – aber ein anderer, mindestens ebenso wichtiger Aspekt des Release-Managements fällt dabei oft genug unter den Tisch:

Releases haben vor allem etwas mit strukturierter längerfristiger Planung einer Change-Umsetzung zu tun – und mit Produkten oder Produktvarianten.

Ein Grund für die Schieflage im Kursbetrieb ist die Prüfungsrelevanz diverser Unterprozesse/Verfahren des Release-Managements. Zu Themen wie „Testen und Akzeptieren“ eines Releases, zum zugehörigen Baselining im Configuration Management [CFM] oder zum PIR lassen sich einfach gute Testfragen verschiedener Schwierigkeitsgrade formulieren.

Ein anderer Grund liegt in einer Denke, in der ITSM auf den operativen Service-Betrieb reduziert wird: Man hat bereits einen operativen Service und zugehörige IT-Systeme, die durch „Requests for Change“ [RFC] aus unterschiedlichen Quellen verändert werden. Aus Effektivitäts- und Effizienzgründen bündelt man dann RFCs (manchmal?) zu Releases.

Kriterien für eine Bündelung von Changes zu definierten Releases können dabei sein:

  • Dringlichkeit,
  • Komplexität und/oder der fachliche oder technische Verwandheitsgrad der verschiedenen Requests for Change,
  • geschätzter Aufwand,
  • Verfügbarkeit von Ressourcen,
  • Optimierung des Ressourcen-Einsatzes.

Und schon wird Release-Management zum Fortsatz des Change Managements – leider. Nimmt man den Bezug des Release-Managements zum Baselinig in einer CMDB des Configuration Managements hinzu, ergibt sich etwa das obige Beziehungsdreieck.

Man kann sich jedoch ein wenig vom Kursbetrieb emanzipieren und einen anderen Standpunkt einnehmen.

IT-Services und Releases im Kontext von Produkten

Eine Perspektive, die im ITSM leider oft ausgeblendet wird, ist die des Produktmanagements. IT-Services sind manchmal identisch mit dem Produkt, das verkauft werden soll. Oft genug stützen diese IT-Services aber Produkte und Dienstleistungen jenseits der IT. Ich finde, dass in beiden Fällen eine Perspektive des Produkt-Managements – und nachgelagert des Service-Portfolio-Managements – angebracht ist.

Wenn ich aber IT-gestützte Produkte und Dienstleistungen an den Verbraucher bringen will, muss ich zügig Marktnischen besetzen und den Kunden regelmäßig neue Produkt-Features anbieten (Kundenbindung). Das ist gerade und zunehmend bei „intelligenten“, also IT-gestützten Produkten der Fall. Es ergibt sich automatisch ein strategisches Denken in Kategorien neuer „Produktvarianten“ oder „Produkt-Releases“. Getriggert und unterfüttert wird die strategische Produktplanung oft durch Ergebnisse eines kontinuierlich stattfindenden Research & Development-Prozesses [R&D] im Unternehmen. Daneben spielt auch das Feedback aus Kunden-Communities, die sich zu erfolgreichen Produkten im Internet ausbilden, eine wichtige Rolle.

Diese Perspektive macht Produkt-Release-Management und nachgeordnet das Release-Management im ITSM zum strategischen Steuerungsinstrument.

Damit ändert sich nicht der Bezug des Release-Managemwnts zum Change- oder Configuration-Management. Es ändert sich aber sehr wohl die Bedeutung und die steuernde Rolle des Release-Managements. Unser Dreieck kippt:

Die strategische Produktplanung entwickelt handfeste Visionen neuer Produkt-Releases. Sie macht dies in Form von Anforderungen an neuen, modifizierten oder erweiterten Produkt-Features fest, die sich u.a. als Changes in der IT (SW, HW, Client-Features, Serverdienste, etc.) manifestieren und natürlich auch im „Change Management“ über RFCs einen Niederschlag finden müssen. Die gestrichelte Linie im Diagramm deutet dies an.

Die strategischen Planungen fangen aber beim Produkt-Release an. IT-Releases (im besonderen Haupt-Releases) haben in innovativen Unternehmen ihre Ursache häufiger in geplanten Produkt-Releases als RFCs, die sich aus dem operativen Betrieb, Incidents oder Problems ergeben.

Zwei Gesichter des Release-Managements

Aus meiner Sicht hat das Release-Management im ITSM deshalb zwei Gesichter:

Eine planende und auch steuernde Funktion im strategischen Interesse des Business
Die Norm besagt hierzu: „Der Service-Provider muss gemeinsam mit dem Business die Releases von Services, Systemen, Software und Hardware planen. Alle relevanten Parteien, beispielsweise Kunden, Anwender, Operations- und Support-Mitarbeiter, müssen die Pläne, wie das Release ausgerollt werden soll, vereinbaren und genehmigen.“ Der Code of Practice bestätigt das noch mal: „Das Release der entsprechenden Informationssysteme, Infrastrukturen, Services und Dokumentationen sollte mit dem Business zusammen geplant werden.“ ( In beiden Fällen habe ich zitiert nach „ISO/IEC 20000 – Eine Einführung, Van Haren Publishing, 2009).

Das IT-Service-Management läuft dabei der strategischen Produktplanung nach und orientiert sich an dieser. Zugehörige Changes werden durch die Planung von Produkt-Releases induziert. Das entspricht gewissermaßen einer Umkehrung der Idee der Bündelung vorhandener Changes zu Releases. Es widerspricht einem Aufgreifen und einer Bündelung von Changes, die sich aus anderen Quellen ergeben, sowie einer Integration in geplante Releases jedoch nicht. Beides ist eher zur Deckung zu bringen. Eine strategische Release-Planung verleiht dem Change Schedule dabei eine business-orientierte Struktur. Sie verschiebt den Schwerpunkt der Release-Planung deutlich in Richtung Produkt-Management.

Eine steuernde Funktion im taktischen Sinne einer geordneten Erzeugung, Prüfung und produktiven Implementierung von IT-Services und IT-Systemen
Hierunter fallen alle diejenigen Aspekte, die auf der taktischen Ebene erforderlich sind: Build- und Integrations-Planung, Test/Abnahmen auf QA- und Produktiv-Systemen(QA), Logistik, Migrationen, Dokumentation, Versionierung, Baselinig und andere Prozesse im Rahmen des Configuration Managements, Release-Readiness Review, Paketierung, Erzeugung Definitive Media Library, Work-Prozess-Changes, Schulungen, Cut-Over-Plan, Back-Out-Planung, ….

Hierbei handelt es sich um konkrete vorbereitende und umsetzende Schritte auf der logistischen Ebene, der SW-Entwicklungsebene, der HW- und Infrastruktur-Ebene und ggf. der Ebene der Anwender und dortiger Arbeitsprozesse. All diese Schritte auf der taktischen Ebene münden in die faktische Produktivsetzung eines konkreten neuen Releases.

Grafisch spiegelt die nebenstehende Skizze die Unterscheidung zwischen strategischer und taktischer Ausprägung des RLM wider.

Fazit

Ich finde in jedem Fall, dass dem Release-Management eine andere Rolle zukommt als die eines Fortsatzes des Change Managements. Release-Management ermöglicht vielmehr erst eine strategische IT-Planung im Sinne des Business. Es induziert Changes in gleicher Weise wie es sie aufgreift.

Leider ist die aus meiner Sicht herausragende Bedeutung des Release-Managements im ITSM – nämlich als eine Brücke zum Produkt-Management – durch die Integration in den Block der „Control Processes“ (ISO/IEC 20000:2011) vermindert worden. In der 2005er-Version der ISO/IEC 20000 nahm das RLM noch aus guten Gründen einen eigenen Prozessblock ein.

 

Schreibe einen Kommentar

Dieser Blog verwendet Cookies. Bei weiterer Nutzung gehen wir von Ihrem Einverständnis aus. Optionen/Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen