IT Change Management nach ITIL

Rollen und Verantwortlichkeiten im ITSM Change-Management-Prozess, Ziele, die 7 Rs sowie Unterschiede zwischen ITIL v3 und v4 – eine Geschichte für mehr Durchblick im ITSM.

Inhalt:

Dr. Christian Klaus hat ein Problem. Nach einem folgenschweren Ausfall im IT-System seiner Firma ist er aufgefordert, den Change-Management-Prozess zu überarbeiten. Den Fokus legt er dabei klar auf das Risikomanagement, eines der sieben Rs im ITIL Change Management.

 

Doch was war passiert?


Auslöser für Dr. Klaus' Kopfschmerzen war eine kleine Änderung am IT-Setup in einer regionalen Filiale. Die Störung hatte sich flächenartig ausgebreitet und am Ende die Kommunikations- und Videosysteme der gesamten Organisation stark beeinträchtigt. Mitarbeiterinnen und Mitarbeiter im Homeoffice waren abgeschnitten. Meetings zwischen der Geschäftsleitung und Kunden wie auch Lieferanten konnten nicht stattfinden. Drei Stunden ackerte die IT, bis wesentliche Geschäftsprozesse wieder anliefen.

Als ITIL-Experte und Process Owner für das IT Change Management waren Dr. Klaus die Zusammenhänge, die zu dem Ausfall geführt hatten, in ihrer Gesamtheit mittlerweile transparent.

Die Root Cause Analysis war durchgeführt worden, eine Post Implementation Review gab es dagegen nicht. Die Änderung in der Außenstelle war weder durch den Change Prozess genehmigt, noch war sie durch eine qualifizierte und autorisierte Person vorgenommen worden.

 

Best Practices und Fallstricke des IT Change Managements


Der Change-Management-Prozess sah konkrete Schritte für das Risiko Management vor, um genau solche Ausfälle zu verhindern. Zudem hatte Dr. Klaus schon vor zwei Jahren gemeinsam mit dem IT Change Manager eine Policy verfasst, die die Best Practices des Change Managements nach ITIL definiert und für die eigene IT-Organisation abbildet. Regelmäßig fanden Schulungen für die Teams statt, in denen die Inhalte wiederholt und diskutiert wurden. Alle Vorgaben aus dem Risiko Management der Change Management Policy waren schlicht ausgehebelt – sie waren einfach nicht beachtet worden.

 


webinars-itil

IT Change Management im Webinar:
Leidige Pflicht oder Erfolg durch Veränderung?

Neue Technologien entscheiden immer mehr über den Erfolg von Unternehmen. Damit steigt die Bedeutung funktionierender Change Management Prozesse. Erfahren Sie im Webinar (45 Minuten), wie Sie das Change Management effizient und praxisorientiert aufstellen.

Jetzt anmelden


 

Über das integrierte Service Management Tool zu einheitlichen ITSM-Prozessen


Die Theorie war an der Praxis gescheitert, in der dringende Anliegen nicht selten zum Umgehen der Prozesse einladen. Dr. Klaus war klar: Allein mit Disziplinierung der Teams würde er nicht weiterkommen. Zudem brannte ihm ein weiteres Bedürfnis unter den Nägeln. Ihm schwebte schon länger vor, die ITSM-Prozesse in seiner Firma mit einem integrierten Service Management Tool zu unterstützen und zu vereinheitlichen. Wichtig war, dass es diese Anforderungen seiner Prioritätenliste erfüllte:

  • bessere Prozesskontrolle über
    • eine Tool-basierte Forward Schedule of Change (FSC),
    • eine organisationsübergreifende Kalenderplanung,
    • eine umfassende Ressourcenverwaltung sowie
    • eine Steuerung und Kontrolle aller Change-Management-Rollen und -Verantwortlichkeiten
  • Berechtigungen für alle Prozessaktivitäten ausschließlich über die Integration mit dem unternehmensweiten LDAP-System
  • Transparenz über Abhängigkeiten und mögliche Auswirkungen in der IT-Infrastruktur
  • Transparenz über alle Change- und Release-Management-Aktivitäten vom erstmaligen Request bis zum Post Implementation Review
  • Bearbeitung und Dokumentation aller Change-Management- und Release-Management-Aktivitäten im Change Management Tool; vollständig basierend auf dem Inventar der Asset & Configuration Management Database (CMDB)
  • einfache, nachvollziehbare Kommunikation zu den Prozessschritten in allen Change-Management-Phasen – bestenfalls automatisch abgebildet innerhalb des Tools
  • umfassendes, transparentes Risikomanagement als Voraussetzung für die erfolgreiche Arbeit im Change Advisory Board (CAB) – insbesondere bei der Bewertung von Emergency Changes im eCAB
  • aufwandsarmes Messen und Berichten aller relevanten Key Performance Indikatoren (KPIs)
  • Vereinfachung des ITIL-Change-Management-Workflows

Eine ITSM-Software, die diese Anforderungen bewältigt, würde erheblich zur Verbesserung der Change-Management-Prozesse beitragen, da war sich Dr. Klaus sicher. Doch Tools und Policies für sich sind kein Erfolgsgarant. Dr. Klaus wusste: Ohne die Menschen im Unternehmen geht gar nichts. Schließlich waren es schon jetzt die Mitarbeiterinnen und Mitarbeiter, die mit ihrer Arbeit die Werte für Kunden schufen.

Organisatorisches Change Management (OCM): Menschen im Mittelpunkt


Selbstverständlich wollte Dr. Klaus die Möglichkeiten der Automatisierung in einem Tool nutzen. Ihm war aber bewusst, dass die geplanten Veränderungen mit Blick auf das Mehr an Kontrolle, Transparenz und Rechteverwaltung nicht bei allen Kollegen und Kolleginnen von Beginn an auf Gegenliebe stoßen würden.

Er hatte eine sensible Ader für die Befindlichkeiten des Teams. Die individuellen Rollen und Verantwortlichkeiten waren wichtig für die Selbstbestimmung, ja für das Selbstbewusstsein vieler – nicht nur in der Zentrale, sondern auch in der international verteilten Organisation. Bewährte, zum Teil geliebte Abläufe und Routinen waren seit Jahren etabliert.

Die Menschen kannten sich. Sie verstanden sich auch in der Vorbereitung und Umsetzung kritischer, komplexer Changes und bei großen Deployments fast blind. Schnell konnten Veränderungen im Sinne von Abgrenzung oder gar Beschneidung zu Unmut, Demotivation und politischen Interventionen auf Führungsebene führen.

Rechnung trägt dem seiner Meinung nach ITIL 4 mit seinen neuen Prinzipien. Während die 26 Life Cycle Prozesse aus ITIL 3 relative starre, regelhafte Abläufe formulieren, gewähren die 34 Management Praktiken aus ITIL 4 Freiheiten für die Definition maßgeschneiderter Prozesse. Große Hoffnungen hegte Dr. Klaus beim Organisatorischen Change Management (OCM) aus ITIL 4, das auf das Prinzip "einfach und praktikabel" setzt. Zudem schien ihm vorteilhaft, dass ein Prinzip des agilen Change Managements ohnehin schon lange im Team verinnerlicht war und gelebt wurde: das Prinzip der kontinuierlichen (Service) Verbesserung inklusive Continual Improvements Register. Beides würde die Neuausrichtung in der Organisation erleichtern.

34 Management Praktiken nach ITIL 4.

Übersicht: 

Die Unterschiede zwischen ITIL v3 und v4 beim IT Change Management

 

ITIL v3

ITIL v4

Beschreibt Change Management als Prozess in der Service Transition. Beschreibt das Change Management als Service-Management-Praktik und nennt es Change Enablement.

ITIL v4 führt die grundlegenden Aktivitäten im Change Enablement auf sowie die wichtigsten Inputs, Outputs und Rollen.

(IT-) Organisationen können auf Basis dieser Richtlinien einen angepassten Prozess für das Managen von Changes entwerfen, der die jeweiligen individuellen Anforderungen widerspiegelt.
Prozessschritte:
  • Change Management Support
  • Bewertung von Change-Vorschlägen
  • RfC-Erfassung und -Review
  • Bewertung und Implementierung von Notfall-Changes
  • Change-Bewertung durch den Change Manager
  • Change-Bewertung durch das Change Advisory Board (CAB)
  • Change-Planung und Freigabe der Build-Phase
  • Freigabe der Change-Deployment-Phase
  • Implementierung von Minor Changes
  • Post Implementation Review und Change-Abschluss

Change-Enablement-Praktik:

Der Change-Management-Prozess nach ITIL v3 wird nicht obsolet und kann als Vorlage für die individuelle Anpassung in der IT-Organisation verwendet werden.

Hauptaktivitäten:

  • Record
  • Plan
  • Approve
  • Execute
  • Review
Fokus auf Service Transition und Deployment

Fokus auf die Service-Wertschöpfungskette inklusive Konzeptions- und Entwicklungsphase

Change Enablement soll so entworfen sein, dass es die Ende-zu-Ende-Wertschöpfungskette des Service Managements im Auge behält.

Ein iterativer Ansatz soll die Balance halten zwischen einer schnellen Umsetzung eines RfCs einerseits und dem Management der einhergehenden Risiken für bestehende Services andererseits.

 

26 Life Cycle Prozesse nach ITIL 3.

 

Erfolgsfaktoren im IT Change Management


Veränderung kann nur gelingen, wenn klar ist, wofür man es tut und alle Beteiligten Vertrauen fassen, dass die Anstrengung auch gelingen kann. Diese Transparenz und Zuversicht herzustellen, war Dr. Klaus' größte Herausforderung.

Dass man künftig Ausfälle wie den jüngsten der Kommunikationssysteme verhindern wollte, dafür musste Dr. Klaus keine große Überzeugungsarbeit leisten. Niemand wünscht sich Fehler und Widersprüche im Prozess-Workflow, gestörte Abläufe, Ausfälle und Eskalationen. Auf einfach geregelte, nachvollziehbare und gut dokumentierte Abläufe mit klaren Verantwortlichkeiten sowie ein kontrolliertes Risikomanagement konnten sich alle einigen, denen eine sauber funktionierende, performante IT-Infrastruktur am Herzen lag.

Dr. Klaus fasste seinen Plan:

  • Für seine Anforderungsliste an das künftige ITSM-Tool würde er sich im Einkaufsprozess stark machen.
  • Dabei würde er noch einmal die Bedeutung einer integrierten Asset & Configuration Management Database hervorheben und die Zusammenhänge mit dem jüngsten Vorfall unterstreichen.
  • Gleichzeitig würde er darauf drängen, den Request for Information (RfI) um die Aspekte zu ergänzen, die nicht allein den prozessualen, systemnahen Funktionalitäten dienten. Tool-Funktionen, die Transparenz und Automatisierung ermöglichen und dadurch Routinearbeiten überflüssig machen, sollten mehr Gewicht bekommen. Auch auf die einfache Bedienbarkeit über verschiedene Geräte und Kanäle hinweg sollte mehr Augenmerk gelegt werden.

Nur dann, so war er sich sicher, würden sich die Kollegen und Kolleginnen schnell mit den Veränderungen anfreunden. Nur dann könnten die Veränderungen im IT Change-Management-Prozess schnell aktiviert werden. Und nur unter dieser Voraussetzung könnte er seinem Auftrag gerecht werden, schnell und zuverlässig dafür zu sorgen, Großausfälle künftig zu verhindern.


 

Die 7 Rs des IT Change Managements

Ein Erfolgsfaktor für Dr. Klaus waren die sieben Rs. Doch was ist das eigentlich genau?

Die 7 Rs des IT Change Managements sind eine Checkliste relevanter Aspekte, die beim Erstellen und Bearbeiten eines Change Requests berücksichtigt werden sollten. Die sieben einfachen Fragen helfen dabei, Changes strukturiert auf den Weg zu bringen, die sonst wegen zu vieler Unklarheiten abgelehnt würden.

 

1. Who RAISED the change request?

Wer hat den Änderungsantrag eingebracht? In der Fülle von Abteilungen, Ansprechpartnerinnen und Mitentscheidern sind Change Requests auf Zuruf ein Garant für Chaos. Zunächst muss geklärt werden, woher die Anforderung kommt. Für wen tun wir das? Wo bekomme ich Antworten auf Rückfragen her? Das systematisch zu dokumentieren ist der erste Schritt für strukturiertes IT Change Management.

 

2. What is the REASON for the change?

Warum machen wir das? Aus welchem Grund wird der Change gebraucht? Eine gute Lösung ist nichts wert, wenn wir damit das falsche Problem lösen. Zum anderen werden mit einem Change häufig Lösungsansätze skizziert, die den Blick auf eine bessere Idee versperren. Wenn wir Klarheit über die Gründe für den Change bekommen, lassen sich Chancen und Risiken besser gegeneinander abwägen. Für wichtige Themen suchen wir dann nach der Lösung, die im Kontext am besten passt, während Änderungen mit hohem Risiko bei minimalem Geschäftsnutzen verhindert werden.

Bei der Klassifizierung hilft die Portfolio-Analyse entlang der Vierfeldermatrix, wobei sich die Changes ähnlich wie beim Incident Management entlang der zwei Achsen (1) Auswirkung (z. B. Anzahl der User und Devices) und (2) Dringlichkeit sortieren lassen.

 

3. What RETURN is required from the change?

Welchen Ertrag versprechen wir uns von dieser Änderung? Die Zukunft kennt niemand und dennoch ist es wichtig, verschiedene Szenarien durchzuspielen. Was soll die Änderung einbringen, damit wir anschließend sagen können: das hat sich gelohnt. Nicht jeder Change übersetzt sich direkt in Kundennutzen, der z. B. in Form eines Software-Features einen Aufpreis der Software rechtfertigt. Die Automatisierung von zeitaufwändigen händischen Tasks kann dagegen Kapazitäten im Development für Innovationen freilegen. Automatische Regressions- und Lasttests entlasten den technischen Support. Der Abbau von technischen Altlasten (Technical Debt) hält die Entwicklungsumgebung zukunftssicher, so dass auf Neuerungen am Markt schnell reagiert werden kann. Diese weichen Faktoren müssen, so gut es geht, in harte Kennzahlen mit Blick auf Kosten und Nutzen übersetzt werden, anhand derer sich priorisieren lässt.

 

4. What are the RISKS involved in the requested change?

Rückt bei den Returns v. a. die optimistische Seite samt Best Case Scenario am Ende der Skala in den Blick, nehmen wir bei den Risiken die pessimistische Perspektive hin zum Worst Case Scenario ein. Jede Änderung birgt Risiken. Manche lassen sich vermeiden, andere muss man gegebenenfalls in Kauf nehmen, wenn die Chancen einerseits oder die Nachteile, den Change nicht umzusetzen andererseits, schwerer wiegen. Doch dass sich Änderungen in einem Teil des Systems auf andere Bereiche auswirken, davon ist auszugehen. Die Konsequenzen sollte man daher vorab bestmöglich durchspielen.

 

5. What RESOURCES are required to deliver the change?

Welche Ressourcen werden für die Umsetzung der Anforderung benötigt? Auf dem Makro-Level geht es hier immer um Zeit und Geld, auf der Mikro-Ebene des IT Change Managements um Mensch (Skills) und Maschine (Capabilities). Diese existieren – oder fehlen – nicht im Vakuum. Sind die Kräfte in einem Projekt gebunden, fehlen sie in einem anderen. Gehen wir trotzdem beide an? Gleichzeitig? Welche Verzögerungen treten an anderer Stelle auf, wenn wir einen Change umsetzen? Die Frage hört bei der internen IT-Organisation nicht auf, sondern umfasst die gesamte Wertschöpfungskette bis hin zum Kunden (Customer Value Chain). Auch Antworten auf diese Fragen müssen in die Priorisierung von IT-Projekten einfließen.

 

6. Who is RESPONSIBLE for the "build, test, and implement" part of the change?

Wer soll's machen? Wer baut, testet und implementiert den Change? Meist sind das für die einzelnen Teilschritte unterschiedliche Leute im Team oder sogar verschiedene Abteilungen. Umso wichtiger ist es, die Verantwortlichkeiten einerseits transparent und nachvollziehbar und somit um- und durchsetzbar zu machen. Dann ist unmissverständlich klar, wer für welche Aufgabe aktiv werden muss und im Falle eines Misserfolgs lassen sich unproduktive Schuldzuweisungen vermeiden. Über das gesamte Change und Release Management hinweg muss die Verantwortung klar verteilt und allen transparent sein.

 

7. What is the RELATIONSHIP between the suggested change and other changes?

Welche Beziehung besteht zwischen der vorgeschlagenen Änderungsanforderung und anderen Changes sowie vorhandenen Services? IT-Umgebungen sind komplex und stehen in vielen Abhängigkeiten zu anderen Bereichen und Funktionen im System. Manchmal reicht es, auf Auswirkungen in anderen Bereichen hinzuweisen, in anderen Fällen ist man auf deren Vorarbeiten angewiesen. Eine integrierte Konfigurationsmanagement-Datenbank (Configuration Management Database, CMDB) macht gegenseitige Abhängigkeiten transparent und ermöglicht die gemeinsame Zeit- und Reihenfolgeplanung zur Umsetzung von Changes bei möglichst wenig Ausfallzeiten und Zeitverzögerungen.

 

 

 

André Jung

Geschrieben von André Jung

André Jung hat in mehr als 30 Jahren in der IT-Wirtschaft vielfältige Erfahrungen gesammelt im Umgang mit Menschen – in Führungspositionen, im Vertrieb und in Professional Services. Den Bereich Customer Service Management hat er über zwei Jahrzehnte für Orange Business Services in Deutschland, Österreich und Osteuropa verantwortet. Seine Expertise, Gedanken und Standpunkte zum Thema IT Service Management und ITSM-Tools bringt er heute mit Begeisterung in Fachartikel und Videos ein - wenn er nicht gerade als Motorrad-Sicherheitstrainer oder Orchestermusiker unterwegs ist.


Ähnliche Beiträge

Abonnieren Sie den Blog für Benachrichtigungen zu neuen Inhalten!