Ablaufdiagramm Change-Management-Prozess (ITIL)

Was ist ablaufdiagramm change-management-prozess (itil)?

Change Management meint in dieser Vorlage das IT-Service-Change-Management: den stehenden Prozess, den jede Änderung an einem Produktivservice durchläuft, vom gestellten Änderungsantrag bis zum geschlossenen Änderungsdatensatz. Gemeint ist nicht das organisatorische Veränderungsmanagement, also die menschenseitige Disziplin rund um Modelle wie ADKAR oder die acht Schritte von Kotter, auch wenn beides umgangssprachlich „Change-Management-Prozess“ heißt. Gezeichnet ist hier die operative Variante nach ITIL, die ein Change-Manager gemeinsam mit einem Change Advisory Board dauerhaft betreibt.

Der größte Nutzen steckt in einer einzigen Entscheidung ganz vorn: Um welche Art von Änderung handelt es sich? Alles durch dieselbe vollständige Bewertung und dasselbe wöchentliche Gremium zu schleusen, erzeugt einen Rückstau, und ein Rückstau ist genau das, was Menschen dazu bringt, Änderungen am Prozess vorbei durchzuführen. Deshalb triagiert das Diagramm einmal, und zwar früh. Standardänderungen sind gegen ein dokumentiertes Änderungsmodell vorab freigegeben und gehen direkt in die Terminplanung. Normale Änderungen erhalten eine Risiko- und Auswirkungsanalyse und gehen ins CAB. Notfalländerungen bekommen eine beschleunigte Freigabe durch das ECAB und laufen anschließend über exakt denselben Weg aus Terminplanung, Umsetzung und Review, damit eine dringende Behebung nie eine unaufgezeichnete ist.

Das Zweite, was ein Diagramm klärt, ist die Verantwortung, und deshalb ist dieses hier als Swimlane-Diagramm gezeichnet: Antragsteller, Change-Manager, CAB, umsetzendes Team und Service-Verantwortlicher. Der Service-Verantwortliche hat eine eigene Bahn, weil die Verifizierung der Schritt ist, den Teams am häufigsten überspringen. „Es ist ausgerollt“ und „der Service funktioniert“ sind zwei verschiedene Aussagen, und der Unterschied zwischen ihnen ist der ganze Grund, warum es einen Rollback-Pfad gibt. In diesem Diagramm löst eine nicht bestandene Verifizierung den Rollback-Plan aus, und sowohl die erfolgreiche als auch die zurückgerollte Änderung erreichen weiterhin das Review nach der Umsetzung und den Abschluss.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Aufnahme über die Bahnen Antragsteller und Change-Manager: „Änderungsantrag stellen“, „RFC im Änderungsregister erfassen“ und der Vollständigkeitsfilter „Antrag vollständig und zulässig?“, der dünne Anträge über „Fehlende Angaben nachreichen“ zurückgibt und danach erneut prüft.
• Die dreifache Triage an der Entscheidung „Änderungsart?“, die Standardänderungen direkt in den Änderungskalender, normale Änderungen in die Risiko- und Auswirkungsanalyse und Notfalländerungen an die Notfallfreigabe durch das ECAB leitet.
• Bewertung und Freigabe: „Risiko und Service-Auswirkung bewerten“, „Bewertung und Rollback-Plan dokumentieren“ als ein Dokument statt eines Ticketverlaufs, danach „CAB prüft die Änderung“ und die Entscheidung „CAB gibt die Änderung frei?“: abgelehnte Änderungen enden am Endpunkt „Änderung abgelehnt und geschlossen“ in der Bahn des Antragstellers.
• Terminplanung, in der der freigegebene, der Notfall- und der Standardpfad auf „Im Änderungskalender terminieren“ zusammenlaufen und auf die Prüfung „Kollision mit einer anderen Änderung?“ treffen, die Überschneidungen zur Neuterminierung zurückschickt.
• Bau und Umsetzung in der Bahn des umsetzenden Teams: „Änderung bauen und testen“ und anschließend „Im freigegebenen Fenster umsetzen“.
• Verifizierung und Abschluss: Der Service-Verantwortliche prüft mit „Service nach der Änderung verifizieren“ und beantwortet „Änderung erfolgreich?“; ein Nein führt über „Rollback-Plan ausführen“, und beide Ausgänge treffen sich im „Review nach der Umsetzung“ und im Schließen des Änderungsdatensatzes.

Wann Sie diese Vorlage verwenden sollten

• Sie schreiben oder überarbeiten ein Change-Management-Verfahren nach ITIL für einen Service Desk, ein Plattform- oder ein Infrastrukturteam, das bislang aus Gewohnheit und Chatverläufen heraus arbeitet.
• Sie einigen sich darauf, was als Standard-, normale und Notfalländerung gilt, bevor Sie die Änderungsarten in ServiceNow, Jira Service Management oder Freshservice konfigurieren, damit das Werkzeug eine bereits getroffene Entscheidung abbildet und keine erfindet.
• Sie arbeiten neue Change-Manager, CAB-Mitglieder oder Rufbereitschaften ein, die wissen müssen, welche Änderungen eine Freigabe brauchen, wer sie erteilt und was außerhalb der Geschäftszeiten gilt.
• Sie dokumentieren für einen Auditor oder Kunden, wie Änderungen bewertet, freigegeben, getestet und zurückgerollt werden, etwa gegen SOC 2 CC8.1 oder ISO/IEC 27001:2022 Anhang A 8.32. Das Diagramm dokumentiert das Verfahren; der Nachweis sind die Änderungsdatensätze, die es erzeugt.
• Sie wollen Ihre Quote fehlgeschlagener Änderungen nach einem schlechten Quartal senken und müssen sehen, wo Verifizierung und Rollback stehen und wer sie verantwortet.

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.