13.3 Genehmigungen, Change Authority, CAB und Change-Kalender
Kurz erklärt
Nicht jede Änderung darf sofort umgesetzt werden.
Abhängig vom Risiko, den Auswirkungen und der Bedeutung eines Changes müssen geeignete Personen oder Gremien über dessen Durchführung entscheiden.
ITIL verwendet hierfür den Begriff Change Authority.
Zusätzlich unterstützen ein Change Advisory Board (CAB) sowie ein Change-Kalender die koordinierte Planung und Durchführung von Änderungen.
Warum Genehmigungen notwendig sind
Änderungen können erhebliche Auswirkungen auf IT-Services haben.
Beispiele:
- Ausfall geschäftskritischer Systeme,
- Sicherheitsprobleme,
- Datenverlust,
- Unterbrechung der Produktion,
- Beeinträchtigung mehrerer Standorte.
Deshalb sollte vor der Umsetzung geprüft werden,
ob der erwartete Nutzen die möglichen Risiken rechtfertigt.
Was ist eine Change Authority?
die über einen Change entscheidet.
ITIL schreibt keine feste Rolle vor.
Je nach Organisation kann dies beispielsweise sein:
- Teamleiter,
- Service Owner,
- Change Manager,
- Fachbereich,
- Projektleitung,
- IT-Leitung.
Die Entscheidung richtet sich nach Risiko und Auswirkungen des Changes.
Nicht jeder Change benötigt dieselbe Genehmigung
Ein Standard Change ist bereits vorab genehmigt.
Ein Normal Change benötigt häufig eine individuelle Freigabe.
Ein Emergency Change nutzt meist ein beschleunigtes Genehmigungsverfahren.
Die Genehmigung sollte immer zum Risiko passen.
Genehmigungen nach Risiko
Ein mögliches Beispiel:
| Risiko | Mögliche Change Authority |
|---|---|
| gering | Teamleitung |
| mittel | Change Manager |
| hoch | Change Authority oder CAB |
| sehr hoch | Management oder Geschäftsleitung |
Die konkrete Zuordnung legt jede Organisation selbst fest.
Was ist ein Change Advisory Board (CAB)?
Ein Change Advisory Board (CAB) ist ein beratendes Gremium.
Es unterstützt die Change Authority,
indem es Änderungen bewertet und Empfehlungen ausspricht.
Das CAB entscheidet nicht automatisch selbst über jeden Change.
Die endgültige Entscheidung trifft die zuständige Change Authority.
Aufgaben des CAB
Das CAB unterstützt beispielsweise bei:
- Risikobewertung,
- Auswirkungsanalyse,
- Terminplanung,
- Ressourcenplanung,
- Konflikterkennung,
- Priorisierung,
- Abstimmung zwischen Teams.
Dadurch verbessert sich die Qualität von Entscheidungen.
Mögliche Teilnehmer eines CAB
Je nach Change können unterschiedliche Personen beteiligt sein.
Beispiele:
- Change Manager,
- Service Owner,
- Systemadministratoren,
- Netzwerkadministratoren,
- Information Security,
- Fachbereiche,
- Projektleitung,
- Lieferanten.
Nicht jeder Teilnehmer ist bei jedem Change erforderlich.
Emergency CAB (ECAB)
Für besonders dringende Änderungen kann ein Emergency Change Advisory Board (ECAB) eingesetzt werden.
Es besteht meist aus wenigen entscheidungsbefugten Personen.
Dadurch können dringende Entscheidungen schneller getroffen werden.
Typische Situationen:
- kritische Sicherheitslücke,
- Produktionsausfall,
- Ransomware-Angriff,
- schwerwiegender Netzwerkausfall.
Der Change-Kalender
Ein Change-Kalender dokumentiert,
wann geplante Änderungen stattfinden.
Typische Informationen:
- Termin,
- betroffene Services,
- Verantwortliche,
- Wartungsfenster,
- Status,
- Risiko.
Dadurch lassen sich Überschneidungen vermeiden.
Vorteile eines Change-Kalenders
Ein Change-Kalender hilft dabei,
- Kollisionen zu vermeiden,
- Wartungsfenster zu koordinieren,
- Ressourcen besser zu planen,
- betroffene Teams rechtzeitig zu informieren,
- Risiken zu reduzieren.
Er verbessert die Übersicht über geplante Änderungen.
Beispiel eines Change-Kalenders
| Datum | Service | Art des Changes |
|---|---|---|
| 12.09. | VPN | Softwareupdate |
| 13.09. | ERP | Datenbankupdate |
| 14.09. | Firewall | Firmwareupdate |
| 15.09. | WLAN | Controller-Aktualisierung |
So erkennen Administratoren frühzeitig mögliche Konflikte.
Warum Terminüberschneidungen problematisch sind
Werden mehrere kritische Änderungen gleichzeitig durchgeführt,
kann dies zu Problemen führen.
Beispiel:
- Firewall-Update,
- Core-Switch-Austausch,
- Storage-Migration
am selben Abend.
Bei einer Störung wird die Ursachenanalyse deutlich erschwert.
Der Change-Kalender hilft,
solche Situationen zu vermeiden.
Wartungsfenster
Viele Changes werden innerhalb geplanter Wartungsfenster durchgeführt.
Typische Vorteile:
- geringere Auswirkungen auf Benutzer,
- besser planbare Arbeiten,
- ausreichende Zeit für Rollback,
- koordinierte Kommunikation.
Wartungsfenster sollten frühzeitig angekündigt werden.
Kommunikation vor einem Change
Vor größeren Änderungen sollten relevante Personen informiert werden.
Beispiele:
- Benutzer,
- Service Desk,
- Administratoren,
- Management,
- externe Dienstleister.
Die Information sollte unter anderem enthalten:
- Zeitpunkt,
- betroffene Services,
- erwartete Auswirkungen,
- Ansprechpartner.
Dokumentation der Genehmigung
Jede Genehmigung sollte nachvollziehbar dokumentiert werden.
Beispiele:
- wer genehmigt hat,
- Zeitpunkt,
- Risiko,
- Bedingungen,
- besondere Auflagen.
Dadurch bleiben Entscheidungen transparent.
Praxisbeispiel
Ein Unternehmen plant,
die Firmware aller Core-Switches zu aktualisieren.
Die Risikobewertung ergibt:
- hoher Business Impact,
- mehrere Standorte betroffen.
Der Change wird:
- im CAB besprochen,
- in den Change-Kalender eingetragen,
- für ein Wartungsfenster am Wochenende geplant.
Alle betroffenen Fachbereiche werden vorab informiert.
Typische Fehler
Fehler 1
Änderungen werden ohne Genehmigung durchgeführt.
Fehler 2
Der Change-Kalender wird nicht gepflegt.
Fehler 3
Mehrere kritische Changes finden gleichzeitig statt.
Fehler 4
Das falsche Entscheidungsgremium wird beteiligt.
Fehler 5
Emergency Changes werden nicht dokumentiert.
Fehler 6
Benutzer werden nicht informiert.
Fehler 7
Genehmigungen sind nicht nachvollziehbar.
Fehler 8
Wartungsfenster werden nicht eingehalten.
Fehler 9
Externe Dienstleister werden zu spät eingebunden.
Fehler 10
CAB-Sitzungen beschäftigen sich mit Standard Changes,
die bereits vorab genehmigt sind.
Checkliste Genehmigung
- Change-Typ bestimmt
- Risiko bewertet
- Change Authority festgelegt
- Genehmigung dokumentiert
- Verantwortlichkeiten bekannt
- Bedingungen berücksichtigt
- Kommunikation geplant
- Umsetzung freigegeben
Checkliste Change-Kalender
- Termin eingetragen
- Wartungsfenster abgestimmt
- Überschneidungen geprüft
- betroffene Services dokumentiert
- Verantwortliche bekannt
- Benutzer informiert
- Rollback berücksichtigt
- Monitoring vorbereitet
Bedeutung für Fachinformatiker für Systemintegration
Fachinformatiker sind häufig an der Vorbereitung und Umsetzung von Changes beteiligt.
Typische Aufgaben:
- Risiken einschätzen,
- technische Informationen bereitstellen,
- Wartungsfenster abstimmen,
- Change-Kalender pflegen,
- Änderungen dokumentieren,
- Benutzer informieren,
- Monitoring nach dem Change überwachen.
Sie liefern wichtige Entscheidungsgrundlagen für die Change Authority.
Zusammenfassung
Change planen
↓
Risiko bewerten
↓
Change Authority bestimmen
↓
Genehmigung einholen
↓
Change-Kalender aktualisieren
↓
Beteiligte informieren
↓
Umsetzung vorbereiten
Merksätze
Die Change Authority entscheidet über einen Change.
Das CAB unterstützt die Entscheidung – es ersetzt sie nicht.
Standard Changes benötigen normalerweise keine erneute Genehmigung.
Ein gepflegter Change-Kalender verhindert Konflikte zwischen Änderungen.
Gute Kommunikation reduziert Risiken und Überraschungen.
Verwandte Seiten
- 13.1 Ziele und Grundlagen des Change Enablement
- 13.2 Change-Typen und Risikobewertung
- 13.4 Umsetzung, Tests und Rollback
- 13.5 Zusammenspiel mit Incident, Problem, Service Configuration Management und Monitoring
- Service Configuration Management
- Incident Management
- Monitoring and Event Management
Quellen und Versionsstand
Offizielle Grundlagen
- PeopleCert – ITIL Practice Guide: Change Enablement
- ITIL Foundation – Version 5
Einordnung
ITIL verwendet den Begriff Change Authority für die Person oder Gruppe, die einen Change genehmigt. Ein Change Advisory Board (CAB) besitzt in ITIL eine beratende Funktion und unterstützt die Entscheidungsfindung. Der Einsatz eines CAB, eines Emergency CAB (ECAB) und eines Change-Kalenders richtet sich nach Größe, Komplexität und Risiko der jeweiligen Organisation.
Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: aktuelle ITIL-4-Practice-Guidance
Fachlicher Stand: August 2026