So erstellen Sie einen Change-Control-Prozess

So gestalten Sie einen Change-Control-Prozess: Änderungsarten sauber definieren, die Liste der Standardänderungen kurz halten, einen Rollback-Plan verlangen und den Notfallweg zeichnen statt zu verschweigen.

Ein Change-Control-Prozess regelt, wie eine geplante Änderung bewertet, freigegeben, umgesetzt, verifiziert und geschlossen wird: mit Kategorien, die bestimmen, wie genau jede Änderung geprüft wird.

Kurz gesagt

  • Drei Kategorien: Standard, Normal, Notfall, definiert über Risiko und Reichweite, nicht über den Aufwand.
  • Halten Sie die Liste der vorab genehmigten Standardänderungen so kurz, dass sie jemand pflegt.
  • Was der Bewertungsnachweis enthalten muss, gehört in den Prozess, nicht ins Ermessen des Antragstellers.
  • Jede Änderung hat einen Rollback-Plan, und der Rollback führt in die Planung zurück statt ins Nichts.
  • Zeichnen Sie den Notfallweg: die Alternative ist ein undokumentierter.

Ablauf nach Änderungsgegenstand wählen

Die Kategorien entscheiden, ob der Prozess gelebt wird

Ein Change-Control-Prozess steht und fällt mit seinen Kategorien. Schicken Sie jede Änderung durch ein wöchentliches Gremium, finden die Leute Wege, gar keine Änderung mehr anzumelden: aus einem Steuerungsproblem wird damit ein Sichtbarkeitsproblem. Genehmigen Sie zu viel vorab, prüft das Gremium nichts mehr, worauf es ankommt. Die Definition der Kategorien (Standard, Normal, Notfall) ist die eigentliche Entwurfsarbeit, und sie wird meist zuletzt und am unschärfsten geschrieben.

Das zweite, was stimmen muss, ist der Bewertungsnachweis. Ein Change Advisory Board kann nur so gut sein wie das, was ihm vorgelegt wird, und ein Schritt namens „Auswirkungen und Risiko bewerten“ garantiert uneinheitliche Einreichungen. Erst wenn festgeschrieben ist, was der Nachweis enthalten muss (betroffene Services, Ausfallfenster, Risikostufe, Abhängigkeiten, Testvorgehen und Rollback-Ansatz), wird aus dem Gremienbeschluss eine Prüfung statt eines Eindrucks.

Das Beispiel unten zeigt einen Change-Control-Ablauf über fünf Bahnen. Es enthält die drei Wege, die jeder funktionierende Prozess braucht: eine Standardänderung, die das Gremium ganz überspringt, eine normale Änderung über Bewertung und CAB und einen Notfallweg mit eigener Freigabeinstanz, dazu einen Rollback-Pfad, der in die Planung zurückführt statt zu enden.

Dieses Beispiel konzentriert sich auf IT-Services. Für freigegebene physische Teile, Zeichnungen oder Stücklisten zeigt /de/templates/technischer-aenderungsantrag-ecr den illustrativen ECR-014: zusätzlich zu Bewertung und Genehmigung werden Revisionen, wirksame Lose, genehmigte Altbestandsverwendung und Erstmusterprüfung dokumentiert. Genehmigte Dokumentenrevisionen laufen bei /de/templates/dokumenten-change-control-workflow weiter; Freigabenachweise gehen vor Abschluss an die änderungsverantwortliche Person zurück.

Drei Wege durch einen Prozess

Ein Change-Control-Ablauf vom Antrag bis zum Abschluss. Achten Sie darauf, wie die Triage-Entscheidung drei Kategorien in drei verschiedene Richtungen schickt.

  1. Die Triage entscheidet über alles Weitere

    Änderungsantrag stellen, im Änderungsregister erfassen, dann die dreifache Entscheidung „Änderungsart?“. Standardänderungen gehen direkt in die Umsetzung, normale in die Bewertung, Notfälle zu ihrer eigenen Freigabeinstanz, eine Entscheidung, die den Aufwand der gesamten Änderung festlegt.

  2. Die Bewertung ist die Entscheidungsgrundlage des CAB

    Auswirkungen und Risiko bewerten, Umfang und Ausfallfenster abstimmen, die Bewertung dokumentieren, danach CAB-Review und Freigabe. Steht nicht fest, was der Nachweis enthalten muss, verbringt das Gremium seine Sitzung damit, Informationen nachzufordern, statt zu entscheiden.

  3. Eine Ablehnung ist ein Weg, kein Stillstand

    Die CAB-Rückmeldung geht an den Antragsteller, der überarbeiten und erneut einreichen oder die Zurückstellung akzeptieren kann, und hier mündet auch der Notfallweg mit seiner eigenen Freigabe ein. Prozesse ohne Überarbeitungsschleife erzeugen Änderungen, die aufgegeben statt verbessert werden.

  4. Den Rollback vor der Änderung planen

    Umsetzung und Rollback werden gemeinsam geplant, das Änderungsfenster wird terminiert, die Änderung umgesetzt. Erst die gemeinsame Planung macht den Rollback real; nachträglich geschrieben ist er ein Absatz, den nie jemand erprobt hat.

  5. Verifizieren, und bei Fehlschlag zurückspringen

    Änderung testen und verifizieren, bei Fehlschlag den Rollback-Plan ausführen und zurück in die Planung, danach Review nach der Umsetzung und Abschluss. Ein Change-Control-Prozess, der bei der Umsetzung endet, kann gar nicht wissen, ob seine Änderungen wirken.

So funktioniert es

  1. Definieren Sie Ihre drei Kategorien

    Schreiben Sie auf, was in Ihrer Organisation als Standard-, normale und Notfalländerung gilt, gemessen an Risiko und Reichweite, nicht am Aufwand. Eine einzeilige Konfigurationsänderung an einem Zahlungssystem ist keine Standardänderung; ein großes, aber vielfach eingeübtes Routine-Deployment kann eine sein.

  2. Halten Sie die Liste der Standardänderungen kurz und verantwortet

    Standardänderungen funktionieren nur, wenn die Liste gepflegt wird. Geben Sie ihr einen Verantwortlichen und einen Überprüfungstermin und verlangen Sie, dass sich eine normale Änderung mehrfach bewährt, bevor sie aufgenommen wird. Eine ungepflegte Standardliste wird zu dem Weg, den alle für alles nutzen.

  3. Legen Sie fest, was der Bewertungsnachweis enthält

    Machen Sie aus dem Bewertungsschritt eine Checkliste: betroffene Services und Nutzer, Ausfallfenster, Risikostufe, Abhängigkeiten, Testvorgehen, Rollback-Ansatz und wer einbezogen wurde. Keine andere einzelne Änderung verbessert den Nutzen eines Change Advisory Board so deutlich.

  4. Benennen Sie die Freigabeinstanz und ihren Rhythmus

    Wer gibt frei, wie oft tagt das Gremium und wann ist Einreichungsschluss für die Agenda? Benennen Sie die Notfall-Freigabeinstanz danach gesondert: wer eine Störungsbehebung außerhalb der Geschäftszeiten freigeben darf, ist selten das ganze Gremium, und genau diese Lücke führt dazu, dass Notfalländerungen ohne Freigabe laufen.

  5. Verlangen Sie einen Rollback-Plan und klären Sie, wer ihn auslöst

    Jede Änderung bekommt einen, geplant parallel zur Umsetzung. Legen Sie vorab fest, wer die Befugnis hat, ihn auszulösen, wie lange er dauert und welche Schwelle die Entscheidung auslöst: mitten in einer Störung will niemand eine Richtlinie auslegen müssen.

  6. Zeichnen Sie den Notfallweg ehrlich

    Jede Organisation hat einen. Geben Sie ihm Kriterien, eine namentlich benannte Freigabeinstanz und die Pflicht zur nachträglichen Dokumentation innerhalb einer festen Frist. Ein gezeichneter Notfallweg mit Dokumentationspflicht ist eine Kontrolle; ein ungezeichneter ist einfach das, was um drei Uhr nachts passiert.

Häufige Fehler

  • Ein Weg für jede Änderung

    Wer triviale Änderungen durch ein wöchentliches Gremium schleust, erzieht die Organisation dazu, den Prozess zu umgehen, und verliert die Sichtbarkeit über die Änderungen, auf die es ankommt.

  • Unscharfe Anforderungen an die Bewertung

    Das Gremium wird zum Forum für Informationsanfragen statt für Entscheidungen, und die Qualität der Freigabe hängt davon ab, wer die beste Einreichung geschrieben hat.

  • Der Rollback wird nach dem Plan geschrieben

    Ein nachträglich erdachter Rollback ist ungetestet und häufig gar nicht durchführbar. Planen Sie beides gemeinsam: sonst haben Sie keinen.

  • So tun, als gäbe es keine Notfälle

    Den Notfallweg nicht zu dokumentieren, schafft ihn nicht ab: es beseitigt nur die Kriterien, die Zuständigkeit und den Nachweis.

Eigenen Change-Control-Prozess erstellen

Öffnen Sie das Change-Control-Beispiel als eigenes Diagramm, tragen Sie Ihre Änderungsarten ein und benennen Sie Ihre Freigabeinstanz.

Eigenen Change-Control-Prozess erstellen

Verwandte Anleitungen

Häufig gestellte Fragen

Was ist der Unterschied zwischen Change Control und Change Management?

Change Control ist der verfahrensmäßige Teil: wie eine konkrete geplante Änderung beantragt, bewertet, freigegeben, umgesetzt, verifiziert und geschlossen wird, mit einem Nachweis auf jeder Stufe. Change Management ist weiter gefasst: Strategie, Kategorien, Rollen, Kommunikation und die Verbesserung des Verfahrens selbst, in manchen Organisationen zusätzlich die gesamte Begleitung der Menschen im Wandel. Das Diagramm, das zuerst gebraucht wird, ist fast immer Change Control, denn danach wird täglich gearbeitet.

Was sind Standard-, normale und Notfalländerungen?

Eine Standardänderung ist vorab genehmigt, risikoarm und wiederholbar; sie überspringt das Gremium und folgt einem festgelegten Verfahren. Eine normale Änderung durchläuft Bewertung und Freigabe. Eine Notfalländerung wird von einer verkleinerten Instanz freigegeben, weil das Warten auf den regulären Weg mehr Schaden anrichten würde als das Risiko der Änderung. Definieren Sie jede Kategorie über Risiko und Reichweite statt über die Größe und verlangen Sie, dass Notfälle innerhalb einer festen Frist nachdokumentiert werden.

Wer sollte im Change Advisory Board sitzen?

Personen, die Auswirkungen beurteilen und für die betroffenen Services sprechen können: Service-Verantwortliche, der Betrieb, bei Bedarf die Informationssicherheit sowie jemand, der die Kunden- oder Geschäftsauswirkung vertritt. Halten Sie das Gremium klein genug, um entscheidungsfähig zu bleiben, und geben Sie ihm einen Vorsitz mit Stichentscheid. Ein Gremium mit fünfzehn Personen prüft nichts sorgfältig, und wer noch nie einen Einwand erhoben hat, nimmt teil, statt zu prüfen.

Was passiert, wenn eine Änderung die Verifizierung nicht besteht?

Führen Sie den Rollback aus und kehren Sie in die Planung zurück, statt unter Zeitdruck vorwärts zu reparieren. Genau deshalb wird der Rollback-Plan gemeinsam mit der Änderung geschrieben und die Befugnis, ihn auszulösen, vorab benannt. Nach der Wiederherstellung läuft die gescheiterte Änderung mit den gewonnenen Erkenntnissen erneut durch die Bewertung, sie als neue Änderung ohne Vorgeschichte zu behandeln, wiederholt denselben Fehler nur mit anderen Beteiligten.

Was ist der Unterschied zwischen Change Control und Versionskontrolle?

Versionskontrolle identifiziert und merkt sich aufeinanderfolgende Zustände eines einzelnen Artefakts: welcher davon aktuell ist und was ihm vorausging. Change Control ist der umfassendere Prozess von Bewertung über Freigabe und Umsetzung bis zu Verifizierung und Abschluss, der überhaupt erst entscheidet, ob eine vorgeschlagene Änderung stattfinden darf, und der in der Regel eine neue Version erzeugt, sobald sie freigegeben ist. Die begriffliche Unterscheidung im Detail finden Sie unter /de/guides/versionskontrolle-vs-change-control, die dokumententypspezifischen Varianten dieser Struktur unter /de/templates/dokumenten-change-control-workflow und /de/templates/sop-change-control-prozess.

Die Vorlage hinter dieser Anleitung

Ablaufdiagramm Change-Control-Prozess (Änderungslenkung) — Ablaufdiagramm für den Change-Control-Prozess: Änderungsantrag, Auswirkungsanalyse, CAB-Freigabe, Umsetzung mit Rollback-Plan, Verifizierung und Abschluss, mit eigenem Notfallpfad.

Browse all Leitfäden für Qualitätsmanagement und kontinuierliche Verbesserung

Change-Control-Prozess: Antrag → Bewertung → Freigabe → Umsetzung → Review und Abschluss
So erstellen Sie einen Change-Control-Prozess