Change Management (ITIL)
aus Wikipedia, der freien Enzyklopädie
Change Management wird in mehreren Gebieten umschrieben, dieser Artikel bezieht sich auf die Welt der Informatik. In der IT Infrastructure Library (ITIL) wird zwischen den Disziplinen
- Incident Management (Störungsbehebung),
- Problem Management (Problem Eruierung),
- Change Management (Änderungs Kontrollen) und
- Config-/ Asset Management (Inventur der Informatik nachführen) unterschieden.
Diese Disziplinen werden als Service Management umschrieben und betreffen immer alle Teile der Software (SW) Hardware (HW) und Netzwerke einer IT Infrastruktur. Die Disziplin Change Management umfasst das Koordinieren von Veränderungen in der IT und wird in folgendem Artikel im Detail erklärt.
[Bearbeiten] Change-Management
IT wird ein zunehmend kritischerer Faktor für die Unternehmen. Geschäftsanforderungen ändern sich ständig, neue Technologien werden eingesetzt, Anwender fordern einen immer höheren Service-Umfang, um ihre Aufgaben erfüllen zu können. All diese Faktoren bedingen eine IT-Umgebung, in der Management und Kontrolle von Changes sehr genau geregelt sind.
Die Erfahrung zeigt, dass ein hoher Anteil von Problemen bezüglich der IT-Service-Qualität sich bis zu einem Change am System zurückverfolgen lässt. Solche Probleme verursachen enorme geschäftliche Kosten und werden immer weniger akzeptabel. Dieser Artikel beschreibt die Best Practices für Change-Management und geht auf die grundlegende Rolle dieses Bereiches für die Implementierung vieler anderer ITSM (IT Service Management)Best Practices ein. Schliesslich bringt jede Entwicklung der IT-Infrastruktur, ob sie sich nun auf Capacity-Management, Network Services Management oder den Service Desk bezieht, Changes mit sich, die wiederum ein Risiko bedeuten. Daher ist eine sehr strikte Vorgehensweise für ein effektives Change-Management sinnvoll.
[Bearbeiten] Change-Management - Ziele
Es ist das Hauptziel des Change-Management Prozesses sicherzustellen, dass standardisierte Methoden und Verfahren zur Durchführung effizienter und schneller Changes genutzt werden, damit die Auswirkungen von Changes auf die Service Qualität und die Durchführung der Unternehmensaktivitäten minimiert werden. Ein solches Verfahren ist nötig, um eine Balance zwischen dem Bedarf für einen Change und evtl. Auswirkungen des Changes herzustellen. Es ist besonders wichtig, dass der Change-Management Prozess transparent ist und offene Kommunikationsschnittstellen vorsieht, damit Änderungen ohne Störungen in der Produktiv-Umgebung durchgeführt werden können.
[Bearbeiten] Mission Statement
Innerhalb der strategischen Zielsetzung (Mission Statement) hat der Begriff "autorisierte Changes' eine sehr starke Bedeutung und ist genau festgelegt. Man könnte sogar Inflexibilität hineininterpretieren. Aber gute Change-Management-Verfahren werden sowohl den kleinen alltäglichen Changes gerecht, als auch den Changes, die für die sofortige Wiederherstellung eines kritischen Service erforderlich sind oder die Auswirkungen für eine große Anzahl von Kunden haben. Wenn zum Beispiel ein Anwender sein Passwort ändern möchte, wäre ein kompletter Request for Change inkl. anschließender Besprechung des Change Advisory Board für die Genehmigung unangemessen. Auch sollte ein Change, der sofort erfolgen muss, um einen kritischen Service wiederherzustellen, einen schnelleren Bearbeitungspfad durchlaufen als normale Changes. Hierauf wird in diesem Modul noch näher eingegangen.
Manche sehen in der Implementierung umfassender funktionsübergreifender Change-Management-Prozesse mit formeller Dokumentation, Besprechungen und Genehmigungen zusätzliche Bürokratie. Auf den ersten Blick könnte man meinen, dass dieser allumfassende Change-Management-Prozess diejenigen behindern wird, die die Changes durchführen müssen, um den Betrieb der IT-Umgebung aufrecht zu halten. Tatsächlich sollten geeignete Change-Management (und Configuration- Management) Prozesse jedoch die Notwendigkeit ständiger Ad-Hoc-Changes reduzieren, die man in Umgebungen vorfindet, die keine oder keine ausreichenden Change und Configuration-Management-Verfahren umfassen. Ein durchdachter Change und Configuration-Management-Prozess sollte Changes, die erforderlich sind, zügig bearbeiten und genehmigen. Diese genehmigten Changes werden vom IT Management unterstützt und wurden auf Risiko, Kosten und Auswirkungen untersucht.
[Bearbeiten] Prozess Implementierung
In der heutigen Geschäftswelt fordert die Abhängigkeit von IT-Systemen und Technologie vom Management, dass viel Zeit investiert wird in die Abschätzung der Bedeutung von Unternehmensveränderungen auf die IT und des Einflusses von IT Änderungen auf das Unternehmen. Die Verwaltung von Changes ist eine VoIlzeit- Aufgabe geworden. Wenn Changes so verwaltet werden können, dass das Risiko, die Schwere der Auswirkung und mögliche Unterbrechungen optimiert werden und Changes natürlich auch beim ersten Versuch erfolgreich sind, ist es für das Unternehmen von grundlegender Bedeutung, dass dieser Prozess schnell implementiert wird.
[Bearbeiten] Change-Management - Aufgaben
Change-Management ist dafür verantwortlich, den Change Prozess zu verwalten. Der Prozess kümmert und kontrolliert nur, dass Changes genehmigt werden und effizient, kostengünstig und mit minimalem Risiko für die neuen und die bestehenden Services ausgeführt werden. Um dies auf eine geeignete Art durchzuführen, wird ein Prozess benötigt. Aber es werden auch detaillierte Verfahren und Anleitungen gebraucht, wie die verschiedenen Dinge im Prozess durchzuführen sind. Um das Risiko eines jeden Changes einschätzen zu können, ist es sehr wichtig, dass detaillierte Informationen über die einzelnen CIs (Configuration Items) und ihren Relationen zueinander verfügbar sind. Die Bestandteile der IT-Infrastruktur, Configuration Items, werden im Rahmen des Configuration-Managements verwaltet. Das Change-Management umfasst typischerweise:
- Initiieren, Dokumentieren und Autorisieren von Änderungen
- Einschätzung der Auswirkungen, Kosten, Vorteile und Risiken der in Erwägung gezogenen Änderungen
- Rechtfertigung und Genehmigung von Changes
- Planen und Koordinieren der Implementierung von Changes ~ Überwachen und Berichterstattung über die Implementierung
- Prüfung und abschließende Bearbeitung von Request for Changes (RfCs)
Eine wichtige Aufgabe ist, dass Changes geplant werden. Nur geplante und mit einem angemessenen Zeitplan versehene Changes können effektiv kontrolliert werden, da dies sicherstellt, dass genügend Zeit vorhanden ist, um einen Überblick zu erhalten, was getan werden muss und dass getan wird, was getan werden muss. Um effektive, gut geplante Changes durchzuführen brauchen wir Einblick in die benötigten und verfügbaren Ressourcen. Dazu benötigen wir ein gutes Tool.
Kommunikation ist der Schlüssel für einen erfolgreichen Change Prozess. Zuwenig Kommunikation ist oft der Grund, dass Changes nicht korrekt durchgeführt werden und Incidents auftreten. Je mehr Mitarbeiter informiert werden, desto größer ist die Chance, dass der Change angemessen analysiert und überwacht wird, so dass die Durchführung fehlerfrei ist. Daher ist eine Kommunikationsstruktur (z.B. das CAB, Change Advisory Board) notwendig. Wichtig sind natürlich auch Reports. Diese helfen dabei, die Changes selbst bekanntzugeben und wie diese durchgeführt wurden.
[Bearbeiten] Terminologie
Die Definition der Begriffe sind
[Bearbeiten] Change
Das Hinzufügen, Ändern oder Entfernen von genehmigter, unterstützter oder eingefrorener Hardware, Netzwerk, Software, Anwendungen, Umgebungs-Komponenten, Systemen, Desktop Builds, zu ihrer Verwendung notwendiger oder mit ihnen zusammenhängender Konfiguration oder dazugehörender Dokumentation.
[Bearbeiten] Request for Change
Formular (Papier oder Online-Form) das zur Aufnahme von Details eines Änderungsantrags genutzt wird, der sich auf ein beliebiges CI (Configuration Item) innerhalb der Infrastruktur oder auf mit der Infrastruktur verbundene Verfahren oder Geräte bezieht.
[Bearbeiten] Forward Schedule of Changes
Zeitplan, der Details der zur Durchführung genehmigten Changes und deren vorgesehenes Implementierungs-Datum enthält.
[Bearbeiten] Change-Management Prozess
Der prinzipielle Ablauf ist unabhängig davon, ob es sich um einen kleinen Change, wie vielleicht das Erweitern des Arbeitsspeichers eines Servers, oder ein Projekt mit erheblicher Auswirkung auf den bestehenden Betrieb handelt. Auch die Dringlichkeit hat keinen Einfluss auf den Ablauf selbst, jedoch sind die Ablaufgeschwindigkeiten und Prioritäten unterschiedlich. Entscheidende Blöcke im Change-Managementprozess sind
[Bearbeiten] Request for Change
Mit der Antragsstellung durch das Auslösen eines RfCs beginnt der Lebenszyklus eines Changes.
[Bearbeiten] Registrierung und Klassifizierung
Sammeln der benötigten Informationen, um Entscheidungen darüber zu treffen, was geändert werden muss, in welche Kategorie der Change fällt und welche Auswirkungen er hat, um die Genehmigung angemessen durchführen zu können. Eine Priorität und Kategorie wird dem Change basierend auf dessen Auswirkung zugewiesen. Risikoabschätzung ist in diesem Stadium von entscheidender Bedeutung.
[Bearbeiten] Überwachung und Planung
Alle Changes werden unter der Verantwortung des Change-Managements geplant und wenn dies für die optimale Kontrolle des/der Changes notwendig ist, wird ein kompletter Zeitplan (mit Meilensteinen, FSC) bereitgestellt.
[Bearbeiten] Genehmigung
Entscheidung, ob der Change durchgeführt wird oder nicht.
[Bearbeiten] Ausarbeitung & Test
Genehmigte Changes werden zur Ausarbeitung an die entsprechenden technischen Gruppen weitergegeben. Das Change-Management übernimmt, unterstützt durch Release-Management und normales Linien-Management die Koordination, um sicherzustellen dass die Aktivitäten sowohl die erforderlichen Ressourcen bekommen als auch innerhalb des vorgegebenen Zeitplans durchgeführt werden. Um zu verhindern, dass die Changes schwerwiegende Auswirkungen auf die Service Qualität haben, wird empfohlen, die Changes vor der Implementierung genauestens zu Testen und Back-Out Pläne vorzusehen.
[Bearbeiten] Freigabe der Implementierung
Nach einem geeigneten Test und der Überprüfung, dass alle notwendigen Aktionen durchgeführt wurden, z.B. Prüfung auf Vorhanden sein eines Back-Out-Plans, kann der Change zur Durchführung freigegeben werden.
[Bearbeiten] Implementierung
Es ist die Aufgabe des Change-Managements dafür zu sorgen, dass die Changes im vorgesehenen Zeitrahmen implementiert werden. Dies wird jedoch meistens die Koordination des Changes bedeuten, da die eigentliche Ausführung in der Verantwortung von Anderen liegt (z.B. werden Hardware-Anderungen von Technikern durchgeführt).
[Bearbeiten] Auswertung
Das Change-Management muss nach einer festgelegten Zeitspanne alle durchgeführten Changes auswerten. Dies geschieht durch einen "Post Implementation ; Review" (PIR). Bei diesem Vorgang kann es erforderlich sein, dass CAB-Mitglieder mitwirken. Das Change-Management fordert dafür Unterstützung an. Das Change-Management sollte auch Auswertungen durchführen und entsprechende Maßnahmen ergreifen um jegliche Mängel im Change-Management-Prozess selbst infolge ineffektiver Changes zu beseitigen.
[Bearbeiten] Request for Change (RfC) - Umfang
Der Request for Change ist eine Anfrage bzw. Auftrag an das Change-Management, eine Änderung oder Erweiterung in der IT-Umgebung vorzunehmen. Hierbei werden komplette Services und Cis neu aufgenommen oder bestehende Services und Cis angepasst. Requests for Change werden aus vielen verschiedenen Gründen gestellt von vielen verschiedenen Antragstellern. Dies ist der Beginn des Lebenszyklus eines Change. RfCs können sich auf jeden Teil der Infrastruktur beziehen und auf jeden Service oder jede Aktivität. RfCs können natürlich in Papierform oder - wie es zunehmend der Fall ist - elektronisch gehalten sein, vielleicht im Intranet der Firma. Alle RfCs sollten aufgezeichnet werden und durch die Vergabe einer Nummer eindeutig identifizierbar sein.
Die folgenden Felder sollten in einem RfC Formular enthalten sein, unabhängig von Papierform oder elektronischer Ausführung:
- RfC Nummer (zusätzlich ein Querverweis zur Problem Nummer, wo nötig)
- Beschreibung und Identität der zu ändernden Elemente (einschließlich der CI dentifikation, wenn ein Config-Management System genutzt wird).
- Grund der Änderung
- Auswirkung, wenn Change nicht implementiert wird.
- Version des zu ändernden Elements.
- Name, Büro und Telefonnummer der Person, die den Change vorgeschlagen hat
- Datum, an dem der Change vorgeschlagen wurde.
- Priorität des Changes.
- Abschätzung der Auswirkung und benötigten Ressourcen (welche bei Bedarf auch auf einem separaten Formular aufgeführt sein können).
- Wenn passend CAB Empfehlungen (welche bei Bedarf auch separate aufgeführt sein können, mit Abschätzung der Auswirkung und benötigten Ressourcen).
- Unterschrift zur Genehmigung (könnte auch elektronisch sein).
- Datum und Zeit der Genehmigung.
- Zeitplan der Implementierung (Release Identifizierung und/oder Datum/Uhrzeit).
- Ablageort des Release/Implementierungs Plans.
- Details des Change Ausarbeiters / Implementierers.
- Back-Out Plan.
- Aktuelles Datum und Zeit der Implementierung.
- Review Datum.
- Review Ergebnisse (einschließlich Querverweis auf neuen RfC, wenn nötig).
- Risiko-Analyse und -Management.
- Einfluss auf Störfall- und Katastrophenpläne des Business.
- Status des RfC - z.B.. 'aufgenommen', 'geschätzt', 'abgelehnt', 'genehmigt', 'wartend'.
Während der Change in seinem Lebenszyklus weiterläuft, sollte der Request for Change aktualisiert werden, so dass die Person, die den Change initiiert hat, über den Status informiert wird. Aktuelle genutzte Ressourcen und die aufgelaufenen Kosten ,- sollten als Teil des Datensatzes eingetragen werden.
[Bearbeiten] Priorisierung
Wenn der Change einmal angenommen ist, werden Priorität und Kategorie (siehe nächste Folie) vergeben. Die Priorität zeigt die Bedeutung des Changes und setzt sich zusammen aus der Auswirkung des Problems und der Dringlichkeit für die Behebung. Der Problem Manager hat vielleicht eine Priorität bereits bestimmt, aber die endgültige Priorisierung für den Change wird im Change-Management vorgenommen, wobei alle anderen RfCs, die sich in der Diskussion befinden, mit betrachtet werden. Die Kategorie wird vom Change Manager zugewiesen. Diese Klassifizierung bestimmt, wie die Angelegenheit weiter bearbeitet wird und wird daher von der "Schwere" der Anpassung bestimmt.
Unterteilung der Priorität - Beispiele für Prioritätsabstufungen sind:
[Bearbeiten] Dringend
Höchste Priorität; der RfC betrifft ein Problem das eine immense Beeinträchtigung der Nutzung wesentlicher Services verursacht, oder er betrifft eine dringende Anpassung der IT (zum Beispiel neue Funktionalitäten wegen geschäftlicher Überlegungen oder neuer gesetzlicher Richtlinien). Dringende Changes unterscheiden sich von den normalen Verfahren, weil die notwendigen Ressourcen für diesen Typ sofort zur Verfügung gestellt werden müssen. Eine Dringlichkeitssitzung des CAB (CAB/EC) oder des IT-Steuerkreises kann erforderlich sein. Alle anderen geplanten Aktivitäten werden möglicherwise vorübergehend ausgesetzt.
[Bearbeiten] Hoch
Verursacht schwerwiegende technische Schwierigkeiten für eine große Gruppe oder Anzahl von Anwendern oder betrifft andere dringende Situationen. Dieser Change erhält höchste Priorität bei der Zuweisung von Ressourcen für Entwicklung, Test und Durchführung des Changes.
[Bearbeiten] Mittel
Normale Priorität: keine immense Dringlichkeit oder hohe Auswirkung, aber der Change kann auch nicht bis zum nächsten geplanten Release oder Wartungsfenster verschoben werden. Der Change erhält eine durchschnittliche Priorität bei der Zuweisung von Ressourcen.
[Bearbeiten] Niedrig
Ein gerechtfertigter und notwendiger Change, der aber auf einen passenderen Zeitpunkt verschoben werden kann. Zum Beispiel bis zum nächsten Release oder geplantem Wartungsfenster. Ressourcen werden entsprechend dem Zeitpunkt zugeordnet.
[Bearbeiten] Kategorisierung
Unterteilung der Kategorie Kategorien werden durch den Change Manager zugewiesen, wenn nötig in Zusammenarbeit mit dem CAB. Die Kategorien geben einen Hinweis auf die Auswirkung des Changes auf das Unternehmen und die Belastung der IT- Organisation. Unten ist ein Beispiel einer Unterteilung von Kategorien aufgeführt:
[Bearbeiten] Standard
Standard-Änderungen an der Infrastruktur für die genaue Verfahrensanweisungen existieren und die vorab vom Change Manager genehmigt wurden. Man ist sicher, dass die geschriebene Verfahrensanweisung sicherstellt, dass das Risiko vernachlässigt werden kann. Der Change kann ohne nochmalige Kontaktierung eines Change Managers ausgeführt werden.
[Bearbeiten] Kategorie 1
Geringes Risiko für die laufenden Geschäftsprozesse. Ein Change, der nicht viel Arbeit erfordert. Der Change Manager kann diese Art Change freigeben ohne ihn mit dem CAB zu diskutieren.
[Bearbeiten] Kategorie 2
Deutliches Risiko für die laufenden Geschäftsprozesse. Changes die größere Anstrengungen erfordern und einen größeren Einfluss auf die Services haben. Solche Changes werden in der nächsten geplanten Besprechung des CAB diskutiert, um die benötigten Aufwände und möglichen Konsequenzen vorherzusagen. Vor der Besprechung werden einige benötigte Dokumente an die CAB Mitglieder und möglicherweise an einige Spezialisten und Entwickler gesandt. Bei Changes mit der Priorität "Dringend" ist entsprechend das CAB/EC zuständig.
[Bearbeiten] Kategorie 3
Erhebliches Risiko für die laufenden Geschäftsprozesse. Ein Change der einen großen Aufwand und viele Ressourcen zur Durchführung erfordert. Bei einem Change dieser Art benötigt der Change Manager die Zustimmung des IT-Managements, eines IT-Steuerkreises oder der Geschäftsführung und muss ihn dann mit dem CAB besprechen.
Die meisten Changes können den ersten beiden Kategorien zugeordnet werden.
[Bearbeiten] Das Change Advisory Board (CAB)
"Change Advisory Board" ist ein ITIL-Begriff. Manche verstehen unter dem Begriff 'Board' sehr formelle regelmäßige Besprechungen derselben Gruppe von Top-Managern. Eine CAB-Besprechung kann sowohl formell als auch informell sein. In der heutigen Geschäftswelt könnte der Begriff 'Team' die typische Form eines CAB treffender beschreiben. Das CAB-"Team" kann sich regelmäßig treffen, nach ITIL- Empfehlung mindestens alle 20 Tage. Die CAB-Besprechungen können auch mehrmals pro Woche stattfinden, wobei jederzeit Sonderbesprechungen einberufen werden können. Einige CAB-Mitglieder werden wahrscheinlich regelmäßig an den CAB-Besprechungen teilnehmen; andere dagegen können zur Teilnahme an einzelnen Besprechungen aufgefordert werden, um Inputs zu einem bestimmten Request for Change zu liefern, der zur Diskussion steht.
Das CAB ist dazu da, die meisten der Changes zu billigen und dem Change Manager zu helfen, die Changes einzuschätzen und zu priorisieren. Wenn ein CAB einberufen wird, müssen die ausgewählten Mitglieder fähig sein, den Change sowohl vom Standpunkt des Geschäfts, als auch vom technischen Standpunkt aus beurteilen zu können. Um diesen Mix zu erreichen, müssen im CAB sowohl Leute vertreten sein, mit einem klaren Verständnis für die Geschäftsanforderungen des Kunden und der Anwender wie auch Leute aus den technischen Entwicklungs- und Support Bereichen.
Mitglieder im CAB könnten sein der Change Manager, Kunden, Anwender auf Management-Ebene, Repräsentanten von Anwendern, Anwendungsentwickler /- betreuer (wenn angemessen), Experten / technische Consultants, Mitarbeiter aus dem Service (wenn benötigt), Mitarbeiter der Haustechnik (wenn Changes die Büroinstallationen betreffen und umgekehrt), Vertreter von Subunternehmern und Drittherstellern (wenn benötigt - beispielsweise bei Outsourcing Verfahren).
Es ist wichtig zu betonen, dass das CAB
- Sich aus ständigen Mitgliedern (Vorsitz - Change Manager) und temporären Mitgliedern zusammensetzt.
- Sich entsprechend den zu bearbeitenden Changes zusammensetzt.
- Sich in der Zusammensetzung auch innerhalb eines einzelnen Meetings erheblich unterscheiden kann.
- Lieferanten hinzuziehen sollte, wenn das hilfreich ist.
- Sowohl die Anwender- wie die Kundensicht beachten sollte.
- Zumindest zeitweise den Problem Manager/Service Level Manager und Customer Relations Mitarbeiter hinzuziehen sollte.
Wenn Changes der Kategorie 2 auftreten, die in kürzester Zeit beurteilt werden müssen (Priorität "Dringend) ist es nötig, eine kleinere Organisation einzurichten, die - die Befugnis hat, dringende Entscheidungen zu treffen. Solch ein Gremium wird in ITIL "CAB Emergency Commitee" (CAB/EC)genannt. Change Verfahren sollten festlegen wie die Zusammensetzung des CAB und CAB/EC jeweils bestimmt wird, basierend auf den o.g. Kriterien und allen weiteren Kriterien, die für das Business wichtig sind. Das wird auch sicherstellen, dass die Zusammensetzung des CAB die Möglichkeit bietet, angemessene Entscheidungen in jedem möglichen Eventualfall zu treffen, sowohl aus der Business Perspektive heraus wie auch vom technischen Standpunkt aus.
[Bearbeiten] Beziehungen zu anderen ITIL Prozessen
[Bearbeiten] Configuration Management
Change- und Configuration-Management sind zwei sehr eng miteinander verzahnte Prozesse. Ein Configuration-Management kann ohne ein Change-Management nicht bestehen, da es auf die aktuellen Informationen über die IT -Infrastruktur durch das Change- Management angewiesen ist. Umgekehrt hat ein Change-Management ohne ein Configuration-Managment keine Möglichkeit, die Auswirkungen eines Changes auf die übrige IT-Infrastruktur, die IT- Services und damit auf das Business zu beurteilen. Wenn der Configuration Manager - nach der Überprüfung - CI's (Configuration Item) in der Konfiguration gefunden hat, die nicht in der Datenbank sind, gibt es zwei Möglichkeiten:
- die Datenbank ist nicht aktuell was darauf hinweisen kann, dass das Configuration-Management über einen Change nicht informiert war
- jemand hat einen illegalen - nicht genehmigten - Change durchgeführt
[Bearbeiten] Analyse, Risiko und Auswirkung
Der wichtigste Bereich in dem die Prozesse verbunden sind, ist die Analyse von Auswirkung und Risiko eines Changes. Das meiste davon muss mit Unterstützung der CMDB durchgeführt werden. Nach Erhalt eines RfC ist eine der ersten Tätigkeiten, die durchgeführt werden muss, herauszufinden welches CI oder welche CIs geändert werden müssen und was die Auswirkung auf die bestehende Infrastruktur ist. Change Management muss auch feststellen, ob dieser eine RfC auf mehrere verschiedene RfCs hinausläuft, da als Ergebnis des RfCs mehrere CIs geändert werden müssen. Es muss auch herausgefunden werden, ob dieser Change einen oder mehrere Benutzer, eine oder mehrere Organisationen oder einen oder mehrere Services betrifft um den richtigen Auswirkgungsgrad zuordnen zu können. Basierend darauf kann der Change Manager entscheiden, ob das CAB einberufen werden muss, wer eingeladen wird und auf welchem Level diskutiert werden muss.
[Bearbeiten] Capacity Management
Das Capacity Management muss die Auswirkung von Changes auf die bestehenden Kapazitäten abschätzen und zusätzlich benötigte Kapazitäten herausfinden. Zusätzliche Kapazitätsanforderungen müssen in den Kapazitätsplan aufgenommen werden und als solche ebenfalls als RfCs behandelt werden.
[Bearbeiten] Release Management
Das Release-Management muss den Inhalt und Zeitplan von Releases vorschlagen. Release-Management ist dann für die Implementierung der festgelegten Releases verantwortlich.
[Bearbeiten] Zusammenfassung von RfCs
Die Zusammenfassung verknüpfter RfCs hilft nicht nur bei der realistischeren Bewertung der Auswirkungen, sondern reduziert auch den bürokratischen Aufwand des Change-Management.
[Bearbeiten] Zusammenfassung
[Bearbeiten] Ziel
Das Ziel von Change Management ist es, alle Anpassungen an der IT-Infrastruktur auf systematische Art und Weise durchzuführen. Dadurch werden die Risiken der Störung des Service und der draus resultierenden Qualitätsminderung des Service auf ein Minimum reduziert.
[Bearbeiten] Request for change (RfC)
Ein Change ist eine beliebige Veränderung eines oder mehrerer Cis. Er kann variieren zwischen schwerwiegend (wie beispielsweise das Ersetzen eines Kontroll-Servers) und einfach (das Ersetzen eines Druckertreibers) und kann jede der Komponeneten in der CMDB betreffen. Damit die Anpassungen ausgeführt werden, können Kunden ebenso wie das Problem-Management Änderungsanträge (Request for Change, RfC) an den Change Manager stellen. Interne IT-Anforderungen (Service-Planung, Entwicklung, etc.) können ebenfalls in einem RfC resultieren.
[Bearbeiten] Der Change Manager
Der Change Manager ist verantwortlich für die Durchführung eines Changes in einer systematischen Art und Weise nachdem die bekannten Risiken abgewogen wurden. Er überwacht auch den Fortschritt des Changes. Der Change Manager beurteilt die Requests for Change (RfC) zusammen mit dem Change Advisory Board (CAB). Dieses Gremium besteht aus erfahrenen Mitarbeitern der betroffenen Disziplinen.
[Bearbeiten] Der Prozess
Der Change Manager erhält den Request for Change (RfC), prüft ihn auf Vollständigkeit, nimmt ihn auf und klassifiziert ihn basierend auf den geschätzten Risiken. Wenn der Change grundsätzlich genehmigt wurde, werden die Konsequenzen hinsichtlich der Kapazität aufgenommen. Verfügbarkeit und Kosten werden im Service-Planungs-Prozess analysiert. Der Vorschlag kann dann, nach der Genehmigung durch das Change-Management, für Design, Entwicklung und Test an die Entwicklungs-Abteilung weitergegeben werden.
Der Change Manager entscheidet, wenn nötig beraten durch das CAB, über den Zeitplan des Release auf der Basis der Testergebnisse und einem gut ausgearbeiteten Back-Out-Plan. Der Back-Out-Plan stellt sicher, dass die Organisation jederzeit zur vorherigen Situation zurückkehren kann, wenn unvorhergesehene Probleme auftauchen. Erst dann wird dem Release-Verantwortlichen die Implementierung genehmigt. Wenn ein Release sich auf Software bezieht, folgt der Freigabe ein Produktions-Test durch den Release-Management-Prozess, bevor testweise ausgerollt wird. Zusätzlich muss immer eine Überprüfung (Post Implementation Review, PIR) des Changes und der Art und Weise, wie er implementiert wurde, folgen.
[Bearbeiten] Management Reports
Change-Management muss (im Idealfall zusammen mit dem Business-Management) Messgrößen ermitteln, die eine bestimmte Bedeutung haben. Es ist relativ leicht, Incidents zu zählen aus denen Probleme und aus denen wiederum Changes werden. Es ist jedoch ungleich wichtiger, die zugrundeliegenden Ursachen zu betrachten und Trends zu ermitteln. Am Besten ist es, die Auswirkung von Change-Management zu messen und mit der Zeit geringere Unterbrechungen durch die Einführung von Change-Management nachzuweisen wie auch die Geschwindigkeit und Effektivität zu messen, mit der die IT Infrastruktur auf geänderte Geschäftsanforderungen reagiert. Verwendete Messgrößen sollten, wenn praktikabel, mit den Geschäftszielen verknüpft werden - und mit Kosten, Services, Verfügbarkeit und Zuverlässigkeit. Alle Vorhersagen sollten mit aktuellen Messungen verglichen werden.
Regelmäßige Zusammenfassungen der Changes sollten dem Service-Management, den Kunden und dem Anwender Management zur Verfügung gestellt werden. Verschiedene Management Ebenen benötigen üblicherweise verschiedene Arten an Informationen. Das reicht vom Service Manager, der vielleicht einen detaillierten wöchentlichen Report verlangt, bis zu Senior Management Ausschüssen die üblicherweise nur quartalsweise eine Management Zusammenfassung verlangen. Berücksichtigen Sie die folgenden Fakten und Statistiken in den Management Reports:
- Die Anzahl der in einer Periode durchgeführten Changes insgesamt und nach CI, Konfigurations-Typ, Service etc.
- Eine Aufschlüsselung der Gründe für Changes (Benutzer Aufträge, Erweiterungen, Geschäftsanforderungen, Service Call/lncident/Problem Fixes, Verfahren/Trainings- Verbesserungen, etc)
- Die Anzahl erfolgreicher Changes
- Die Anzahl rückgängig gemachter Changes (Back-Out) zusammen mit den Gründen dafür (fehlerhafte Einschätzung, schlechter Build)
- Die Anzahl von Incidents, die auf Changes zurückgeführt werden können (aufgeschlüsselt nach Schwere des Problems) und die Gründe dafür (z.B. fehlerhafte Einschätzung, schlechter Build)
- Die Anzahl von RfCs (und Trends hinsichtlich der zukünftigen Anzahl)
- Die Anzahl durchgeführter Changes die überprüft wurden und die Anzahl der noch ausstehenden Überprüfungen (aufgeschlüsselt nach der Zeit
- Hohe Anzahl von RfCs, die sich auf ein einziges CI beziehen (diese Cis sind es wert, näher betrachtet zu werden) inklusive der Gründe (z.B. veränderte Benutzeranforderungen, instabile Komponente, schlechter Build)
- Zahlen aus vorhergehenden Zeiträumen (letzte Periode, letztes Jahr) zum Vergleich
- Die Anzahl abgelehnter RfCs
- Das Verhältnis von durchgeführten Changes zu den fehlgeschlagenen Changes (insgesamt und aufgeschlüsselt nach CI)
- Noch ausstehende Changes, aufgeschlüsselt nach CI und der Stufe im Change-Management Prozess
[Bearbeiten] Quelle
- HP: ITIL Grundlagen für IT Service Management, Student Workbook, Version D.00_DE-1, Course No. H1846S, hp education services [1].
