Änderungen freigeben, ohne alles auszubremsen

Drei Änderungsarten, drei Entscheidungswege

Ein Standard Change ist keine kleine Änderung, sondern eine wiederholbare mit hinterlegtem Modell: Ablauf, Risikobewertung und Freigabe sind einmal beschlossen worden und gelten für jede weitere Ausführung. Wer dieses Modell nicht schriftlich hat, hat keinen Standard Change, sondern eine Gewohnheit.

Ein Normal Change durchläuft die Einzelbewertung, und wie tief die ausfällt, richtet sich nach Risiko und Auswirkung. Genau hier entscheidet sich, ob der Ablauf trägt. Eine einzige Freigabestufe für alles erzeugt entweder unnötige Wartezeit bei kleinen Änderungen oder zu wenig Prüfung bei großen.

Der Emergency Change ist der Weg für Änderungen, die eine laufende oder unmittelbar drohende schwere Störung beheben. Er verkürzt die Bewertung, nicht die Dokumentation. Die Nachweise werden nachgezogen, sobald der Betrieb wieder steht.

Change Authority ist eine Zuordnung, kein Gremium

ITIL 4 spricht von der Change Authority, also von der Person oder Gruppe, die eine bestimmte Änderungsart autorisieren darf. Das kann ein Board sein, oft ist es aber sinnvoller, die Autorität nach Risikoklasse zu verteilen, damit eine Anpassung an einem Testsystem nicht auf denselben wöchentlichen Termin wartet wie ein Rechenzentrumsumzug.

Das Change Advisory Board aus der v3-Welt lebt in vielen Organisationen weiter und ist dort nützlich, wo tatsächlich Abhängigkeiten zwischen Bereichen besprochen werden müssen. Zum Engpass wird es, sobald es die einzige Instanz für alles ist. Der zuverlässigste Hinweis darauf ist ein wachsender Anteil an Emergency Changes.

Warum die Practice Enablement heißt

In der ersten ITIL-4-Foundation-Ausgabe trug die Practice noch den Namen Change Control, mit den Practice Guides wurde daraus Change Enablement. Die Umbenennung ist kein Etikett: Der Auftrag lautet, so viele Änderungen zu ermöglichen, wie das Geschäft braucht, und dabei das Risiko beherrschbar zu halten. Eine Practice, die vor allem Anträge ablehnt, erfüllt ihren Zweck nicht.

Praktisch heißt das, den Anteil der Standard Changes bewusst zu erhöhen. Jede wiederkehrende Änderung, die mehrfach ohne Zwischenfall durchgelaufen ist, ist ein Kandidat für ein Modell. Das ist der einzige Hebel, der die Wartezeit senkt, ohne die Prüfung zu schwächen.

Die Stellen, an denen der Ablauf kippt

Der Change-Kalender wird zur Pflichtübung, sobald niemand ihn liest. Sein Zweck ist die Kollisionsprüfung: zwei Änderungen am selben Wochenende an Systemen, die voneinander abhängen, und hinterher kann niemand sagen, welche die Störung ausgelöst hat. Dafür braucht der Kalender die Verknüpfung zu den betroffenen Configuration Items und nicht nur einen Termin.

Der Rückfallplan ist die zweite Stelle. Er gehört in den Antrag und nicht in den Kopf der Person, die die Änderung durchführt, und er braucht die Angabe, bis wann die Rückkehr überhaupt noch möglich ist. Nach einer Datenmigration ist dieser Punkt oft deutlich früher erreicht, als im Antrag steht.

Die dritte Stelle ist die Nachbetrachtung. Ein Post Implementation Review, das nur nach gescheiterten Änderungen stattfindet, erzeugt Rechtfertigungsdruck statt Erkenntnis. Tragfähiger ist eine Stichprobe über erfolgreiche Änderungen, denn dort wird sichtbar, welche Prüfschritte tatsächlich etwas gebracht haben.