Nu när vi är agila, kan vi då glömma ITIL?

2020-09-15
Kan vi glömma ITIL nu när ”alla” är agila och arbetar i DevOps- och/eller SAFe-miljö? Det finns säkert en del som tror det, och det skapar frustration både hos de som använder och ansvarar för ITIL-processer och de som arbetar agilt, i t.ex. DevOps team. För det kan vi inte.
I den här bloggen reder vi ut begreppen och beskriver hur de olika ramverken / arbetssätten kan samverka för att tillsammans skapa en bättre och effektivare digital och IT-leverans med fokus på ökat kundvärde och att upprätthålla en stabil IT-miljö.
 
Effektiva, agila och snabba IT-leveranser
När företag ska leverera ett konstant ökat kundvärde är det inte bara time-to-market och kundvärde i IT-leveransen som är viktigt utan också kvaliteten under produktionssättningen av system och ny funktionalitet, samt att kunna hantera snabba åtgärder vid (allvarliga) störningar under drift.
 
Även om allt ska gå snabbt och vara enkelt får inte förändringar förorsaka allvarliga störningar för kunden. Inte heller angränsande system eller applikationer får påverkas negativt av produktionssättningar.
 
Det är alltså lika viktigt som tidigare att snabbt hantera störningar under daglig drift som att minimera fel vid produktionssättning – allt för att minimera kundpåverkan.
 
Produktionsstörningar
Produktionsstörningar kan uppstå dels under en produktionssättning av ny eller uppdaterad funktionalitet eller under daglig drift. I DevOps-världen kanaliseras information om driftstörningar till det DevOps-team som har ansvaret för tjänsten och därmed ansvaret att lösa de (tekniska) problem som förorsakar störningen.
 
Information om att en störning uppstått kan komma från kund via Service Desk till rätt team eller att teamet själva upptäcker störningen t.ex. genom ett övervakningslarm. Att på ett tidigt stadium upptäcka potentiella eller pågående störningar är viktigt för att minimera nertiden för tjänsten.
 
Behovet att kommunicera med kunden/användaren och med interna affärsansvariga finns alltid vid en allvarlig störning. Under arbetet med störningen har inte teamet möjlighet att ensamt hantera kommunikationen, utan förlitar sig på att Service Desk ansvarar för att kommunicera nödvändig kommunikation.
 
Oavsett om traditionella metoder används för att samla kompetens för att hantera störningar i produktionsmiljön snabbt, eller om Intelligent Swarming används, måste omkringliggande processer/rutiner finnas på plats som gör allt för att underlätta incidentlösningen och minimera lösningstiden. Då ingår även att kommunicera med kunder och med affärsansvariga.
 
ITIL adresserar processer och funktioner för en effektiv hantering av dessa områden.
 
Planering av förändringar i produktionsmiljön
För att säkerställa att en förändring inte förorsakar en störning i produktionsmiljön är det viktigt analysera och identifiera eventuella störningsrisker under produktionssättningen. Analysen tar bl.a. ta hjälp av information om olika relationer mellan hårdvara, mjukvara och nätverk och hur dessa kan påverka varandra. Information som beskrivs i en databas enligt ITIL.
 
För att säkerställa att tillräckliga insatser görs för att minimera tekniska risker och för att minimera eventuella affärsrisker godkänns produktionssättningen av dem som har den bästa kunskapen om tjänsten och tekniken. När godkännandet flyttas till det team som ansvarar för tjänsten minimeras ledtider inför och under en produktionssättning.
Allt enligt ITILs Change-process.
 
När förändringen är återkommande och har genomförts på samma godkända sätt ett flertal gånger utan att medföra störning, kan den sen genomföras utan att godkännas varje gång, och ledtiden för produktionssättnigen kan förkortas ytterligare.
 
Grundorsaken till störningen
När det gäller störningar / incidenter i produktionsmiljön, oavsett om de inträffar vid en produktionssättning eller om de inträffar under drift, är det viktigt att ta reda på grundorsaken till varför störningen inträffade. Ibland är det lätt att identifiera och åtgärda, ibland är det mer komplicerat. Ibland åtgärdar man grundorsaken, ibland inte. En anledning till att inte åtgärda kan vara att störningen snabbt kan hanteras när den inträffar igen och att det är en mer effektiv lösning än att åtgärda grundorsaken. För att säkerställa att alla medarbetare vet hur tidigare störningar åtgärdats, dokumenteras dessa på ett överenskommet sätt i ett gemensamt system. Allt enligt processen Problem i ITIL.
 
Agilt och ITIL i samverkan
Som exemplen ovan visar, är ITIL ett ramverk som kan användas för att införa effektiva arbetssätt i en IT-organisation och därmed också för DevOps-teamen i organisationen.
 
Snabba agila leveranser - Korta ledtider: Det finns ingen motsägelse mellan ITIL och korta ledtider för att stödja snabba leveranser. ITIL:s processansvariga måste samverka med den agila organisationen för att de skall förstå varandras arbetsrutiner. ITIL-processerna behöver anpassas till att stödja Agil/DevOps-arbetssätt men också omvänt. Agila/DevOps-team behöver förstå hur ITIL-ramverket ge stöd för att deras arbetssätt ska bli effektivare.
 
Produktionsstörningar – ITIL Incident Management: När allvarliga produktionsstörningar uppstår och både det egna och andra team måste engageras, behöver samtidigt intern kommunikation och kundkommunikation upprätthållas. Som stöd i incidentlösningen används ITIL:s process Incident Management, men teamen har också tillgång en CMDB som innehåller produktionsmiljöns relationer mellan HW, SW och nätverk. ITIL beskriver i Configuration management hur information i en CMDB ska hållas uppdaterad.
 
Planering av förändringar i produktionsmiljön – ITIL Change Management:
ITIL:s Change management upplevs ofta som en flaskhals när organisationen vill inför förändringar i allt snabbare takt. Det kan bero på att Change management-processen är införd på ett sätt bestämmer i detalj vilka forum som ska finnas för att granska och godkänna de enskilda förändringarna och när i tiden dessa forum bör / kan genomföras. Dessa beslutsforum är ofta managementtunga och styrs ofta av när management är tillgängliga – en gång per vecka eller en gång var 14e dag, vilken gör att förändringstakten blir långsam.
 
ITIL Change Management beskriver att en riskanalys ska genomföras inför varje förändring vilket minimerar risken för att förändringarna misslyckas och inte påverkar omkringliggande tjänster. Men också en Standard Change som kan användas för mindre och återkommande förändringar/”changar” och som alltid genomförs på samma sätt.
 
Genom att etablera distribuerade godkännande- och beslutsforum som drivs och genomförs av respektive DevOps team och genom att införa standardförändringar för mindre återkommande förändringar, kan tiden mellan varje produktionssättning förkortas avsevärt.
 
Grundorsaken till störningen – ITIL Problem Management: Problem Management beskriver strukturen för att göra en analys av grundorsaken till varför en allvarlig störning/Incident inträffat (Root Cause Analysis, RCA). Prioritering och genomförande av en RCA görs av teamet och Problem Management hjälper till att beskriva hur kunskapsdelning av RCA-innehållet kan hanteras.
 
Kontroll på relationer – ITIL Configuration Management / CMDB:
För att säkerställa en hög kvalitet i arbetet med att hantera fel och felåtgärder, slutgiltigt lösa Problem och säkerställa ändringar inom ramen för ITIL Incident-, Change-, och Problem Management, är en uppdaterad CMDB av högt värde. Incident-, Change och Problem Management har behov av att se relationerna mellan HW, SW och Nätverk i produktionsmiljön för att kunna effektivt lösa incidenter, analysera grundorsaker till incidenter och minimera störningsrisken på olika komponenter när en förändring /change ska genomföras.
 
ITIL och den Agila resan!
För att kunna integrera ITIL och agila arbetssätt måste ITIL:s processorganisation och den Agila/DevOps-organisationen ha en öppen och ständig dialog för att förstå behovet av både självständigt arbete i team och struktur och ordning och reda via processer. Genom samverkan och förståelse för verksamhetens behov kan de gemensamt erbjuda en snabbare IT-leverans och kundleverans med fokus på ökat kundvärde och samtidigt upprätthålla en stabil IT miljö.
 
 
Leif Carlström
 
Vill du få lite mer kött på benen inom området ITIL och Agilitet, kanske få lite mer praktiska tips,  så kan du delta på vår Kunskapsfrukost den 23 september eller anmäla dig ett lite längre GIG – ”ITILS PLATS I DEN AGILA RESAN” där allt också bli lite mer praktiskt och genomgripande.

Kommentera inlägget

(endast BiTA kan se din epostadress)
Här sker en kontroll av att det är en människa som skickar uppgifterna.

Tidigare blogginlägg