Change management-processen håller ihop hela överlämningsfasen, från att den aktuella funktionen tar beslutet att en förändring ska genomföras i processen kontinuerlig förbättring till att driftansvarig formellt tar över ansvaret för den genomförda förändringen.
En förändring definieras som:
”Ett tillägg, en förändring eller en borttagning av något som kan påverka leveransen av IT-tjänster eller tillhörande dokumentation.”
Syfte
Huvudsyftet med change management-processen är att säkerställa att förändringar registreras, utvärderas, prioriteras, planeras, testas, etableras och dokumenteras på ett kontrollerat sätt.
Det sker genom att i alla förändringar som genomförs:
- Säkerställa att all information om förändringen finns registrerad
- Bedöma om förändringen behöver genomgå tjänstedesign
- Använda beprövade och dokumenterade metoder och rutiner
- Utreda vilken påverkan förändringen har på IT-miljön
- Beakta risken för verksamheten
- Säkerställa att alla aktuella aspekter av förändringen har beaktats
- Koordinera driftsättningen med övriga förändringar
- Säkerställa att det finns en återställningsplan inför driftsättning
Omfattning
Varje IT-organisation måste själv besluta vilka förändringar som ska registreras i change management-processen. Det finns ingen standardnivå som fungerar för alla. Det fungerar heller inte att sätta en nivå för samtliga tjänster när till exempel ett byte av en reservdel i en PC inte behöver registreras i change-processen, medan samma reservdel i en central lagringslösning behöver kontrolleras mer noggrant eftersom den innebär en större risk.
Utöver change management-processen sker förändringar även i driftuppgifter och i request fulfilment-processen. Att tvinga IT-organisationen till att registrera dessa ärenden även i change management-processen är inte effektivt.
Eftersom både driftuppgifter och request fulfilment bygger på dokumenterade rutiner blir den praktiska lösningen att varje ny rutin registreras som en förändring i change management-processen där rutinen kvalitetsgranskas och godkänns som en standardändring. Därefter kan rutinen genomföras i respektive process utan dubbelregistrering av ärendet. Det viktiga är att alla förändringar registreras så att spårbarheten finns om något skulle gå fel.
Riskbedömning
Målet med change management-processen är att få så lite störningar som möjligt i verksamheten när förändringar genomförs. Tyvärr finns oftast inte resurser till att granska samtliga förändringar som genomförs, vilket innebär att IT-organisationen måste prioritera vilka förändringar som den ska kontrollera mer noggrant. Ett sätt att prioritera är att göra en riskbedömning av de förändringar som ska genomföras och på det sättet lägga resurser på de ändringsärenden som har störst risk att störa verksamheten.
Riskbedömningen görs genom att bedöma sannolikheten att något händer och konsekvensen om det händer. Sannolikhet och konsekvens bedöms var för sig som låg, medel eller hög enligt följande tabell.
Därefter kombineras dessa värden i en matris så att den totala risken kan sättas. I den kombinerade matrisen värderas konsekvens högre än sannolikhet vilket beror på att en hög konsekvens behöver hanteras även om sannolikheten att det inträffar är liten.
Den totala riskbedömningen används sedan till att avgöra typen av förändring, vilken nivå på godkännande som behövs samt vilka förebyggande åtgärder som krävs för att ändringen ska godkännas för driftsättning.
Låg – Kan godkännas av change manager. En förändring som genomförs ofta bör dokumenteras som rutin och godkännas som en standardändring.
Medel – Kan godkännas av change manager. Enklare återställningsplan på teknisk nivå ska finnas.
Hög – Måste godkännas av change advisory board (CAB). En detaljerad återställningsplan måste finnas.
Typer av ändring
Change management-processen fungerar som en kvalitetskontroll av förändringar som ska genomföras i IT-miljön. En noggrann granskning av varje förändring skulle ta mycket tid och resurser. Dessutom skulle det administrativt fördröja genomströmningen av förändringar så mycket att IT-organisationen inte skulle acceptera processen.
Därför delas förändringsärenden in i olika typer som bygger på vilken risk förändringen har att påverka IT-miljön negativt om något skulle gå fel.
Standardändring
En standardändring utförs ofta och är väl dokumenterad på instruktionsnivå, så att den utförs på samma sätt varje gång. Den är godkänd av change management-processen en gång och behöver således inte passera genom processen före etablering förutsatt att dokumentationen följs.
En standardändring kännetecknas av:
- Beprövade och dokumenterade arbetsrutiner
- Oftast förknippad med en låg kostnad
- Låg risk vid genomförandet
- Används för att genomföra beställningar i request fulfilment-processen
- Används för att utföra förändringsaktiviteter i driftuppgifter
När en rutin för en ny standardändring skrivs så ska rutinen skickas som en förändring genom change management-processen som ett normalärende för kvalitetsgranskning och godkännande.
Normal ändring
Ändringar av typen normal omfattar endast en tjänst eller en begränsad del av IT-miljön som till exempel en server eller en databas. Risken bedöms som liten eller medel och den genomförs av erfarna medarbetare med beprövade metoder.
Denna typ av ändring behöver inte bedömas av change advisory board (CAB) utan kan efter granskning godkänns för driftsättning av change manager.
Högriskändring
Ändringar som bedöms som hög risk eller som påverkar flera olika delar av IT-miljön behöver granskas mer noggrant innan driftsättning. Det kan även finnas ett behov av att flera olika delar av både IT-organisationen och verksamheten deltar i beslutet.
Dessa ändringsärenden hanteras av beslutsforumet CAB inför driftsättningen. Efter driftsättning och eventuell provdriftsperiod tas ärendet upp igen i CAB för att godkänna överlämningen av ansvaret från projektet till driften.
Akut ändring
Syftet med typen akut ändring är att snabbt kunna lösa en incident i IT-miljön där det krävs en förändring för att göra detta. Om förändringen kräver ett beslut från CAB, men incidentens negativa påverkan på verksamheten är så stor att det inte finns tid att invänta nästa planerade möte, sammankallas istället en emergency change advisory board (eCAB).
eCAB består av färre personer än CAB, dock minst följande:
- Change manager
- Påverkade kunder i verksamheten
- Berörd tjänsteägare
- Expert som kan redogöra för val och konsekvenser
För att detta ska fungera krävs det att akuta ändringar är kopplade till en specifik rutin som alla inom IT-organisationen känner till. En sådan rutin skulle kunna innehålla:
- Kort beskrivning av situationen dokumenteras och change manager tillkallas
- Telefonmöte med berörda parter för godkännande
- Information till berörda intressenter
- Genomförande av ändringen
- Verifiering av att allt gått bra
- Dokumentation av hela förloppet
- Stängning av ärendet
- Redovisning av hela ärendet på nästa CAB möte
Förändringsschema
Ett dokument eller en kalender som listar alla godkända förändringar och deras planerade driftsättningsdatum. Det är bra om även önskade driftsättningsdatum läggs in i schemat för kommande icke godkända driftsättningar så att alla kan se vad som finns planerat och samordna sina releaser. Med ett gemensamt förändringsschema kan change manager enkelt kommunicera dagar då det råder förändringsstopp genom att lägga in även dessa i schemat.
Beslut i processen
Det finns två nivåer av beslut i processen, en som avgör om en förändring ska genomföras, och en som godkänner kvaliteten inför driftsättning.
Eftersom mandatet för att fatta beslut om en förändring ska genomföras finns i olika forum och på olika nivåer i styrmodellen, används change control board (CCB) som generell benämning för dessa forum.
Change Control Board (CCB)
Change control board är en generell beteckning för de forum som har mandat att besluta om förslag till förändringar. Till exempel en funktion eller en projektstyrgrupp. Förändringsförslagen utreds, bedöms och prioriteras tillsammans med alla andra förslag till förbättringar i processen kontinuerlig förbättring. De förslag som beslutas att de ska genomföras hanteras vidare i change management-processen och drivs av respektive forum.
Change Advisory Board (CAB)
Change advisory board (CAB) är det forum som beslutar om en förändring har tillräcklig kvalitet för att driftsättas i IT-miljön. CAB drivs av change manager men består av olika deltagare beroende på vilka driftsättningsärenden som ska hanteras. Syftet med CAB är att samordna, planera och kvalitetsgranska större driftsättningar så att risken för störningar i verksamheten minimeras.
Ett exempel på bemanning av CAB är:
- Change manager (sammankallande)
- Representant för CCB (ärendeägare)
- Driftansvarig (mottagare)
- Ansvarig service desk (mottagare)
- Systemspecialist (expert på systemet)
- Tekniker (expert på infrastrukturen)
Varje representant för respektive CCB föredrar sina egna ärenden. Även om det på det aktuella mötet inte finns några ärenden för ett specifikt CCB så finns det en samordnande kvalitetskontroll i att samtliga CCB finns representerade på varje CAB iallafall.
Förändringar i IT-miljön är ofta en del av en förändring i verksamheten. Vid denna typ av förändringar har verksamheten en stark knytning till de beslut som tas i change management-processen. Alla beslut från design och finansiering till driftsättning och godkännande är egentligen verksamhetsbeslut i verksamhetens egen beslutsprocess. I dessa situationer sköts samordningen mellan förändringen inom IT-organisationen och förändringen inom verksamheten av CCB forumet.
Aktiviteter
Alla önskemål och förslag till förändringar måste prioriteras av respektive funktion tillsammans med allting annat som ska göras i processen kontinuerlig förbättring. Först efter att funktionen har beslutat att gå vidare med ett förändringsförslag så registreras ärendet som en request for change (RFC) i change management-processen.
Om förändringen är komplex, omfattar flera olika områden eller innebär en hög risk så ska ett designpaket utformas i processen tjänstedesign. Designpaketet omfattar alla aspekter på en förändring och säkerställer att förändringen verkligen uppnår sitt syfte samt att IT-organisationen kan leverera den tänkta funktionaliteten efter driftsättning.
Nästa steg är att godkänna designen. För stora och komplexa förändringsförslag är det först i detta steg som konsekvenserna är belysta och CCB har ett komplett beslutsunderlag. Är förändringen resultatet av en förändring i verksamheten ska beslutsunderlaget för godkännande lyftas till verksamhetens beslutsprocess.
Efter ett formellt godkännande av designen ska CCB koordinera utveckling och test av förändringen. Omfattningen på detta steg kan variera från några timmar till flera månader beroende på storleken på förändringen. Aktiviteterna utveckling och test sker i release management-processen. Här sker även en övergång från att betrakta förändringen som ett enda ärende till att hantera flera releasepaket. En större förändring delas oftast upp i flera releaser och i resterande del av change management-processen hanteras varje specifikt releasepaket som ett eget ärende. Det ursprungliga förändringsärendet ligger kvar under hela förändringen och knyter samman alla releaseärenden.
Den funktionella testen av ett releasepaket sker i release management-processen. När paketet kommer tillbaka till change management är det kvaliteten inför driftsättning som ska godkännas. Här är första gången som change advisory board (CAB) samlas för att granska ärendet. CAB ansvarar även för att koordinera driftsättningen på en övergripande nivå vilket sker genom att alla aktuella driftsättningar planeras in i det gemensamma förändringsschemat.
Driftsättningen sker i release management-processen som testar och säkerställer att funktionaliteten och kvaliteten i releasepaketet uppnåtts. Denna testperiod kan vara flera veckor vid större releaser. Efter driftsättningen tas ärendet åter upp i CAB forumet för godkännande av drift. Här sker det formella överlämnandet mellan projektet som utvecklat förändringen och driftansvarig.
När en förändring eller ett releasepaket är godkänt och överlämnat till drift utvärderar och stänger change manager alla förändringar som passerat processen med syftet att identifiera förbättringsförslag. Även genomförda standardförändringar utvärderas för att upptäcka om någon av dessa har resulterat i störningar.
I utvärderingen ställer change manager frågan om en störning som uppkommit beror på att dokumenterade rutiner inte har följts eller om rutinerna behöver förbättras. Vid större störningar eller problem som uppstått under ärendets gång ska en utredning göras för att analysera anledningen till att det hände och vad som kan göras för att det inte ska hända igen. Denna utredning brukar benämnas som post implementation review (PIR).
Värde för verksamheten
Förändringar i IT-miljön har ofta negativ påverkan på verksamheten med störningar i leveransen av tjänster. Change management-processen stödjer IT-organisationen att utföra förändringarna mer kontrollerat, vilket minimerar störningarna och skapar ett värde för verksamheten.
Processen skapar även ett tydligare gränssnitt mellan verksamhetens beslutsprocess och förändringar i IT-miljön vilket bidrar till att verksamheten kan få bättre beslutsunderlag för sina egna förändringar och därmed skapa en mer komplett konsekvensbild av tänkta verksamhetsförändringar.
Dokumentation
Följande dokumentation ska finnas inom ramen för change management:
- Rutiner för RFC
- Designkriterier
- Mall för business case
- Rutiner för CAB möte
- Checklista för godkännande av driftsättning
- Mall för standardändring
- Förändringsschema
Relationer till övriga processer och funktioner
Change management-processen har kopplingar till många andra processer. Här listas de vanligaste:
Trigger
Change management-processen triggas genom att:
- En funktion eller annat beslutande forum tar beslutet att gå vidare med ett förbättringsförslag som omfattar en förändring av IT-miljön
- En incident kräver en förändring i IT-miljön för att kunna lösas
- En driftuppgift omfattar en förändring i IT-miljön
- En beställning omfattar en förändring i IT-miljön
Input
Följande Input behövs för processen:
- Komplett dokumentation över tjänster, system och produkter samt deras beroenden
- Tydlig styrmodell för beslut
- Beskrivning av förändringen (RFC)
- Förändringsschema
Output
Följande output genereras av processen:
- Genomförda förändringar i IT-miljön
- Rapporter och statistik
- Utvärderingar av misslyckade förändringar
- Förbättringsförslag
Mätning
Så här kan Change management-processen mätas:
- Antal
- Öppna ärenden
- Genomförda driftsättningar
- Nekade driftsättningar
- Akuta förändringar
- Driftsättningar som stör verksamheten vid genomförandet
- Driftsättningar som tvingas använda återställningsplanen
- Driftsättningar som genererar oväntade bieffekter (Incidenter)
- Genomsnittstid för ett ändringsärende från aktiviteten godkänna driftsättning till aktiviteten
Utmaningar
Change management-processen är en komplex process som skär genom hela IT-organisationen och även interagerar med verksamheten. Dessutom sker hantering av förändringar i angränsande processer som till exempel i verksamheten, inom applikationsutveckling och hos leverantörer.
Den största utmaningen är att inte blanda ihop dessa olika förändringsprocesser utan att istället lägga kraften på att hitta gränssnitten mellan dem. Detta kräver ett öppet sinne hos alla inblandade parter och en förståelse för att modeller behöver anpassas efter verkligheten för att fungera.
Dessutom behöver följande moment särskild uppmärksamhet vid införande av processen:
- Utbilda och informera om syftet med processen så att IT-organisationen ser den övergripande effektivitetsvinsten med färre störningar istället för att reagera på den extra administration som tillkommer per förändring
- Säkerställa att alla ändringar registreras. Från start är det absolut viktigaste att få in alla förändringar som ärenden i processen. Att kvalitetsgranska varje ärende gör att processen blir administrativ och trög vilket kan leda till att den inte används
Säkerställa engagemanget hos chefer och ansvariga i verksamheten. Utan ständiga påminnelser och uppföljning är det lättare att inte använda processen
