Das Konzept der Value Streams in ITIL 4 (siehe auch diesen Beitrag) ist die größte strukturelle Veränderung im ITIL-Framework und wird den bisherigen Service Lifecycle aus ITIL V3 ersetzen. Organisationen können aus einem vordefinierten Satz von Bausteinen, den so genannten Wertschöpfungsaktivitäten, agile Prozesse entwickeln. Diese sind stärker als je zuvor auf eine enge Zusammenarbeit mit Kunden ausgerichtet und sollen die Effizienz im laufenden Betrieb erhöhen. Besonderes Augenmerk wird daraufgelegt, dass die Wertschöpfung gemeinsam entsteht (Co-Creation).
Foto: Efecte, Peter Schneider
Dieser neue Ansatz zur flexiblen Prozessgestaltung hat jedoch eine Schwäche: Es ist ziemlich einfach, bestehende Prozesse einer Organisation zu übernehmen und als ITIL 4-Wertschöpfungskette abzubilden. Wenn der Übergang zum neuen Framework jedoch nicht konsequent weitergeführt wird, verschwendet das Abbilden und Dokumentieren der bestehenden Prozesse lediglich Ressourcen und macht Organisationen nicht agiler.
Das Buch der ITIL 4 Foundation enthält bisher keine konkreten Richtlinien für agile Wertströme und Praktiken wie Change Control und Release Management. Es bleibt also vorerst den Prozessdesignern überlassen, innerhalb der Organisation eine neue, wirklich agile Arbeitsweise zu entwickeln oder eben die bestehenden Prozesse lediglich eins zu eins abzubilden. Tatsche ist: Nur, wenn die Prozesse bei der Einführung von ITIL 4 iterativ und kundenorientiert gestaltet werden, können Organisationen von den Vorteilen des flexibleren Value-Stream-Konzepts in ITIL 4 profitieren.
TIPP: CIOs sollten bei Modernisierungsprojekten immer im Hinterkopf behalten, dass Agilität nur als ganzheitlicher Ansatz funktioniert. Sie müssen dafür Sorge tragen, dass Prozessdesigner ITIL 4 nicht nur als formale Schablone auf bestehende Abläufe anwenden, sondern ihre Prozesse gemeinsam mit Fach- und IT-Abteilungen komplett neu definieren.
Agile Prozesse nicht mit Wasserfall-Tools managen
Das ITIL 4 Foundation Buch erklärt ausführlich die Schlüsselfaktoren für agiles Service Management. Dazu zählt unter anderem eine möglichst frühzeitige Präsentation von Arbeitsergebnissen, damit Kundenfeedbacks schneller umgesetzt werden können (Improve). In diesem Zusammenhang wird die visuelle Darstellung von Arbeitsfortschritten nach Kanban als wesentliche Voraussetzung für agile Serviceprozesse genannt.
Viele ITSM-Tools für die Bearbeitung von Störungen (Incidents) und Änderungen (Change) sind nach dem Wasserfall-Modell konzipiert. Sie werden meist in tabellarischer Form dargestellt und nach Prioritäten oder Soll-Lösungszeiten geordnet. Es ist jedoch nicht auf den ersten Blick ersichtlich, welches Thema sich in welchem Prozess-Status befindet und was als nächstes zu tun ist. Daes erschwert die Zusammenarbeit in Teams, sorgt für Missverständnisse auf Kundenseite, schafft zusätzlichen Gesprächsbedarf - und kann im schlimmsten Fall sogar den Projekterfolg gefährden.
Kanban-Ansichten sorgen für mehr Transparenz, fördern die Zusammenarbeit verschiedener Stakeholder und erleichtern die Kundenkommunikation erheblich. Sie gewährleisten ein eindeutiges Ranking anstehender Aufgaben, stellen Themen mit der gleichen Priorität gleichberechtigt nebeneinander und schaffen durch die entstehende Transparenz eine gute Grundlage für agil arbeitende Teams. ITSM-Anbieter haben das erkannt und Kanban-Ansichten für das Incident Management eingeführt. Einige Tools verfügen sogar über Visualisierungsmöglichkeiten für das Aufgaben-Management im Service Desk sowie die agile Softwareentwicklung.
ITIL 4 schafft also im Grunde eine Nachfrage nach Tools, die Kanban-Ansichten für den Bereich Incident Management, aber auch für Change Control, Release Management und Service Configuration Management bereitstellen. Entsprechend dürften die Service-Management-Lösungen angepasst werden.
TIPP: Führungskräfte sollten darauf achten, dass eingesetzte Tools Projektfortschritte und Schwachstellen zeigen, die Zusammenarbeit von Teams verbessern und die schnelle Umsetzung von Kundenfeedbacks erleichtern. Erst wenn das durchgängig gelingt, werden Serviceprozesse nicht nur ITIL-4-kompatibel, sondern tatsächlich agiler.
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.
Foto: Efecte, Peter Schneider
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.