Change Management
Problemer kan opstå når ændringer laves i IT-infrastrukturen. Derfor er der brug for en proces, Change Management, for at begrænse de skader som opstår når ændringer udføres. Kerneproces i ITIL.
Formål
- Sikre at standardmetoder og procedurer bruges til hurtig håndtering af alle Changes.
- Sikre at Change-relaterede Incidents påvirker mindst muligt.
- Sikre at SLA overholdes.
Definitioner
De mest centrale begreber indenfor Change Management:- Request for Change (RFC), ofte blot kaldet "Change", er at spørge om lov til at udføre en ændring i IT-infrastrukturen.
- Servicevindue: Start- og sluttidspunkt hvor der er tilladelse til at udføre en Change.
- Change Advisory Board (CAB): Specialister og ledere som vurderer og godkender Change Requests.
- Change typer: Emergency, Normal, No Impact.
- Forward Schedule of Changes (FSC): Kalender med planlagte Changes.
Processer
Vigtige processer og aktiviteter indenfor Change Management:- Registrere Change (rollback-plan)
- Vurdere Change (CMDB som hjælpeværktøj)
- Godkende Change (CM, CAB) og give Servicevinduer
- Udføre Change
- Lukke Change.
- Opdatere CIs.
- Identificere udførte, ikke-godkendte Changes.
- Rapportere på Change-processen.
Udfordringer
- Sikre at alle ændringer registreres (efter-registreres) rettidigt.
- Sikre at der ikke udføres uautoriserede ændringer.
- Sikre at servicevindue overholdes.
- Sikre godkendelser fra relevante personer.
KPIer
Eksempler på Key Performance Indicators for Change Management:- Change succes (% succes, % fejl).
- Changes som fører til Incidents (opdages af brugerne).
- Antal uautoriserede Changes.
- Changes udført indenfor / udenfor det godkendte servicevindue.
- Changes efter type: Emergency, Normal, No Impact.
Roller
Vigtige roller for Change Management-processen:- Change Manager: Ansvarlig for Change-processen.
- Incident Manager
- CAB-medlemmer (Change Advisory Board)
- Release Manager: Bistår ved større udrulninger.
- Udvikler
- Tester
- Systemejer
Noter om Change Management
Rigtig mange Incidents opstår på grund af menneskelige fejl med den konsekvens at IT-systemer går ned når de burde køre og IT-omkostninger accelererer på grund af brandslukning og sjusk. Change-processen forsøger at ændre på den situation ved at registrere og godkende Changes inden de udføres.
Der er særligt to begrundelser for Change-processen. Først, at IT er forretningskritisk og nedetid koster. Dernæst, at en IT-infrastruktur er så kompleks at den sjældent kan gennemskues af enkelt-personer særligt når det handler om ændringer i forretningssystemer som kører på et avanceret setup af servere, databaser og indbyrdes afhængige systemer.
Alternativet til Change Management er nedetid, ustabile forretningssystemer, og en masse tid forbrugt på at løse Incidents ("Hvad skete der?").
Typer af udførte Changes:
- Autoriseret Change som går godt. Det er idealsituationen for Change-processen, men sjældent normalt. Målet er at få registreret alle Change Requests, og sikre at de godkendes eller afvises.
- Uautoriseret Change lavet ved en uheld. Det sker nemt at en menneskelige fejl fører til en Incident. Change-processen registrerer fejlen og sikrer at den udbedres.
- Uautoriseret Change lavet med vilje. Det undergraver Change-processen hvis uautoriserede Changes alligevel udføres, og det er her vi ser om ledelsen virkelig bakker op om Change-processen (eller vender det blinde øje til og ad den skaber mistillid til Change-processen).
En tommelfinger-regel er, at du opretter en Change hvis du har brug for en medskyldig når det går galt.. :-)
Næste: Næste side: Configuration Management »