IT Changes – Yes, we can!

Request for Change

Änderungen werden per RfC beantragt. Das Change-Management prüft, und wenn nötig, aktualisiert es die Daten, um sie in den Change Record zu übernehmen. Es korrigiert jedoch keine inhaltlichen Fehler, sondern gibt fehlerhafte Anträge an den Antragsteller zurück. Pläne werden oft erst nach der Freigabe verfeinert. Die RfC-Struktur ist für Service-Changes und Änderungen der IT-Infrastruktur im Grundsatz identisch. Unterschiede gibt es in der Ausprägung der Angaben. Ein Business Case ist z. B. die Rechtfertigung für einen neuen IT-Service, während ein operativer Change durch wiederholt auftretende technische Probleme begründet werden kann. Bei einem Service-Change stammen viele Daten aus dem SDP, das u. a. einen Plan zur Einführung (Transition Plan) ebenso wie Qualitätskriterien enthält. Tabelle 1 gibt eine Übersicht über typische Felder eines RfC und eines Change Records. Sie sind für den Einzelfall anzupassen.

Tabelle 1: Felder des RfC und des Change Records

Feld Beschreibung RfC Change Record
Zusammenfassung
ID Eindeutige Nummer als Referenz wird vergeben wird vergeben
Change Requestor Antragsteller mit Kontaktdaten Angabe Prüfung
Change Owner Verantwortliche Abteilung bzw. Kostenstelle für RfC Angabe Prüfung
Logging Date Zeitstempel des RfC-Eingangs wird vergeben wird vergeben
Priority Dringlichkeit des Changes Angabe Prüfung
Due To Fälligkeit für Umsetzung Angabe Prüfung
Category Kategorie (Auswirkung, Risiko) Angabe Prüfung
Type Art der Begründung (z. B. Business Case, Compliance usw.) Angabe Prüfung
Target Baseline (Release) Verweis auf Release (Stand), in die Change aufgenommen werden soll Angabe Prüfung
Description Zusammenfassung der Änderung Angabe Prüfung
CIs Betroffene Configuration Items (Geräte, Dokumentationen usw.) mit Beschreibung der jeweiligen Änderungen oder des Service Design Package (SDP) Angabe Prüfung
Justification Begründung für Change (Business Case, Referenz auf Ticket usw.) Angabe Prüfung
Risk Statement Zusammenfassung der Risiken Angabe Prüfung
Umsetzung (Implementation)
Implementation Date and Time Zeitpunkt der Umsetzung, Verweise u. a. auf Wartungsfenster Angabe Prüfung, Aktualisierung
Duration Dauer der Umsetzung Angabe Prüfung, Aktualisierung
Costs Kosten der Umsetzung Angabe Prüfung, Aktualisierung
Change Implementer Verantwortlicher für Umsetzung Angabe Prüfung, Aktualisierung
Implentation Plan Ablauf der Umsetzung, Zerlegung in einzelne Arbeitspakete (Work Orders) Angabe Prüfung, Aktualisierung
Release Plan/Deployment Plan Planung für das Ausrollen des Releases (u. a. abgeleitet aus dem Transition Plan des SDP) Angabe Prüfung, Aktualisierung
Resources Ressourcen für Umsetzung Angabe Prüfung, Aktualisierung
Communication Plan Informationsfluss über Änderung Angabe Prüfung, Aktualisierung
Quality Acceptance Criteria Kriterien für erfolgreiche Umsetzung Angabe Prüfung, Aktualisierung
Test Plan Teststellungen vor Umsetzung Angabe Prüfung, Aktualisierung
Risk Management Plan Plan mit identifizierten Risiken der Umsetzung, Bewertung und getroffene Maßnahmen Angabe Prüfung, Aktualisierung
Backout Plan Rückbauplan, falls Probleme auftreten Angabe Prüfung, Aktualisierung
Approval (Freigabe)
Approval Entscheidung: Freigabe oder Ablehnung Dokumentation
Approval Date Zeitpunkt der Entscheidung Dokumentation
Approver Entscheider Dokumentation
Approval Statement Erläuterung der Entscheidung Dokumentation
CAB Meeting Verweis CAB-Sitzung Dokumentation
Advisory Board Zusammensetzung CAB ggf. Vorschlag Dokumentation
Closure (Abschluss)
Closure Ergebnis (erfolgreich/fehlgeschlagen) Dokumentation
Closure Date Abschlusszeitpunkt des RfC Dokumentation
Closure By Abschluss Dokumentation
Closure Statement Ergebnis des Abschlusses Dokumentation
Review Statement Ergebnis des Reviews Dokumentation
Review Date Zeitpunkt des Reviews Dokumentation
Reviewer Dokumentation
Lessons Learned Erfahrungen im Rahmen des Changes Dokumentation
Entwicklung von Applikationen

Ein Entwickler hat zwei Berührungspunkte mit dem Change Management. Einerseits entwickelt oder konfiguriert er Applikationen zu einem Service Change, zum anderen ist er als Experte in die Fehlersuche und Korrektur von Anwendungen eingebunden (Problemmanagement). Zwar gibt es einen Build-Schritt im Release- und Deployment-Management, doch geht es im Wesentlichen um die Zusammenstellung des Release. Die ITILv3-Autoren skizzieren den Rahmen für die Entwicklung einer Anwendung im Band „Service Design“ im Abschnitt „Application Management“. Allerdings finden sich in den ITIL-Büchern weiterhin keine Empfehlungen, wie die Software entwickelt werden soll, sondern man verweist auf etablierte Vorgehensweisen in der Softwareentwicklung. Die Grundlagen für das organisationsweite Design, insbesondere zur IT-Rahmenarchitektur, sollten dokumentiert sein. Es ist dann Aufgabe des Service-Change-Managements, vor der Freigabe zu prüfen, ob das Servicedesign und insbesondere die Anwendungen diese Vorgaben einhalten.

Fazit

Änderungen am Serviceportfolio an einzelnen Diensten oder Applikationen oder auf Ebene der Infrastruktur gehören zum Alltag der IT. Sie sind nicht die Ursache der Probleme, sondern die leichtfertige und zu oft unkoordinierte Einführung. Bewährt hat sich ein IT-Change-Management, das alle Änderungen sichtet und deren Umsetzung überwacht, aber selbst nicht ausführt. Der Erfolg hängt einerseits von der Akzeptanz und der organisatorischen Verankerung ab. Mit Standard-Changes kann der Eindruck zunehmender Bürokratie vermieden werden. Ein Verbund von Change Managements auf operativer Ebene hilft, Ressentiments gegen eine empfundene zentralistische Kontrolle zu entkräften.

Dr. Roger Fischlin ist Senior Business Consultant bei der Management- und Technologieberatung BearingPoint. Zuvor war er fast fünf Jahre für den IT-Betrieb des Fraunhofer Network Operation Centers zuständig. Er hat Informatik und Mathematik an der J.W.Goethe-Universität Frankfurt studiert und über Kryptografie bei Prof. Dr. Claus-Peter Schnorr promoviert.
Kommentare

Schreibe einen Kommentar

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