So verbesserst du deinen IT-Support-Workflow
Die Weiterentwicklung des IT-Änderungsmanagements
Das Änderungsmanagement, auch bekannt als Change Enablement, ist eine IT-Managementpraktik zur Minimierung von Unterbrechungen bei IT-Services während der Durchführung von Änderungen an kritischen Systemen und Services.
Bei einer Änderung wird etwas hinzugefügt, geändert oder entfernt, was direkte oder indirekte Auswirkungen auf Services haben könnte.
Mithilfe von Änderungsmanagementpraktiken sollen Vorfälle reduziert und behördliche Vorgaben eingehalten werden. Die Praktiken gewährleisten eine effiziente und schnelle Bearbeitung von Änderungen an der IT-Infrastruktur und an Code, und zwar unabhängig davon, ob es sich um die Einführung neuer Services, die Verwaltung bestehender Services oder die Lösung von Problemen im Code handelt. Moderne Ansätze beim Änderungsmanagement lösen Silos auf, bieten Kontext und Transparenz, vermeiden Engpässe und minimieren Risiken.
Das Risikomanagement ist eine verwandte ITIL 4-Praktik, die befolgt wird, "um sicherzustellen, dass das Unternehmen Risiken versteht und effektiv damit umgeht". Sowohl das Änderungs- als auch das Risikomanagement erfordern die Nachverfolgung und Verknüpfung von Änderungen, um eine überprüfbare Dokumentation zu erstellen. Unternehmen, die auf Daten zu früheren Änderungen und deren Erfolgsquoten zurückgreifen können, sind besser in der Lage, ihre Praktiken so anzupassen, dass ein ausgewogenes Gleichgewicht zwischen Risiko und Geschwindigkeit erzielt wird.
Datengestützte, adaptive Praktiken sind wesentlich effizienter als das herkömmliche Änderungsmanagement, das oft unnötig langsam, prozesslastig und überbeansprucht sein kann. Da sich das Änderungsmanagement mit Herausforderungen wie Risiken und Compliance, Nachvollziehbarkeit und teamübergreifender Koordination befassen muss, wird es häufig komplex, bürokratisch und mühsam.
Doch das muss nicht so sein. Betrachte das Änderungsmanagement einfach als "notwendiges Übel" des ITSM, das zwar nicht immer eine schöne aber eine wichtige Aufgabe ist. Mit den richtigen Praktiken und der passenden Kultur kann das Änderungsmanagement weniger Vorfälle, weniger Stress für deine Teams und mehr Zeit für die Bereitstellung von Mehrwert für Kunden bedeuten.
Definition des Änderungsmanagements
Einige von uns verbinden mit dem Begriff Änderungsmanagement jeden Aspekt einer Änderung, etwa Technologien, Mitarbeiter und Prozesse sowie die Auswirkungen auf Kunden und Systeme. Für mehr Klarheit im Kontext des ITSM wird in ITIL 4 zwischen dem IT-Änderungsmanagement und den organisatorischen Änderungsmanagementpraktiken (Organizational Change Management) unterschieden.
- Organizational Change Management stellt sicher, "dass Veränderungen in einer Organisation reibungslos und erfolgreich umgesetzt werden und dass durch das Management der menschlichen Aspekte der Veränderungen nachhaltige Vorteile erzielt werden."
ITIL 4 definierte dann den früheren Änderungsmanagementprozess als "Change Control" Practice neu.
- Unter Change Control Practice versteht man Folgendes: "Sicherstellen, dass Risiken richtig bewertet werden, Changes genehmigen und einen Change-Kalender verwalten, um die Anzahl der erfolgreichen Changes von Services und Produkten zu maximieren."
Dieser neu gewählte Name löste Kontroversen aus und viele IT-Teams lehnten die Assoziation mit "Kontrollen" ab. Einige verbinden dieses problematische Wort mit Bürokratie, Engpässen und unnötigen Schritten, für die das herkömmliche Änderungsmanagement berüchtigt ist.
Axelos hörte sich das Feedback an und reagierte darauf. "Nach dem Release von ITIL 4 Foundation haben wir von mehreren Leuten auf der ganzen Welt gehört, dass die Practice falsch interpretiert oder missverstanden wurde, weil sie sich anscheinend auf die 'Kontrolle von Änderungen' oder die 'Kontrolle von Teams' konzentrierte, anstatt auf die 'Kontrolle der Änderungsrate'."
ITIL hat sich letztendlich dazu entschieden, die Practice als "Change Enablement" zu bezeichnen. Der neue Name steht für eine Praktik, die Teams unterstützt und ihnen die nötige Fähigkeit (und Freiheit) bietet, um Änderungen voranzutreiben.
Doch eigentlich ist es letztendlich egal, welchen Begriff du verwendest. (In diesem Artikel und bei Atlassian sprechen wir vom Änderungsmanagement.) Deutlich wichtiger ist dein Ansatz. Mit funktionierenden Teams und der richtigen Kultur ist dein Unternehmen bereits auf dem richtigen Weg, um eine effektive Änderungsmanagementpraktik zu erstellen.
Die Beziehung zwischen dem Änderungs- und dem Release-Management
Das Release-Management ist eine weitere wichtige Praktik für das Änderungsmanagement. Laut ITIL 4 besteht der Zweck des Release-Managements darin "neue und geänderte Services und Funktionen zur Nutzung zur Verfügung zu stellen". Releases können von Änderungen der Softwarefunktionen bis hin zu Dokumentations- und Schulungsupdates alles Mögliche umfassen.
In der Vergangenheit wurden beim Release-Management Änderungen gebündelt und den Kunden als Paket präsentiert. Das herkömmliche Release-Management hält strenge Projektmanagementstandards ein und kann zu Reibungen bei der Auslieferung wertvoller Updates für Kunden führen. Und dies führt wiederum zu Frustration bei Teams, die sich an Agile-Prinzipien halten.
Wir können das Release-Management für den DevOps-Kontext neu interpretieren. Das Release-Management sollte seinen Schwerpunkt von der herkömmlichen Projektmanagementfunktion auf die Integration und Automatisierung verlagern. Das beginnt bei der Integration von Code-Pipelines in ein sicheres System, das nach Möglichkeit eine automatische Überprüfung umfasst sowie Nachverfolgung und Überwachung ermöglicht. Dies kann die siloartigen Ansätze der Vergangenheit aufbrechen und für einen reibungslosen Weg zur Produktion sorgen. Beim Release-Management könnte es vor allem darum gehen, die kontinuierliche Bereitstellung von Mehrwert für Kunden deutlich zu vereinfachen und das You-build-it-you-own-it-Prinzip anzuwenden.
Warum ist das IT-Änderungsmanagement so wichtig?
Moderne Unternehmen haben einige kritische und sich gegenseitig ausschließende Erwartungen an ihr IT-Team. Zum einen erwarten sie stabile, zuverlässige Services, die sicherstellen, dass das Unternehmen produktiv ist und die Erwartungen der Endbenutzer erfüllen kann. Zum anderen muss das IT-Team regelmäßige Serviceupdates implementieren, damit sich das Unternehmen an sich ständig ändernde Sicherheits-, Kosten- und Geschäftsanforderungen anpassen kann.
Wenn weder das eine noch das andere erreicht wird, hat das schwerwiegende Folgen. Die Unfähigkeit, einen zuverlässigen Service aufrechtzuerhalten, kann die Produktivität massiv beeinträchtigen und hohe Kosten verursachen. Viele Unternehmen berichten laut Gartner von Ausfällen in Höhe von mehr als 300.000 US-Dollar pro Stunde. Bei einigen webbasierten Services liegt diese Zahl unter Umständen noch deutlich höher.
Gleichzeitig werden Unternehmen, die sich nicht auf die Zukunft einstellen, nicht in der Lage sein, mit geschäftlichen Entwicklungen Schritt zu halten, und hinter die Konkurrenz zurückfallen. Wenn Änderungen zu langsam bereitgestellt werden, kann das zur Folge haben, dass Mitarbeiter zu Unternehmen mit weniger schwerfälligen Systemen abwandern. Oder deine Kunden wenden sich anderen Unternehmen zu, die ihnen einen höheren Wert für ihr Geld bieten.
Wie gehst du also mit diesen widersprüchlichen Anforderungen am besten um? Eine Änderungsmanagementpraktik bietet deinem Unternehmen die Chance, Updates auszuliefern und dabei Stabilität zu gewährleisten sowie Risiken zu minimieren. Das Änderungsmanagement unterstützt Unternehmen auf folgende Weise bei der Durchführung von Änderungen:
- Erstellung eines Frameworks für die Verwaltung von Änderungsprozessen
- Priorisierung von notwendigen Änderungen für eine ordnungsgemäße Zuweisung von Ressourcen
- Einbindung relevanter Informationen für eine intelligentere Entscheidungsfindung
- Einbeziehung der notwendigen Stakeholder aus Entwicklung und IT in den Genehmigungsprozess
- Implementierung von Änderungstests, um Vorfälle zu vermeiden
- Rationalisierung und Verbesserung des Änderungs-Workflows, um schneller Mehrwert zu schaffen
Arten von Änderungen
ITIL beschreibt drei Arten von Änderungen:
Standardänderungen (Standard-Changes)
Standardänderungen sind risikoarm, werden häufig wiederholt und vorab genehmigt. Sie werden oft durchgeführt und folgen einem dokumentierten, genehmigten Prozess.
Zum Beispiel ist das Hinzufügen von Arbeitsspeicher oder Speicher eine Standardänderung. Wenn du einen fehlerhaften Router durch einen identischen funktionierenden Router austauschst, ist das eine Standardänderung. Wenn du eine neue Instanz einer Datenbank erstellst, ist das ebenfalls eine Standardänderung.
All diese Änderungen sind üblich und folgen einem klar definierten Prozess. Und weil der Prozess vermutlich bereits einmal den Risikobewertungs- und Genehmigungsprozess im Änderungsmanagement durchlaufen hat, müssen diese Prozesse nicht bei jedem Routeraustausch erneut durchlaufen werden.
Für viele Unternehmen bieten Standardänderungen eine gute Möglichkeit zur Automatisierung. Einige Unternehmen berichten, dass bis zu 70 % der Standardänderungen automatisiert werden können, sodass ihre Teams sich auf normale Änderungen und Notfalländerungen konzentrieren können.
Normale Änderungen (Normale Changes)
Normale Änderungen sind keine Notfalländerungen, für die es keinen definierten, vorab genehmigten Prozess gibt.
Das Upgrade auf ein neues Content-Management-System ist beispielsweise eine normale Änderung. Die Migration auf ein neues Rechenzentrum ist ebenfalls eine normale Änderung. Leistungsverbesserungen sind normale Änderungen. Sie sind weder standardmäßig noch wiederholbar. Mit diesen Änderungen sind gewisse Risiken verbunden, sie sind aber noch keine Notfälle. Und das bedeutet, dass sie beim Änderungsmanagement erst einmal zur Risikobewertung und Genehmigung in die übliche Warteschlange kommen.
Einige normale Änderungen, wie der Wechsel des Rechenzentrums, sind risikoreich und erfordern möglicherweise eine Risikobewertung und Genehmigung durch ein Change Advisory Board (CAB). Andere Änderungen, wie Website-Änderungen, sind eher risikoarm und können von einer festgelegten Change Authority oder durch automatisierte Prüfungen und Peer Reviews schneller genehmigt werden.
Notfalländerungen (Notfall-Changes)
Diese Änderungen ergeben sich aus einem unerwarteten Fehler oder einer Bedrohung und müssen sofort behoben werden, etwa um den Service für Kunden oder Mitarbeiter wiederherzustellen oder Systeme vor einer Bedrohung zu schützen.
Die Implementierung eines Sicherheitspatches ist beispielsweise eine Notfalländerung. Die Beseitigung eines Serverausfalls ist eine Notfalländerung. Die Behebung eines größeren Vorfalls ist eine Notfalländerung.
Die Dringlichkeit von Notfalländerungen bedeutet, dass sie in einem viel engeren Zeitrahmen bearbeitet werden müssen, da das Risiko eines langwierigen Prüfprozesses höher ist als das Risiko, das mit der schnellen Lösung des Problems verbunden ist.
Wie du deine Änderungen kategorisierst, hängt von Faktoren wie deinem Unternehmen, deinen Prozessen und deiner Risikotoleranz ab. Wir plädieren dafür, den Universalansatz aufzugeben und stattdessen jede Änderung auf der Grundlage einer Risikobewertung unterschiedlich zu behandeln. Je mehr dein Unternehmen über frühere Vorfälle und bestimmte Systeme weiß und andere relevante Daten einbezieht, um so einfacher kann es eine größere Anzahl von Änderungen als Standard kennzeichnen und diese vorab genehmigen. Ein modernes Änderungsmanagement sollte dazu beitragen, dass Änderungsanfragen so einfach und effektiv wie möglich abgewickelt werden können.
Was ist ein Change Advisory Board (CAB)?
In den meisten traditionellen IT-Organisationen wird ein Change Advisory Board (CAB) damit beauftragt, die Risiken jeder Änderung zu bewerten und Änderungen zu genehmigen (oder auch nicht). Normalerweise führt ein CAB regelmäßige Meetings durch, um alle vorgeschlagenen anstehenden Änderungen zu überprüfen. Bei Bedarf zieht es Experten hinzu, um diese Änderungen zu erklären, zu rechtfertigen oder zu bewerten.
Change Advisory Boards können einerseits dazu beitragen, Risiken zu reduzieren und die Alarmbereitschaft zu erhöhen, wenn eine Änderung für das Unternehmen nicht zum gewünschten Ergebnis führt. Anderseits können sie aber auch Engpässe verursachen, vor allem, wenn sie aus Personen zusammengesetzt sind, die wenig mit den bereitgestellten Änderungen zu tun haben. In vielen Unternehmen ist der Genehmigungsprozess für das Change Advisory Board (CAB) komplex und zeitaufwändig, was den Änderungsprozess verlangsamt.
Viele IT-Teams verzichten auf herkömmliche CAB-Meetings oder beschränken den Umfang auf besonders riskante Änderungen und wichtige organisatorische Belange. In diesem Paradigma können CABs zu zuverlässigen Beratern werden, die dafür zuständig sind, Änderungstrends zu überwachen, Ratschläge zu erteilen, wie damit mithilfe von Praktiken umgegangen werden kann, und die Koordination zwischen Teams und ihren Anforderungen zu übernehmen.
ITIL 4 fördert auch die Dezentralisierung deiner Change Authority und ihre Eingliederung auf der Ebene der geschäftlichen Stakeholder oder der Kollegen. Anstatt einen separaten Ausschuss einzusetzen, solltest du das Änderungsmanagement in normale Arbeitsabläufe mit relevanten Stakeholdern eingliedern. Um Engpässe zu vermeiden, ziehe Automatisierung, virtuelle Checklisten und Peer Reviews als flexiblere und kollaborativere Alternativen in Erwägung.
Der Änderungsmanagementprozess
In flexiblen High-Velocity-Teams verlagert sich der Änderungsmanagementprozess weg von langwierigen Überprüfungen und Genehmigungen durch nichttechnische Stakeholder hin zu automatisierten, kollaborativen Prozessen zwischen IT- und Entwicklungsteams. Dies steigert die Agilität, ohne die Risiken zu erhöhen.
Hier findest du einen einfachen Überblick über einen Änderungsmanagementprozess sowie einige Empfehlungen, wie du schneller Mehrwert schaffen kannst.
| Schritt | Best Practices |
| Änderungsanfrage – Jemand fordert eine Änderung an und fügt Hinweise zu möglichen Risiken, zur erwarteten Implementierung und den betroffenen Systemen ein. | Richte ein intuitives Self-Service-Portal für Stakeholder und IT-Mitarbeiter ein, damit sie einfach eine standardmäßige Änderungsanfrage stellen können. Stelle sicher, dass deine Entwicklungs- und IT-Teams auf derselben Plattform zusammenarbeiten können, damit während des gesamten Workflows für Änderungsanfragen Kontext und Transparenz gewährleistet sind. |
| Prüfung der Änderungsanfrage – Ein Change Manager oder Peer Reviewer prüft die erste Änderungsanfrage. Wie hoch ist die Wahrscheinlichkeit, dass sie erfolgreich ist? Sind die Risiken und Vorteile korrekt? Lohnt es sich, die Änderung vorzunehmen? | Nutze Automatisierung, um die Änderung automatisch zu genehmigen, oder starte einen kurzen Genehmigungsprozess, bevor die Änderung implementiert wird. |
| Änderungsplan – Das Team erstellt eine Strategie für die Änderung. Es dokumentiert erwartete Ergebnisse, Ressourcen, Zeitpläne, Testanforderungen und Möglichkeiten, die Änderung bei Bedarf rückgängig zu machen. | Bringe Stakeholder mit einem Kick-off-Meeting zum Änderungsmanagement auf den aktuellen Stand. Informiere Teams anhand von Vorlagen für Wissensdatenbanken, mit denen deine Änderungspläne dokumentiert werden sollen. |
| Genehmigung der Änderung – Der entsprechende Change Manager, Peer Reviewer oder das CAB prüft den Plan und genehmigt die Änderung. | Rationalisiere Genehmigungen mit Peer Reviews. Breche Silos durch die Nachverfolgung und Dokumentation gemeinsamer Arbeiten auf, damit Kollegen einfach und asynchron zusammenarbeiten können. |
| Implementierung der Änderung – Das Team liefert die Änderung aus und dokumentiert währenddessen Verfahren und Ergebnisse. | Nutze Automatisierung, um deine Prozesse und Standards zu unterstützen. Die Workflow-Automatisierung kann Anfragen basierend auf deinen Geschäftsregeln an die nächste autorisierte Person weiterleiten und sie ihr zuweisen. |
| Abschluss der Änderung – Der Change Manager überprüft und schließt zum gegebenen Zeitpunkt die Änderung. Aus seinem Bericht sollte hervorgehen, ob die Änderung erfolgreich war, zeitnah vorgenommen wurde, korrekt eingeschätzt wurde, im Budgetrahmen geblieben ist usw. | Bewahre Wissensdatenbankartikel und Tickets auf, damit Teams aus früheren Erfahrungen lernen können. Vielleicht gibt es Möglichkeiten, ähnliche Änderungsanfragen in Zukunft zu automatisieren? |
Best Practices für das Änderungsmanagement
Wie bereits erwähnt betrachten viele von uns das Änderungsmanagement als notwendiges Übel. Niemand befasst sich gern damit, aber jeder weiß, wie wichtig es ist. Wir können jedoch einige Schritte unternehmen, um die Sache angenehmer zu gestalten.
Hier sind einige Best Practices für ein modernes Änderungsmanagement:
- Verschaffe dir einen Überblick über die Risikotoleranz und die gesetzlichen Verpflichtungen deines Unternehmens.
- Vereinfache und automatisiere Änderungsmanagementprozesse in allen Bereichen, in denen das möglich ist.
- Richte CABs strategischer aus.
- Führe Praktiken ein, die Standardänderungen zur Normalität werden lassen.
- Nutze verschiedene Frameworks wie ITIL und DevOps, um Leitlinien zu finden, die für dein Unternehmen am besten geeignet sind.
- Priorisiere die Zusammenarbeit.
- Nutze Chaos Engineering, um das Risiko zu reduzieren.
- Optimiere die Aufnahme von Änderungsanforderungen für IT- und Entwicklerteams.
- Gewinne neue Erkenntnisse mithilfe von Änderungsmetriken und KPIs.
- Nutze einen DevOps-gesteuerten Ansatz für das Release-Management.
Stelle dich den Herausforderungen des Änderungsmanagements
Entwickler möchten Code schnell und ohne zusätzlichen Zeit- und Arbeitsaufwand für die manuelle Dokumentation bereitstellen. IT-Operations-Teams versuchen, Risiken zu reduzieren, detaillierte Aufzeichnungen für Audits zu führen und Vorfälle zu vermeiden. Wenn man Entwickler darum bittet, ihren Prozessen einen zusätzlichen Schritt hinzuzufügen, Dinge aufzuschreiben oder ein- und auszuchecken, erhält man den Eindruck, dass sie dadurch von ihren eigentlichen Arbeitszielen abgehalten werden. Bittet man das Operations-Team, bestehende Prozesse zu überarbeiten, Genehmigungsprüfungen aufzuheben und mehr Aufgaben zu automatisieren, wird man das Gefühl nicht los, dass dadurch mehr Risiken entstehen.
Noch nie stand so viel auf dem Spiel. Die zunehmende Verbreitung softwaregestützter Services hat die Erwartungen der Kunden und die Nachfrage nach stets verfügbaren, leistungsstarken Services erhöht. In einer zunehmend dynamischen Umgebung wächst der Aufwand für die Verwaltung von Services stetig.
Wie lassen sich diese Herausforderungen also überwinden? Beispielsweise indem wir zunächst mit dem Vorurteil aufräumen, dass ein schwerfälliger Prozess Risiken reduziert. Dann eine Kultur, geeignete Praktiken und Tools einführen, die Teams bei der Zusammenarbeit und der Auslieferung unterstützen. Und schließlich, indem wir kontinuierlich Informationen integrieren, um den Nutzen der vorherigen Schritte zu demonstrieren, und weiterhin nach Verbesserungen streben.
Möchtest du erfahren, wie Jira Service Management deinen Änderungsmanagementprozess transformiert?
Atlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
White Paper lesenWissensdatenbank: deine Lösung für eine bessere Zusammenarbeit
Entdecke die Vorteile einer Wissensdatenbank für dein Unternehmen. Du kannst mit ihr die Produktivität steigern, den Kundenservice verbessern und das Informationsmanagement effektiv optimieren.
Artikel lesen