# 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 **Change Authority** ist die Person oder Gruppe, 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