Change Management (ITIL)

Change-Management ist ein Themengebiet aus ITIL und wird dort im Buch Service Transition als Prozess definiert, der das Ziel hat, dass alle Anpassungen an der IT-Infrastruktur kontrolliert, effizient und unter Minimierung von Risiken für den Betrieb bestehender Business-Services durchgeführt werden.

Daneben existiert der Begriff Change-Management in der Betriebswirtschaftslehre als eigenständige Disziplin zur Umsetzung weitreichender Veränderungen in Organisationen (siehe Veränderungsmanagement).

Hintergrund

Ein hoher Anteil kostenintensiver IT-Service-Störungen lässt sich häufig auf schlecht koordinierte oder unzureichend gesteuerte Änderungen an der IT-Servicelandschaft zurückverfolgen. Diese Störungen können aufgrund der heutigen Abhängigkeit der Unternehmensprozesse von der IT enorme Kosten nach sich ziehen. Dies rechtfertigt Investitionen in IT-Prozesse, in welchen jede Änderung hinsichtlich des Bedarfs und Nutzens sowie auf die möglichen negativen Auswirkungen hin geprüft wird und die Störungen durch entsprechende Maßnahmen auf ein akzeptables Minimum reduziert werden.

Es ist daher die Aufgabe des Change-Managements, sicherzustellen, dass standardisierte Methoden und Verfahren zur Durchführung von Veränderungen existieren und diese auch effizient und konsequent genutzt werden.

Change-Management-Aufgaben

Change-Management ist dafür verantwortlich, den Change-Prozess zu erstellen und zu verwalten. Der Prozess beinhaltet die Erfassung, Dokumentation, Genehmigung und Überwachung und stellt sicher, dass Änderungen geplant, effizient, kostengünstig und mit minimalem Risiko ausgeführt werden.

Um das Risiko eines jeden Changes einschätzen zu können, braucht man detaillierte Informationen über die einzelnen CIs (Configuration Items) und ihre Relationen zueinander. Die Bestandteile der IT-Infrastruktur, sog. Configuration-Items, werden im Rahmen des Configuration-Managements mit einer Configuration-Management-Datenbank (CMDB) 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)

Wichtig ist, dass Changes mit ausreichendem zeitlichem Vorlauf 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 vorgesehen ist und was zusätzlich noch unternommen werden muss.

Kommunikation ist der Schlüssel für einen erfolgreichen Change-Prozess. Zu wenig 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, sodass die Durchführung fehlerfrei ist. Daher ist eine Kommunikationsstruktur (z. B. das CAB, Change Advisory Board) notwendig. Wichtig sind auch Berichte (Reports). Diese helfen dabei, die Changes selbst sowie die Art und Weise ihrer Durchführung bekanntzugeben.

Mission-Statement

Innerhalb der strategischen Zielsetzung (Mission Statement) hat der Begriff "autorisierte Changes" eine sehr starke Bedeutung und ist genau festgelegt. Aber gute Change-Management-Verfahren werden sowohl den kleinen alltäglichen Changes, 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, gerecht. Wenn zum Beispiel ein Anwender sein Passwort ändern möchte, wäre ein kompletter Request for Change inkl. anschließender Besprechung des Change-Advisory-Boards 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.

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 aufrechtzuerhalten. 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 erforderliche Changes zügig bearbeiten und genehmigen. Diese genehmigten Changes werden vom IT-Management unterstützt und wurden auf Risiko, Kosten und Auswirkungen untersucht.

Prozess-Implementierung

In der heutigen Geschäftswelt fordert die Abhängigkeit von IT-Systemen und Technologie vom Management, dass genug Zeit in die Abschätzung der Bedeutung von Unternehmensveränderungen auf die IT und des Einflusses von IT-Änderungen auf das Unternehmen investiert wird. Die Verwaltung von Changes ist eine Vollzeit-Aufgabe geworden. Wenn Changes so verwaltet werden, dass das Risiko, die Schwere der Auswirkung und mögliche Unterbrechungen optimiert werden und Changes auch beim ersten Versuch erfolgreich sind, ist es für das Unternehmen von grundlegender Bedeutung, dass dieser Prozess schnell implementiert wird.

Terminologie

Die Definitionen der Begriffe sind:

Change

Änderung oder Erweiterung einer vorhandenen Spezifikation, eines Produkts oder einer Dienstleistung (Service). Hierzu gehören das Hinzufügen, Ändern oder Entfernen von genehmigter, unterstützter oder eingefrorener Hardware, Netzwerk-Komponenten, Software, Anwendungen, Umgebungs-Komponenten, Systemen, Desktop Builds, zu ihrer Verwendung notwendiger oder mit ihnen zusammenhängender Konfiguration oder dazugehörender Dokumentation.

Request for Change (RfC)

Eine Änderungsanforderung bzw. deren 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.

Forward Schedule of Changes (FSC)

Zeitplan, der Details der zur Durchführung genehmigten Changes und deren vorgesehenes Implementierungs-Datum enthält.

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:

Request for Change

RfC – zu deutsch Änderungsantrag. Mit der formellen Registrierung des Antrages beginnt der Lebenszyklus eines Changes. Der RfC ist das eigentliche Logbuch, also die Sammlung aller Aktivitäten dieses Lebenszyklus. Alle Aktivitäten, Diskussionen, Beschreibungen, Analysen, Dokumentationen und Entscheidungen bezüglich einer Veränderung werden darin festgehalten.

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.

Ü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.

Genehmigung

Entscheidung, ob der Change durchgeführt wird oder nicht.

Ausarbeitung und 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.

Freigabe der Implementierung

Nach einem geeigneten Test und der Überprüfung, dass alle notwendigen Aktionen durchgeführt wurden, zum Beispiel Prüfung auf Vorhandensein eines Back-Out-Plans, kann der Change zur Durchführung freigegeben werden.

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-Änderungen von Technikern durchgeführt).

Auswertung

Das Change-Management muss nach einer festgelegten Zeitspanne alle durchgeführten Changes auswerten. Dies geschieht durch einen "Post Implementation Review" (PIR).

Ziel ist es, die Effizienz der durchgeführten Maßnahmen sowie des dazugehörigen Prozesses zu durchleuchten. Dabei sollen sowohl die durchgeführte Veränderung als auch die dabei benutzten Methoden und Prozesse einer Ist-Soll-Analyse unterzogen werden. Bei größeren Changes spielen auch Kosten-Nutzen-Vergleiche, die Return on Investment (ROI)-Kalkulation sowie die Messung der Zielerreichung aus der geschäftlichen Perspektive eine Rolle. Ein allgemeingültiger Bewertungskatalog aus dem PIR erlaubt eine objektive Bewertung und kann in der Summe, auf einen längeren Zeitraum bezogen, auch eine Trendaussage liefern, ob die eingesetzten Mittel effizient zur Lösung von Problemen beitragen.

Der Bewertungskatalog beinhaltet zum Beispiel Fragen wie:

• Sind gesetzte Ziele innerhalb vorgegebener Grenzen erreicht worden?
• Entspricht das erreichte Ergebnis der vorherigen Erwartungshaltung?
• Wurden vereinbarte Projektzeiten (Milestones) eingehalten?
• Ist der Prozess mit dem vorgegebenen Budget und den angedachten Ressourcen durchgeführt worden?
• Sind unvorhergesehene Probleme aufgetreten?

Bei diesem Vorgang kann es je nach Umfang des ursprünglichen Changes erforderlich sein, dass sowohl CAB-, MB- und/oder EC-Mitglieder als auch entsprechende Berater mitwirken. Das Change-Management legt die Termine und die Agenda fest und fordert dafür Unterstützung an. Das Change-Management sollte auch die vereinbarten Auswertungen durchführen und entsprechende Maßnahmen einleiten, um jegliche Mängel im Change-Management-Prozess selbst infolge ineffektiver Changes zu beseitigen.

Umfang des Request for Change (RfC)

Der Request for Change ist eine Anfrage, beziehungsweise ein 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 von vielen verschiedenen Antragstellern gestellt. Dies ist der Beginn des Lebenszyklus eines Changes. RfCs können sich auf jeden Teil der Infrastruktur beziehen und auf jeden Service oder jede Aktivität. RfCs können 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-Identifikation, 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 separat 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-/Implementierungsplans
• 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, sodass 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.

Priorisierung

Wenn der Change einmal angenommen ist, werden Priorität und Kategorie 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 bereits eine Priorität 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.

Beispiele für Prioritätsabstufungen sind:

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öglicherweise vorübergehend ausgesetzt.

Hoch

Behebt schwerwiegende technische Schwierigkeiten für eine große Gruppe oder Anzahl von Anwendern oder betrifft andere wichtige Situationen. Dieser Change erhält höchste Priorität bei der Zuweisung von Ressourcen für Entwicklung, Test und Durchführung des Changes.

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.

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.

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:

Standard

Standardänderungen an der Infrastruktur, für die genaue Verfahrensanweisungen existieren und die vorab vom Change-Manager genehmigt wurden. Die genannten Verfahrensanweisungen stellen sicher, dass Risiken vernachlässigt bzw. gut gesteuert werden können. Der Change kann ohne nochmalige Kontaktierung eines Change-Managers ausgeführt werden.

Normal

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.

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.

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 (MB) und muss ihn dann mit dem CAB besprechen.

Emergency – Notfall

Ein Sonderfall des Changes, der nicht den üblichen Prozess durchläuft, sondern sofort, notfalls auch unter erheblichem Risiko und ohne weitere Genehmigung von Stakeholdern, meist zur Abwendung größeren Schadens durchgeführt wird. Bei einem Change dieser Art benötigt der Change-Manager nur die Zustimmung des Emergency Committee (EC). Vorrangig ist hier, auf eine Notsituation reagieren zu können, entsprechende weitere Genehmigungen und Tests werden erst nach dem Change durchgeführt.

Die meisten Changes können den ersten beiden Kategorien zugeordnet werden.

Das Change Advisory Board (CAB)

„Change Advisory Board“ ist eine ITIL-Rolle. 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 unterstützt den Change-Manager, Changes hinsichtlich des Business Impacts 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 zu beurteilen. Um diesen Mix zu erreichen, müssen im CAB sowohl Personen mit einem klaren Verständnis für die Geschäftsanforderungen des Kunden vertreten sein als auch Anwender und Vertreter aus den technischen Entwicklungs- und Supportbereichen.

Mitglieder im CAB können neben dem Change-Manager sein: Kunden, Anwender auf Management-Ebene, Repräsentanten von Anwendern, Anwendungsentwickler oder -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 anderen Herstellern (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 Committee (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 wie auch vom technischen Standpunkt aus.

Beziehungen zu anderen ITIL-Prozessen

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-Management 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 – CIs (Configuration Item) in der Konfiguration gefunden hat, die nicht in der Datenbank sind, gibt es zwei Möglichkeiten:

1. die Datenbank ist nicht aktuell, was darauf hinweisen kann, dass das Configuration-Management über einen Change nicht informiert war
2. jemand hat einen illegalen – nicht genehmigten – Change durchgeführt

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 Auswirkungsgrad 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.

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.

Releasemanagement

→ Hauptartikel: Releasemanagement

Das Releasemanagement ist der Prozess, der für die Planung des zeitlichen Ablaufs und die Steuerung des Übergangs von Releases in Test- und Live-Umgebungen verantwortlich ist. Das wichtigste Ziel des Releasemanagements ist es sicherzustellen, dass die Integrität der Live-Umgebung aufrechterhalten wird und die richtigen Komponenten im Release enthalten sind. Das Releasemanagement ist Teil des Release-und-Deployment-Management-Prozesses.

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.

Zusammenfassung

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 Komponenten 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.

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.

Der Prozess

Der Change-Manager erhält die Änderungsanforderung (engl. "Request for Change" oder RfC), prüft sie auf Vollständigkeit, nimmt sie auf und klassifiziert sie, basierend auf den geschätzten Risiken. Wenn die Änderung 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 der Veröffentlichung ("release") auf der Basis der Testergebnisse und einen 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 es sich um ein "software release" handelt, folgt der Freigabe ein Produktions-Test durch den Release-Management-Prozess, bevor die Software testweise zum Einsatz verteilt wird. Zusätzlich muss immer eine Überprüfung (Post Implementation Review, PIR) der Änderung und der Art und Weise, wie sie implementiert wurde, folgen.

Managementreports

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 Managementzusammenfassung verlangen. Folgenden Fakten und Statistiken sollten in den Managementreports berücksichtigt werden:

• 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 (Benutzeraufträge, Erweiterungen, Geschäftsanforderungen, Service Call/Incident/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

Einzelnachweise

HP, ITIL Grundlagen für IT-Service-Management, Student Workbook, Version D.00_DE-1