IT-Fachjargon erklärt
Change Management ist leistungsstark und weitreichend, da es jede Phase des ITIL-Lebenszyklus unterstützt. Es ist wichtig zu erkennen, dass es strategische, taktische und operative Änderungen gibt, die definiert und verwaltet werden müssen, um die Serviceziele Ihrer Organisation zu unterstützen. Darin liegen die Schlüssel zum Erfolg.
Wenn Sie an ITIL denken, stellen Sie sich vielleicht eine starre Sammlung von Prozessen und Verfahren vor, die definieren, wie Ihre Organisation interne Kunden mit Services versorgt. Doch wer sich wirklich intensiv mit ITIL auseinandersetzt, weiß, dass das Framework alles andere als starr ist – tatsächlich ist der ITIL-Lebenszyklus sowohl dynamisch als auch ständig im Wandel. Change Management ist dabei besonders hervorzuheben: Es ist leistungsstark und weitreichend, da es jede Phase des ITIL-Lebenszyklus unterstützt. Im Zusammenhang mit Change Management ist es wichtig zu erkennen, dass es strategische, taktische und operative Änderungen gibt, die definiert und verwaltet werden müssen, um die Serviceziele Ihrer Organisation zu unterstützen. Darin liegen die Schlüssel zum Erfolg.
Auf seiner grundlegendsten Ebene ist Change Management mit dem Risikoverständnis der Organisation verbunden. Während Risk Management uns lehrt, Risiken basierend auf der Unternehmensstrategie und unseren Fähigkeiten zu akzeptieren, zu ignorieren, zu reduzieren oder zu nutzen, geht es beim Change Management darum, Risiken für Ihre Organisation zu managen. In diesem Leitfaden werden verschiedene Arten von Änderungen erörtert. Der Schlüssel zu effektivem Change Management liegt darin, Änderungstypen nach Risikobereitschaft zu definieren und die von der IT-Organisation geforderten Validierungsstufen entsprechend festzulegen.
In meinen vielen Jahren ITIL-Erfahrung bin ich nur auf wenige Organisationen gestoßen, die keine Schwierigkeiten mit Change Management hatten. Für viele Unternehmen war es eine Frage des fehlenden echten Verständnisses der Definition. Sehr häufig implementieren Organisationen lediglich einen oder zwei Aspekte des Prozesses und bezeichnen dies als Change Management. So bezeichnen manche Unternehmen, die ausschließlich Change Approvals oder Post Implementation Reviews durchführen, ihren Prozess als Change Management. Andere Organisationen haben kein solides Verständnis der Unterschiede zwischen Change Management und Release and Deployment – oder verstehen nicht wirklich, was Release and Deployment ist. Im Allgemeinen ist dies ein Zeichen für den Reifegrad der Organisation in Bezug auf den Prozess selbst – und je tiefer sie in die Best Practices eintauchen, desto klarer nehmen ihre Change Management-Prozesse Gestalt an und entfalten eine echte Wirkung.
Wie bei allen ITIL-Prozessen gibt es auch beim Change Management zahlreiche Herausforderungen. Die Nutzung von Weiterbildungsangeboten, Expertenwissen und erstklassiger Technologie kann dazu beitragen, den Prozess und die Service-Ergebnisse für das Unternehmen zu verbessern sowie Initiativen in den Bereichen DevOps, Big Data, IOT, Cyber-Resilience, Digital Transformation usw. voranzutreiben.
Behalten Sie beim Lesen dieses Leitfadens den geschäftlichen Mehrwert im Blick: Es kommt darauf an, das Wesentliche für Ihre Organisation zu tun – und es richtig zu tun, indem Sie Menschen, Prozesse, Technologie und Lieferanten optimal einsetzen, um Ihre Ziele zu erreichen. Service Excellence ist eine Reise, die nie endet und kontinuierlich praktiziert und verfeinert werden muss. Und vergessen Sie nicht, Ihre Erfolge zu feiern!
Verwandt: Essentials of Modern Change Management
Der Change Management-Prozess ist darauf ausgelegt, den Lebenszyklus strategischer, taktischer und operativer Änderungen an IT-Services durch standardisierte Verfahren zu steuern. Das Ziel von Change Management ist es, Risiken zu kontrollieren und Unterbrechungen der damit verbundenen IT-Services und Geschäftsprozesse zu minimieren.
Hinweis: Organizational Change Management (OCM) wird manchmal mit Change Management verwechselt. OCM befasst sich jedoch mit den Auswirkungen neuer Prozesse und Veränderungen in der Organisationsstruktur auf die betroffenen Menschen. OCM und Change Management ergänzen sich, da die Organisationsstruktur das Verhalten von Menschen und Prozessen beeinflusst.
Das Ziel von Change Management ist es, standardisierte Verfahren für die Bearbeitung von Änderungsanforderungen auf agile und effiziente Weise zu etablieren, um das Risiko und die Auswirkungen einer Änderung auf den Geschäftsbetrieb drastisch zu minimieren.
Obwohl keine Best Practice, kein Framework und keine Methodik hundertprozentigen Erfolg garantieren kann, hilft Change Management dabei, Risiken zu managen und die von Ihnen bereitgestellten und unterstützten IT-Services vor unnötigen Fehlern zu schützen. Die Aufrechterhaltung zuverlässiger Geschäftssysteme ist für das Überleben jeder Organisation im heutigen Wettbewerbsumfeld unerlässlich. Anpassungen an einem beliebigen Element der IT-Infrastruktur können den Service-Mehrwert beeinträchtigen und die Produktivität negativ beeinflussen. Strukturierte und geplante Änderungen helfen dabei, das potenzielle Risiko, das mit Infrastrukturänderungen einhergeht, zu minimieren. Gleichzeitig bietet ein gut strukturierter und geplanter Change Management-Prozess erhebliche geschäftliche Vorteile.
Zu den Vorteilen, die sich aus Change Management ergeben, zählen:
Change Management ist ein zentraler Prozess innerhalb der Service Transition-Publikation – einem Teil des ITIL Service Management Best Practice-Frameworks, das Anleitungen für den Aufbau, die Bereitstellung und den Übergang neuer oder geänderter IT-Services in den Betrieb enthält. Darüber hinaus werden Hinweise zur Außerbetriebnahme von Services gegeben. Das Ziel von Service Transition im IT-Prozesslebenszyklus ist es, Änderungen an IT-Services zu planen und zu managen, dabei Risiken zu minimieren und die Entscheidungsunterstützung für Benutzer und das Unternehmen zu verbessern.
Die ITIL Service Transition-Prozesse umfassen:
Verwandt: Ivanti Service Management Solutions
Gemäß ITIL ist eine Änderung „die Hinzufügung, Modifikation oder Entfernung eines genehmigten, geplanten oder unterstützten Services oder einer Service-Komponente, die Auswirkungen auf IT-Services haben könnte." In den meisten Fällen ist eine Änderung ein Ereignis, das von der zuständigen Change-Autorität genehmigt wurde, unter Minimierung von Risiken bewertet und implementiert wird, den Status eines Configuration Item (CI) anpasst und für das Unternehmen und seine Kunden Mehrwert schafft.
Änderungen können auf zwei Wegen eingeleitet werden:
Eine Change Request ist ein formeller Antrag, der von einem Stakeholder der Organisation oder von einem Service-Nutzer über den Service Desk eingereicht werden kann, um mithilfe des Request Fulfillment-Prozesses ein Configuration Item zu ändern.
Ein Change Proposal ist eine übergeordnete Beschreibung einer potenziellen Service-Einführung oder einer wesentlichen Änderung und umfasst den Business Case sowie den Implementierungsplan. Diese Proposals werden in der Regel durch den Service Portfolio Management-Prozess in der Service Strategy erstellt und an den Change Management-Prozess weitergeleitet.
**Eine Service Request, die normalerweise über den Service Desk abgewickelt wird, kann eine Change Request sein. Eine Service Request kann eine Change Request sein, wenn die Änderung einen IT-Service durch Hinzufügung, Modifikation oder Außerbetriebnahme von Komponenten oder Configuration Items des IT-Service betrifft. Service Requests werden mithilfe des Request Fulfillment-Prozesses des Service Desk erfüllt und involvieren die Change Management-Prozesse (und möglicherweise den Supplier Management-Prozess). Viele Service Requests sind Standard Changes.
Ein Emergency Change ist eine Änderung, die so schnell wie möglich bewertet und implementiert werden muss, um einen schwerwiegenden Incident zu beheben. Emergency Changes sind in der Regel mit höheren Risiken verbunden und weisen eine hohe Fehlerquote auf, weshalb sie auf ein Minimum beschränkt werden sollten. Die genaue Definition eines Emergency Change sollte in der Change Management-Richtlinie festgelegt werden.
Ein Standard Change ist eine Änderung, die häufig vorkommt, ein geringes Risiko aufweist und über ein vorab etabliertes Verfahren mit dokumentierten Aufgaben zur Durchführung verfügt. Standard Changes unterliegen einer Vorabgenehmigung, um den Change Management-Prozess zu beschleunigen. Für Standard Changes werden häufig Change Models erstellt – dokumentierte und wiederholbare Pläne zur Verwaltung einer bestimmten Art von Änderung –, die das Vorgehen bei wiederkehrenden Änderungen beschreiben. Wenn das Risiko eines Standard Change für die Organisation zunimmt, kann er zu einem Normal Change werden.
Eine Änderung, die erhebliche finanzielle Auswirkungen haben und/oder mit hohem Risiko verbunden sein kann. Eine solche Änderung erfordert einen detaillierten Change Proposal mit finanzieller Begründung und entsprechenden Genehmigungen auf Managementebene. Das Verfahren jeder Organisation zur Identifikation und Verwaltung eines Major Change variiert je nach Größe und Komplexität des Unternehmens. Eine Änderung dieser Art kann von der operativen auf die taktische oder von der taktischen auf die strategische Ebene wechseln und eine andere Genehmigungsinstanz erfordern.
Ein Normal Change ist eine Änderung, die weder Standard noch Emergency ist und in der Regel eine wesentliche Änderung an einem Service oder der IT-Infrastruktur umfasst. Ein Normal Change unterliegt dem vollständigen Change Management-Prüfprozess, einschließlich der Prüfung durch das Change Advisory Board (CAB) sowie der Genehmigung oder Ablehnung.
Weitere Change Requests können umfassen:
Verwandt: Weitere IT-Begriffe erklärt
ITIL bietet ein Framework, das an die individuellen Anforderungen einer Organisation in Bezug auf Service Delivery und Support angepasst werden kann. Die Entwicklung eines standardisierten Change Management-Prozesses, der vom Management gebilligt wird, erleichtert die schnelle, wirtschaftliche und effektive Verwaltung von Änderungen, wenn diese auftreten. Der Prozess kann anschließend durch Service Management-Software automatisiert werden. Change Control ist ein untergeordnetes Element des gesamten Change Management-Prozesses, das sicherstellen soll, dass Änderungen kontrolliert, erfasst, analysiert und genehmigt werden.
Ein typischer Change Management-Prozess umfasst die folgenden Aktivitäten:
Eine Request for Change wird in der Regel von der Einzelperson, dem Prozess oder der Geschäftseinheit erstellt, die die Änderung anfordert. Je nach Art der Änderung enthält ein RFC-Datensatz unterschiedliche Informationen, die für Entscheidungen zur Genehmigung und Implementierung der Änderung erforderlich sind – darunter identifizierende Informationen, eine Beschreibung, das von der Änderung betroffene Configuration Item, eine Begründung für die Änderung, die Kontaktdaten des Antragstellers, die Art der Änderung, den Zeitrahmen, die Kosten, einen Rückabwicklungsplan sowie eine geschäftliche Begründung.
Jede Request for Change sollte von der zuständigen Change-Autorität auf geschäftliche Praktikabilität geprüft und priorisiert werden. Diese Anforderungen können abgelehnt und zur Benachrichtigung oder zur Anforderung weiterer Details an den Einreicher oder das Management zurückgegeben werden. Nicht genehmigte Änderungen sollten überwacht und bei Bedarf abgeschlossen werden.
Demo ansehen: Ivanti Neurons for ITSM - Change Management
Die Bewertung der Änderung hinsichtlich ihrer Auswirkungen, Risiken und Vorteile für IT-Services ist entscheidend, um unnötige Unterbrechungen des Geschäftsbetriebs zu vermeiden. Bei bestimmten Änderungstypen, wie z. B. Major Changes, findet eine formelle Change Evaluation durch den Change Evaluation-Prozess statt, die in einem Change Evaluation Report dokumentiert wird. Die Impact-Bewertung berücksichtigt die Auswirkungen auf das Unternehmen, die Infrastruktur, den Kundenservice, andere Services – sowohl IT- als auch Nicht-IT-Services –, die Implementierungsressourcen sowie die aktuell im Change Log geplanten Änderungen. Ein Change Advisory Board (CAB) kann ebenfalls Änderungen bewerten. Das CAB kann aus verschiedenen Stakeholdern bestehen, wie z. B. dem Service Owner, technischem Personal und/oder finanziellem Personal, um den Bedarf der Änderung zu beurteilen.
Change Requests erfordern in der Regel vor der Implementierung eine Genehmigung, und jede Änderung benötigt die Autorisierung durch die jeweils zuständige Genehmigungsinstanz, abhängig von der Art der Änderung (strategisch, taktisch, operativ). Dies variiert je nach Organisation, hängt jedoch häufig von der Unternehmensgröße, dem erwarteten Risiko der Änderung, potenziellen finanziellen Auswirkungen und dem Umfang der Änderung ab.
Nach der Genehmigung wird eine Change Request oder der Change-Datensatz an den Release and Deployment-Prozess übergeben, um die Zusammenarbeit mit den zuständigen technischen und/oder Application Management-Teams für den Aufbau, das Testing und die Bereitstellung der Änderung zu koordinieren. Für jeden Change sollten Korrekturmaßnahmen für den Fall eines Implementierungsfehlers vorbereitet werden. Nach Abschluss von Aufbau und Testing sollte Release and Deployment den Change Manager über die Ergebnisse und empfohlenen Implementierungsanforderungen informieren. Der Change Manager sollte jeden CHANGE auf Basis der empfohlenen Implementierungsanforderungen und des Business-Risk-Managements einplanen. Mithilfe eines Forward Schedule of Changes (FSC) oder Change Schedule kommuniziert der Change Manager alle bevorstehenden Änderungen an die betroffenen Stakeholder. Der FSC sowie projizierte Service-Ausfälle (PSO) bzw. erwartete Abweichungen in der Service-Verfügbarkeit werden bei der Koordination der Implementierung berücksichtigt. Release and Deployment ist für die Implementierung und Koordination des Schulungsbedarfs verantwortlich.
Nach Abschluss der Änderung sollte eine Post Implementation Review (PIR) – eine Überprüfung der detaillierten Implementierungsergebnisse – stattfinden, um zu bestätigen, dass die Änderung ihre Ziele erfolgreich erreicht hat. Bei erfolgreicher Implementierung und sofern die Änderung mit der Behebung eines Fehlers im Service verbunden war, sollten alle damit zusammenhängenden Problems und Known Errors geschlossen werden. Falls nicht erfolgreich, sollte der Korrekturplan entsprechend aktiviert werden.
Zur Unterstützung des Prozesses sollte ebenfalls eine Change Management-Richtlinie definiert werden. Diese Richtlinie kann Folgendes umfassen: die Definition eines Emergency Change; den unmittelbaren Nutzen des Prozesses; die Förderung einer änderungs- und ITIL-freundlichen Unternehmenskultur; die Festlegung von Rollen und Verantwortlichkeiten für verschiedene Change Management-Aktivitäten; die Beschränkung des Zugriffs auf Change Management auf autorisiertes Personal; Risikomanagement sowie Leistungsmessung.
Verwandt: Der umfassende Leitfaden zu ITIL
Change Management ist mit anderen ITIL Service Management-Prozessen über den gesamten Service-Lebenszyklus vernetzt, einschließlich Problem Management und Configuration Management.
Zur Lösung von Problemen sind häufig Änderungen erforderlich, um Workarounds zu implementieren und Known Errors zu beheben. Problem Management kann eine RFC einreichen, um einen Fehler in der IT-Infrastruktur zu beheben, der Probleme und Incidents verursacht. Problem Management kann dabei den normalen, standardisierten oder den Emergency Change-Prozess nutzen. In jedem Fall muss eine RFC eingereicht werden.
Change Management stützt sich bei der Bewertung der Auswirkungen einer Änderung auf die IT-Infrastruktur auf Konfigurationsinformationen im CMDB. Es ist unerlässlich, dass die von der Änderung betroffenen CIs identifiziert werden. Die mit dem betroffenen Configuration Item (CI) verbundenen Informationen werden zudem während des gesamten Change Management-Prozesses aktualisiert.
Change Management steuert die Änderung und koordiniert Aufbau, Testing und Implementierung mit dem Release and Deployment-Prozess. Diese beiden Prozesse sind so eng miteinander verzahnt, dass sie aufgrund der Übergaben wie ein einziger Prozess wirken sollten. Dies fördert eine serviceorientierte Ausrichtung und beseitigt Prozesssilos – auch bekannt als der „Throw it over the fence"-Ansatz bei der Implementierung.
Um Risiken, die sich negativ auf das Unternehmen auswirken können, zu minimieren und zu steuern, stellt IT Service Continuity sicher, dass die notwendigen IT-Services innerhalb der vereinbarten Mindest-Service-Levels wiederhergestellt werden. Mit IT Service Continuity sind zahlreiche Verfahren verbunden, die regelmäßige Aktualisierungen erfordern, um ihre Genauigkeit zu gewährleisten. Diese Aktualisierungen und Änderungen werden durch den Change Management-Prozess verwaltet.
Jede Änderung wird hinsichtlich ihrer Auswirkungen auf die Sicherheit bewertet.
Knowledge Management trägt dazu bei, die Entscheidungsunterstützung für Änderungen sicherzustellen. Dies umfasst die Koordination und Zusammenarbeit mit anderen Prozessbereichen bei der Weiterentwicklung von Daten, Informationen und Wissen für serviceorientierte Entscheidungen.
Benutzer fordern mitunter Änderungen an IT-Services oder Configuration Items an, die verwaltet werden müssen. Change Management verwaltet die meisten dieser Änderungen als Standard Changes – solange das Risiko der Änderung nicht erfordert, dass die jeweilige Änderung als Normal Change behandelt wird.
Portfolio Management übermittelt Change Proposals zur weiteren Bearbeitung an Change Management.
Verwandt: Was ist Knowledge Management?
Klar definierte Rollen und Verantwortlichkeiten sind der Schlüssel zu einem erfolgreichen Change Management. Obwohl jede Organisation ihre eigenen Anforderungen festlegt, sind die folgenden Rollen typischerweise im Change Management-Team zu finden:
Die Einzelperson oder Geschäftseinheit, die eine Änderung anfordert.
Eine Gruppe von Unternehmens-, Finanz- und technischen Vertretern, die Änderungsbewertungen durchführen. Der Change Manager / die Change-Autorität ist in der Regel der Vorsitzende des Change Advisory Board (CAB); Mitglieder können Kunden, Management, Entwickler, Berater, technisches Personal und nicht-IT-Büropersonal umfassen. Die Zusammensetzung der Vertreter variiert je nach Art der zu beurteilenden Änderung. Jede CAB-Sitzung wird durch eine CAB-Agenda geleitet, die die zu besprechenden Änderungsthemen priorisiert. Darüber hinaus kann ein Emergency Change Advisory Board (ECAB) eingerichtet werden, das bei Emergency Changes schnell zusammenkommt – diese Regelung sollte in der Richtlinie verankert sein. Das CAB kann auch zur Verbesserung des Change Management-Prozesses selbst eingesetzt werden.
Der Change Manager oder die Change-Autorität ist der Verantwortliche für den Change Management-Prozess. Diese Person prüft alle Change Requests, lehnt Anforderungen mit unzureichenden Informationen ab, leitet CAB-Sitzungen, identifiziert relevante CAB-Mitglieder, erstellt und verwaltet den Forward Schedule of Changes (FSC), fungiert als Bindeglied zur Koordination von Änderungen, überprüft implementierte Änderungen, verwaltet PIR, schließt RFCs ab und erstellt Management-Berichte. In einigen Organisationen gibt es Change Owner und Change Manager / Change-Autoritäten. Der Owner ist für die Wirksamkeit des Prozesses und dessen Verbesserung verantwortlich, der Manager für die Ausführung des Prozesses. Wenn nur eine Rolle existiert, trägt diese alle Verantwortlichkeiten.
Jeder ITIL-Prozess sollte hinsichtlich seines Erfolgs bei der Kostensenkung und der Steigerung des Service-Mehrwerts – einschließlich Verfügbarkeit und Zuverlässigkeit – gemessen werden. Die Identifizierung von Service-Konsumerisierungstrends, die Messung der Auswirkungen von Änderungen sowie der Nachweis einer Reduzierung von Geschäftsunterbrechungen durch Änderungen sind wichtige Verbesserungen, die dazu beitragen, die Ergebnisse des Change Managements mit den Unternehmenszielen zu verknüpfen.
Wichtige Change Management-KPIs und Kennzahlen für den Change Management-Prozess umfassen:
Der Wandel vollzieht sich heute schneller als je zuvor, und die Implementierung eines qualitativ hochwertigen Change Management-Prozesses macht den Umgang mit konstantem Wandel deutlich handhabbarer. Die Implementierung eines der ITIL-Prozesse kann eine anspruchsvolle Aufgabe sein – Change Management bildet dabei keine Ausnahme, sondern stellt ein beachtliches strategisches Projekt dar. Die Unterstützung der Unternehmensführung und des oberen Managements für die Change Governance zu gewinnen ist entscheidend, um die Akzeptanz der Mitarbeiter zu sichern, die das Framework sowohl implementieren als auch einhalten sollen. Die Einführung von Change Management muss für jeden Stakeholder in konkreten Mehrwerten ausgedrückt werden. Ebenso wichtig ist ein dediziertes Projektmanagement zur Koordination der Implementierung sowie eine IT Service Management-Lösung zur Unterstützung Ihrer ITIL-Prozesse.
Change Management kann ein schwer fassbares Konzept sein. Vermitteln Sie Zweck und Vorteile eines gut strukturierten Change Management-Prozesses auf allen Ebenen der Organisation, gewinnen Sie die Unterstützung der Unternehmensführung und arbeiten Sie sich durch die Hierarchieebenen. Alle Stakeholder an Bord zu holen ist grundlegend für den Erfolg von Change Management.
Definieren Sie die Typen und Kriterien für jeden Änderungstyp, den Sie verwalten werden.
Identifizieren Sie klar die Rollen und Verantwortlichkeiten aller am Change Management-Prozess beteiligten Personen, einschließlich des Change Managers, der Mitglieder des Change Advisory Board (CAB) und der Executive Sponsors.
Jeder oben identifizierte Änderungstyp erfordert einen Prozess, der dazu beiträgt, Erwartungen für Antragsteller und Support-Mitarbeiter zu definieren. Diese Prozesse können in Ihrer ITSM-Lösung für ein automatisiertes Management implementiert werden.
Identifizieren Sie die Kennzahlen, die für Ihre geschäftlichen Stakeholder von Bedeutung sind. Nutzen Sie diese, um Verbesserungen nachzuweisen und Ihre Erfolge zu kommunizieren.
Der Change Management-Prozess, die beteiligten Personen und die eingesetzte Technologie sollten regelmäßig auf ihre Leistung hin auditiert oder überprüft werden, und Verbesserungen sollten vorgenommen werden, um die betriebliche Effizienz sicherzustellen.
Diese können auf der organisatorischen Governance und/oder dem Reifegrad des Change Management-Prozesses bei der erfolgreichen Handhabung der verschiedenen Änderungstypen basieren.
Für IT-Organisationen, die Change Management-Software und/oder IT Service Management-Suites mit Change Management-Funktionen evaluieren, sind die folgenden Features wichtig – wenn nicht sogar unverzichtbar – um wichtige Prozesse effektiv zu unterstützen.
Change Management-Software sollte Administratoren mindestens in die Lage versetzen, folgende Aufgaben durchzuführen:
*Dieser Inhalt wurde ursprünglich auf Cherwell.com veröffentlicht, vor der Übernahme durch Ivanti.
Behalten Sie die Kontrolle über Ihre IT-Infrastruktur.