Det är två vitt skilda saker att läsa om hur man implementerar Change enligt ITIL och en annan att verkligen utföra det. Man måste vara medveten om vilka hinder som ligger framför en. Sådant går inte att läsa om i en bok. Därför säger vi att man måste se praktisk på en Change-implementation.
I varje organisation har man hinder i form av frågor som, ”varför behöver vi Change när allt fungerar?” Change är aldrig enkelt. Det finns också beroendeställningar och riskfaktorer att ta hänsyn till som kan ge oönskade resultat. Förutom allt detta, har olika organisationer olika problem beroende på dess storlek.
I en liten organisation kan alla beslut om och hanteringen av Change ligga hos en enda person. I större organisationer ska det finnas regler för vem som får bestämma vad när det gäller Change. Samtidigt kan det också finnas informella hierarkier och personbundna problem man kan behöva ta hänsyn till. Det har stor betydelse i en organisation från vem initiativet till en ny Change-process kommer.
Dessa tre frågor skall du ställa dig innan du inför Change:
- Varför skall vi börja jobba med Change?
- Vad skall ingå i Change-processen?
- Vilka effekter och konsekvenser kan införandet ge?
checklista med sex steg, för att du ska undvika många av de problem som kan uppstå.
1 Ta fram en Change policy
Det kanske viktigaste steget är att ta fram en Change policy som sätter upp regler för Change, vem som får ta beslut och vem som ska implementera. Det här är enkelt i en liten organisation, men viktigare och svårare i en stor. Att se till att det finns en Change Manager för varje process och varje applikation är lika viktigt som att ge dem det fulla ansvaret under processen.
Det är också viktigt att i policyn bestämma vem som ska hantera det motstånd som ofrånkomligen uppstår när man inför en ny process och se till att policyn ger det stöd som behövs. Implementera också en policy som säkerställer balansen mellan kostnad, flexibilitet och riskfaktorer.
2 Få med sig alla berörda parter
Nästa steg är att ”sälja in” Change. Identifiera ”vad ger det här mig” och förklara vad Change kommer att ge var och en av de berörda parterna. När du säljer in idén om förändring, se till att fokusera på ”varför” istället för ”vad”. Mer om det i vår artikel om att få med sig kollegorna i förändringsledningen.
3 Definiera Change
Det är inte helt givet att alla har samma uppfattning om vad Change innebär. Man kan till exempel ha olika uppfattning om dess omfattning, effekt och grad av angelägenhet. Därför är det viktigt att hela tiden falla tillbaka på Change-policyn. ITIL rekommenderar också att man definierar en Change-modell som delar upp Change utifrån dess omfattning, effekt och grad av angelägenhet. Gör man den uppdelningen går det både att minska resursanvändningen, minska tidsåtgången och få en bättre riskbalansering. Om man inte gör uppdelningen riskerar man att all Change måste gå igenom hela processen som kan knyta upp personer i onödan samtidigt som viktigare uppgifter blir liggande.
Change Management kräver en disciplinerad inställning till kontroll som ska vara förstärkt av den antagna Change-policyn och med uppbackning av ledningen. Change Management-gruppen behöver vara beslutsför för att kunna genomföra processen i hela organisationen.
4 Tilldela roller och ansvarsområden
I organisationens Change-policy ska rollerna tydligt framgå. Att vara Change Manager är sällan särskilt populärt, i alla fall inte i början av processen, vilket gör att man behöver hitta rätt person för uppdraget. Det är viktigt att de kan lyssna och vara lösningsfokuserade för att undvika
konflikter. Man måste bestämma vem som behöver besluta om vad. Att en CIO ska behöva besluta om lösenord är inte effektivt. Därför ska det finnas ett antal standard Change där man bestämt vem som kan ta beslut.
Till sist behövs en CAB, Change Advisory Board, som fungerar som styrgrupp där flera typer av kompetenser och intressenter inom organisationen samlas för att reda ut effekter och följa upp pågående arbeten. I de fall där man behöver göra akuta insatser behövs också en ECAB, Emergency Change Advisory Board, som kan rycka ut snabbt om det behövs.
5 Följ de sex stegen i ITIL med rätt verktyg
I ITIL förespråkas att man följer de sex stegen i ITIL för att skapa en strukturerad Change-process; record, assess, authorize, coordinate implementation, evaluate, close. Change Management processen kommer aldrig att fungera till hundra procent första gången, men det är bättre att ha en process än ingen alls. Genom att följa ITIL kommer processen att ständigt förbättras.
För att följa, dokumentera och framför allt utvärdera processen, behövs bra verktyg. På detta sätt kan man också följa vilka värden som adderats av Change-processen. Det är också av yttersta vikt att kommunicera Change-processerna för att öka förståelsen och minska antalet oauktoriserade Change.
6 Definiera KPI
Change Management är en av de svåraste delarna it service management processerna att implementera, men också en av de mest värdefulla och den är kritisk för att uppnå ökad IT-mognad. För att behålla styrfarten är det viktigt att ta fram och definiera KPI, Key Performance Indicators, som visar på den övergripande nyttan. Ta fram en KPI som är relevant för din organisation och använd den för att visa på värdet av Change-processen.
Mer om Change Management kan du läsa i vårt whitepaper Change Management i praktiken.
Du är välkommen att kontakta oss om du vill bolla idéer om Change Management, ITSM-processer eller helpdeskfrågor i allmänhet.
Change Management i ServiceDesk Plus
Med Change Management-modulen i vår helpdesklösning ServiceDesk Plus uppnår du strukturerad och snabb hantering av alla förändringar i din IT-infrastruktur. I modulen ingår bland annat kategorisering av ändringar, konfiguration av Change Avisory Boards (CAB) och automatisering av arbetsflöden.
ServiceDesk Plus från ManageEngine är en helpdesklösning för alla typer av organisationer. Med avancerade ITSM-funktioner i kombination med användarvänlighet hjälper ServiceDesk Plus supportteam att leverera service i världsklass med minskade kostnader. Finns både för lokal installation (on-premises), Azure och som molntjänst.
