De flesta störningar är självförvållade

Bakgrunden till processen är obekväm: en stor del av alla allvarliga driftstörningar orsakas inte av angrepp eller hårdvarufel, utan av något någon just ändrade.

En uppdatering som rullades ut på en fredag. En brandväggsregel som skulle vara tillfällig. Ett certifikat som ingen visste löpte ut.

Förändringshantering handlar inte om att hindra ändringar. Den handlar om att veta vad som ändras, vem som godkänt det och hur man tar sig tillbaka.

Tre typer som ska hanteras olika

Att blanda ihop dem är den vanligaste orsaken till att processen upplevs som byråkrati.

Standardförändringar är förhandsgodkända och låg risk: en ny användare, en rutinmässig patchkörning, ett klientbyte. De ska inte gå via något förändringsråd. De ska loggas och verkställas.

Normala förändringar kräver bedömning: en versionsuppgradering, en ny integration, en omkonfigurering av något verksamhetskritiskt. Dessa riskbedöms och godkänns innan de genomförs.

Akuta förändringar genomförs för att lösa en pågående störning. De får gå före, men ska dokumenteras i efterhand – annars blir undantaget regeln inom ett halvår.

En bra tumregel: om mer än en tredjedel av era förändringar är akuta är det inte verkligheten som är kaotisk, utan processen som är för tung.

Fyra saker varje förändring ska beskriva

Vad som ska göras. Konkret nog att någon annan kan utföra det.

Vilka tjänster som påverkas. Här behövs en CMDB. Utan register över beroenden bygger bedömningen på att någon minns rätt.

Hur ändringen återställs om det går fel. Den punkt som oftast saknas och som kostar mest när den behövs.

Hur ni vet att den lyckades. Ett verifieringssteg, inte en känsla av att det nog gick bra.

Ett förändringsråd som inte bromsar

Ett CAB tar ställning till de normala förändringarna. Rådet behöver inte vara stort eller mötas ofta, men det behöver ha mandat och representation från verksamheten.

Ett CAB bestående enbart av tekniker missar konsekvent verksamhetsrisken – att uppgraderingen är tekniskt trivial men läggs samma vecka som bokslutet.

Möt tillräckligt ofta för att inte bli en flaskhals, och ha en väg för godkännande mellan mötena. Ett råd med två veckors väntetid kringgås systematiskt, och då förlorar ni både kontrollen och spårbarheten.

Förändringskalendern

En gemensam kalender över planerade förändringar gör två saker.

Den förhindrar att två team ändrar i samma miljö samtidigt – en av de svåraste feltyperna att felsöka i efterhand.

Och den gör det möjligt att införa stoppperioder när verksamheten inte tål störningar: bokslut, lönekörning, högsäsong. Att säga nej i förväg är betydligt enklare än att förklara sig efteråt.

Börja lättare än ni tror

Det här är den ITIL-praktik som oftast byggs för tung från start.

En process som upplevs som ett hinder kringgås, och en kringgången process ger sämre spårbarhet än ingen process alls. Börja med att bara registrera vad som ändras. Lägg till godkännanden när ni vet vilka ändringar som faktiskt är riskabla.

Nyckeltalet

Andelen förändringar som orsakade en incident. Det är det ärligaste måttet på om processen fungerar, och det bör följas tillsammans med övrig uppföljning i ert ITSM-system.

Se även incidenthantering för vad som händer när en förändring går fel, och problemhantering för hur återkommande fel spåras till sin orsak.