IT-Change-Management – Steuerung von Änderungen

IT Changes – Yes, we can!

Roger Fischlin

Die Innovationskraft der Informationstechnologie bedingt viele Änderungen und Neuerungen. Doch dies ist ein wunder Punkt in der betrieblichen Praxis, denn bei der Umsetzung kommt es immer wieder zu Pannen, die sogar zu ungeplanten Serviceausfällen führen können. Die IT Infrastructure Library (ITIL) ist heute der De-facto-Standard für das IT-Servicemanagement. Diese Sammlung bewährter Praktiken umfasst mit dem IT-Change-Management eine Domäne für den sicheren Umgang mit Änderungen. Das Konzept ist naheliegend, die Herausforderung steckt in der organisatorischen Verankerung.

Der amerikanische Präsident Obama begeisterte das Volk mit dem Versprechen „Change“. IT-Verantwortliche verbinden mit diesem Wort eher Unbehagen, denn das Ausrollen neuer Dienste oder die Modifikationen der IT-Systeme führen im Alltag häufig zu ungeplanten Ausfällen. Gartner Research [1] nennt ernüchternde Zahlen: Nur eine von fünf Unterbrechungen habe eine technische Ursache. Auf Softwarefehler, Performanceprobleme (also Designschwächen) und Änderungen an Anwendungen entfielen zu 40 %, die restlichen 40 % seien Fehler des IT-Personals. Es wundert nicht, wenn IT-Leiter hinter vorgehaltener Hand gelegentlich über leichtfertige Änderungen spotten, das Gegenteil von „gut“ sei „gut meint“. Auch bekannte, weltweit agierende Unternehmen waren bereits betroffen [2]. Ein Administrator hatte 2001, vielleicht einfach aus Sicherheitsüberlegungen, auf einem Router die maximale Anzahl paralleler DNS-Anfragen beschränkt. Der Webserver konnte nicht mehr alle Rechnernamen zeitnah auflösen, die Webpräsenz des Unternehmens war nicht mehr erreichbar. Die Fachleute fanden erst nach mehreren Stunden die Ursache. Das Unternehmen ging mit Details an die Öffentlichkeit, da Gerüchte eines erfolgreichen Internetangriffs im Web kursierten. Das Unternehmen hat offenbar die Abläufe verbessert, denn die Webpräsenz ist seitdem stets verfügbar. Fehlgeschlagene Änderungen bedeuten oft einen Prestigeschaden und führen in der Konsequenz zu vermeidbaren Arbeiten. Dugmore und Lacy bringen die Folgen mit britischem Understatement auf den Punkt: „Unsuccessful changes also waste valuable effort on unplanned activities that result in chaos while everyone tries to recover“ [3]. Die amerikanischen Autoren des „Visible Ops Handbook“ finden direktere Worte: „To err is human. To really screw up requires the root password“ [4].

Aus dem obigen Beispiel lassen sich mehrere Punkte für den Umgang mit Änderungen ableiten. Jeder Change ist fundiert zu begründen. Dies können wirtschaftliche Überlegungen (z. B. Business-Case, Effizienzverbesserung), notwendige Anpassung an geänderte Rahmenbedingungen (z. B. regulative Vorgaben) oder soziale Aspekte (u. a. Green IT) sein. Eine Änderung muss sorgfältig vorbereitet und ihre Auswirkungen müssen analysiert werden, die Umsetzung erfolgt erst nach formaler Freigabe. Derjenige, der eine Änderung beantragt, darf sie gemäß Funktionstrennungsprinzip weder bewerten noch die Implementierung autorisieren. Neben dem Umsetzungskonzept (inklusive Teststellungen) gilt es, zusätzlich einen Rückbauplan (Backout-Plan) zu entwerfen. Denn sollten trotz aller Maßnahmen Unstimmigkeiten auftreten, geht man anhand der Aufstellung unverzüglich – soweit möglich – zum stabilen Ausgangszustand zurück. Erst dann beginnt die Fehlersuche, um die Folgen so gering wie möglich zu halten. Der formale Ablauf für Änderungen stellt sicher, dass jeder Change dokumentiert und so von jedem jederzeit nachvollziehbar ist. Man wirkt so Erfahrungen aus dem Alltag eines IT-Betriebs entgegen, dass nach dem Wochenende niemand weiß, ob und gegebenenfalls welche Änderungen ein Administrator am Freitagnachmittag auf die Schnelle vollzogen hat.

IT-Change-Management

Die IT Infrastructure Library (ITIL) ist heute in der Praxis der Maßstab für serviceorientiertes IT-Management. Diese vom britischen Office of Governance Commerce (OGC) publizierte Sammlung bewährter Vorgehensweisen entspricht dem Stand der Technik, um IT-Services effizient und in der vereinbarten Qualität zu erbringen. Die zweite ITIL-Auflage wird allerdings in der Wahrnehmung mit der Erbringung eines vorgegebenen Serviceangebots überwiegend gleichgesetzt. Das OGC als ITIL-Herausgeber wirkte dieser verkürzten Sichtweise mit der Einführung des Servicelebenszyklus in ITILv3 entgegen. Im übergeordneten Kontext „Servicestrategie“ wird das Portfolio aller IT-Dienste geplant und gesteuert. Ein IT-Service wird ausgehend von der strategischen Planung konzipiert (Service Design), eingeführt (Service Transition) und betrieben (Service Operation). Bei Änderungen am Service oder an dessen Design beginnt im Sinne eines kontinuierlichen Verbesserungsprozesses der Kreislauf oder Lebenszyklus von vorne. Die ITILv3-Autoren zeichnen das Bild eines Rads mit „Service Strategy“ als Nabe in der Mitte.

Abb. 1: Freigabeprozess Change Management

Die Steuerung von Änderungen ist nach ITIL Aufgabe des Change Managements (Änderungswesens). Im Mittepunkt steht der Freigabeprozess (Abb. 1). Der Antragssteller (Change Requestor) reicht einen Änderungsantrag ein. In diesem so genannten Request for Change (RfC) beschreibt und begründet er den Change und stößt den Freigabeprozess an. Der Change Manager dokumentiert den Vorgang in einem Datensatz (Change Record). Der RfC wird nach einer formalen Eingangsprüfung kategorisiert und priorisiert. Letzteres gibt an, wie zeitnah die Umsetzung erfolgen soll. Die Kategorie bezieht sich auf die Fehlerwahrscheinlichkeit und die Auswirkung bei der Implementierung. Es ist festgelegt, wer für die Genehmigung je nach Kategorie die Entscheidungsbefugnis hat (Change Authority). Einfache Änderungen mit standardisierter Umsetzung kann ein lokal Verantwortlicher nach Absprache mit dem Change Management genehmigen. Changes mit überschaubarem Risiko autorisiert üblicherweise der Change Manager, bei größeren Fällen beraten ihn Mitglieder eines Gremiums (Change Advisory Board, CAB). Dieses setzt sich je nach Kontext aus Fachleuten der IT und Vertretern der Fachseite bzw. des Kunden und Lieferanten zusammen. Sie haben eine Gesamtsicht auf die IT und ihre Nutzung, über die ein einzelner Administrator nicht verfügt. Der Change Manager trägt die Verantwortung und bestimmt über die Freigabe. Das Gremium unterstützt ihn, trifft aber keine Mehrheitsentscheidung. Die Rolle des Change Managers muss die Autorität und die Befugnis haben, Änderungen in begründeten Fällen abzulehnen. Der Führung obliegt hingegen, weitreichende Änderungen zu bewilligen. Sie greift bei ihrer Entscheidung auf das Fachwissen des CAB und insbesondere die Erfahrung des Change Managers zurück.

Das Change Management koordiniert und überwacht nach der Freigabe der Änderungen deren Umsetzung, führt sie aber nicht aus. Es legt Termine fest (Schedule) und bündelt gegebenenfalls Changes zu einem Paket. Dieses so genannte Release definiert einen bestimmten Stand (Baseline) der IT, der oft durch eine Release-, Versionsnummer, Jahreszahl oder Quartalsangabe ausgedrückt wird. Der Change-Kalender enthält alle genehmigten Changes mit Implementierungszeitpunkt oder den geplanten Terminen. Support-Mitarbeiter können anhand der Liste Störungsmeldungen oder Anfragen einem Change zuordnen. Ab der dritten Auflage von ITIL heißt dieser Kalender „Change Schedule“ (CS), die veraltete Bezeichnung „Forward Schedule of Change“ (FSC) deckte nur zukünftige Änderungen ab. Der Kalender enthält Informationen über vereinbarte Wartungsfenster für Modifikationen (Change Windows) sowie festgelegte Sperrzeiten (Frozen Zones), in denen Änderungen im Sinne von „never change a running system“ grundsätzlich untersagt sind. Das Change Management führt im Nachgang eine Abnahme durch, ob die Implementierung gemäß Spezifikation durchgeführt wurde, und schließt den Vorgang formal ab.

Geschrieben von
Roger Fischlin
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.