Auch ITIL 4 nimmt CIOs nicht die Arbeit ab

Agile Methoden im Bereich Change Control einführen

In ITIL 4 wurde die Praxis des Change Managements in Change Control umbenannt. Bis auf den Namenswechsel gibt es jedoch kaum nennenswerte Veränderungen zur Umsetzung der zugehörigen ITIL-Praktiken (Prozessen und Funktionen). Es existiert lediglich ein kleiner Unterschied im Notfall-Änderungsprozess, der nun eine Genehmigung der Change Authority überflüssig macht.

Ansonsten sind die Empfehlungen nahezu identisch mit ITIL 3: Der zugehörige Prozess folgt immer noch einem Wasserfall-Value-Stream - zumindest, wie er während eines zertifizierten ITIL 4 Foundation Trainings präsentiert wird. Neue agile Methoden wurden bisher noch nicht in die Praxis von Change Control umgesetzt.

Wenn aber ITIL 4 nicht konkretisiert, wie ein agiler Prozess für Kernpraktiken wie Change Control aufgebaut werden soll, wie können dann Organisationen von der eher langsamen Incident-Verwaltung mit starren Zeitplänen mit Dutzenden unterschiedlicher Start- und Enddaten wegkommen? Die Antwort klingt auf den ersten Blick relativ simpel: Indem sie das bestehende Wasserfall-Konzept kritisch hinterfragen und auch für diesen Bereich den Einsatz agiler Methoden prüfen.

Ein möglicher Weg ist die Verwendung von Scaled Agile Frameworks (SAFe). Auf das Service Management bezogen bedeutet das: Statt für alle Wertschöpfungsaktivitäten einzelne Start- und Endtermine für Implementierung, Test und Bereitstellung festzulegen, lassen sich diese als so genannte Agile Release Trains (ARTs) organisieren. Dazu werden virtuelle Organisationen definiert, die aus Mitgliedern verschiedener Abteilungen bestehen. Sie arbeiten an einem gemeinsamen Projekt und entwickeln dieses in klar definierten Iterationsschritten weiter.

Alle Funktionen und Änderungen werden dabei gemeinsam mit Kunden abgestimmt und klar priorisiert. Ähnlich wie ein U-Bahn-Zug, der zu festen Zeiten Fahrgäste aufnimmt, können die einzelnen ARTs Funktionen für das nächste Release beisteuern. Ist ein festgelegter Termin nicht einzuhalten, müssen die Beteiligten bis zum nächsten warten. Der Vorteil: Neuplanungen aufgrund von Verzögerungen entfallen und die Fachbereiche gewinnen mehr Transparenz wann notwendige Änderungen einzuplanen sind.

Service-Management-Praktiken wie Change Control, Service Validation und Release Management sollten anstelle vieler einzelner Start- und Enddaten mit einem einzigen Programmschritt verknüpft sein. Die Ergebnisse der einzelnen Service Management Praktiken können dann in die Agile Release Trains geliefert werden: Ist eine Aktivität erledigt, fährt der "Release-Zug" zur nächsten ART.

Dieses agile Vorgehen reduziert den Aufwand für die Einstellung und Anpassung der Start- und Endtermine aller Aktivitäten enorm. Dank einer solchen strukturellen Vereinfachung entstehen klare Zeitpläne für jedes agile Team. Abhängigkeiten, die die oben genannten Praktiken unnötig verlangsamen, werden nunmehr vermieden. Außerdem können sich Kunden viel besser auf Änderungen (Changes) vorbereiten, die ihren Geschäftsbetrieb beeinflussen.

TIPP: Aufgrund der noch unklaren Handlungsanweisungen zur praktischen Umsetzung von Change Control sollten IT-Organisationen bereits heute überlegen, wie sie Wertströme mit modernen Methoden agilerer managen können. CIOs sind gut beraten, gemeinsam mit Prozess-Architekten und -Ownern zu prüfen, welche Ansätze sich dafür eignen und wie sich individuelle Wertschöpfungsaktivitäten mit agilen Methoden organisieren lassen.

Fazit: Ohne Risikobereitschaft kein Erfolg

Die Information Technology Infrastructure Library (ITIL) bleibt auch in Version 4 das Standard-Regelwerk für den Aufbau von Serviceprozessen. ITIL 4 soll Organisationen zu mehr Agilität verhelfen und ist im Grunde schon lange überfällig. Dennoch stellt das erste Buch der ITIL Foundation den Experten bisher weder konkrete agile Workflows noch fertige Wertströme für wichtige Praktiken wie Change Control und Release Management zur Verfügung. Zwar ist davon auszugehen, dass der ITIL-Rechteinhaber Axelos diese noch nachreicht - ob und wann dies geschieht, ist aber ungewiss.

CIOs, die agilere Serviceprozesse anstreben, sollten keine Zeit verlieren, sich aber auch über eines im Klaren sein: Es wird nicht reichen, ein neues Tool für IT- oder Enterprise-Service-Management (ITSM, ESM) zu kaufen und bestehende Prozesse damit gemäß ITIL 4 nachzubilden. Damit Organisationen vom neuen ITIL-Standard wirklich profitieren können, sind vor allem Eigeninitiative und Risikobereitschaft gefragt: Etablierte Vorgehensweisen müssen geprüft und eingespielte Abläufe unter Umständen völlig neu strukturiert werden.

Die Veränderung beginnt beim Projektmanagement und setzt vor allem bei Prozess-Architekten einen agilen Mindset voraus. Organisationen werden nicht umhinkommen, eigene Erfahrungen zu sammeln - und über die bisherige ITIL-4-Dokumentation hinauszugehen. Am Ende ist auch ITIL 4 nur eine Sammlung von Best Practices, die auf individuelle Bedürfnisse anzupassen ist.