Ablaufdiagramm Change-Control-Prozess (Änderungslenkung)

Was ist ablaufdiagramm change-control-prozess (änderungslenkung)?

Change Control ist die Reihe von Toren zwischen „jemand möchte etwas ändern“ und „die Änderung ist produktiv“. Jedes Tor erzeugt einen Nachweis: was beantragt wurde, was die Auswirkungsanalyse ergeben hat, wer freigegeben hat, wann umgesetzt wurde, ob die Verifizierung bestanden wurde und was das abschließende Review ergeben hat. In IT- und Engineering-Teams läuft das üblicherweise als Change Management nach ITIL mit einem CAB; in einem regulierten Qualitätsmanagementsystem ist es das Verfahren zur Änderungslenkung, das validierte Prozesse vor stillem Abdriften schützt. Die Form des Prozesses ist in beiden Fällen dieselbe.

Die meisten Fehler im Change Control sind Übergabefehler, keine Prozessfehler. Der Antragsteller weiß nicht, welchen Detailgrad die Bewertung braucht, das CAB prüft einen Ticketverlauf statt einer Bewertung, der Umsetzer baut einen Plan ohne Rollback, und hinterher schließt niemand den Datensatz. Genau deshalb ist diese Vorlage als Swimlane-Diagramm gezeichnet: Antragsteller, Change-Manager, CAB, umsetzendes Team und Qualitätssicherung verantworten jeweils bestimmte Schritte, und das Diagramm zeigt unmissverständlich, wo die Arbeit den Verantwortlichen wechselt.

Die beiden Zweige, die Teams am häufigsten undokumentiert lassen, sind auch die beiden, um die später am meisten gestritten wird: der Notfallpfad und der Umgang mit einer abgelehnten Änderung. Dieses Diagramm enthält beide. Notfalländerungen erhalten eine beschleunigte Freigabe durch den CAB-Vorsitz und laufen anschließend über denselben Umsetzungs- und Review-Weg, sodass sie nie unaufgezeichnet bleiben. Abgelehnte Änderungen gehen mit der CAB-Rückmeldung an den Antragsteller zurück, auf eine Entscheidung, die entweder in eine erneute Bewertung führt oder den Antrag als zurückgestellt schließt.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Aufnahme und Triage über die Bahnen Antragsteller und Change-Manager: Änderungsantrag stellen, Änderung im Änderungsregister erfassen und die dreifache Entscheidung „Änderungsart?“, die Standardänderungen direkt in die Umsetzungsplanung, normale Änderungen in Auswirkungsanalyse und CAB-Review und Notfalländerungen an den CAB-Vorsitz leitet.
• Bewertung: Auswirkungen und Risiko bewerten, Umfang und Ausfallfenster mit dem Antragsteller abstimmen und das Ergebnis in einer einzigen Bewertung dokumentieren, damit das CAB ein Dokument prüft statt eines Kommentarverlaufs.
• Die CAB-Entscheidung „Änderung freigeben?“: Das CAB prüft den Änderungsantrag und gibt ihn entweder in die Umsetzungsplanung frei oder lehnt ihn an den Change-Manager zurück.
• Der Zweig für abgelehnte und zurückgestellte Änderungen: Die CAB-Rückmeldung geht an den Antragsteller, der entweder überarbeitet und erneut einreicht (zurück in die Auswirkungsanalyse) oder den Antrag als zurückgestellt schließt.
• Der Notfallpfad: Dringende Änderungen umgehen die reguläre CAB-Sitzung über die Notfallfreigabe durch den CAB-Vorsitz und laufen danach über exakt denselben Planungs-, Umsetzungs- und Review-Weg.
• Umsetzung und Verifizierung: Umsetzung und Rollback planen, Änderungsfenster terminieren, Änderung im Fenster umsetzen, danach testet und verifiziert die Qualitätssicherung. Eine nicht bestandene Verifizierung löst den Rollback-Plan aus und führt zurück in die Planung; eine bestandene führt in das Review nach der Umsetzung und den Abschluss des Änderungsdatensatzes.

Wann Sie diese Vorlage verwenden sollten

• Sie dokumentieren ein Change-Management-Verfahren nach ITIL für den IT-Betrieb oder ein Plattform-Team, einschließlich der Frage, wer im CAB sitzt und was diesem Gremium vor der Entscheidung vorliegt.
• Sie schreiben eine SOP zur Änderungslenkung für ein Qualitätsmanagementsystem, in dem Änderungen an einem validierten Prozess oder Produkt eine dokumentierte Auswirkungsanalyse und einen benannten Freigebenden brauchen.
• Sie arbeiten neue Change-Manager, CAB-Mitglieder oder Rufbereitschaften ein, die wissen müssen, welche Änderungen eine Freigabe benötigen und welche nicht.
• Sie klären Freigabebefugnisse, bevor Sie den Ablauf in Jira, ServiceNow oder einem QM-System als Workflow konfigurieren, damit das Werkzeug einen abgestimmten Prozess abbildet und keinen erfindet.
• Ein Kunde oder Auditor hat gefragt, wie Änderungen freigegeben, getestet und zurückgerollt werden.

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Rollen

   Ersetzen Sie Antragsteller, Change-Manager, CAB, umsetzendes Team und Qualitätssicherung durch die Rollen und Teams, die es bei Ihnen wirklich gibt. Wenn eine Person zugleich Change-Manager und CAB-Vorsitz ist, führen Sie diese Bahnen zusammen, statt eine Trennung vorzutäuschen. Halten Sie die Zahl der Bahnen bei höchstens fünf, damit das Diagramm lesbar bleibt.

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

   Die Triage trennt bereits Standard, Normal und Notfall. Schreiben Sie auf, was bei Ihnen in welche Kategorie fällt, und notieren Sie diese Schwellen direkt an der Entscheidung. Setzen Sie sie nach Risiko und Wirkungsbreite statt nach Ticketgröße, und halten Sie die Liste vorab genehmigter Standardänderungen kurz genug, dass sie tatsächlich jemand pflegt.

3. Benennen Sie die Änderungsinstanz und ihren Takt

   Halten Sie am Schritt „CAB prüft den Änderungsantrag“ fest, wer freigibt, wie oft das Gremium tagt und wann Einreichungsschluss für die Tagesordnung ist. Regeln Sie die Notfallbefugnis separat, denn wer eine Störungsbehebung außerhalb der Geschäftszeiten freigeben kann, ist selten das gesamte Gremium.

4. Legen Sie fest, was die Bewertung enthalten muss

   Machen Sie aus dem Bewertungsschritt eine echte Checkliste: betroffene Services und Nutzer, Ausfallfenster, Risikostufe, Abhängigkeiten, Testansatz und Rollback-Ansatz. Die CAB-Entscheidung ist nur so gut wie dieser Nachweis, und genau er wird später zum Audit-Trail der Änderung.

5. Regeln Sie Rollback und Verifizierung

   Entscheiden Sie, wer ein Rollback ausführt, wie lange es dauert und wodurch es ausgelöst wird. Definieren Sie danach, was Verifizierung für Ihre Änderungen bedeutet: Smoke-Test, Regressionssuite, Freigabe durch den Service-Verantwortlichen. Passen Sie die Schleife bei nicht bestandener Verifizierung an, wenn Ihre Richtlinie ein sofortiges Rollback statt einer Neuplanung vorsieht.

6. Veröffentlichen Sie das Diagramm und halten Sie es versioniert

   Teilen Sie das Diagramm dort, wo die Arbeit stattfindet, neben dem Änderungsantragsformular oder im Runbook. Überprüfen Sie es nach jeder Änderung, die schiefgelaufen ist, 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

Was ist der Unterschied zwischen Change Control und Change Management?

Change Control ist der enge, verfahrensmäßige Teil: wie eine konkrete Änderung beantragt, bewertet, freigegeben, umgesetzt, verifiziert und geschlossen wird, mit einem Nachweis an jedem Schritt. Change Management ist weiter gefasst und umfasst Strategie, Kategorien, Rollen, Kommunikation und die Weiterentwicklung des Verfahrens selbst. Dieses Ablaufdiagramm zeigt die Änderungslenkung, also das Verfahren, das man üblicherweise zuerst dokumentiert, weil es das ist, wonach im Alltag gearbeitet wird.

Wer sollte eine Änderung freigeben, und braucht wirklich alles ein volles CAB?

Nein. Jede Änderung durch ein vollständiges Gremium zu führen erzeugt einen Rückstau und drängt Menschen dazu, den Prozess zu umgehen. Die meisten Teams arbeiten mit drei Stufen: vorab genehmigte Standardänderungen mit dokumentiertem Verfahren, die keine Prüfung brauchen; normale Änderungen, die ins CAB gehen; und Notfalländerungen, die eine einzelne benannte Instanz freigibt, etwa der CAB-Vorsitz oder die Rufbereitschaftsleitung. Setzen Sie die Schwellen nach Risiko und Wirkungsbreite, nicht nach Ticketgröße, und schreiben Sie sie an die Triage-Entscheidung.

Wie fügen sich Notfalländerungen ein, ohne den Prozess auszuhöhlen?

Eine Notfalländerung verdichtet die Freigabe, sie entfällt nicht. In diesem Diagramm überspringt der Notfallzweig die reguläre CAB-Tagesordnung, erhält aber weiterhin eine ausdrückliche Freigabe, durchläuft weiterhin die Umsetzungsplanung mit Rollback und landet weiterhin im Review nach der Umsetzung und im Abschluss. Die praktische Regel der meisten Teams: innerhalb von Minuten mündlich freigeben, den Änderungsdatensatz aber noch am selben Tag schreiben und jede Notfalländerung im nächsten CAB daraufhin prüfen, ob die Einstufung als Notfall gerechtfertigt war.

Was passiert mit Änderungen, die das CAB ablehnt oder zurückstellt?

Sie brauchen ein ausdrückliches Ende, sonst tauchen sie als unerfasste Arbeit wieder auf. In dieser Vorlage gibt der Change-Manager die Begründung des CAB an den Antragsteller zurück, der dann vor einer Entscheidung steht: überarbeiten und erneut einreichen, was in die Auswirkungsanalyse und eine zweite Prüfung zurückführt, oder das Ergebnis akzeptieren und den Antrag als zurückgestellt schließen. Die Begründung festzuhalten zählt hier genauso viel wie die Entscheidung selbst, denn zurückgestellte Änderungen kommen meist zurück, sobald die blockierende Abhängigkeit wegfällt.

Unterscheidet sich das von der Änderungslenkung für Dokumente oder SOPs?

Ja. Dies ist die generische, IT-betrieblich geprägte Version von Change Control: ein CAB, ein Rollback-Plan sowie ein Umsetzungs- und Verifizierungsschritt, ausgelegt für Änderungen an Systemen und Services. /de/templates/dokumenten-change-control-workflow und /de/templates/sop-change-control-prozess sind engere Varianten derselben Grundform für einen bestimmten Dokumententyp: Das CAB wird dort durch Dokumentenprüfer und -freigeber ersetzt, der Rollback-Plan durch den Einzug der abgelösten Version. Wenn Sie eigentlich die begriffliche Unterscheidung zwischen Versionskontrolle und Change Control suchen und kein Diagramm, siehe /guides/version-control-vs-change-control.