Von ITIL v3 zu ITIL 4: der echte Unterschied

Vom Lifecycle zum Service Value System

In ITIL v3 hieß die Gliederung Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement. Weil das fünf Bücher waren, die man in dieser Reihenfolge las, haben viele Organisationen ihre Prozesslandkarte genauso aufgebaut. Das funktionierte, solange ein Vorhaben tatsächlich einmal von der Strategie bis in den Betrieb lief.

ITIL 4 dreht die Perspektive. Im Zentrum steht das Service Value System, in das Nachfrage und Gelegenheit hineinlaufen und aus dem Wert herauskommt. Darin liegen die Leitprinzipien, die Governance, die Service Value Chain mit ihren sechs Aktivitäten, die Practices und die kontinuierliche Verbesserung. Ein Wertstrom nimmt sich aus der Value Chain nur die Aktivitäten, die er braucht, in der Reihenfolge, die zur Arbeit passt, und kehrt zu manchen mehrfach zurück.

Dazu kommen die vier Dimensionen des Service-Managements: Organisationen und Menschen, Information und Technologie, Partner und Lieferanten sowie Wertströme und Prozesse. Sie sind kein Zusatzkapitel, sondern die Prüffrage an jede Entscheidung. Ein Verbesserungsvorhaben, das nur an Prozessen und Werkzeugen arbeitet, scheitert regelmäßig an der dritten Dimension, weil der Lieferantenvertrag die Reaktionszeit vorgibt.

Die umbenannten Begriffe und was dahintersteckt

Aus Change Management wurde in ITIL 4 zunächst Change Control, inzwischen trägt die Practice den Namen Change Enablement. Request Fulfilment heißt jetzt Service Request Management, Event Management wurde zu Monitoring and Event Management, aus Service Asset and Configuration Management wurde Service Configuration Management, und IT Service Continuity Management heißt schlicht Service Continuity Management. Continual Service Improvement war in v3 eine eigene Phase. In ITIL 4 fällt der Zusatz Service weg: Continual Improvement ist dort Practice und zugleich Baustein des Wertsystems, in der Service Value Chain heißt die zugehörige Aktivität Improve.

Die Umbenennungen sind keine Kosmetik. Change Enablement zielt darauf, möglichst viele Änderungen mit vertretbarem Risiko durchzulassen, statt an einer Freigabestelle zu bremsen. ITIL 4 spricht deshalb von einer Change Authority, die zum Risiko der jeweiligen Änderung passt, statt ein einziges Gremium für alles zuständig zu machen. Wer den Prozess im Werkzeug umbenennt und den Freigabeweg unverändert lässt, hat nichts gewonnen.

Bei den Funktionen ist der Bruch am größten. ITIL v3 kannte vier davon: Service Desk, Technical Management, Application Management und IT Operations Management. In ITIL 4 gibt es keine Funktionen mehr. Der Service Desk lebt als Practice weiter, für die anderen drei gibt es keine Eins-zu-eins-Nachfolge, ihre Inhalte verteilen sich auf Practices wie Infrastructure and Platform Management oder Software Development and Management.

Was ein altes v3-Zertifikat heute noch wert ist

Neue Prüfungen nach dem v3-Schema gibt es nicht mehr. Das einmal erworbene Zertifikat bleibt als Nachweis erhalten, es ist aber kein Baustein eines aktuellen Zertifizierungswegs mehr. Für eine Bewerbung sagt es weiterhin, dass jemand ITSM-Grundlagen gelernt hat, für ein Modul im heutigen Schema zählt es nur an einer Stelle.

Diese Stelle ist die Managing Professional Transition der Version 5. Sie steht ITIL v3 Expert und ITIL v3 Master offen, ebenso ITIL 4 Managing Professional und ITIL 4 Master, und dauert fünf Tage. Wer nur v3 Foundation hat, geht den regulären Weg über eine aktuelle Foundation.

Wichtig für die Planung: Die ITIL-4-Module sind bis zum 31. Dezember 2027 erwerbbar. Wer aus der v3-Welt kommt und eine Designation anstrebt, sollte sich deshalb überlegen, ob der Umweg über ITIL 4 überhaupt noch lohnt oder ob der direkte Weg in die Version 5 der kürzere ist.

Woran der Umstieg in echten Projekten scheitert

Der häufigste Fehler ist das Mapping-Denken: Man legt eine Tabelle an, links die 26 v3-Prozesse, rechts die 34 Practices, und hakt Zeile für Zeile ab. Das geht schief, weil eine Practice mehr umfasst als ein Prozess. Sie schließt Rollen, Kompetenzen, Werkzeuge, Lieferanten und Informationen ein, also alles, was die vier Dimensionen abdecken. Eine saubere Prozessbeschreibung ergibt noch keine Practice.

Der zweite Fehler ist, die Phasen still weiterleben zu lassen. Wenn im Werkzeug weiterhin ein Ticket erst nach Design, dann nach Transition und dann in den Betrieb wandert, hat sich nur das Etikett geändert. Der Test ist einfach: Nimm einen echten Ablauf, etwa den Weg eines Serviceantrags vom Eingang bis zur Bereitstellung, und zeichne auf, welche Aktivitäten er tatsächlich in welcher Reihenfolge berührt. Wenn dabei Engage zweimal vorkommt, arbeitest du bereits mit Wertströmen.