Blog-Reihe: „Houston, wir haben ein Problem“ (IT-Support. Teil 5)
Oxana MartevaiaIm letzten Teil dieser Blogreihe werden wir uns mit den Aufgaben des Change-Managements befassen. Unter Change-Management fallen Änderungen am Produktivsystem, die nicht umfangreich genug sind, um im Rahmen eines regulären Releases freigegeben zu werden, z.B. geringfügige Konfigurations- und Parameteränderungen oder das Verschieben des Zeitraums automatisch eingeplanter Prozesse.
Change-Management erfordert zunächst einmal das sorgfältige Dokumentieren der Änderungen, die am Produktivsystem vorgenommen werden sollen, mit zugehöriger Risiko- und Folgenabschätzung. Hier sind die Fragen zu beantworten wie: Was kann während der Implementierung der Änderung passieren? Sind der Service oder die Applikation während dieser Zeit nur eingeschränkt verfügbar oder muss das System sogar komplett heruntergefahren werden? Welchen Risiken setzen wir der Bank aus, wenn wir diese Änderung nicht vornehmen?
Für gewöhnlich werden zur Abwicklung von Changes (wie übrigens auch für Incidents und Problems) Softwarelösungen, wie z.B. ServiceNow verwendet. Solche Softwarelösungen lassen Hard- und Softwarekonfigurationen detailliert mit ihren Abhängigkeiten untereinander abbilden, sodass im Tool aufgesetzte Changes z.T. auch automatisch die von einem Change betroffenen Stakeholder (Verantwortliche Manager, Application Owner, Supporteinheiten, Fachabteilungen) bestimmt und über geplante Änderungen informieren kann. Außerdem verwalten solche Software-Tools häufig auch das Einholen und Gewähren von Genehmigungen für Changes von den betroffenen Stakeholdern und verantwortlichen Change-Prüfern.
Ein weiterer „Best Practice“-Ansatz besteht darin, regelmäßig über anstehende Changes für einen System- oder Komponentenkomplex mit allen beteiligten Stakeholdern zu sprechen; dies kann z.B. im Rahmen eines moderierten „Change Advisory Board“ geschehen.
Sauber aufgesetzte Change-Management-Prozesse erlauben auch das korrekte Dokumentieren von Änderungen im Produktivsystem, die zeitkritisch sind, um z.B. absehbare Störungen proaktiv zu beheben oder aber bereits aufgetretene Störungen zu beseitigen. Solche kritischen Changes, um Schaden und Geldverlust zu vermeiden, sind oft auf die schnelle Umsetzung ausgelegt, erfordern dementsprechend aber auch Genehmigungen von mindestens einer befugten Autorität.
Abschließend ist festzuhalten, dass der Dreh- und Angelpunkt bei solchen Notfall-Changes immer die Kritikalität der abzusehenden oder tatsächlich eingetretenen Störung ist und welche Auswirkungen sie auf die Geschäftsprozesse haben. Man kann sich leicht vorstellen, dass es bei einem mehrstündigen Ausfall des Online-Bankings einer größeren Bank gleich um eine Menge Geld und einen potentiellen Imageschaden geht.
Quellen:
Kommentare
Popular Posts
