Grunderna i Change Management enligt ITIL

av | jul 29, 2019 | ITIL/ITSM

Change management är en kärnprocess för IT-organisationer och har funnits representerad i ITIL ända sedan starten på 80-talet.

Att ha kontroll över vilka förändringar som arbetas på respektive nyligen har satts i produktion är kritiskt för varje IT-organisation. Utan det blir det omöjligt att bedöma arbetsbelastning på personal, förväntade ledtider på leveranser samt naturligtvis också än svårare att hitta varför plötsliga driftsstörningar uppstår.

I den 4:e versionen av ITIL har processen förfinats ytterligare och har bland annat döpts om till Change Enablement (ett kort tag också Change Control). Därmed dags att slå hål på ett missförstånd kring Change management (i den här texten har vi valt att behålla det gamla etablerade namnet för igenkänningsfaktorns skull) .

Syftet med processen Change Management enligt ITIL

Syftet med Change management är inte att hindra tekniker från att göra sitt jobb genom att implementera byråkratiska processer. Det är heller inte till för att hindra tekniker att utföra produktionssättningar då det finns risk för efterföljande störningar och incidenter.
Syftet med processen är, och varför den också fått sitt namn, att ha kontroll över vilka förändringar som arbetas på respektive kunna följa upp vilka produktionssättningar som gjorts. Detta för att:
  • Veta vilka förändringar i miljön som är klara, fortfarande pågår respektive inte är färdiga.
    Om du lättare kan se arbetsenheter och hur arbetsflödet ser ut, kan du lättare hitta flaskhalsar och annat som hindrar er effektivitet.
  • Kunna förstå och bedöma belastning på interna resurser.
    Genom att bara jobba med en sak i taget blir du mer effektiv. Läs mer om varför lite längre ned.
  • Undvika onödiga krockar med andra förändringar av den miljö vi arbetar mot.
    Det kanske finns några steg i ert flöde som saknas? Eller några som egentligen är onödiga och borde tas bort?
  • Säkerställa att nödvändig dokumentation uppdateras i samband med förändring.
    När du väl fått flöden och visualisering på plats är det betydligt lättare att hitta små detaljer att finslipa på. Och nej, de kommer inte att ta slut. Det finns alltid något mer att slipa på.
  • Det inte introduceras onödig risk genom att inte ha stringenta metoder för change-arbetet.
    Varje förändring av produktionsmiljön är alltid en risk för IT-tjänsternas tillgänglighet och stabilitet. Vi bör då alltså ha ha effektiva metoder för att undvika att problem uppstår vid produktionssättningar (såsom test, rollbackplanering innan utrullning etc.).
  • Förenkla felsökning om det, mot förmodan, visar sig att produktionssättningen/förändringen, inte blev helt lyckad.
    När du väl fått flöden och visualisering på plats är det betydligt lättare att hitta små detaljer att finslipa på. Och nej, de kommer inte att ta slut. Det finns alltid något mer att förbättra.

Definitionen av en Change/Förändring

Vad är då definitionen av en change/förändring? Enligt ITIL 4 så är det varje ändring (new, update, delete) av konfigurationen kring en eller flera komponenter som används för att tillhandahålla en IT-tjänst.

En change kan alltså vara en ändring av en brandväggsregel, installation av ett nytt OS på server eller dator, patchning av en programvara, ny kod i en applikation eller egentligen vadsomhelst som vi betraktar som en ändring av en använd komponent. Den exakta definitionen av en change kan se lite olika ut mellan organisationer men enkel tumregel är att om förändringen kan innebära ökad risk och/eller att tjänsten påverkas negativt (dvs slutar fungera enligt önskad eller överenskommen nivå) i samband med förändringen så är det en change. Detta innebär alltså att även en kodförändring är att betrakta som en change.

Processen sträcker sig också från det att vi börjar arbeta med förändringen (planeringsfasen) ända till och med produktionssättningen. Idag har många organisationer som anammat DevOps eller mer utvecklade Agile/Scrum-metoder hittat sätt att automatisera mycket av flödet kring produktionssättningar. Det är utmärkt och helt i linje med ITIL så länge det finns någon form av dokumentation och versionshantering av detta. Även tester ingår i change-flödet och automatiserade tester är också de helt i linje med ITILs definition och målsättning.

Tre typer av Change

Flertalet organisationer har hittat sätt att standardisera och minimera risker med förändringar. Vidare så finns det också ett antal ofta återkommande aktiviteter som man arbetat på för att förenkla och hantera löpande allteftersom de uppstår. Typiskt hittar man på driftsavdelningar ofta standardiserade metoder för att hantera löpande patchar och uppdateringar medan lite större förändringar kan behöva lite mer tid, planering, kontroller och uppföljning. Utöver det finns det självklart också de där olyckliga tillfällena när vi hittat ett kritiskt säkerhetshål eller har en större incident som endast kan lösas med hjälp av en förändring av miljön (givet att vi inte kan göra en rollback bara). Därför definierar ITIL tre typer av förändringar.

 

  • Standard Change: Denna är känd och har en känd procedur, låg risk och är därför i förväg godkänd. Dvs teknikern behöver inte be om någon form av granskning eller godkännande för att kunna genomföra förändringen. Med fördel kan också dessa förändringar, som ju är återkommande i sin karaktär, scriptas så att de kan genomföras än snabbare och med bättre säkerhet.
  • Normal Change: Denna kan visserligen vara känd, det kan också vara känd teknik men omfattningen på risken med förändringen respektive arbetsinsatsen är av sådan karaktär att det är bra om någon annan än teknikern faktiskt slänger ett öga på förändringen och granskar att man tänkt igenom alla viktiga aspekter av förändringen (mer om detta nedan). Denna change brukar därmed gå igenom någon form av mer formell granskning innan den produktionssätts.
  • Emergency Change: Egentligen kan en emergency change vara vilken som av de ovanstående typerna men den har till skillnad från de övriga en tidsfrist som är extremt kort. Därmed kan vi tolerera en högre grad av flexibilitet kring dokumentation etc vilket kan göras i efterhand. Emergency change-ar skall endast vara triggade av större driftsstörningar eller identifierade större säkerhetshål. Inte som det ibland blir som ett sätt att försöka gå runt CAB:en. Och de ska självklart hållas till ett minimum, helst noll per år.

Change authority – eller CAB som det hette i ITIL v3

Idag har de allra flesta organisationer någon form av formell funktion för att granska och schemalägga förändringar till produktionsmiljön. Vissa har det till och med för utvecklings- och eller stage-miljö. Det är dock tveksamt om det är en rekommenderad väg att gå och ITIL säger egentligen ingenting särskilt om just detta. Vidare så i ITIL v3 rekommenderade man att skapa en definierad grupp som godkände förändringar kallad CAB (Change Advisory Board).

Vad är då en Change authority? ITILs definition av detta är ”the nominated authority with mandate to approve changes”. Det här kan låta lite högtravande och många organisationer har kanske fastnat på ordet Authority. För det första så behöver Change Authority:n på inget sätt vara med och godkänna varje förändring. Dels enligt change-typerna ovan och dels för att det helt enkelt inte är effektivt. För det andra så betyder definitionen heller inte att det bara finns en Change Authority (framöver kallar vi den för CA för enkelhetens skull) som ska kontrollera alla förändringar som görs. Tvärtom kan en organisation ha så många CA:s den själv vill. Slutligen så ska CA:n bestå av folk med kompetens att förstå problemställningen. Dvs det ska vara tekniker som kan bedöma den tekniska risken/förutsättningen och inte nödvändigtvis chefer som potentiellt inte har den nödvändiga insikten.

Ofta är det dock någon form av formell linjeauktoritet med i gruppen (CA:n) men det är inte något som ITIL specifikt förordar. Tvärtom så definierar ITIL 4 tydligt att ”peer reviewing” snarare är en toppmarkör på effektiv hantering snarare än större formella diskussionsforum. Speciellt i organisationer med ”high change velocity” som man återfinner i effektiva agila team.

Emergency change authority

Kopplat till CA brukar det också finnas någon form av Emergency-CA eller liknande. Som namnet ger vid handen så är det en funktion (en eller flera individer i organisationen) som vid behov av en akut förändring har mandat i organisationen att godkänna just denna. Dessa individer kan vara medlemmar av den vanliga CA:n eller ha en helt egen definierad roll (ibland kallas den ”Critical Situation Manager, Incident Manager, Shift captain eller liknande påhittiga namn).

Vi jobbar inte enligt vattenfalls-ITIL, vi är agila!?

Hur hänger den här processen ihop med agil utveckling och agila team? Intressant nog så är det i den agila cykeln väldigt tydligt definierat hur man samlar förändringsönskemål i en backlogg och sedan på ett möjligen informellt men ändå mycket strukturerat sätt beslutar om exakt vilka förändringar som man avser att göra inom ramen för en Sprint.

Detta är i praktiken att till fullo följa ITIL-processen om än med andra ord. (En change heter till exempel inte change utan user story eller något liknande). Ett product team meeting där Product owner tillika utvecklarna träffas för att gemensamt diskutera fram vilka prioriteringar man har för en given sprint är den agila motsvarigheten till ett CA-möte. Därmed finns det egentligen ingen konflikt mellan processerna, möjligen finns det dock en viss språkförbistring

Hur och varför ska man dokumentera en Change/Förändring?

Det finns egentligen inga exakta regler kring detta men ett par saker är bra att tänka på:

  • Vi vill gärna göra andra medvetna om vad vi jobbar med så att vi inte råkar introducera några onödiga krockar.
  • Någonstans måste det ändå finnas någon form av minimum av information som definierar hur miljön ser ut, alltså behöver vi skriva upp det någonstans någorlunda lättillgängligt.
  • Om vi inte gör det synligt vad vi arbetar med så blir det svårt att bedöma arbetsbelastning respektive förväntade leveranstider.
  • Om det uppstår bekymmer efter en produktionssättning så kan vi väsentligen korta ner felsökningstiden om vi på ett enkelt sätt kan se vad som nyligen har förändrats.
  • Keep it simple. På tok för många organisationer skapar på tok för komplexa lösningar kring change-process och dokumentation. Omöjliga workflows, oändliga mängder fält som ska fyllas i (och vars data aldrig följs upp) krångliga steg i processen med inbyggda väntetider som förlänger ledtider etc. Undvik allt detta som pesten.

Tips

Om din organisation har svårt att komma igång med eller följa processen för change management fundera då över hur du kan förenkla den. Genom att förenkla kraven på dokumentation, estimering, tidssättning etc så är det lättare att få acceptans för arbetssättet. Väljer ni sen att visualisera arbetet på en kanbantavla eller liknande blir det ganska enkelt att fråga den personen “var kommer vi att dokumentera denna förändring så att informationen blir lättillgänglig för de som behöver informationen”. Tillsammans kan ni då hitta bra, enkla och tillgängliga lösningar. 

Försök heller inte sälja in processen med motiveringen “vi kan inte lita på att ni tekniker inte ska introducera fel och brister i vår miljö, så därför gör vi det så omständligt som möjligt genom byråkratiska processer, tunga beslutsprocesser, omfattande dokumentation” etc. Börja hellre då att prata om hur vi ska kunna säkerställa att inte unika individer blir helt dränkta i för mycket arbete och hur vi genom bättre kontroll på change-processen kan förstå hur mycket jobb vi har att göra och har gjort.

Hur ser change-processen ut?

Det finns en del goda råd och tips att hämta från ITIL på hur en generisk changeprocess kan se ut. Det viktiga dock är att man börjar enkelt och över tid när behov infinner sig utökar. I korta drag kan man säga att processen består av följande 4 steg.

Det finns en del goda råd och tips att hämta från ITIL på hur en generisk changeprocess kan se ut. Det viktiga dock är att man börjar enkelt och över tid när behov infinner sig utökar. I korta drag kan man säga att processen består av följande 4 steg.

Observera att change-en börjar alltså redan när vi får ett behov om att ändra något. Den börjar inte när vi jobbat med det under någon månad eller så och nu önskar gå till produktion . Vidare så förordar den att vi ska kontrollera att det vi önskar ändra på kommer att fungera även efter förändringen. Det vanligaste är faktiskt att de komponenter vi ändrar på fungerar utmärkt även efter ändringen. Dessvärre finns det ofta andra komponenter som är beroende av den nyförändrade komponenten och som efter förändringen kanske inte riktigt fungerar som de ska. Detta är då en change-skapad incident.

Ingen change utan Rollback!

Varje förändring som vi implementerar i produktionsmiljön ska helst kunna återkallas om den visar sig skapa bekymmer. Detta kallas för Rollback. Livet skulle vara enkelt om vi kunde använda detta som en regel men det finns dock tillfällen då förändringen inte kan återkallas. Till exempel har vi skapat nya data som skulle försvinna, eller den komponent vi ändrat på går helt enkelt inte att återställa.

Detta betyder dock inte att rollbackplanering blir dispositiv. Istället så ska vi göra den rollbackplanering som går. Med hjälp av de verktyg som idag finns och används inom tex DevOps så brukar rollbacken till och med kunna vara helt eller delvis automatiserad. Till och med till den nivån att larmsystem som upptäcker fel efter förändring också automatiskt kan genomföra återkallande till senast kända fungerande konfiguration (vilket ju också är varför det är så viktigt att dokumentera och versionshantera allt).

Rollback skall alltså planeras för. Om det inte bedöms som möjligt så skall detta vara med i risk-kalkylen som görs innan produktionssättning. Man måste också definiera en ”point of no return”. Dvs hur länge kan vi befinna oss i den nya förändrade miljön och tryggt rulla tillbaka om något fel uppstår eller när har vi gått förbi denna osynliga gräns. Det kan handla om en definierad tidsrymd, datamängd eller annat som påverkar. Men se till att ha tänkt igenom dessa alternativ innan ni gör er förändring.

Change och Incidenter

Det är väl inte alla som vill erkänna att en förändring de gjort skapat bekymmer i produktionsmiljön efteråt, speciellt om man inte lever i en ”blame free culture”. Men den bistra sanningen är att de allra flesta incidenter som uppstår gör det på grund av att något har ändrats i miljön. Väldigt få saker slutar fungera av sig själva. Vidare så är det lätt hänt att olika change-ar krockar med varandra, speciellt i organisationer där den ena handen inte vet vad den andra gör. Det är alltså rimligt att tro att en change kan resultera i en incident. För att råda bot på detta och minimera risken så finns det ett par saker man kan göra:

  • Undvik stora förändringar, dela upp dem i många små. Detta är också helt i linje med hur vi jobbar inom agil systemutveckling. Om du lättare kan se arbetsenheter och hur arbetsflödet ser ut, kan du lättare hitta flaskhalsar och annat som hindrar er effektivitet.
  • Se till att ha koll på vilka förändringar som jobbas på så att du på ett enkelt sätt kan kommunicera det till resten av organisationen. Då kan du också undvika onödiga krockar. Genom att bara jobba med en sak i taget blir du mer effektiv. Läs mer om varför lite längre ned.
  • Testa ordentligt. Det ska också göras så tidigt som möjligt i processen, inte bara på slutet. Det kanske finns några steg i ert flöde som saknas? Eller några som egentligen är onödiga och borde tas bort?
  • Sköt din dokumentation över miljön så du vet vad du förändrar. När du väl fått flöden och visualisering på plats är det betydligt lättare att hitta små detaljer att finslipa på. Och nej, de kommer inte att ta slut. Det finns alltid något mer att slipa på.
  • Undvik så långt det är rimligt att göra manuella förändringar. Sedan länge jobbar vi med förändringar av klienter med stöd av distributions- och ”deploy-” verktyg. Samma ska gälla för servrar, nätverksutrustning etc. Gör vi fel med detta som metod så vet vi åtminstone alltid exakt vilket fel vi gjort.
  • Och slutligen, betrakta inte en incident skapad av en change som endast negativ. Det finns tvärtom väldigt många goda lärdomar vi kan göra från dessa tillfällen om vi bara tar oss tid att reflektera och lära oss. Man kan lära sig oerhört mycket så länge man inte är upptagen med att förklara varför man inte har fel.

Hur mäter vi changeprocessen?

Mätning, målstyrning och KPI:er är naturligtvis också ett viktigt område för Change Management. Vi tror att det här, precis som innan alla områden, är viktigt att man börjar i små steg och sedan i iterationer utvecklar lämpliga sätt att mäta och utvärdera changerpocessen. ITIL-publikationerna redovisar också flera olika nyckeltal som flera av dem är bra men kanske inte alla ska anammas från första början. Nedan listar vi vad vi tycker är några bra värden att utgå ifrån och sedan utveckla allteftersom:

 

  • Antal nya och levererade change-ar per period (för att se om vi håller tempot mot efterfrågan)
  • Change backlog (dock är detta i huvudsak relevant för en operationsfunktion)
  • Change fail rate (andel Change som inte fungerar enligt plan från början)
  • Change leadtime
  • Change workload / resource
  • Change WIP

Avslutningsvis

Det går inte att överskatta värdet av en väl fungerande changeprocess. Att hantera förändringar på ett säkert men snabb sätt är kritiskt i en värld där kraven på nya funktioner och tjänster hela tiden ökar. Vi återkommer dock alltid till att det är en process där vi bäst utvecklar den i många små iterationer. Vi tror också att det är bäst att detta görs av teknikerna som ska jobba i processen snarare än att ha en central processfunktion som skriver instruktioner till andra. Det tenderar oftast i att sluta med delvis accepterade processer, haltande införande och i värsta fall också en hel del missnöje internt i organisationen över krångliga verktyg, byråkratiska processer och chefer som övervakar vårt arbete.

Vill du analysera ditt change-flöde?

Hämta vår SIPOC-guide, så kan du enkelare strukturera och visualisera hur ditt change-flöde ser ut.

Share This