ITIL v5 – Vad är nytt och vad spelar faktiskt roll?

I februari 2026 lanserades ITIL v5. Precis som tidigare uppdateringar bygger den vidare på tidigare versioner snarare än att ersätta dem helt. ITIL v5 är därför främst en evolution av ITIL 4, snarare än ett helt nytt ramverk.

Enligt Peoplecert (organisationen som numera äger ITIL) består ITIL v5 ungefär av:

• 40% oförändrat material från ITIL 4
• 24% vidareutvecklat innehåll
• 36% helt nytt innehåll

Det innebär att mycket av det som introducerades i ITIL 4 fortfarande är relevant, samtidigt som vissa områden har utvecklats för att bättre passa dagens organisationer.

Precis som tidigare versioner handlar det därför mindre om att börja om och mer om att förstå vad som faktiskt har förändrats.

Vad är nytt i ITIL v5

Som konstaterat ovan är mycket stora delar oförändrat eller lika. Detta gäller framför allt inom det man kallar Practices. Vilket i mångt och mycket är där det praktiska arbetet utförs. Grundprocesser och strukturer såsom Incident, Change etc är mer eller mindre oförändrade om än med en del mindre kosmetiska förändringar och en tydligare koppling mot produkt- och tjänsteleverans med stöd av AI.

Områden som däremto har en tydlig förändring är:

• Produkt- och tjänsteperspektiv
• AI-anpassat ramverk (för hela organisationen dvs både inom IT såväl som verksamheten)
• Tydligare mer utvecklad livscykelmodell
• Förenklad och förtydligad terminologi

1. Digital product and Service management

ITIL v5 går från ett renodlat service-perspektiv till ett kombinerat digitalt produkt- och tjänsteperspektiv.

Detta speglar hur många organisationer arbetar idag, där:

• IT levererar digitala produkter
• Digitala tjänster består av digitala produkter
• Tjänster innehåller funktioner och kan paketeras i olika typer av erbjudanden

ITIL v5 försöker därför förena:

• Produktstyrning
• Service management
• Leverans

Detta är en av de större förändringarna i ramverket. Och det tar kanske också udden av den inte helt produktiva men ganska vanligt förekommande diskussionen om det finns en konflikt mellan ”product-” (läs agilt/lättrörligt) och ”service-” (läs stabil leverans)perspektiven. I praktiken vad ITIL v5 gör är en distinktion mellan om det är en digital produkt under ett utvecklingsskede (som visserligen kan löpa länge) där ett visst mått av utforskande är nödvändigt. Jämfört med när en leverans övergår till ett mer stabilt ”tjänsteläge”. Framför allt blir detta tydligt när man också utvecklar och förtydligar kring hur ansvarsfördelning ser ut mellan ”provider” och ”consumer/customer” i den nya utvecklade livscykeln. 

Här tillhandahåller ITIL v5 ett ganska lättfattligt strukturperspektiv som möjliggör för organisationer att bygga rätt förmågor för rätt typ av leverans.   

ITIL Guiding principles

2. AI-anpassat ramverk

ITIL v5 beskrivs som AI-native vilket innebär att:

• AI ses som en naturlig del av ”digital product and service management”
• AI- governance introduceras och ges grundläggande struktur
• Automatisering och intelligenta arbetsflöden får större fokus. 

Allt detta är ganska nytt då det i ITIL v4 främst nämndes indirekt. Praktiskt det man omfamnar med AI-anpassningen är flera olika delar. Dels ger man format och struktur åt hur AI bör styras på övergripande nivå genom governance-riktlinjer. Dels pekar man ut specifika praktiska tillämpningar av AI för att utveckla och förbättra den interna produkt- och tjänsteleveransen. Och slutligen så skapar man en förlängning av den sista av de 7 guidande principerna om ”Optimize and Automate” som introducerades redan 2016. 

Eftersom AI är ett så omfattande område har man också utvecklat ett helt eget utbildningsspår inom AI governance. Utöver att man integrerat AI inom egentligen alla andra delar av materail, koncpet och kurser. 

3. Digital Product and Service Lifecycle  

En av de tydligare förändringarna i ITIL v5 är introduktionen av ett mer uttalat Digital Product and Service Lifecycle-perspektiv.

ITIL har tidigare rört sig mellan olika livscykelperspektiv:

• ITIL v3 — tydlig tjänstelivscykel 
• ITIL 4 — mindre fokus på livscykel, mer på värdeflöde
• ITIL v5 — återintroducerar livscykel, men i en moderniserad form

Skillnaden i ITIL v5 är att livscykeln inte längre enbart handlar om tjänster utan om digitala produkter och tjänster tillsammans. Och där det tydligatt framgår vad som är en produkt respektive tjänst är var den befinner sig i just livscykeln. Precis som jag nämner ovan skapar också den nya utvecklade livscykeln en tydligare bild över ansvar, gränsdragningar och samverkansstrukturer mellan ”provider” och ”consumer/customer”. 

Vidare är det centralt att man inte heller uppfattar livscykeln som strikt sekventiell. Utan snarare är det ett antal sammanhängande aktiviteter eller stadier som man kan röra sig mellan beroende på situation. Kortfattat beskriver man här hur varje organisation kan ha olika typer av värdekedjor som rör sig mellan dessa olika staider på ett för organisationen specifikt och unikt sätt. 

Livscyklen i ITIL v5 består av följande 8 stadier.

• Discover – Identifiera behov och linjera med strategi
• Design – forma lösning och värdeflöden
• Acquire – anskaffa och tilldela resurser (interna och/eller externa där resurser kan vara människor, partners, färdiga COTS-system etc.)
• Build – utveckling, konstruktion och konfiguration av digitala och analoga komponenter
• Transition –  förflyttning från utveckling till produktion 
• Operate – övervaka digitala produkter, system och tjänster för optimal prestanda
• Deliver – hantera användare, on- och offboarding samt upprätta hålla tjänsteleverans i enlighet med SLA
• Support – hantera störningar, avbrott och större ”contingencies”

Detta speglar hur många organisationer arbetar idag. Samt skapar ett tydligare ramverk att förhålla sig till när man har en ”blandad leverans” mellan egenutvecklat, konfigurerade standarsystem, komplexa integrationer såväl som rena SAAS-tjänster. 

Förändrat och oförändrat

Flera delar finns kvar men har utvecklats:

• Guiding principles (förtydligade)
• Value chain (tydligare koppling till leverans)
• Practices (mer praktisk vägledning)
• Governance (tydligare koppling till transformation)

ITIL v5 försöker generellt vara mer:

• Praktiskt
• Mindre abstrakt
• Mer tillämpningsbart

Vad är oförändrat eller i princip samma?

Det är också viktigt att notera vad som inte har förändrats. Kärnan från ITIL v4 finns kvar:

• Fokus på värdeskapande
• Helhetsperspektiv
• Flexibilitet
• Anpassning till organisation

Det innebär att organisationer som redan använder ITIL 4 i praktiken ofta inte behöver göra några större förändringar. ITIL v5 handlar snarare om att utveckla arbetssätt än att ersätta dem. Använder man t.ex. typiska basprocesser frånITIL såsom Incident, Problem, Change Management (numera enablement) så kan man alltså i lugn och ro fortsätta med det. 

Vad spelar faktiskt roll

Om man bortser från begrepp och modeller finns några saker som sannolikt är mest relevanta:

• Tydligare koppling mellan produkt och tjänst
• Större fokus på värdeflöden
• AI som naturlig del av leverans
• Mer praktisk vägledning

Samtidigt är det viktigt att konstatera att ITIL v5 inte förändrar grundidén med ITIL. Kundfokuserat värdeskapande med kontinuerlig anpassning och förbättring utifrån ett helhetsperspektiv. 

Sammanfattning

ITIL v5 är en evolution av ITIL 4.

• 40% oförändrat
• 24% vidareutvecklat
• 36% nytt

Det nya handlar framförallt om:

• Produkt- och tjänsteperspektiv
• AI-anpassning
• Tydligare värdeflöden
• Mer praktisk tillämpning

För organisationer som redan arbetar enligt ITIL 4 innebär ITIL v5 därför oftast inte en omstart  utan snarare en vidareutveckling.

Nota bene. I samband med att uppdateringen levereras har också ett anpassat utbud av kurser och vidareutveckling tagits fram. För den som vill förkovra sig hänvisar vi i första hand till den officiella sidan. 

Utgångsläget

Vår restaurangkedjekund, verksam inom Norden och norra Europa, befinner sig i en expansiv fas och behövde hjälp med att accelerera sitt förändringsarbete. Verksamheten ställer krav på ökad snabbhet och tillväxt.

Kunden hade under ett par år arbetat aktivt med att utveckla och stärka samarbetet mellan verksamhet och IT. Målsättningen var  bl.a. kortare ledtid från idé till att kundvärde uppstår. Hypotesen var att förutsättningar till  ett bättre samarbete och ett mer lättrörligt arbete skulle öka vid ett mer produktorienterat tankesätt.

Förändringsarbetet som hade drivits internt hade fokuserat på att dela in IT-organisationen i domäner/värdeströmmar, skapa ett PMO med portföljprocesser samt etablera en ny Operating Model.

För att accelerera det fortsatta förändringsarbetet önskade kunden stöd. Primärt inom områdena leveransflöden, prioriteringsprinciper, kundsamarbete och kapacitetsplanering.

Uppdraget

I en kombination av workshops och konsultinsatser arbetade Onbird med IT-organisationen under november 2024 – juni 2025. Först gjordes en nulägesanalys som diskuterades och förfinades med ledningsgruppen. Utifrån nuläge och önskad målbild, i samarbete med kund, upprättades en plan framåt med konkreta åtgärder för hela IT-organisationen såväl som samarbetet med verksamheten.

Gemensam kadens

IT-organisationen och verksamheten har starka beroenden till varandra och behöver vara synkade i en gemensam kadens för sin utveckling. Samt ha  förutsägbarhet kring leveranser. Onbird hjälpte till att etablera relevanta rutiner och ceremonier för att skapa arenan för att identifiera och få kontroll på kundens IT-leveransflöden. Både interna flöden likväl de som inkluderar externa leverantörer.

 Iterationsmodell

Som stöd till arbeta i en gemensam kadens togs en iterationsmodell fram anpassad till kunden. Iterationsmodellen förankrades, beslutades och etablerades inom IT-organisationen samt med nyckelpersoner inom verksamheten. Detta arbete gjordes m.h.a. workshops och individuell coachning.

Visualisering

Onbird stöttade i arbetet kring att visualisera allt arbete. Projekt som daglig drift och utveckling. Planerat som oplanerat, i ett gemensamt verktyg. Genom att synliggöra allt arbete ökade förutsättningarna till att bl.a. identifiera flaskhalsar, hantera beroenden, göra gemensamma prioriteringar, mäta leveranser m.m.

Uppföljning och mätetal

Onbird tog fram mätetal för att möjliggöra uppföljning av leveranser samt identifiera organisationens leveranskapacitet. Dessa mätetal implementerades sedan av kund för att driva det fortsatta förbättringsarbetet.

Utbildning, workshops och gemensamma utvecklingsinsatser

IT-organisationen utbildades i flöden och agila metoder för att skapa en gemensam förståelse och diskussion kring lämpliga förändringar. Teorin omvandlades till praktik vid förankring av den iterationsmodell som tagits fram för kundens behov. Mellan workshop och iterationsstart fick grupperna möjlighet, och stöttning i, att genomföra de förändringar i struktur och arbetssätt som identifierats. Planering av hur och när förändringar skulle ske gjordes i dialog med respektive gruppering, vilket resulterade i välmotiverade och anpassade insatser.

Resultat

Utifrån den plan som sattes upp för att nå de uppsatta målen kan vi bl.a. se följande resultat:

• En tydlig och gemensam månadskadens för IT-organisationen samt dess nyckelpersoner i verksamheten. Genom att ha samma takt och samma struktur för sitt arbete blir samarbete och förutsägbarhet bättre.
• En tydligt förbättrad kommunikation, dialog och förväntansbild inom IT-organisationen, både inom grupperingar och mellan grupperingar.
• Ökad transparens kring arbetet, både inom IT-organisationen såväl som för verksamheten/affären. Alla kan se status och vad som pågår.
• Etablerade forum med verksamheten för en tydligare dialog kring planerat arbete, förväntningar, prioriteringar och leveransstatus.
• Skifte i fokus till vad som ska levereras när, inte vad man som organisation är upptagen att arbeta med. Det ökar förutsägbarheten av leveranser.
• Tydliga gemensamma principer för prioritering av arbete. IT och verksamhet behöver prioritera tillsammans för att nå gemensamma mål.
• Framtagande av gemensamma definitioner på leveransenheter för att möjliggöra mätning och uppföljning av bl.a. ledtider.
• Skapat förutsättningar för nyckeltal att mäta bl.a. leveranskapacitet och ledtider.
• Diskussioner om vikten av reflektion och förbättring. Alla grupperingar har genomfört retrospektiv. Att ge grupperingar inom organisationen utrymme och ansvar för sin egen förbättring, både i arbete och i arbetssätt, leder till att diskussion förs och att man har börjat utkräva ansvar från varandra.

Mer info/Kontakt

Vill du veta mer om vårt uppdrag? Kontakta Onbirds Torbjörn Dahlström som fungerade som uppdragsansvarig för vårt arbete med restaurangkedjan!

Uppdraget

Skapa inspiration, samsyn och ökad kompetens kring fortsatt arbete med optimerad leverans.

-Undersöka hur organisationen och processer är optimerade för bästa möjliga värdeflöde.
–Säkerställa att alla medarbetare på Idnet har verktyg för att förstå hur Idnets flöden ser ut genom att:

• Kartlägga vart i flödet flyter det på och var stannar det upp?  
• Vilka är flaskhalsarna ”de svagaste länkarna i kedjan”?
• Vart förekommer det svinn/waste i flödet?
• Hitta sätt att eliminera slaskhalsar och svinn.

Övningar

För att realisera teorin och på ett lekfullt sätt och coacha deltagarna till att på egen hand kunna upptäcka och vända ineffektivitet till effektivitet genomfördes ett antal övningar.

Värdeströmsövning Cykelbutik
Deltagarna lär sig att mappa ut värdeflöde genom ett case

Vi följer en webbshopbeställning av en cykel till upphämtning i fysisk butik. Övningen ger deltagarna handfasta verktyg att tillämpa i vardagen för att mappa ut, förstå och optimera värdeflöden. Fokus på mätbar förbättring och skillnad mellan värdeadderande respektive icke-värdadderande arbete som kan elimineras.  

Mer info/Kontakt

Du kan läsa mer om Idnet här

Vill du veta mer om vårt uppdrag? Kontakta Onbirds Torbjörn Dahlström som fungerade som uppdragsansvarig för vårt arbete med Idnet!

Leverantörsstyrning: 3 vanliga misstag och hur du undviker dem

IT-organisationer idag är helt beroende av sina leverantörer för att skapa värde i verksamheten. Inte minst i form av leveranser som behöver gå sömlöst över ibland flera olika leverantörer för att värde ska uppstå. Trots att leverantörer spelar en strategisk roll, betraktas ofta samarbetet mer som en transaktion än som en långsiktig relation. Leverentörer skall styras snarare än integreras. Ofta beror detta på invanda tankemönster och dolda dogmer som styr vår relation till leverantörer. Tankemöster som leder till frustration och ineffektivitet. Både hos köpande IT-organisationer såväl som hos deras leverantörer. 

Omfattningen

Hur stor är då omfattningen av leverantörsberoendet? Om vi bortser från de situationer där den interna IT-organisationen egentligen bara är en beställningsorganisation och i princip allt reellt tekniskt arbete utförs av leverantörer vilket är en helt egen problemställning. Så är det ändå svårt att sätta en exakt summa.

Siffror visar dock att en betydande del av IT-budgetarna i Sverige går till leverantörer. Under 2022 uppgick den offentliga sektorns IT-utgifter (dvs till leverantörer) i Sverige till nästan 32 miljarder kronor, enligt en rapport från Upphandling24. I den privata sektorn uppskattades Sveriges totala IT-investeringar (dvs interna och externa kostnader) till 382 miljarder kronor år 2021, enligt Radar Ecosystem Specialists (vilket inkluderar både traditionell IT och industriell teknik). Det finns säkert mer relevanta siffror men oavsett så visar dessa på hur avgörande det är att hantera leverantörsrelationer strategiskt, givet den mängd pengar det handlar om.

Söm(n)lösa leveranser

Utöver de enorma summor som jag refererar till ovan, och kanske nästan än viktigare, är frågan om IT-organisationer också lyckas få till effektiva värdeströmmar och leveranskedjor genom sina olika leverantörer. Det är på inget sätt ovanligt att leveranser till kund/verksamhet går genom flera olika leverantörer. Olika system, program och applikationer som förvaltas/utvecklas av olika leverantörer men där värdet till kund förutsätter att alla gjort sin del. Uppdelning mellan leverantörer som ansvarar för utveckling och andra för test är också vanligt. Och slutligen, traditionellt har jag ofta sett en leverantör som ansvarar för applikation/utveckling. Medan någon annan haft ansvar för infrastrukturen som applikationen körs på. 

Oavsett om vi har denna typ av komplexa värdekedjor, eller avgränsade till kanske bara en leverantör, så behöver vi få till sömlösa leveranser. Där arbetet flyter obehindrat från den ena posten till nästa. Annars får vi förseningar, fördyrningar och förgrymmade mottagare som står och stampar i väntan på leverans. 

Tankemönster skapar misstag

Trots leverantörers strategiska vikt, trots omfattningen av kostnader och trots vårt behov av sömlösa leveranser så sker såklart misstag. Misstag som grundar sig på felaktiga underliggande tankemönster. 

På inget sätt gäller dessa för alla organisationer, och säkerligen finns det fler. Men nedan listar jag 3 vanliga misstag jag sett genom åren, varför de uppstår och hur de kan lösas. Detta då givet att man faktiskt förstår sin underliggande mentala modell. 

3 vanliga misstag

Hårdare avtal ger högre kvalitet

Många tror att detaljerade avtal med hårda SLA:er och straffavgifter säkrar en god leverans. I verkligheten leder detta ofta till ett kortsiktigt fokus på att undvika straff snarare än att skapa verkligt värde. Leverantörer som optimerar för att uppfylla SLA:er hittar ofta vägar att göra det utan att varken leverera på tid eller skapa den bästa lösningen för verksamheten.

Lösning: Istället för att lägga allt fokus på hårda krav och kontroll, satsa på gemensamma incitament för förbättring och innovation. Ha en öppen dialog om vad som skapar värde på lång sikt. Skippa viten, prova belöningsmekanismer istället. (Stalltips 1 – samarbete är inte en pappersfråga, det är en människofråga).

Leverantörer är  resurser och inte samarbetspartners

Många IT-organisationer behandlar leverantörer som molnresurser – där bemanning kan ökas och minskas i realtid utan någon  förlust. I verkligheten består leverantörer av människor och team som behöver stabilitet för att leverera hög kvalitet. Om vi kräver att en leverantör snabbt ska skala upp kan vi i bästa fall få tillgängliga konsulter, men sannolikt inte nödvändigtvis rätt kompetens. Effektiviteten minskar också per enhet ju fler resurser vi lägger till. 

Lösning: Skapa en jämn arbetsbelastning och samarbeta för att optimera flödet snarare än att kräva snabb skalbarhet. Bygg långsiktiga partnerskap och skapa en stabil kapacitet istället för att se leverantörer som en flexibel buffert. (Stalltips 2 – hur och var ser ni hur mycket arbete ni skickat till leverantörer?). 

Ineffektivitet i leveranser är (alltid) leverantörens fel

När leverantörer levererar sent eller med bristande kvalitet är det lätt att skylla på dem. Men ofta beror problemen på systemiska faktorer – som att vi som kund skapar ojämna arbetsflöden, skickar ospecificerade beställningar eller inte delar en tydlig backlog med leverantören. Många leverantörer arbetar dessutom i egna stuprör utan insyn i våra processer, vilket gör det svårt för dem att anpassa sig efter våra behov.

Lösning: Se leverantören som en del av värdekedjan och arbeta tillsammans för att identifiera flaskhalsar. Ge dem insyn i era processer och etablera gemensamma förbättringsmål för att optimera flödet. (Stalltips 3 – eftersträva hellre kundteam från leverantör än specialistgrupperingar för ett snabbare och jämnare flöde av leveranser).

Checklistor leverantörshantering

 Använd våra checklistor för att utvärdera och åtgärda eventuella utmaningar i leverantörshanteringen. 

• 10 frågor – överbelastar vi våra leverantörer?
• 7 frågor – skapar vi flaskhalsar hos våra leverantörer?

Åtägrder och lösingsförslag för varje punkt. 

Utveckla din leverantörssamverkan

Varje situation är såklart unik men vi har sammanställt två kostnadsfria checklistor som du kan använda för att identifiera och åtgärda vanliga fallgropar.  Vi rekommenderar också att för de leverantörer och leveranser där ni har kopplade värdekedjord göra en analys av värdeflödet. Det är det bästa sättet att inte bara kvantifiera problemet utan också att hitta rätt lösningar som har verklig effekt. 

Teknisk skuld är inte bara en IT-fråga – det är en strategisk och ekonomisk risk som kan bromsa hela din verksamhets framgång.

I en värld där digitalisering är avgörande för konkurrenskraft och innovation, står många CIO:er och IT-strateger inför samma utmaning: teknisk skuld. Den dolda kostnaden som uppstår när gamla system, kortsiktiga beslut och otillräckligt underhåll staplas på varandra. Ofta sker detta för att snabbt möta deadlines eller hålla kostnader nere på kort sikt. Men över tid förvandlas detta till en växande börda som blockerar vår affärs- och verksamhetsmässiga flexibilitet i en värld som förändras snabbare än någonsin tidigare.

Inte BARA en IT-fråga

Teknisk skuld slår ofta hårt mot IT-organisationer men det är inte bara en IT-fråga. Den tekniska skuld som varje organisation byggt upp påverkar hela organisationens förmåga att anpassa sig till nya affärsbehov, svara på marknadsförändringar och leverera värde till kunder. Ju längre den ignoreras, desto högre blir kostnaden – både i tid, pengar och förlorade möjligheter. Typiskt genererar den flera olika problem såsom:

• Fördröjda projekt och förlängda ledtider i leveranser från IT till verksamhet.
• Hindrar innovation och snabb anpassning av verksamhetsprocesser.
• Ökad risk för driftsstopp, tekniska sårbarheter och säkerhetsincidenter.
• Eskalerande kostnader för underhåll och support.

Varför uppstår teknisk skuld?

Teknisk skuld uppstår inte över en natt utan är summan av ett antal tidigare beslut, quickfixes och workarounds vi gjort historiskt. Det är också teknik och plattformar som tidigare varit goda lösningar men som inte längre motsvarar våra behov. Typiskt bakomliggande, och samverkande, skäl för dessa beslut kan vara:

• Snabba lösningar för att möta deadlines: Beslut som prioriterar kortsiktig leverans framför hållbarhet.
• Brist på regelbundet underhåll: Föråldrade system som inte uppdateras i takt med verksamhetens behov.
• Ansvarsmässig uppdelning mellan verksamhet och IT:  Där IT får uppdraget att sköta drift och underhåll helt frikopplat från verksamheten med resultatet att deras behov hela tiden går före.
• Budgetrestriktioner och kortsiktiga kostnadsbesparingar: Investeringar skjuts upp i tron att det sparar pengar, medan kostnaden i själva verket växer. 

Hur påverkas din verksamhet?

Icke hanterad teknisk har främst långsiktigt negativa effekter. Kanske är det också därför den tekniska skulden ofta inte får den uppmärksamhet och fokus den behöver. Amazons CTO konstaterade en gång att ”när mina team inte lägger minst 20% av sin tid på att hantera/eliminera teknisk skuldå så sover jag inte på nätterna. Sannolikt finns det inte en nivå som alla bör upprätthålla men erfarenhetsmässigt träffar jag många fler kunder som klagar på sitt berg av teknisk skuld än kunder som inte gör det. Teknisk skuld påverkar  typiskt negativt på flera sätt bland annat: 

• Längre Ledtider och Minskad Produktivitet:
  Föråldrade system och ineffektiva processer gör att nya funktioner och produkter tar längre tid att lansera. Detta hämmar konkurrenskraft, driver upp kostnader och skapar förseningar och problem i leveranser.
• Högre Drift- och Underhållskostnader:
  Att underhålla gamla system blir dyrare över tid, samtidigt som risken för driftstopp och fel ökar. Komplexiteten i IT-landskapet ökar och beroendet till unik individuell kompetens likaså. Gamla lösningar saknar ofta relevant dokumentation och/eller är ouppdaterad. 
• Eskalerande säkerhetsrisker:
  Utdaterade system är en säkerhetsrisk. En enda incident kan kosta miljoner i förlorade intäkter och skadat förtroende. Sårbarheterna ökar och riskerna med dem. 
• Hindrad Innovation och Flexibilitet:
  Kanske viktigast av allt, teknisk skuld gör det svårt att anpassa sig snabbt till nya affärsbehov och marknadsförändringar. Risken att missa möjligheter är visserligen stor, men än större är risken att tappa existerande kunder och affärer som ställer nya krav är än större.

Ta kontroll över din tekniska skuld idag

Teknisk skuld är inte ett problem som löser sig självt. Det kräver medvetenhet, strategi och rätt verktyg. Genom att ladda ner vårt whitepaper får du den kunskap du behöver för att börja arbeta proaktivt och framtidssäkra din organisation.

I takt med att den digitala transformationen accelererar, blir IT alltmer kritiskt för företagens framgång. Trots detta finner sig CIO:er och IT-avdelningar ofta på efterkälken när det gäller deras deltagande i strategiska affärsdiskussioner. För att djupdyka i denna paradox genomförde vi en undersökning bland ett antal CIO:er från olika branscher. Utifrån svaren från undersökningen kunde vi kategorisera inom två huvudsakliga kategorier, ”tekniska aspekter” och ”strategiska och organisatoriska frågor”.

I detta inlägg kommer vi att fokusera på den senare kategorin: ”strategiska och organisatoriska frågor” som ofta ligger till grund för 4 av de största CIO-utmaningarna. Samtidigt som de också erbjuder de mest betydande möjligheterna för förändring inom organisationer.  Vår undersökning visar på dessa 4 CIO-utmaningar och hur de riskerar att marginalisera CIO:er och IT från den strategiska affärsdialogen.

4 CIO-utmaningar

1. Kommunikationsgap mellan IT och affärsledning

En genomgående feedback från CIO:erna är att det finns ett signifikant kommunikationsgap mellan IT och affärsledningen. ”Vi talar olika språk,” som en CIO uttryckte det, där IT fokuserar på teknik medan affärssidan fokuserar på marknadsandelar och intäkter. Denna brist på gemensamt språk skapar hinder för effektivt samarbete och strategiskt engagemang.

2. IT:s bristande förståelse för företagets verksamhet och strategiska mål

Många CIO:er påpekade att IT-avdelningarna inte alltid har en djup förståelse för företagets strategiska mål. Detta gör det svårt för IT att på ett meningsfullt sätt bidra till strategiska beslut. Vilket begränsar deras möjlighet att fungera som en strategisk partner snarare än som en stödfunktion.

3. Perceptionen av IT som en kostnad snarare än en investering 

En annan utmaning är hur IT uppfattas ekonomiskt inom organisationen. ”IT ses ofta som en kostnadspost, inte som en investering i företagets framtid,” noterade en deltagande CIO. Detta synsätt minskar viljan att integrera IT i strategiska planeringsprocesser.

4. Snabba teknologiska förändringar och osäkerhet

Den snabba takten i teknologisk utveckling skapar osäkerhet kring hur IT bäst kan bidra till företagets långsiktiga mål. CIO:erna uttryckte att denna osäkerhet ofta leder till tveksamhet från affärsledningens sida att fullt ut engagera sig med IT på en strategisk nivå.

Strategiska åtgärder för att förstärka IT:s roll i affärsstrategin 

Våra resultat belyser betydande hinder som måste övervinnas för att IT ska kunna ta sin rättmätiga plats i den strategiska affärsdialogen. För att adressera dessa utmaningar rekommenderar vi följande:

1. Förbättrad kommunikation: Skapa forum och processer där IT och affärsledningen kan mötas för att diskutera och utforma strategiska mål med ett gemensamt språk. Detta underlättar förståelse och samarbete mellan de två enheterna.
2. Utbildning för både IT och verksamhetspersonal:
   • För IT-personal: Investera i utbildningsprogram som stärker IT-avdelningens förståelse för företagets affärsstrategier och marknadsförhållanden. Detta bidrar till en mer strategiskt inriktad IT-funktion som kan agera proaktivt snarare än reaktivt.
   • För verksamhetspersonal: Utbilda verksamheten i IT. Det är lika viktigt att verksamhetspersonal får utbildning i grundläggande IT-kunskaper och förståelse för hur teknologi kan stödja affärsmålen.
3. Synliggör IT:s värde: Positionera IT som en vital investering genom att tydligt demonstrera hur IT-initiativ bidrar till affärsresultat och mål. Detta ändrar synsättet på IT från en kostnad till en central del i att driva innovation och tillväxt.
4. Adressera affärsmässig komplexitet: Utveckla en strategisk IT-roadmap som inte bara visar hur teknologiinvesteringar stöder företagets långsiktiga mål men också skapar en flexibel och skalbar IT-arkitektur. Detta tillvägagångssätt bör ge rum för flexibilitet och valfrihet för affärsverksamheten. Vilket är kritiskt i en ständigt föränderlig och komplex affärsmiljö. En sådan IT-planering gör det möjligt för organisationer att effektivt navigera i förändring och utnyttja nya teknologiska framsteg för att förbli konkurrenskraftiga.

Steg-för-steg process för att koppla IT-initiativ till affärsmål och kvantifierbara resultat

Att koppla IT-initiativ till affärsmål och kvantifierbara resultat är avgörande för att visa IT:s värde. Såväl som säkerställa att teknikinvesteringarna bidrar positivt till organisationens övergripande framgång. Vi använde oss av ett AI för att få en en steg-för-steg process som kan hjälpa CIO:er och IT-ledare att uppnå detta:

Avslutningsvis

Det är dags för företagsledare att omvärdera IT:s roll och dess potential att driva innovation och strategisk förändring. Genom att ta itu med de identifierade utmaningarna kan företag inte bara stärka sin konkurrenskraft. Utan också säkerställa att IT fullt ut bidrar till verksamhetens framgång.

Bakgrund och Metod

Undersökningen syftade till att identifiera CIO:ers huvudutmaningar de står inför just nu. Vi intervjuade ett urval av CIO:er från en rad olika sektorer (och totalt 15 olika branscher) inom privat näringsliv. Var och en med sin unika syn på IT:s roll inom sina organisationer. Vidare använde vi AI för att sammanställa resultatet såväl som rekommendationer. I detta delades resultaten in i två huvudsakliga kategorier. ”Tekniska aspekter”, respektive ”Strategiska och organisatoriska frågor”.  Vi har i denna blogg valt att endast fokusera på de senare då detta är inom vårt expertisområde.

Agila ledarskapsworkshops

Våra agila ledarskapsworkshops riktar sig mot både IT-ledare såväl som ledare inom affärsverksamheten. Med hjälp av dessa workshopar kan ni bygga bättre gemensamma kunskaper och förmågor. Bland annat i syfte att reducera de ovan nämnda CIO-utmaningarna.

Pris: Fastpris mot offert

Datum: Levereras endast företagsinternt. 

Från olika håll framför man emellanåt att agila metoder och traditionella projekt (ibland kallade vattenfall) inte går att kombinera. Men i realiteten är det många organisationer som ändå gör det. Hur går man då bäst tillväga när man kombinerar de olika metoderna och dess nyckelroller? I denna blogg tittar vi lite närmare på frågan om rollerna Scrum Master vs Projektledare och hur man säkerställer ett gott samarbete dem emellan.

Syfte och ansvar Scrum Master och Projektledare

Vi börjar med att kort reda ut de två rollernas syfte och ansvar.

Projektledarens huvudsakliga syfte är att säkerställa ett framgångsrikt projekt. Vi definierar framgång i projekt när det uppnår såväl projekt- som effektmål inom ramen för budget och tidsambitioner. Här har projektledaren ett ansvar för att både projektleveransen, såväl som att de önskade resultat eller effekter som projektleveransen syftar till, uppnås/realiseras.

En Scrum Master säkerställer, som primärt syfte, att det agila teamet fungerar så effektivt som möjligt. Scrum Mastern har ansvar och fokus på att teamets förmåga att kontinuerligt skapa mesta möjliga värde, hela tiden utvecklas och förbättras. I praktiken innebär detta att Scrum Mastern inte enkom kan fokusera på teamet. Dessutom stödjer och hjälper hen produktägaren, hjälper teamet identifiera och undanröja hinder. Utöver detta, för Scrum Mastern teamets talan gentemot övriga verksamheten.

En liten ”disclaimer”

I texten nedan använder jag titeln ”Scrum Master”. Inte för att jag anser att det är den enda agila metoden eller för den delen är ett tvång för att anamma agila metoder. Istället använder jag termen utifrån enkelhet, igenkänning samt att rollen är vanligt förekommande. Kärt barn har många namn och den kan därför också heta ”Agil coach”, ”Kanban lead”, ”Kanban Master”, Agile lead” eller någon annan titel i olika organisationer. I slutändan är min förhoppning att rollen  – utifrån beskrivningen – ändå blir förståelig och känns igen.

Rollernas ansvarsuppgifter

Låt oss titta lite närmare på själva ansvarsuppgifterna som Projektledare respektive Scrum Masters förväntas göra enligt gängse rolldefinitioner.

Projektledare

Projektplanering.

Utvecklar, upprättar och underhåller en realistisk projektplan. Denna plan hjälper organisationen att förstå vad som behövs göras och i vilken ordning. Allt för att kunna nå projektets mål.

Kommunikation.

Projektledaren säkerställer att tydlig och effektiv kommunikation sker inom projektgruppen. Det gäller såväl med intressenter som med styrgrupp/beställare av projektet.

Budget.

Projektledaren ansvarar oftast för att formulera och löpande följa upp projektets kostnader. I praktiska termer kan det därmed också handla om att hantera fakturor och tidrapporter. Här ingår också att sammanställa finansiella kostnader och resultat till projektets styrgrupp och beställare.

Beslutsfattande.

Projektledare är som namnet antyder en ledarskapsroll. Detta tar sig uttryck i att projektledaren ofta behöver fatta beslut för att leda projektet och dess medlemmar mot projektets mål. Det innebär oftast att behöva prioritera mellan aktiviteter. Vidare innebär det också att lösa konflikter samt löpande justera och anpassa projektplanen därefter.

Personalhantering.

Denna del är beroende av om projektet tilldelas egen personal eller använder personal från ”linjeorganisationen”. En effekt av detta kan bli att också frågor om rekrytering, ledning, lönesättning etc åligger en projektledare.

Riskhantering.

Projektledaren ansvarar för att identifiera, motverka och hantera risker som uppstår i projektet. Eftersom projekt per definition alltid innebär en risk av något slag,  så brukar detta vara en av de centrala delarna av projektledarens arbete.

Rapportering.

Slutligen har projektledaren ett ansvar att gentemot styrgrupp och beställare rapportera på projektets progress (leverans, tid och kostnad). Dessutom att tydligt kommunicera vilka hinder och/eller risker projektet stött på längs vägen.

Potentiella konflikter mellan Scrum Master och Projektledare

I grunden bör det inte uppstå oundvikliga konflikter mellan Scrum Masterns och Projektledarens ansvarsområden och arbetsuppgifter. Tvärtom finns betydande vinster att uppnå genom nära och produktivt samarbete mellan rollerna. För att visa på områden där vi bör hålla ögonen öppna, listar jag här några potentiella konfliktområden och effektiva hanteringsmetoder:

Projektplanering

Projekt planeras vanligtvis i en linjär tidsordning med fördefinierade sekvenser av aktiviteter, såsom kravinsamling, analys, design, etc.. Agila metoder förespråkar däremot en mer cirkulär metod. Istället för att detaljerat planera varje steg, fokuserar man på vad som är mest relevant just nu, vad som kan slutföras under korta cykler och hur arbetet bäst kan struktureras. Genom att acceptera den agila cykeln och den komplexitet som är inneboende inom systemutveckling, kan dessa synsätt samverka effektivt. Det innebär som exempel, praktiskt, att projektplanen behöver beskrivas mer övergripande. Detta leder till större flexibilitet i leverans för att antingen uppnå så mycket som möjligt inom tilldelad tid eller att acceptera att projektet kan ta längre tid än initialt förutspått.

Beslutsfattande

Traditionella projekt styrs ofta med hierarkiska metoder där ledaren leder och fördelar arbetsuppgifter, instruerar medarbetare om vad som förväntas samt i vilken ordning. Agila metoder betonar istället att medarbetare är kompetenta och villiga att prestera om de ges rätt förutsättningar. Det handlar mindre om rollbeskrivningar och mer om hur varje projektledare leder sitt projekt. Här är det är avgörande att beslutsfattandet inte skapar hinder för de agila teamen. Eventuella konflikter som uppstår behöver hanteras av både Projektledaren och Scrum Master.

När det kommer till prioritering, följer de agila metoderna att en Produktägare kontinuerligt prioriterar det agila teamets fokus. Det är därför viktigt med en nära dialog mellan Produktägare och Projektledare.

Hinder och Skydda teamet

Det är vanligt att projekt skapar hinder för agila team, där projektplanen inte tar hänsyn till teamets verkliga kapacitet och överbelastar dem med arbetsbörda. Ett vanligt bekymmer är att projektet efterfrågar tillgång till specifika resurser från teamet, såsom medarbetare med unik kompetens som behövs i projektet. Detta resulterar ofta i att teamets effektivitet hämmas, eftersom det blir oklart om och när dessa medlemmar är tillgängliga för teamets arbete eller om de måste engageras i projektet istället. En effektiv strategi för att hantera detta är att undvika att tilldela specifika resurser.

”Pull” istället för ”Push”

Låt istället projektet begära arbete och leveranser från teamet, som sedan själva avgör hur de ska utföra detta. Visserligen finns utmaningar med detta tillvägagångssätt, och ibland innebär det att teamet måste förstärka sina resurser för att undvika brister inom kompetensen. Men, trots att detta kan upplevas som kostsamt eller ineffektivt, har erfarenheter från ”pair programming” visat på positiva effekter i termer av kvalitet och innovation som vida överstiger de förmodade extra kostnaderna. Detta har till och med varit en överraskning för VD-positioner. Dock bör ett agilt team alltid ha fokus på att kompetenserna i teamet har rätt spridning, oavsett om de är omgivna av projekt eller ej. 

Fördelar med Scrum Master och Projektledare i samverkan

Flera betydande fördelar uppnås genom en väl genomtänkt och balanserad tillämpning av både projektmodeller och agila metoder. Fördelarna stärks ytterligare genom att följa agila principer såsom ”individer och interaktion före processer och verktyg”. Exempel på de fördelar som kan uppkomma inkluderar:

Behov av effektiva team inom projekt

En projektledare drar stor nytta av en Scrum Master och dennes arbete. Scrum Master fokuserar på att coacha teamet för att uppnå högsta möjliga effektivitet, vilket ger projektledaren ett pålitligt stöd och en försäkran om att det berörda teamet kan hantera sina uppgifter på ett utmärkt sätt.

Dessutom, med de agila teamens kontinuerliga förbättringar, levererar de ännu bättre arbete som efterfrågas av projektet i takt med tiden. När denna leveranskvalitet kan mätas och verifieras över tiden, minskar åtminstone en av de potentiella riskfaktorerna för projektet. Här spelar Scrum Master en central roll i att stödja projektledaren att uppnå de satta målen.

Beslut, rapportering och budget

Tillsammans med projektledaren är en Scrum Master aktiv i att rapportera till och ha dialog med styrgruppen och beställarna. Det kan liknas vid att ”fabrikschefen” validerar om leveransplanerna från ”sälj/distributionschefen” är genomförbara både på kort och lång sikt. En Scrum Master, som också deltar i de övergripande besluten som styrgruppen tar, bistår både styrgruppen och teamet att fatta välgrundade beslut om prioriteringar, inriktningar och målsättningar.

Normalt sett har inte en Scrum Master en egen budget, vilket vanligtvis är fallet för en projektledare. Dock är denna typ av resurser viktiga för både projektet och dess agila team. Sagda resurser kan användas för att främja specifik kompetensutveckling, inköp av komponenter såsom mjukvaror, verktyg, licenser eller liknande, som är till nytta för det specifika teamet.

Kommunikation, kompetens och planering

Medarbetare som är väl informerade om målen, syftet och de förväntningar som finns, har mycket bättre förutsättningar att utföra sina uppgifter på ett bra sätt. Projektledarens roll i kommunikationen är här till stor hjälp för både teamet och Scrum Master. Genom projektledaren tillhandahålls teamet den nödvändiga informationen för att effektivt arbeta och aktivt sträva mot målen för projektet och följaktligen för organisationen.

För projektledare som inte är fullständigt insatta i de agila metoderna kan en Scrum Master utgöra en värdefull resurs för att bygga kompetens. Genom att stödja projektledaren att förstå hur de kan driva sitt projekt i linje med agila metoder, ceremonier (och därmed teamets effektivitet), skapar Scrum Mastern en gynnsam miljö för samverkan mellan projektmetodik och agila processer.

”Lagom agilt”

Projektledaren arbetar utifrån ett projekt- och riskperspektiv, vilket stödjer Scrum Mastern att balansera en ”lagom” användning av agila principer för att styra teamet och dess arbete. Det kan inkludera områden som prognostisering, dokumentation, kommunikation och planering, där teamet exempelvis antar ett kvartalsbaserat planeringsperspektiv och tillsammans med produktägaren skapar en produktroadmap som harmoniserar med projektplanen. Det handlar mer om att hitta en balans än att överdriva den ofta missuppfattade agila inställningen att ”ingenting kan planeras, förutses eller utlovas i en komplex värld”. I det fallet antar arbetet snarare en alltför slumpmässig karaktär, vilket inte heller är önskvärt.

Sammanfattningsvis

Alldeles för ofta ser vi ett slags ställningskrig i organisationer där agila team och förespråkare hamnar i en onödig konflikt med projekt och projektledare. Detta, trots att det egentligen finns tydliga vinster att uppnå i ett produktivt samarbete. Genom att beakta våra råd ovan samt att vardera ”sida” är beredd att kompromissa i någon mån för den andra sidans behov och förväntningar, så kan man etablera ett gott samarbete och skapa värdeskapande leveranser. En av de viktigaste delarna i detta är just att titta på de underliggande principerna för hur vi som organisationer prioriterar, planerar, följer och utvärderar vårt arbete. Sannolikt sker inte detta av sig självt utan kräver ett aktivt deltagande och samarbete.

Om Onbird

På Onbird tror vi på några enkla saker. Vi tror att organisationer idag sitter på en mängd outnyttjade förmågor. Vi tror också på att alltid sträva mot enkelhet. Vidare tror vi på att man först måste definiera vilket problem som man vill lösa innan man definerar lösningen. Slutligen tror vi att vi skapar mest värde åt våra kunder när vi hjälper dem att själva utvecklas och hitta lösningen.

Utifrån det har vi utvecklat en portfölj av tjänster, produkter och utbildningar som vi använder för att hjälpa våra kunder. I portföljen finns kunskap, produkter och lösningar baserade på kända ramverk. Men ramverken kan aldrig vara lösningen eller målet. De kan bäst användas som ett medel för att nå målet. Ibland kallar vi detta för ett ”agnostiskt perspektiv eller förhållningssätt” till ramverk.

Bland våra kunskapsområden erbjuder vi kompetens inom Agile, DevOps, Lean IT och ITSM och ingen av dessa är alltså slutmålet.

Boken ”Detta är Lean – Lösningen på effektivitetsparadoxen” av Niklas Modig och Per Åhlström, är en av de svenska storsäljarna inom managementlitteratur. Författarna som har en bakgrund på handelshögskolan i Stockholm har skrivit en lättförståelig och relativt sett kortfattad bok om Lean och vad de anser är kärnan inom Lean.

Det finns flertalet välskrivna böcker i ämnet men också många som är mindre bra. Det som är denna boks stora fördel är att författarna definierar Lean utifrån mer typiskt akademiska mått. Därmed beskriver man Lean som en verksamhetsstrategi och inte en affärsstrategi. Det här känns som en mycket relevant och tydlig definition som kanske särskiljer dem från andra författare.

Vad är Lean?

Hur beskriver de då Lean. Förenklat så kan man säga att deras definition av Lean är att övergå till en styrning, organisation och metod som fokuserar på Flöde snarare än resurs. I praktiska termer så innebär det att man ser på varje organisation som en fabrik som tar ingående gods, varor, produkter och tjänster, förädlar dem inom organisationen (i bilfabriken genom att montera delar på det som med tiden ska bli en färdig bil) och slutligen distribuerar/säljer detta vidare till kunden/mottagaren av det som organisationen gör. Därmed blir det viktigaste för en organisation alltid hur snabbt enheten (det som organisationen bygger/förädlar) flyter genom fabriken. I en organisation där fokus är inställt på resurseffektivitet så kommer istället frågan om hur upptagen varje resurs är vara viktigare.

Lean utanför biltillverkning

I boken görs en målande beskrivning över hur svensk sjukvård fungerar där Läkare är så dyra resurser så att man därmed alltid kommer att sträva efter att de är fullt belagda. Det låter ju rimligt men förutsättningen för detta är dels att patienter måste stå i kö och vänta på att läkaren ska få tid över för dem samt att varje patient bara får använda upp en lika stor del av läkarens tid eftersom det annars blir stopp i kön och en flaskhals har uppstått (mer om flaskhalsar inom IT ).

Optimera flöde inte resurs 

Genom att göra en tydlig distinktion mellan resurs och flödeseffektivitet så tycker jag att författarna faktiskt lyckats fånga essensen av Lean. Allt annat, alla andra koncept, metoder och verktyg som finns inom Lean-området, är egentligen bara till för att hela tiden smörja och förbättra denna flödeseffektivitet. Pull vs Push. Ständig förbättring, eliminering av strul (waste) etc är alla den naturliga följden av att lägga en verksamhetsstrategi med fokus på flödeseffektivitet.

Med enkla pedagogiska beskrivningar och grepp så förevisar författarna därefter koncept, metoder och naturligtvis hur de ”gör där borta på Toyota” i den resterande delen av boken.

Stöd vid införande

För den som söker hjälp i införandet av lean i sin verksamhet är boken dock tunnare. Boken blir inte nödvändigtvis sämre av detta men det är nog viktigt att man som läsare har det med sig. Att förändra en organisation i grunden, vilket en orientering mot eller omläggning av verksamhetsstrategi till lean är, innehåller många svårigheter och fallgropar. Något som författarna Womack och Jones i sina böcker ”The Machine that changed the world” samt ”Lean Thinking – banish waste and create wealth in you organization” belyser med sina många praktiska exempel och beskrivningar från de olika företag som gett sig på resan. Så frågan om införandet, metod för, strategi bakom etc lämnas ganska obesvarad.

Detta till trots så ger Niklas Modig och Pär Åhlströms bok en mycket bra start för den som vill lära mer om Lean och vad som ingår som viktiga koncept och strategier.

Välkommen till vår omfattande guide för att framgångsrikt införa agila metoder i din organisation. Denna guide är skapad för att hjälpa dig att navigera genom en smidig övergång till agila arbetsmetoder och maximera dina resultat.

Fas 1: Förberedelse och Förståelse

För att påbörja din resa mot agila metoder krävs en stark grund och tydlig förståelse. I den här fasen fokuserar vi på:

• Utbildning om Agila Principer: Förstå grunderna och fördelarna med agila arbetsmetoder samt hur de kan förbättra din organisations agilitet och effektivitet.

• Identifiera Organisationens Mål: Definiera tydliga mål för din agila transformation. Är det ökad samarbetsförmåga, snabbare produktleverans eller ökad kundfokus?

• Skapa En Kommunikationsstrategi: Utveckla en plan för att effektivt kommunicera din organisations övergång till agila metoder till dina medarbetare, partners och intressenter.

Fas 2: Pilotprojekt och Lärdomar

Genom att testa agila metoder i en kontrollerad miljö kan du säkerställa en smidig implementering i hela organisationen. Under denna fas ingår:

• Välj Ett Pilotprojekt: Välj ett passande projekt eller team för att utföra ett pilotprojekt med agila metoder. Detta ger dig möjlighet att testa och anpassa innan full implementering.

• Utbildning och Träning: Ge ditt pilotteam den nödvändiga utbildningen för att framgångsrikt kunna tillämpa agila metoder.

• Implementera Agila Metoder: Använd agila verktyg som sprintplanering, dagliga möten och retrospektiv för att tillämpa agila principer på ditt pilotprojekt.

• Utvärdera och Anpassa: Efter pilotprojektet, utvärdera resultat och lärdomar. Anpassa din strategi baserat på de insikter du har fått.

Fas 3: Skalning och Förbättring

Med lärdomar från pilotprojektet är det dags att sprida de agila metoderna i hela organisationen. Under denna fas fokuserar vi på:

• Utveckla Implementeringsplan: Skapa en plan för att utvidga de agila metoderna till fler team och projekt i hela organisationen. Identifiera etapper, tidslinjer och resurser.

• Utbildning och Stöd: Se till att alla medarbetare får rätt utbildning och stöd för att framgångsrikt anamma agila metoder.

• Anpassning och Optimering: Förstå att agila metoder är anpassningsbara. Justera och optimera processerna baserat på varje teams specifika behov.

• Mätning och Förbättring: Använd regelbunden mätning och retrospektivmöten för att kontinuerligt förbättra dina agila arbetsmetoder.

Avslutning 

Genom att följa denna guide kommer din organisation att vara rustad för en smidig övergång till agila metoder. Genom att investera tid och engagemang i denna transformation kan du uppnå ökad flexibilitet, samarbete och kundfokus, vilket kommer att öka ditt organisations framgång och konkurrenskraft.

Kommentarer från Onbird

Som ni ser i texten ovan så är det ganska generiska råd och tips som ChatGPT levererar. Vi har som sagt identifierat ett antal ytterligare områden och komponenter som vi tycker behöver utvecklas och förtydligas. Nedan är våra tillägg.

Vilket problem ska agila metoder lösa?

Även om vårt kära AI pekar på att det ska finnas ett tydligt syfte och mål så tror vi man först måste börja med att definiera sitt problem. Vad är det vi hoppas åtgärda med att byta arbetssätt? Utan detta finns risken att vi bibehåller vårt problem och lägger ytterligare lager av metoder och strukturer ovanpå. Det blir till sist som en slags lasagne, kanske god men svårt att särskilja lagren. Och därmed svårt att separera ut i efterhand.

Agila metoder i all ära, de har betytt mycket för IT-organisationer, men om de inte har en tydlig koppling till de affärs- och/eller verksamhetsresultat man vill uppnå så kommer de att ge begränsad nytta.

När är vi agila?

När är vi då klara med vår förflyttning? Ja, det enkla men kanske lite tråkiga svaret på den frågan är ju att vi egentligen aldrig blir det. Ett centralt element i de agila metoderna är just att det är en ständigt pågående förbättring mot mer värde, skapat på än kortare tid. Därför blir man kanske aldrig helt klar.

Svaret på frågan ”är vi agila?” får vi kanske aldrig helt svar på. Men vi på Onbird har identifierat åtta olika mognadsfaktorer som vi hävdar kännetecknar organisationer som åtminstone kommit långt i sin agila förflyttning.

• Kundnära IT
• Förutsägbarhet
• Datadrivet beteende
• Flödesorientering
• Acceptans och riskvilja för komplexitet
• Mandatsdistribution
• Teamberad nätverksorganisation
• Kultur- och värdedriven organisation

Var agila i er agila transformation

Att införa agila metoder är på inget sätt en spikrak resa mot framgång och succé. Tvärtom är det många organisationer som inte alls lyckas med planen. Och att planera för att införa ett arbetssätt som förordar iterativitet, kortsiktig planering och anpassning kräver ett motsvarande förhållningssätt i införande. Det innebär att vi behöver vara agila även i vårt införande av agila metoder. Snarare än en rigid och detaljerad plan, så accepterar vi komplexiteten i införandet och hanterar det genom att jobba i många korta iterationer med täta avstämningar på vägen.

Det är heller inte ovanligt att man börjar resan, etablerar några ceremonier och kanske någon processbeskrivning och tilhörande dokumentation. Men egentligen är allt annat lika och de stora och viktiga resultaten uteblir. Stanna därför inte upp bara för att ni skaffat en kanbantavla och definierat lite olika agila mötesceremonier.

Vanliga fallgropar

Agila metoder förespråkar teambaserat arbete. Ofta presenterar detta många olika utmaningar där man egentligen inte skapar team utan utnämner diverse grupper med löst uppknutna individer som kanske till och med hör till flera olika grupper, dvs är hyvlade ostskive-tunna och egentligen inte hinner mycket mer än att springa mellan möten och olika prioriteringar, snarare än få viktigt arbete gjort. Vill du ha lite konkreta råd så har vi satt samman en guide.

Att införa det som ibland kallas Zombiescrum, är på inget sätt att nå framgång. Ofta kan det till och med bli tvärtom. Men vad är då Zombiescrum? Enklast kan det beskrivas som att man har ett antal löst sammansatta grupper av människor som med (någorlunda) jämna mellanrum genomför olika former av möten som har fått namn från agila ceremonier men som egentligen inte alls följer de agila principerna och värderingarna.

Och sist (i denna skrift) men inte minst, så är ett införande av agila metoder att ändra på många grundläggande vanor, beteenden, struktuer och föreställningar som vi har. Sådant tar tid och är till kanske 90% kulturella och knutna till mänsklig dynamik. Resterande 10% är mer praktiska frågor såsom verktygsval, processbeskrivningar eller liknande.

Alternativ för att skala agilitet

De flesta organisationer består inte enbart av ett agilt team. Tvärtom har man ofta flera olika team som på olika sätt ska samverka kring agila leveranser.

Att avgränsa den agila förflyttningen till endast IT-organisationen kommer inte heller att ge alla de vinster som agila metoder kan ge. Hur ska tex verksamheten utvecklas i samklang med den agila leveransen och teamen. Att försöka blanda årsplanering med kortare iterationer kan skapa många problem i en organisation.

Det finns i dagsläget flera olika så kallade ”skalade agila ramverk”. Vanligast är kanske SAFe, men det är inte ett tillräckligt bra skäl för att välja just det ramverket. Här måste man som organisation värdera sina olika alternativ och identifiera vad vi måste skala respektive vad vi kan undvika att skala. I regel behöver man oftast ha någon form av skalad modell som hjälper oss att hålla ihop multipla team, en bred projektportfölj och många olika intressenters behov och önskemål.

Agila metoder, inte bara IT

Även detta område kan man skriva spaltmeter om. Inte minst under rubriken ”vanliga fallgropar”. Här och nu nöjer vi oss med att konstatera att en förflyttning mot agila metoder är svår och till viss del meningslös att avgränsa till endast IT-organisationen. Strukturera därför upp en tanke och en metod för att löpande också kunna utveckla och harmoniera verksamhetssidan mot de agila metoderna och teamen. 

Led förändringen

Sammantaget så kan ett införande av agila metoder bli en ganska omfattande förändring för organisationen. Det är människor, verktyg, processer och principer som allihop ska utvecklas mot nya förmågor. För detta behöver vi ha någon form av strukturerad förändring och förändringsledning. Fundera igenom och definiera vilka som ska driva förändringen, hur deras kadens ska se ut och hur vi värderar och utvärderar framgång i deras arbete. Tips från läktaren, många power-pointpresentationer är sannolikt inte det bästa resultatet. 

Förändringen kan heller inte ske på de kunskaper vi har idag. Ska vi arbeta på ett annat sätt med andra metoder, principer och verktyg så behöver vi också avsätta tid för att utöka vår kompetens. En kompetensplan behöver därför identifieras som riktar sig mot rätt mottagare i organisationen. 

Läs även

• Fördelar med Agila Metoder för IT-Management
• Kundfall: Lyckad Agil Transformation 
• Kurs: Att kombinera agilt och projekt

Detta är del 1 av 2 om flaskhalsar hos IT-organiationer. Denna första del tar upp varför IT-organisationer bör lägga mer fokus på att identifiera och hantera dem. Del 2 tar upp strategier om hur man kan gå tillväga för att hantera dem.

Intern effektivitet ligger högt på varje organisations agenda. Många metoder och ramverk används och vissa effekter brukar kunna skönjas men bestående effekter är svåra att etablera.

I forskningen kring ”theory of constraints” av Eli Goldratt konstateras dock att alla försök att effektivisera eller förbättra verksamheten är meningslösa om de inte är riktade mot flaskhalsar i produktionen eller flödet. Enkelt kan det beskrivas som den svagaste länken, åtgärdar vi inte den så blir hela kedjan dålig. I Eli Goldratts värld så existerar varje organisation endast för att ta gods, varor och produkter och förädla detta för att därefter distribuera det vidare till nästa organisation/kund i kedjan.

Vad är en flaskhals?

Enligt wiktionary är definitionen av en flaskhals: ”en kritisk del i ett flöde eller system som utgör hinder för den normala utvecklingen; den svagaste länken i en kedja”.

En flaskhals är alltså ett fenomen där prestanda eller kapacitet för ett helt system är begränsat av en enstaka eller mindre antal komponenter nödvändiga för processens färdigställande.

Hur ser då flaskhalsar ut i en typisk IT-organisation? Man kan säga att det finns två typer av flaskhalsar. Dels tekniska flaskhalsar. Någon specifik maskin- eller programvara som utför någon given men kritisk uppgift. Och med kritisk här menar vi egentligen bara kritisk för flödet den ingår som en del av.

Det kan vara en singel ftp-server eller en hårdvara som hanterar överföringar etc. I vanliga fall löser vi hårdvarubegränsningar med redundans med utgångspunkt från att undvika ”single-point-of-failures”.

Bara häromdagen satt jag med en organisation som inte kunde fatta go-nogo beslut om en release eftersom huvudutvecklaren satt på ett flygplan och ingen vågade fatta beslut utan honom.

Varför blir så ofta personberoende?

Några vanliga förklaringar kan vara:

• IT-organisationer söker och utvecklar specialistkompetens. Specialisten blir per definition en flaskhals, annars skulle hen vara en generalist i organisationer.
• För att veta vem som gör vad lägger vi mycket kraft och tid på att utveckla tydliga roller och ansvar  för respektive uppgift dvs. inte för helheten, den är oftast för komplex.
• Organisationen delas upp efter kompetens men leveranser kräver korsfunktionella samarbeten för att kunna ske. Detta är egentligen den moderna motsvarigheten till Fords löpande band.
• Verksamheten (och därmed de anställda) värderas utifrån deras beläggning i första hand och inte utifrån organisationens ”throughput”-förmåga. Gärna understött av ett budgetstystem som baserar sig på samma principer.
• Bonus- och belöningssystem implementeras som inte i första hand främjar samarbete med andra funktioner utan istället suboptimering på den egna funktionens resultat.
• Ett överdrivet fokus på standardisering för att säkra låga omkostnader och IT-säkerhet gör att allt som inte passar ”mallen” blir svårt att hantera.
• Slutligen så finns också den tråkiga men oundvikliga effekten att personal för att säkra sin anställning och löneutveckling gärna gör sig oumbärliga på olika sätt med hjälp av ”unik kompetens” eller liknande.

Vilka effekter kan vi vänta oss av flaskhalsar?

Det uppenbara svaret är långa leveranstider, personberoende, svagheter i leveranskapacitet, stopp i produktion, missnöjda kunder/mottagare av leveranser etc. Det finns också följdeffekter i termer av missnöjd personal, interna frustrationer och naturligtvis ”blame game”. Inom ITIL känd som den icke officiella processen ”Scapegoat Management”.

Men mer konkret så uppstår också ett antal osynliga problem. Alla resurser som befinner sig efter en flaskhals får långa ställtider, dålig beläggning eller ett ojämnt flöde. Åtgärdar vi flaskhals så återkommer ändå bara problemet i flaskhals B och sen C och så vidare.

Resurserna som befinner sig mellan tenderar också att använda den lediga tiden till att hitta på nya saker som skapar nya bekymmer alternativt helt enkelt bara är ett resursslöseri med icke efterfrågade aktiviteter.

Några exempel från verkligheten

Projektgruppen lyckas inte få till ett möte förrän om 4 veckor för alla resurser är uppbokade på annat.

Releasen kan inte produktionssättas för den enda nätverksteknikern som kan hantera den avancerade brandväggsöppningen är inte på plats denna vecka, hen är på kurs/eller annan valfri plats.

Testmiljön kan inte uppdateras den här veckan för att vi väntar fortfarande på svar från leverantören om vad som är den rekommenderade inställningen.

Driftsteknikern (valfritt namn) kan inte lägga tid på uppdateringen av firmware på rack-controllers för han är upptagen med att lösa en större incident som uppstått på produktionsservrarna för den centrala ERP-lösningen.

I del 2 tittar vi närmare på strategier för att hantera och bygga bort flaskhalsar.

Resurserna som befinner sig mellan tenderar också att använda den lediga tiden till att hitta på nya saker som skapar nya bekymmer alternativt helt enkelt bara är ett resursslöseri med icke efterfrågade aktiviteter.