Was ist Change Enablement?

Wozu Change Enablement da ist

ITIL 4 beschreibt den Zweck der Praktik so: die Zahl erfolgreicher Änderungen an Services und Produkten zu maximieren, indem Risiken richtig bewertet, Änderungen autorisiert und der Change Schedule verwaltet werden. Das Wort „maximieren“ ist bewusst gewählt. Erfolg misst sich nicht daran, wie viele Änderungen verhindert wurden, sondern wie viele ohne Schaden durchgehen.

Daraus ergeben sich drei Kernaufgaben, die in jeder Organisation vorkommen, egal wie schlank oder umfangreich der Prozess ist:

• Risiko bewerten

  Welche Services sind betroffen, was passiert, wenn die Änderung schiefgeht, und gibt es einen Rückweg? Die Tiefe der Prüfung richtet sich nach dem Risiko.

• Autorisieren

  Eine dafür bestimmte Change Authority gibt die Änderung frei oder lehnt sie ab. Wer das ist, hängt von der Art der Änderung ab.

• Change Schedule führen

  Ein gemeinsamer Kalender zeigt, welche Änderungen wann geplant sind, damit sie sich nicht gegenseitig stören und Fachbereiche sich darauf einstellen können.

Auf Deutsch lässt sich der Name am ehesten mit „Änderungen ermöglichen“ wiedergeben. In deutschen Organisationen bleibt meist der englische Begriff stehen, weil auch die Zertifizierungsunterlagen ihn verwenden.

Was in ITIL als Change zählt

Ein Change ist das Hinzufügen, Ändern oder Entfernen von etwas, das sich direkt oder indirekt auf Services auswirken kann. Das umfasst deutlich mehr als Software-Releases: eine geänderte Firewall-Regel, ein Wechsel des Dienstleisters, ein neuer Serverstandort oder eine veränderte Zuständigkeit im Support fallen genauso darunter.

Deshalb legt jede Organisation zuerst fest, was überhaupt durch das Verfahren läuft. Ziehst du die Grenze zu weit, erstickt die Praktik an Bagatellen. Ziehst du sie zu eng, laufen genau die Änderungen an der Bewertung vorbei, die später den Ausfall verursachen.

Die drei Change-Arten

ITIL unterscheidet drei Arten von Changes. Sie unterscheiden sich vor allem darin, wie und wann die Freigabe erfolgt:

Wer Änderungen sauber einsortiert, gewinnt Tempo. Je mehr wiederkehrende Arbeit als Standard Change beschrieben ist, desto weniger landet in der Einzelfreigabe, und desto mehr Aufmerksamkeit bleibt für die wenigen wirklich riskanten Vorhaben.

Change Authority: wer freigibt

Change Authority ist in ITIL keine bestimmte Stelle, sondern eine Rolle: die Person oder Gruppe, die für eine bestimmte Art von Änderung entscheiden darf. Für einen Standard Change ist die Authority einmalig bei der Freigabe des Musters tätig. Für Normal Changes kann sie je nach Risiko eine einzelne Führungskraft, ein Kollege im Peer Review, ein Gremium oder eine automatisierte Prüfung in der Deployment-Pipeline sein.

Das klassische Change Advisory Board (CAB) aus ITIL v3 ist damit eine Möglichkeit unter mehreren, keine Pflicht. ITIL 4 empfiehlt, die Entscheidung so nah wie möglich an die Fachleute zu legen, die die Änderung verstehen. Wer alle Entscheidungen an ein zentrales Board hängt, macht dessen Sitzungskapazität zur Obergrenze der Änderungsgeschwindigkeit.

Warum der Name gewechselt hat

In ITIL v3 hieß der Prozess Change Management, in der ersten Fassung von ITIL 4 aus dem Jahr 2019 Change Control und kurz darauf Change Enablement. Hinter der Umbenennung steckt eine Haltung: Die Praktik soll Änderungen ermöglichen und nicht als Schranke wirken. Wenn ein Team mehrfach täglich ausliefern kann, aber zwei Wochen auf ein wöchentlich tagendes Gremium wartet, hat die Freigabe den Nutzen der schnellen Lieferung aufgezehrt.

Der neue Name hat auch eine Verwechslung entschärft. Change Management meint im Unternehmen meist die Begleitung von Menschen durch organisatorische Veränderungen, also etwas völlig anderes als die Freigabe einer Firewall-Regel. Auch in ITIL 5 bleibt Change Enablement eine eigene Practice, behandelt im Practice-Manager-Modul Plan, Implement & Control.