Change-Typen: Standard, Normal, Emergency

In Change Management wird klar: nicht jeder Change muss durchs CAB. Manche Änderungen sind so routinemäßig, gut getestet und risikoarm, dass formale Genehmigung jedes Mal Verschwendung wäre – andere sind so kritisch, dass sie maximale Aufsicht brauchen. Wieder andere müssen gerade jetzt passieren, weil ein Brand zu löschen ist. ITIL unterscheidet deshalb drei Change-Typen: Standard, Normal und Emergency. Jeder hat seinen eigenen Genehmigungspfad, sein eigenes Risikoprofil, seine eigene Dringlichkeit. Diese Lektion zeigt dir die drei Typen mit klaren Beispielen, einen Entscheidungs-Pfad „welcher Typ passt hier?" und die typischen Stolperfallen.

1) Die drei Typen im Vergleich

2) Standard Change – das stille Arbeitspferd

Ein Standard Change ist vorab als Typ genehmigt. Das CAB hat einmal definiert: „Diese Art von Änderung darf jederzeit durchgeführt werden, weil sie risikoarm, gut dokumentiert und tausendfach erprobt ist." Beispiele:

• Neue User-Accounts anlegen (Standard-Profile, Standard-Berechtigungen)
• Mailbox-Erweiterungen auf Standard-Quota
• Druckerinstallation aus dem Standard-Katalog
• Standardsoftware aus dem Software-Katalog installieren
• Reguläre Sicherheits-Patches auf Test-Servern
• Nutzer-Passwort zurücksetzen (auch wenn das oft Self-Service ist)

Voraussetzungen, damit ein Change überhaupt zum Standard wird:

1. Wiederholbar: tritt regelmäßig auf
2. Niedriges Risiko: mehrfach erfolgreich durchgeführt
3. Vor-genehmigt: CAB hat das Pattern formal abgesegnet
4. Dokumentiertes Vorgehen: Schritt-für-Schritt-Anleitung verfügbar
5. Klare Rollback-Strategie: falls doch was schiefgeht

Vorteil: enorme Effizienz. Service Desk und 2nd Level können selbständig arbeiten, das CAB wird entlastet, der Anwender wird schnell bedient. Mehr Service-Anliegen werden zu Service Requests, die per Standard-Change-Workflow umgesetzt werden – oft sogar automatisiert mit Ansible oder ähnlich.

3) Normal Change – der Klassiker

Ein Normal Change ist einzeln zu beantragen und zu genehmigen. Hier läuft der gesamte RFC-Prozess aus der vorigen Lektion: Antrag → Bewertung → CAB → Plan → Umsetzung → PIR. Beispiele:

• Firmware-Update am Core-Switch
• Migration einer Datenbank auf neuere Version
• Einführung einer neuen Anwendung
• Restrukturierung eines AD-Forest
• Verlagerung eines Servers von einem RZ ins andere
• Architektur-Anpassungen an produktiven Systemen

Normal Changes können selbst unterschiedlich groß sein: kleine Konfigurations-Tweaks bis Großprojekt-Migrationen. Manche Organisationen unterteilen weiter in Minor / Major / Significant Normal Changes mit jeweils unterschiedlichen CAB-Eskalationsstufen. Das ist nicht ITIL-Pflicht, aber in der Praxis verbreitet.

4) Emergency Change – das Notfall-Verfahren

Ein Emergency Change ist jetzt sofort nötig, weil ein konkretes, akutes Problem zu bekämpfen ist. Typische Auslöser:

• Cyberangriff läuft, Firewall-Regeln müssen sofort schließen
• Kritischer Service down, nur ein Reboot/Konfig-Wechsel hilft
• Sicherheits-Lücke (Zero-Day) wurde bekannt, sofortiges Patchen
• Hardware-Defekt zwingt zu unmittelbarem Failover
• Compliance-Vorfall, sofortige Zugriffsbeschränkung

Die Genehmigung läuft über das ECAB (Emergency CAB): nicht das volle CAB-Gremium, sondern eine kleine Runde (Change Manager + 1-2 wichtigste Stakeholder), die innerhalb von Minuten erreichbar ist. Auch hier gibt es eine Genehmigung – nicht „einfach machen", sondern bewusste Entscheidung mit dokumentierter Verantwortung. Vollständige Dokumentation wird nach der Umsetzung nachgeholt.

5) Welcher Typ passt? Entscheidungspfad

Anhand weniger Fragen ermitteln, welcher Change-Typ angebracht ist:

6) Die Change-Typen und ihre Tools

7) Antipatterns

• „Wir machen das als Emergency, dann sparen wir uns das CAB." Falsche Verwendung als CAB-Umgehung. Echter Test: Ist jetzt sofort nötig, oder kann es bis nächste CAB-Sitzung warten? Wenn ja → Normal Change.
• Standard-Change-Inflation. Aus Bequemlichkeit werden zu viele Change-Typen pauschal abgenickt. Lösung: Standard-Change-Katalog regelmäßig überprüfen, Kandidaten kritisch hinterfragen.
• Standard-Change-Mangel. Umgekehrt: alles bleibt Normal Change, niemand bemüht sich, Routine-Themen zu standardisieren. Service Desk und CAB ersticken. Lösung: aktiv standardisieren.
• Emergency-Vermeidung um jeden Preis. Manager will keine Emergency Changes in seinem Report → echte Notfälle werden zu „dringenden Normal Changes" umetikettiert. Risiko: Brand wird nicht ausreichend dokumentiert.
• Keine Nachdokumentation nach Emergency. Brand gelöscht, alle gehen nach Hause. Beim nächsten Vorfall fehlen die Daten für die Ursachen-Analyse. Lösung: 48-Stunden-Frist für Nach-Dokumentation, Post-Mortem-Pflicht.
• Change Freeze umgangen. Wichtiger Change „muss raus", obwohl Freeze-Periode. Risiko: ausgerechnet zum schlechtesten Moment Probleme. Lösung: Freezes sind heilig, Ausnahmen nur mit Vorstands-Genehmigung.

Zusammenfassung

ITIL kennt drei Change-Typen: Standard (vorab pauschal genehmigt, niedriges Risiko, häufig wiederholt), Normal (einzeln zu beantragen, durchläuft CAB), Emergency (jetzt sofort nötig, läuft über ECAB). Typische Verteilung: ~70/25/5 %. Voraussetzung für Standard-Change: wiederholbar, niedriges Risiko, dokumentiert, vor-genehmigt, mit klarem Rollback. Normal Changes können weiter in Minor/Major/Significant unterteilt werden. Emergency Changes brauchen schnellen ECAB (Change Manager + 1-2 Stakeholder), volle Dokumentation wird nachgeholt. Entscheidungs-Pfad: 1) Akut? → Emergency. 2) Vorab genehmigter Typ? → Standard. 3) Sonst → Normal. Werkzeuge: Change Calendar, Standard-Change-Katalog, RFC-Templates, Risk-Matrix, Change Freeze Periods. Antipatterns: Emergency als CAB-Umgehung, Standard-Inflation oder -Mangel, fehlende Nachdokumentation nach Emergency, umgangene Freezes.

Verwandte Lektionen: Change Management · Patch-Management · CI/CD · und mehrWeitere relevante LektionenProblem ManagementIncident ManagementKEDBCMDBAnsibleFailoverSLA