En klassisk förändringsprocess kan vara långlindad och osmidig. Kan du göra processen enklare? I det här inlägget diskuterar vi förändringshantering och ett mer agilt tillvägagångssätt. Fungerar det? När fungerar det? Vad fungerar och vad fungerar inte?

Passar ett agilt tillvägagångssätt för standardiserade eller icke-standardiserade förändringar?

Agila tillvägagångssätt tenderar att passa bättre för icke-standardiserade förändringar. Tanken är att det hjälper dig med arbete som är oförutsägbart, medan standardförändringar vanligtvis är utformade för att vara så förutsägbara som möjligt. En bärbar dator som du supporterar är ett bra exempel: du tar en bärbar dator från ditt lager, installerar det operativsystem du behöver, plus standardprogrammen och levererar den bärbara datorn. Alltså inga överraskningar.

Men i icke-standardiserade förändringar kan ett agilt tillvägagångssätt göra stor skillnad.

 

Vad är problemet med det traditionella ITIL-tillvägagångssättet?

Förändringshantering i ITIL infördes för att reglera behandlingen av förändringar i din IT-infrastruktur. Det hjälper dig att förhindra att hela nätverket går ner när du ersätter en server. Det ingår helt enkelt många kontroller och överväganden.

Alla dessa kontroller är mycket användbara, men de har gjort processen för icke-standardiserade förändringar otroligt komplex. Och en komplex process har många nackdelar:

  • Att skicka en förändringsförfrågan (RfC) är mycket arbete. Du måste tänka på tekniska lösningar, utföra konsekvensanalys, uppskatta risker och förutsäga kostnader. Och du är inte ens säker på att förändringen någonsin kommer att utföras. Eller om din information fortfarande är korrekt när ändringen är genomförd.
  • Change Advisory Board (CAB) spenderar mycket tid på att godkänna RfCs. I vissa organisationer diskuterar CAB varje förändring, stor eller liten, brådskande eller inte brådskande. Detta kan innebära att 6 till 8 CAB-medlemmar spenderar tid på att prata om en relativt enkel förfrågan.
  • Förändringsprocessen är som en enkelriktad gata. Innan du skickar in en begäran om förändring måste du planera allt. Efter godkännande är det enda som kvarstår att genomföra den förinställda planen. Tillkommer ny information? Då är det inte så lätt att anpassa sig längs vägen.
  • Förändringsprocessen tar längre tid än det borde behöva. Alla ovan nämnda kontrollmekanismer saktar ner förändringsprocessen. Kanske har du allt klart för att börja implementera en förändring, men du inser plötsligt att “vi skulle fortfarande få CAB att kontrollera de senaste ändringarna, men de kommer inte att träffas förrän nästa onsdag”.

 

Förändringsförfrågningar utan onödiga uppgifter

Nu säger jag inte att processer och kontroller är onödiga. Tvärtom: Jag rekommenderar ofta att organisationer arbetar med RfC-blanketter. Att ha någon form av konsekvensanalys förhindrar stora problem med genomförandet.

Men behöver du ett RfC-formulär varje gång? Jag tror inte det. Hitta rätt balans mellan minimering av risker och förtroende för din IT-avdelning för att göra rätt val i sitt arbete. Ett smidigt förhållningssätt till förändringshantering kan hjälpa dig att hitta den balansen.

Change managern: Produktägare av backloggen för förändringar

Change manager-rollen och CAB-medlemmarnas roller kommer att förändras mest. Traditionellt är en Change manager framförallt ansvarig över processer. Om ni börjar arbeta mer agilt får en Change manager ett mer socialt jobb som är mer fokuserat på de viktigaste delarna i ett projekt.

Det här är uppgifterna för en agil Change manager:

  • Du samlar in och prioriterar dina intressenters önskemål. Sätter RFCs som förändringsförfrågningar på backloggen för förändringar. En backlog är helt enkelt en prioriterad lista över arbete som behöver göras. Om du vill kunna göra en bra prioritering måste du vara medveten om vad som händer i din organisation. Du undersöker de olika RfC:erna och jämför fördelar och problem. Använd den här jämförelsen för att prioritera och granska din prioritering regelbundet, till exempel varannan vecka.
  • Du kontrollerar att RfC-beskrivningarna är tydliga. Du behöver inte en fullständig blankett för varje RfC. Se bara till att du har all information du behöver för att kunna prioritera. Till exempel: Vilka problem ska RfC:n lösa? Vilka möjliga lösningar finns? Vad är den uppskattade omfattningen av förfrågningen? Du behöver inte fylla i alla detaljer, så som en komplett lösning, implementationsplan och budget, direkt.
  • Du ser till att de 5 viktigaste RfC:erna har mer detaljerade beskrivningar. Håll dig till den här tumregeln: ju lägre ned en RFC ligger i backloggen, desto färre detaljer behöver det finnas i förfrågningen. Lämna bara en detaljerad sammanfattning över förfrågningar som du kommer att arbeta med snart. Och du ber endast om ett CAB-godkännande för dessa prioriterade förfrågningar.

CAB: från tekniska detaljer till strategisk nivå

Om Change managern spenderar mer tid på att samla in och prioritera förändringsförfrågningar uppstår frågan: vad kommer CAB:ens roll att vara? De spelar fortfarande en viktig roll i processen, men det är på en mer strategisk nivå. Det här är CAB:ens nya uppgifter:

  • Godkänna de viktigaste RfC:erna. Dessa uppgifter är i stort sett desamma: CAB:en bestämmer om ansökningarna är klara och de kan avvisa vissa RfCs. Huvudskillnaden är att CAB:en endast tittar på RfC:erna som ligger nära toppen av prioriteringslistan, så det sparar mycket tid.
  • Godkänna prioriteringen av backloggen. Change managern har redan prioriterat alla RfCs, så CAB:ens jobb är att se om de överensstämmer med prioriteringarna i backloggen. Om Change managern gör det bra kommer det vanligtvis inte att kräva många justeringar.
  • Ge godkännanden eller avslag vid svängmoment. Under traditionella implementeringar ger CAB:en ett godkännande före go-live, exempelvis under testning. Vid en agil förändringshantering släpps den nya tjänsten vanligtvis bit för bit, och inte i en stor release där hela tjänsten släpps på en gång. Så, när ger CAB:en sitt godkännande? Svaret på den frågan är olika för varje genomförande. IT-teamet och CAB bestämmer i förväg vid vilka stadier av implementationen då CAB:en ska vara involverade.
Bas Blanken, Service Management Consultant & Agile expert