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:

• Was ist IT Change Management?
• Die zentralen Aspekte des IT Change Managements
• Wie lässt sich das IT Change Management in Unternehmen umsetzen?
• Erfolgreiche Implementierung: Organisatorisches Change Management (OCM)
• Die Unterschiede zwischen ITIL v3 und v4 beim IT Change Management
• Best Practices und Fallstricke des IT Change Managements
• Erfolgsfaktoren im IT Change Management

Was ist IT Change Management?

Änderungen in der IT können schnell zu Problemen führen: Sei es der simple Austausch eines Arbeitsplatzrechners, die Einführung einer neuen Software, der Wechsel in die Cloud oder gestiegene Sicherheitsanforderungen. Um solche Neuerungen im Unternehmen optimal umzusetzen, helfen fest definierte Prozesse. Mit dem Changemanagement lässt sich der gesamte Ablauf besser planen. Dies minimiert Risiken und vermeidet Unterbrechungen. Ziel ist es, die bestehende IT-Strategie immer weiterzuentwickeln.

Die zentralen Aspekte des IT Change Managements

Beim IT Change Management gibt es sieben relevante 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. 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. Was ist der Grund für den 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. Welchen Ertrag versprechen wir uns von diesem Change? 

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. Welche Risiken sind mit dem beantragten Change verbunden? 

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. Welche Ressourcen werden benötigt, um den Change umzusetzen? 

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. Wer ist für Erstellung, Testen und Implementierung verantwortlich? 

Wer soll's machen? 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. Welche Beziehung besteht zwischen dem vorgeschlagenen Change und anderen Änderungen im Unternehmen?

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. 

Wie lässt sich IT Change Management im Unternehmen umsetzen? 

Um das IT Change Management im Unternehmen optimal umzusetzen, müssen Veränderungen stets nach festgelegten Punkten erfolgen.

Servicemanagement Tools für einheitliche ITSM-Prozesse

Zunächst müssen der Ist-Zustand analysiert und der Soll-Zustand definiert werden. Danach wird ein Zeitplan für den Change erstellt. Ein Testmodell hilft, Problemen – zum Beispiel bei der Servicequalität – vorzubeugen. Läuft das Testmodell, wird die Veränderung wie geplant umgesetzt.

Einfacher funktioniert dies, wenn die ITSM-Prozesse mit einer Service Management Software unterstützt und vereinheitlicht werden. Dieses sollte folgende Anforderungen erfüllen:

• 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 IT Management Software, die diese Anforderungen bewältigt, trägt erheblich zur Verbesserung der Change-Management-Prozesse bei.

Abb.: Integration von Veränderungen im Unternehmen

Erfolgreiche Implementierung: Organisatorisches Change Management (OCM)

Nach erfolgreicher Implementierung wird der gesamte Vorgang bewertet. Was sollte beim nächsten Mal optimiert werden? Wurden alle gesetzten Ziele erreicht? Wurde der Zeitplan eingehalten? Am besten wird für diese Überprüfung ein eigener Change-Manager eingesetzt, der das gesamte Projekt des IT Service Management überwacht und stetig optimiert.

Menschen im Mittelpunkt

Bei aller technischer Unterstützung darf aber auch der Mensch dahinter nicht vergessen werden. Bewährte, zum Teil geliebte Abläufe und Routinen sind seit Jahren etabliert. Veränderungen können daher schnell zu Unmut, Demotivation und politischen Interventionen auf Führungsebene führen.

Abhilfe schafft ITIL 4, das auf das Prinzip "einfach und praktikabel" setzt. 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.

Die Unterschiede zwischen ITIL v3 und v4 beim IT Change Management

Best Practices und Fallstricke des IT Change Managements

An einem Anwendungsbeispiel möchten wir Ihnen den gesamten Prozess erläutern.

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, eine der sieben Anforderungen im ITIL Change Management.

Änderungen am IT-Setup

Auslöser für Dr. Klaus' Kopfschmerzen war eine kleine Änderung an der Hardware 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.

Abb.: Bessere Zusammenarbeit beim Change Management

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.

Risiko-Management

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.

Webinar: IT Change Management
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.

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 fasst 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 lassen sich Systeme optimieren, Prozesse verbessern und Großausfälle künftig zuverlässig verhindern. Geschäftsziele werden so besser erreicht und die Digitalisierung im Unternehmen vorangetrieben.

Benötigen Sie professionelle Hilfe bei der Umsetzung des IT Change Managements in Ihrem Unternehmen? Unsere Experten von Serviceware unterstützen Sie gerne dabei, Ihre individuellen Anforderungen zu realisieren.