Ablaufdiagramm Change-Management-Prozess (ITIL)

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Rollen

   Ersetzen Sie Antragsteller, Change-Manager, CAB, umsetzendes Team und Service-Verantwortlicher durch die Funktionen, die es bei Ihnen gibt. In vielen Organisationen ist dieselbe Person Change-Manager und CAB-Vorsitz, und kleinere Teams haben gar kein eigenes umsetzendes Team. Führen Sie diese Bahnen zusammen, statt eine Struktur zu zeichnen, die Sie nicht haben, und bleiben Sie bei höchstens fünf Bahnen — sonst ist das Diagramm nicht mehr auf einen Blick lesbar.

2. Definieren Sie Ihre drei Änderungsarten an der Triage-Entscheidung

   Halten Sie neben der Entscheidung „Änderungsart?“ fest, was bei Ihnen als Standard, Normal und Notfall gilt, und setzen Sie die Grenzen nach Risiko und Wirkungsbreite statt nach Aufwand oder Ticketgröße. Halten Sie die Liste vorab freigegebener Standardänderungen kurz genug, dass sie tatsächlich jemand pflegt, und geben Sie jeder Standardänderung ein dokumentiertes Änderungsmodell, dem sie folgen muss.

3. Benennen Sie die Änderungsinstanz, ihren Takt und ihr Notfallpendant

   Halten Sie am Schritt „CAB prüft die Änderung“ fest, wer freigibt, wie oft das Gremium tagt und wann Einreichungsschluss für die Tagesordnung ist. Regeln Sie das ECAB separat: Wer eine Behebung außerhalb der Geschäftszeiten freigeben darf, ist selten das gesamte Gremium. Die Regel, auf die sich die meisten Teams einigen, lautet: innerhalb von Minuten freigeben, den Datensatz am selben Tag schreiben, im nächsten CAB nachbetrachten.

4. Legen Sie fest, was die Bewertung enthalten muss

   Machen Sie aus „Bewertung und Rollback-Plan dokumentieren“ eine echte Checkliste: betroffene Services und Nutzer, Risikostufe, Abhängigkeiten, Ausfallfenster, Testansatz, Rollback-Schritte und wer sie ausführt. Die CAB-Entscheidung ist nur so gut wie dieser Nachweis — und genau dieses Dokument verlangt ein Auditor Monate später.

5. Machen Sie Terminplanung und Kollisionsregeln ausdrücklich

   Halten Sie Ihre Freeze-Zeiträume, Mindestvorlaufzeiten und die Verantwortung für den Änderungskalender fest. Die Kollisionsprüfung in diesem Diagramm ist bewusst eine Entscheidung und keine Formalie, denn die meisten Überschneidungen entstehen, weil zwei Teams dieselbe Abhängigkeit berühren, nicht dasselbe System. Legen Sie vorab fest, ob eine Kollision Neuterminierung oder Eskalation bedeutet.

6. Definieren Sie Erfolg und veröffentlichen Sie das Verfahren versioniert

   Halten Sie fest, was „Änderung erfolgreich?“ bei Ihnen bedeutet: welche Smoke-Tests, wie lange der Service-Verantwortliche beobachtet und was die Rollback-Entscheidung auslöst. Teilen Sie das Diagramm dann dort, wo die Arbeit stattfindet — neben dem Änderungsantragsformular oder im Runbook —, holen Sie die Freigabe der darin benannten Personen ein und bewahren Sie die früheren Fassungen auf, damit Sie belegen können, wann sich das Verfahren geändert hat und warum.

Häufig gestellte Fragen

Ist das IT-Change-Management oder organisatorisches Veränderungsmanagement?

IT-Change-Management. Beide teilen sich den Namen und sonst fast nichts. Dieses Ablaufdiagramm zeigt den operativen Prozess nach ITIL für Änderungen an Produktivservices: Ein RFC wird gestellt, triagiert, bewertet, freigegeben, terminiert, umgesetzt, verifiziert und geschlossen. Organisatorisches Veränderungsmanagement ist die menschenseitige Disziplin, die Mitarbeitende bei der Übernahme einer neuen Arbeitsweise begleitet, üblicherweise strukturiert nach Modellen wie ADKAR oder den acht Schritten von Kotter — ohne CAB, ohne Änderungskalender und ohne Rollback-Plan. Wenn Sie Stakeholder-Analyse und Kommunikationsplanung suchen, ist das hier das falsche Diagramm.

Was ist der Unterschied zwischen Standardänderung, normaler Änderung und Notfalländerung?

Eine Standardänderung ist risikoarm, wiederkehrend und gegen ein dokumentiertes Änderungsmodell vorab freigegeben; sie braucht keine Einzelfreigabe und geht direkt in die Terminplanung. Eine normale Änderung ist alles, was für sich bewertet und freigegeben werden muss — der Weg über die Risiko- und Auswirkungsanalyse ins CAB. Eine Notfalländerung ist eine Änderung, bei der das Warten auf das nächste CAB mehr Schaden anrichten würde als die Änderung selbst; sie erhält eine beschleunigte Freigabe durch das ECAB. In diesem Diagramm laufen alle drei auf denselben Änderungskalender, dieselbe Umsetzung und dasselbe Review zu, denn die Kategorie ändert den Freigabeweg, nicht den Datensatz.

Muss wirklich jede Änderung durch das CAB?

Nein — und alles dorthin zu schicken ist der schnellste Weg, Menschen dazu zu bringen, am Prozess vorbeizuarbeiten. Das CAB gibt es, um Änderungen zu prüfen, deren Risiko noch nicht verstanden ist. Sobald eine Änderungsart oft genug durchgeführt wurde, dass es ein verlässliches Verfahren und ein bekanntes Fehlerbild gibt, stufen Sie sie mit dokumentiertem Modell zur Standardänderung hoch und nehmen sie von der Tagesordnung. Ein CAB, das seine Sitzung mit dem Abnicken von Routinearbeit verbringt, prüft nichts mehr — und der Rückstau, den es erzeugt, drängt die wirklich riskanten Änderungen in den Notfallweg.

Was passiert, wenn eine Änderung fehlschlägt?

Sie nimmt denselben Weg zum Abschluss wie eine erfolgreiche. In diesem Diagramm löst eine nicht bestandene Verifizierung an „Änderung erfolgreich?“ den Rollback-Plan in der Bahn des umsetzenden Teams aus, und die zurückgerollte Änderung geht anschließend genauso in das Review nach der Umsetzung und den Abschluss wie eine erfolgreiche. Zwei Dinge lassen das in der Praxis funktionieren: Der Rollback-Plan wurde vor der Umsetzung geschrieben und freigegeben und nicht während der Störung improvisiert, und das Review fragt nicht nur, ob die Änderung funktioniert hat, sondern auch, ob die Änderungsart richtig gewählt war. Ein zweiter Versuch ist ein neuer RFC, damit der gescheiterte Versuch seinen eigenen Datensatz behält.