Beschreibe die drei Change Kategorien in der ITIL
Die Genehmingungskompetenzen der Changes existieren auf unterschiedlichen Ebenen und orientieren sich nach den Auswirkungen des Changes.
Es existieren drei Change Kategorien in der ITIL: Minor, Significant und Major Changes, die sich nach der Änderungsauswirkung unterscheiden.
Je nach Änderungsauswirkung findet die Genehmigung des Changes auf unterschiedlichen Ebenen statt.
Standard Changes werden auf lokaler Ebene durch die sogenannte lokale Autorisierung genehmigt.
Die sogenannten Minor Changes mit geringem Risiko werden durch den Change Manager autorisiert.
Significant Changes, die nur einen Service oder Organisationseinheit betreffen bedürfen der Genehmigung des CAB/ECAB.
Major Changes hingegen, die mehrere Services bzw. Organisationseinheiten betreffen, werden durch die IT-Steering Group genehmigt.
Für die Freigabe von z.B. strategischen Programmen und Changes mit hohem Risiko und hohen Kosten ist Autorisierung durch die Geschäftsleitung erforderlich.
Beschreibe den Ablauf für Standard Changes
Der Ablauf für Standard Changes besitzt deutlich weniger Aktivitäten, da bei einem Standard Change davon ausgegangen wird, dass dieser bereits einmal als Normal Change alle relevanten Aktivitäten durchlaufen hat und somit dessen Planung, Entwicklung und Auswirkungen dokumentiert ist. Somit sind hier lediglich das Deployment des Changes und der PIR vorgesehen. Werden in einem Standard Change Probleme festgestellt, wird dieser in die Kategorie Normal Change zurückgestuft. Neben der Tatsache, dass ein Standard Change vorher einmal als Normal Change existiert haben muss, darf es auch nur eine ausführende Stelle in der Organisation geben.
Was ist das CAB?
Im Normal Change Ablauf wird dieser RFC je nach Kritikalität vom entsprechend befugtem Gremium freigegeben.
Das Change Advisory Board (CAB) ist eine solche Instanz, welches den Changeantrag diskutiert und entweder eine Freigabe für die Planung (Plan), die Erstellung (Build) und das Testen (Test) des Changes erteilt, oder der RFC im CAB Meeting verworfen wird.
Wie lautet der Ablauf des Normal Changes nach dem Test des Changes?
In einem weiteren Schritt im Ablauf des Normal Changes wird nach dem Test des Changes (u.U. mit erheblicher zeitlicher Verzögerung) die Genehmigung zum Einbringen der Änderung in die Produktivumgebung durch ein Approval der zuständigen Genehmigungsinstanz eingeholt.
Nun kann das Deployment des Changes mit zugehöriger Dokumentation stattfinden.
Der Abschluss dieses Ablaufes im Normal Change wird durch den Post Implementation Review (PIR) gebildet, in dem die Erkenntnisse des Changes in Bezug auf Verbesserungspotentiale in das Configuration Management System (CMS) überführt werden.
Wie ist der Ablauf eines Change-Management Prozesses?
Was ist das CMS?
Configuration Management System (CMS)
In dieser zentralen Datensammlung des CMS laufen alle relevanten Informationen der Changes zusammen, um hieraus weiter Schlüsse für Folgeänderungen ziehen zu können
Was ist ein Change-Review?
Der beantragte Change wird in einem Change-Review, je nach Kategorie des Changes, dem entsprechenden Subprozess (Normal, Emergency oder Standard zugeordnet)
Wie sieht es mit der Änderung im Emergency Change Subprozess aus?
Der Emergency Change Subprozess geht von einer ungeplanten Änderung aus.
Daher existiert die Instanz des Emergency Change Advisory Board (ECAB), welche die Autorität zur Freigabe bzw. Approval des Change Deployments besitzt, um zeitliche Verzögerungen in der Ausfallsituation zu reduzieren.
Der Emergency Change wird sodann in Deployment verteilt und 2 analog zum Normal Change im PIR bewertet, um auch hier Erkenntnisse für zukünftige Changes zu gewinnen
Wozu dient das Change Enablement?
Die Aufgabe des Change Enablement besteht in der Maximierung erfolgreicher Changes in der Organisation durch eine strukturierte Durchführung auf Basis einer Riskobewertung. U.a. für die Konsistenz der CMDB ist es erforderlich, dass Änderungen an der Infrastruktur (den CIs) gemanagt werden.
Die Änderung eines CI wird als Change bezeichnet und ist nach ITIL wie folgt definiert: Hinzufügen, Modifizieren oder Entfernen eines Elementes (CI), das Auswirkungen auf ITServices haben könnte.
Wie sehen die Abläufe von Normal, Emergency und Standard Change vergleichsweise ungefähr aus?
Was ist der Ausgangspunkt für einen Change? Welche möglichen Abläufe gibt es für Änderungen?
Der Ausgangspunkt eines Changes wird durch den Antrag auf eine Änderung gebildet, dem sogenannten Request for Change (RFC). Hiermit wird das Change Enablement initiiert.
Das Änderungsmanagement sieht insgesamt drei mögliche Abläufe für Änderungen vor: den Normal Change, den Emergency Change und den Standard Change.
Der Normal Change behandelt geplante Änderungen mit Auswirkungen auch auf andere Prozesse bzw. Services.
Der Emergency Change behandelt Änderungen, die im Zuge von Ausfällen/Störungen auftreten und der Standard Change behandelt Änderungen, die keine großen Auswirkungen auf andere Prozesse erwarten lassen und bereits einmal durchgeführt wurden (z.B. Anlegen eines Benutzeraccounts).
Was beinhaltet ein RFC?
Inhalt des RFC sollte eine kurze Beschreibung der geplanten Änderung mit Zeitplanung und Risikoanalyse sein.
Was ist zur Kategorisierung von Changes hilfreich?
Bei der Analyse zur Kategorisierung von Changes ist die 7R-Methode des ITSM hilfreich, in der die geplanten Changes in Bezug auf die folgenden Fragen untersucht werden sollten.
Raise:
Wer hat den Change eröffnet?
Reason:
Wozu dient der Change?
Return:
Was bringt der Change? Was bedeutet es, ihn nicht durchzuführen?
Risk:
Welche Risiken bestehen?
Ressources:
Was oder Wer wird benötigt?
Responsibles:
Wer führt den Change durch?
Relationships:
Welche Abhängigkeiten zu anderen Services/CIs bestehen?
Zuletzt geändertvor einem Jahr
