ITIL 4 ist kein Kochbuch

Unternehmen wollen agiler werden. Das neue ITIL-4-Framework soll sie dabei unterstützen, veränderten Marktbedingungen schneller und flexibler gerecht zu werden. Tatsächlich ist die neue ITIL-Version aber kein Kochbuch für agile Unternehmensprozesse.

Unternehmen wollen und müssen agiler werden. Das ITIL-4-Framework soll sie dabei unterstützen, veränderte Marktbedingungen schneller und flexibler aufzugreifen. Doch die neue ITIL-Version ist alles andere als ein Kochbuch für agile Unternehmensprozesse.

Das Konzept der Value Streams in ITIL 4 ist die größte strukturelle Veränderung im ITIL-Framework. Es wird den bisherigen Service-Lifecycle aus ITIL V3 ersetzen. Organisationen können aus einem vordefinierten Satz von Bausteinen, den sogenannten 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 darauf gelegt, dass die Wertschöpfung gemeinsam entsteht (Co-Creation).

Dieser veränderte Ansatz zur flexiblen Prozessgestaltung hat jedoch eine Schwäche: Es ist ziemlich einfach, bestehende Prozesse einer Organisation zu übernehmen und als ITIL-4Wertschö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. Tatsache 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 ValueStream-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 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 Wasserfallmodell 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. Das erschwert die Zusam

menarbeit 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 mit ihren 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 Wasserfallkonzept 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 sogenannte 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 Beteilig

ten 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 Startund Endtermine aller Aktivitäten enorm. Dank einer solchen strukturellen Vereinfachung entstehen klare Zeitpläne für jedes agile Team. Abhängigkeiten, die die 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 agiler managen können. CIOs sind gut beraten, gemeinsam mit ProzessArchitekten 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

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 sollten sich im Klaren sein: Es wird nicht reichen, ein neues Tool für IT- oder EnterpriseService-Management (ITSM, ESM) zu kaufen und bestehende Prozesse damit gemäß ITIL 4 nachzubilden. Damit Organisationen vom neuen ITIL-Standard 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 Projekt-Management und setzt vor allem bei Prozessarchitekten einen agilen Mindset voraus. Organisationen werden nicht umhinkommen, ihre eigenen Erfahrungen zu sammeln.