Trots ledningsgruppers outtröttliga arbete med prioriteringar, affärsmål och strategiska roadmaps upplever många IT-organisationer samma sak: leveransplanen kraschar så fort den möter verkligheten. Varför misslyckas vi med att förutse leveranskapaciteten, trots alla agila ramverk och planeringsverktyg?

Svaret är inte alltid bekvämt: Prioritering är en affärsövning. Leverans är fysik.

I många organisationer behandlas leveransproblem som ett ”metodproblem”: att teamen inte jobbar tillräckligt agilt eller att beställarna är för otydliga. Men i själva verket handlar det om att vi ignorerar systemets underliggande fysik och fattar strategiska beslut baserade på gissningar och magkänsla, snarare än verifierbar leveransdata.

1. Kapacitetsillusionen och dolda kontextbyten

Ett av de absolut vanligaste systemfelen i storskalig IT-leverans är Kapacitetsillusionen. Det är illusionen om delad kapacitet; idén att en nyckelresurs (till exempel en lösningsarkitekt) som sitter i tre olika team bidrar med 33 % kapacitet per team.

Fysiken bakom kontextbyten (context switching) visar dock att nettoeffekten snarare landar på 15 %. Redan på ritbordet överplaneras systemet massivt. Det är ingen agil utmaning, det är ren matematik som stjälper er roadmap.

2. ”Trojanska hästar” skapar kvävande WIP

Ovanpå detta tillkommer ”Trojanska hästar”: sidoinitiativ som startas av verksamheten med egen budget för att runda IT-avdelningens ordinarie prioriteringar. Problemet är att dessa projekt i slutändan belastar precis samma dolda flaskhalsar, vare sig det rör sig om plattformsteam, säkerhetsgranskning eller infrastruktur.

Resultatet blir ett kvävande WIP (Work In Progress) där en oproportionerligt stor andel av systemets faktiska kapacitet konsumeras av osynligt arbete (skugg-IT, teknisk skuld och ad hoc-ärenden) som ledningsgruppen inte ens vet existerar.

Dashbird: AI som brobyggare över stökig data

Det är här modern teknik förändrar spelplanen. Vi har skapat Dashbird, ett verktyg som läser ”rå” data direkt från system som Jira. Tricket med Dashbird är att den inte kräver perfekt arbetshygien i era system. Istället för att lita på att människor manuellt har länkat alla ärenden exakt rätt, gör Dashbird intelligenta sammanslagningar som är för svåra för traditionella BI-verktyg att klara av. Verktyget belyser er dolda data utifrån våra specifika fokusområden och dolda nätverksberoenden.

Simulera din roadmap mot verklig kapacitet

Dessutom introducerar Dashbird en helt ny dimension av planeringskraft: genomförbarhetsanalys. Om du matar in en rudimentär roadmap i systemet, kan Dashbird avgöra hur pass genomförbar den är. Systemet beräknar detta objektivt, baserat på ert historiska flöde och den faktiska kapaciteten hos de funktioner som kommer påverkas av de nya initiativen.

[SKÄRMDUMP: Dashbird Roadmap-simulering – Lägg in din bild här]

Data är bara halva lösningen

Att få kontroll över sin leveranskapacitet handlar inte om att tvinga in organisationen i fler agila ramverk. Det handlar om att förstå fysiken. Vi på Onbird levererar inte bara verktyget, vi hjälper er att tolka dessa mätetal, förstå var systemet blöder och agera på insikterna. Bara när ni vet hur systemet faktiskt beter sig kan ni sluta gissa, och börja leda.

FAQ: Snabba svar om IT-leverans och Kapacitet

Varför misslyckas ofta strategiska roadmaps inom IT?
De misslyckas oftast för att de planeras utifrån en teoretisk budgeterad kapacitet (gissningar) istället för systemets historiska och faktiska leveranskapacitet (throughput). Dolda flaskhalsar och teknisk skuld äter upp tidsmarginalerna.

Vad är ”Kapacitetsillusionen” inom projektledning?
Det är tron att en medarbetare som delas mellan tre projekt bidrar med 33% kapacitet i varje. I verkligheten sänker kontextbyten (context switching) den effektiva kapaciteten drastiskt, ofta ner till 15% per projekt.

Hur kan AI hjälpa till med kapacitetsplanering?
AI kan analysera enorma mängder ofullständig och ostrukturerad data (som kommentarer, loggar och länkningar i Jira) för att hitta dolda mönster och beroenden som traditionella BI-verktyg missar eftersom de kräver felfri manuell inmatning.

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.

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. 

Den osynliga bromsen – hur ineffektiva flöden kostar mer än du tror.

Har du någonsin känt frustrationen över processer som borde gå smidigt men ändå fastnar? Du är inte ensam. Många organisationer kämpar med att hålla sina flöden – oavsett om det gäller IT, produktion eller kundtjänst – i rörelse. Men vad är det som faktiskt stoppar oss, och hur kan vi bryta igenom hindren?

Vad är flöde och varför är det viktigt?

• Flöde innebär, t.ex. ”den smidiga rörelsen av arbete, information eller resurser genom en process”.
• Flöde är avgörande för organisationens framgång:
• Snabbare leveranstider.
• Bättre kundupplevelser.
• Effektiv resursanvändning.

Här är några exempel på vanliga flödeshinder:

• Flaskhalsar: När ett steg i processen inte kan hålla jämna steg med resten.
• Bristande transparens: När data eller information är svår att spåra.
• Överbelastning/WIP: För mycket på gång samtidigt leder till ineffektivitet.
• Silos: Avdelningar som inte kommunicerar eller delar information.
• Manuella processer: Repetitiva och långsamma uppgifter som kunde automatiseras.

Vad leder konsekvenserna av dåligt flöde till?

• Försenade projekt och leveranser: Långsamma processer minskar konkurrenskraften.
• Missnöjda kunder: Långa väntetider eller oförutsägbara leveranser skadar kundupplevelsen.
• Högre kostnader: Ineffektivitet innebär ofta slöseri med resurser.
• Personalens frustration: Ineffektiva flöden skapar stress och minskar arbetsglädjen.
• ”Ineffektivitet”: En allestädes närvarande vetskap om att vi nog skulle kunna vara ännu bättre.

Hur vi hjälper er att förbättra era flöden

1. Identifiera flaskhalsar: Vi analyserar arbetsflöden och hittar de steg där arbetet stannar upp.
2. Automatisera repetitiva processer: Vi ger stöd i användning av teknik för att minska manuellt arbete.
3. Inför WIP-limitar: Vi hjälper er att identifiera och begränsa mängden arbete som hanteras samtidigt.
4. Bryt ner silos: Vi leder er till bättre integration och kommunikation mellan avdelningar.
5. Mät och optimera: Vi lär er använda nyckeltal som Cycle Time, Throughput och Lead Time för att övervaka framsteg.

Att ta första steget

Att skapa smidiga flöden handlar inte bara om att spara tid – det handlar om att frigöra potential, för både medarbetare och organisationen som helhet. Genom att identifiera hinder och ta strategiska beslut kan vi öppna dörren till framgång. Så, vad hindrar dina flöden idag, och vad kan du göra åt det?

Kontakta oss, så hjälper vi dig.

Vill du veta mer om hur du kan förbättra dina flöden innan du tar ett beslut? Lyssna på vårt webinar om effektiva IT-flöden genom att följa denna länk.

Du kan även ladda ner denna checklista för en tydlig bild av de 8 formerna av waste.

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.

Alltså glöm alla protester. Lägg ner de defensiva anklagelserna om ”för mycket byråkrati” och ”det fungerar inte här”. IT Service Management och ITIL är mer relevanta än någonsin för dagens IT. För att klargöra redovisar vi fem snabba skäl till varför:

Ett bibliotek med kunskap och stöd

Sammanfattningsvis  har vi ett ITIL-bibliotek med dokumentation av bästa praxis, kursutbud och stödmetoder som ger hjälp på både en praktisk och mer detaljerad teoretisk nivå. Och ja – det har också varit källan till mycket debatt, många onödiga processdiagram och mycket huvudvärk. (Medan det förra kan och bör förbättras, är det senare att förvänta sig med storskaliga kunskapsramar?) Låt inte detta deprimera dig – ta det i lagom stora bitar och fortsätt. IT i världsklass är inte tänkt att vara lätt, men det är möjligt med konsekvent och medveten ansträngning över tid.

Nu när dagens IT är affärskritisk och surr om digitalisering finns överallt måste vi som arbetar med IT bli ännu tydligare en källa till transformation och förbättring. Det är på många sätt enkelt men inte lätt, och vårt jobb är att ständigt lära oss. Av detta skäl kan och skall ITILs ramverk tjäna som en kunskapskälla, med stöd och relevans för alla moderna IT-verksamheter.

ITIL^® is a registered trade mark of AXELOS Limited. All rights reserved.

Då det (o)lyckligtvis finns en hel del incidenter och problem i vår IT-värld ser vi på Onbird att det idag finns en relativt hög kännedom till Incident Management– och Problem Management-processer.  Och ändå finns såååå mycket utrymme kvar för förbättring.

Ok då, vad är problemet (eller incident)?

Då processerna är så centrala och väsentliga är det förstås viktigt att de fungerar väl.  Får vi snurr på dessa två processer får vi därmed snurr på tjänsteleveransens tillgänglighet.  M.a.o., vi minimerar nertid.

Problemet vi oftast ser är att dessa processer missförstås, får för lite resursfokus och tillämpas felaktigt.  Nedan följer våra fem tips för att maximera effekt av dessa processer i er organisation.

1.  Förstå skillnaden Incident-Problem och bete dig därefter

Incidenter är inte problem och problem är inte incidenter. Incidenter blir inte problem över tid. De blir inte heller problem via eskaleringsmetoder eller annat vis över tid. Ändå vet vi att incidenter och problem har såklart en stark relation som är viktig att både förstå OCH bearbeta parallellt och medvetet.

Återkommande demonstrerar organisationer att de inte förstår skillnaden ovan och då beter de sig fel i hantering. Det är vanligt att man blandar ihop incidenter och problem och godtyckligt väljer hur de skall hanteras. Det innebär ibland att vi tar fram incidenthantering för problem (tänk den frustrationen när teknikern bara lappar ihop med workarounds när användaren söker en fullständig lösning).  Ibland blir det tvärtom, man kör problemhantering för incidenter (igen så frustrerande – användaren behöver en ”quick fix” och teknikern vill borra ner till detaljernas botten).  Denna felaktiga mix i tillämpning gör att det slutliga resultatet blir mindre bra.

”Who cares, låt mig få jobba?!” får jag ofta höra när jag kommit så här långt i dialogen. ”Är det inte bättre att vi bara kommer i gång och löser saken?”

Ja tack, jag älskar angelägenheten. Och min önskan är att vi angeläget tillämpar både Problem- och Incidentprocesserna – parallellt och medvetet – för att maximera våra resultat.

2. Köp mycket silvertejp för Incident Management

Incident Management älskar workarounds (tänk silvertejp ).  Med silvertejp kan vi lösa det mesta snabbt och kortsiktigt. Avseende incidenter är snabbt och kortsiktigt bra – workarounds är BRA. Detta eftersom syftet är att så snabbt som möjligt hjälpa användaren att vara produktiv. Se till att utskriften funkar genom att silvertejpa det till en annan skrivare. Kör ctrl-alt-delete silvertejp för att starta om en klient eller tjänst. Tejpa ihop trasigt data genom att administrera direkt i databasen.

Vår främsta önskan här är att användaren kan vara produktiv – NU! Därmed menar jag att workarounds skall vara en top-of-mind-instinkt när vi arbetar med incidenter. Var kvick, oroa dig inte för grundorsaker och lägg inte för mycket tid på att hitta en perfekt, långsiktig lösning. Ta för all del fram silvertejpen och få i gång din användare.***

3. Dedikera resurser för Problem Management

Välfungerande Incident Management är fantastiskt, men räcker inte.  Vi har alla varit med om frustrationen när workarounds blir för långlivade (permarounds?).  Det kan inte vara meningen?  Vi skall inte leva med en ständig respons av tejpade skrivare, ctrl-alt-deletande och admin-fixar bakom kulisserna.  Således behöver vi OCKSÅ bygga bort dessa fel.

Där kommer Problem Management in i bilden.  I syfte att gå till botten arbetar vi i denna process på ett annat sätt – beteendet är annorlunda.

Tyvärr är det svårt att skapa rätt fokus och rätt mix av dessa två beteenden.  Många organisationer kämpar för att hålla takt med Incident Management och hinner aldrig riktigt med problemlösningar. Ytterligare premierar de att vara ”snabb” med ”mycket på gång” och därmed hinns det inte med de nödvändiga beteendena i Problem Management.

Därför rekommenderar jag separation av dessa processer samt medveten och dedikerad resurs för Problem Management (tänk time-boxing). För att inte slukas av incidentbruset måste vi sätta av explicit tid och resurs för endast problem. Boxa ett antal timmar/personer för Problem Management och ge dem ansvar och rätt att stadigt och envist identifiera grundorsaker och bearbeta problem.

4. Ständig kommunikation mellan Incident och Problem

Då dessa processer har så starka beroenden till varandra är det avgörande att information flödar fritt dem emellan. Följaktligen vill vi säkerställa att maximal medvetenhet om Problemarbete finns i Incident-teamet. Och tvärtom.

Då och då ser jag självständiga Incidentteam som blir lite väl kära i sina workarounds. Silvertejp i all ära, men dessa team lägger ofta för lite tid på samspel med långsiktiga lösningar och problemteamet.

Likaså har vi kaxiga Problemteam som betraktar workarounds som mindre värda. ”Riktiga tekniker går till botten med problemen,” säger de. Varpå de lägger alltför lång tid gömda i sin problemgrotta. Denna grott-tid kanske behövs, men medför samtidigt onödigt mycket incident-downtime och många missnöjda användare.

Låt inte detta uppstå i din organisation. Dela samma ärendehanteringssystem för dessa incidentärenden och problemärenden. Dokumentera lagom med länkar mellan incident- och problemärenden.  Se till att Incidentteamet inte bara stänger incidenter, men också skapar problemärenden när de behövs. Vidare, se till att Problemteamet kommunicerar grundorsaker och tänkbara workarounds till Incidentteamet INNAN de går på den fullständiga lösningen. Inför frekventa ståupp-möten för snabb, muntlig uppdatering mellan teamen och kräv en ständig och öppen kommunikation.

5. Mäta för flöde

När definitioner för distinkta, parallella och medvetna beteenden är aktiverade samt kommunikationen är etablerad skall vi kunna följa och utvärdera vårt arbete genom mätning.  Börja enkelt och hitta ert eget ”lagom” här.

Vanliga mätetal är såklart orienterade mot volym (t.ex. hur många incidenter per vecka?), lösningsgrad (t.ex. hur många problem löser vi per månad?), och tidslängder (t.ex. hur lång genomsnittstid är en incident öppen?). Dessa och många mätetal kan vara intressanta.

Jag har inte för avsikt att lista alla tänkbara mätetal (kontakta mig gärna om du söker input) men att i stället uppmuntra till ett mera generellt syfte med mätning. Oavsett exakta mätetal, se till att ni använder mätning för att demonstrera ett hanterat in- och utflöde av incidenter och problem.  Och vad menar jag med det? Kortfattat behöver vi se till att inflöde inte överstiger utflöde.  Vi behöver hålla takten, dvs lösa ärenden i en takt som gör att vi inte halkar efter. Backloggen av incidenter och problem skall vi hantera så att den inte växer över tid.

Sammanfattning

För att sammanfatta våra fem tips för Incident och Problem Management:

1. Förstå skillnaden och bete dig därefter
2. Köp mycket silvertejp för incidenter
3. Dedikera resurser för Problem Management
4. Ständig kommunikation mellan Incident- och Problem management
5. Mäta för flöde

Kontakta mig och oss på Onbird om vi kan hjälpa till med ytterligare information i detta.

___________________________________________________________________________________________________

OBS – ovanstående förenklar vissa definitioner och syften i viss mån. Det är jag medveten om – min strävan i denna skrift är att enkelt hålla mig till essensen.

*** Tillämpning av workarounds får naturligtvis inte bortse ifrån andra viktiga policybeslut, säkerhetsrutiner, kostnader, andra viktiga beroenden, m.m.  DVS vi ska inte tejpa på ett vilt, farligt eller icke-genomtänkt sätt. 😊 Och om vi har en riktig lösning som är smidig skall vi naturligtvis tillämpa den.

Vad kan vi dra nytta av från Service Management-ramverk såsom ITIL i dessa tider då Agilitet och lättrörlighet står högt på agendan? Finns det viktiga och vanligt förekommande ITIL Processer som alla organisationer, oavsett grad av agilitet, behöver för sin leverans?  Nedan har jag identifierat 5 vanligt förekommande och välanvända ITIL processer som vi tror att alla IT-organisationer behöver ha för att vara effektiva.

Incident Management

Med ITIL Processen Incident management menas den process som organisationer har på plats för att hantera Incidenter, både stora som små. En incident definieras som ”an unplanned interruption to a service or reduction of the quality of the service” som uppstår. Ofta identifieras dessa incidenter antingen genom att användare hör av sig eller något larm/övervakningssystem hör av sig att någon tjänst/applikation/maskin inte längre fungerar som det är tänkt. Målsättningen med processen är att återställa ”normal service operation” så snabbt det bara går. Antingen genom någon form av work-around eller, om det finns, en lättillgänglig permanent lösning.

Varför Incident Management?

Effektiv Incident Management för med sig flera olika positiva effekter såsom:

• Kortare lösningstider i tid till återställning.
• Tydligare verksamhetsorienterad prioritering av vilka Incidenter (störningar) man ska hantera i vilken ordning.
• Bättre synlighet/visualisering över vilka Incidenter (störningar) som pågår och hur dessa hanteras.
• En massa bra data som hjälper oss att identifiera var vi behöver sätta in förbättringsåtgärder (dvs tjänster där vi har många eller omfattande incidenter) såväl som trendstatistik och annat som vi kan lära oss av.

Utmaningar och mätning Incident Management

Vanligt förekommande utmaningar är att Incidenter hanteras i andra verktyg än vad utvecklarna jobbar i (vanligtvis någon form av ärendehanteringssystem). Att utvecklare inte ser koppling mellan ”buggar” och Incidenter fast de egentligen är samma sak. Samt att på grund av hur man organiserat Servicedeskens arbete så använder man inte prioritetsfunktionen på rätt sätt.

Det finns en mängd olika nyckeltal som ofta används inom denna ITIL process och inte alla är bra. Men minst bör man ha koll på hur många man får in löpande. Hur lång tid det tar att lösa Incidenterna. Samt hur många som ligger olösta vid varje givet tillfälle.

Problem Management

Även om ITIL Processen Problem Management är närbesläktad med Incidentprocessen så är den inte samma sak. Med ITIL Processen Problem management menas den process som organisationer har på plats  för att hitta och åtgärda de underliggande tekniska felen som orsakade Incidenter från början. Ett problem definieras alltså som ”a cause, or potential cause, of one or more incidents”. Detta arbete att hitta det underliggande sker inte alltid genom en strukturerad process men är definitivt vanligt förekommande arbete. Målsättningen med processen är alltså i praktiska termer att reducera mängden incidenter över tid och på det sättet skapa ännu mer stabila och tillförlitliga tjänster i produktion.

Varför Problem Management

 Positiva effekter av Problem Management är framför allt:

• Färre incidenter.
• Färre incidenter.
• Stabilare tjänster.
• Färre incidenter.
• Färre gånger som tekniker måste släppa det de jobbar på för att hantera oplanerat arbete.
• Kortare lösningstider av de incidenter som ändå uppstår.

Utmaningar och mätning Problem Management

Med ITIL Processen Problem Management är utmaningen alltför ofta att den inte hanteras strukturerat utan mest reaktivt. Oftast i samband med en större Incident samt ett krav på varför Incidenten uppstod och vad IT-organisationen gör för att den inte ska uppstå igen. Det är heller inte ovanligt att man inte utvärderar effekten eller värdet av Problemprocessen genom att faktiskt mäta nedgången i mängden Incidenter (för övrigt det viktigaste och kanske enda relevanta nyckeltalet för processen).

Proaktiv Problem management vilar också på att det finns bra data att hämta från Incidentprocessen i syfte att hitta trender, svaga områden etc. Tyvärr saknas ofta kvalitativ Incidentdata för detta. Slutligen så hör vi ofta olika organisationer säga”ingen kund är beredd att betala priset för 100% felfria system/tjänster/produkter” . Problemet (pun intended) med det argumentet är två saker. 1. Det finns ingen kund som någonsin fått den kalkylen för det är ingen som vet/faktiskt gjort beräkningen. 2. Det skapar en kultur där vi vänjer oss vid att fel händer och börjar acceptera dem som något helt naturligt och nästan…. korrekt och riktigt?

Service Request Management

Service Request definieras som avrop från användare mot IT-organisationen. Oftast direkt till support-funktionen/servicedesken. Men de kan också gå direkt till systemförvaltare, agila team eller motsvarande. Avropet kan vara sådant som användarbehörigheter, beställning av konto, dator, utrusting, ad-hoc rapport, en fråga eller egentligen vad som helst (förutom Incidenter).  ITIL Processen Service Request Management är alltså den process som IT-organisationer använder för att hantera just ”Service requests”.  Målsättningen med processen är att på ett effektivt sätt hantera och leverera på dessa avrop och därmed möta förväntningar och överenskomna leveranstider.

Varför Service Request Management

Väl hanterad Service Request management skapar flera fördelar för IT-organisationen och dess kunder/användare:

• Kortare ledtider i leveranser till användare.
• Standardiserade och kanske även automatiserade förfaringssätt som ger högre kvalitet.
• Synlighet för användare över progress i ärendehantering/avrop.
• En enkel kommunikationskanal för alla typer av ärenden som inte är störningar (även om vi inte alltid vet vad det är från början).
• Hanterade förväntningar hos användare som därmed ger bättre servicegrad.
• Enklare onboarding av ny IT-personal med hjälp av tydliga riktlinjer för hur leveranser ska hanteras.

Utmaningar och mätning Service Request Management

Den kanske vanligaste utmaningen för just denna process är att den blandas ihop med Incidentprocessen till en enda stor ”supportprocess”. Därmed tydliggörs inte skillnaden mellan att återställa värde (incidenthantering). Respektive tillföra värde (Requesthantering).  På detta sätt riskerar IT-organisationer att prioritera felaktigt, inte hantera kundförväntningar och helt enkelt leverera sämre service. Ett annat problem som vi ofta ser här är också att man inte identifierat och standardiserat sina olika Requests med följden att hanteringen blir både slumpmässig och med dålig kvalitet.

Från Service Request Management processen får vi många bra nyckeltal. Minst bör vi ha koll på:

• Inflödet respektive utflödet.
• Lösningsgrader vid första, andra, tredje kontakt.
• Ledtider för leveranser.
• Fördelning på typer av Requests/avrop (för övrigt ett bra sätt att hitta automationskandidater på).
• Vid varje givet tillfälle, antalet olösta/ej levererade Requests (eller backlog om man vill).

Change Management

Om det finns en process som kan skapa både oro, irritation, glädje och lättnad så är det nog ITIL Processen Change Management. Historiskt har den ofta varit ett rött skynke för agila organisationer på grund av att den uppfattats som ett hinder för agila team och tekniker generellt.  I senaste versionen av processen har den därför anpassats mer till Agile/Devops såväl bytt namn några gånger på vägen. Ska man vara petig så heter den egentligen ”Change Enablement”. Syftet med processen är att ”maximera mängden framgångsrika förändringar i IT-miljön genom att hantera risker, godkänna förändringar och planera dem” så de inte krockar med varandra.

En Change definieras som varje ”addition, modification or removal of anything that could have a direct or indirect effect on services”. Helt enkelt ”vad som helst som vi ändrar i vår IT-miljö och som kan orsaka en incident av något slag”. I praktiska termer betyder det egentligen att även kodförändringar är ”change-ar”. Men oftast hanteras dessa inte som ITIL-change-ar utan som ”utvecklingsärenden, User stories” eller vad vi nu kallar dem. Den vanligaste tillämpningen av Change är sannolikt bara utifrån perspektivet ”kan vi få produktionssätta X-Y-Z. Vilket är bra men missar delar av potentialen i processen.

Varför Change Management (eller enablement som det heter i ITIL 4)

Några positiva effekter man bör kunna se av processen är:

• Tydligare och visualiserad information om vad som ändras i vår tekniska miljö.
• Färre oplanerade Incidenter (vet inte om det finns planerade eller om vi vill ha sådana?).
• Bättre koordinering av arbetet kring Change-ar.
• Snabbare hantering av förändringar (framför allt genom att identifiera och implementera standardförändringar).
• En effektiv hantering av akuta förändringar.

(historiska) Utmaningar Change Management

Som jag nämnde ovan är det inte ovanligt att man endast använder Change-processen för att godkänna produktionssättningar. Historiskt har detta tyvärr ofta varit vad man framför allt velat uppnå med processen. Hindra tekniker från att göra förändringar i miljön med dålig kvalitet som i sin tur resulterar i oönskade Incidenter. Hanteringen har därför ofta gjorts onödigt byråkratisk och väntetiderna på att få sin förändring godkänd blivit oönskat lång. Detta har lett till att många gjort sitt yttersta för att undvika processen. Bland annat genom att helt enkelt inte dokumentera förändringen alls eller endast till ett absolut minimum.  Den positiva bi-effekten är dock att bidra till nya bättre tekniker för sådant som DevOps pipelines och liknande. Något som också ITIL 4 har mycket fokus på bland annat genom sin nya ”practice Deployment Management”.

 Mätning Change Management

När det gäller nyckeltal så finns det lite olika vägar att gå. Många mäter inte alls, vissa mäter antal genomförda change-ar (och med det oftast godkända komponenter för produktionssättning). Medan andra har mer avancerade nyckeltal. Allt hänger på hur man definierar change-ar i organisationen. Om tillämpningen endast utgår från aspekten ”får vi produktionssätta detta…” så blir det mindre relevant att mäta sådant som ”ledtider”. Då ledtiden inte inkluderar allt förarbete.  

Har vi däremot en mer helhetlig bild av processen så kan det vara aktuellt att mäta sådant som:

• Inflöde och utflöde (färdigställt) per period.
• Ledtider.
• Nedlagt arbete (hur omfattande är förändringarna i arbetstid räknat.
• Andel framgångsrika Change-ar (dvs sådana som inte resulterar i oönskade incidenter)

Release Management

ITIL Processen Release management är nära förbunden med changeprocessen. Releaseprocessens syfte är ”to make new and changed services and features available for use”. Man kan alltså säga att change-processen använder sig av releaseprocessen för själva releasehanteringen. Det här kan tyckas lite som överadministration men tanken är att genom en strukturerad process kan vi utveckla bättre metoder, verktyg och tillämpningar. Som också inkluderar sådant som dokumentation, utbildning, handböcker och liknande.

Numer så är det inte ovanligt att agila team själva kan produktionssätta genom sin ”Delivery Pipeline”. Det har också vuxit fram en mängd olika tekniska stödfunktioner för sådant som A-B tester, toggle switching/feature flags och Blue/Green releases. 

ITIL särskiljer också på sina två olika ”practices” Release respektive Deployment Management, där den senare har fokus på själva den tekniska aspekten av att produktionssätta respektive flytta komponenter mellan olika miljöer. Medan Release har fokus på koordinering, planering och kommunikation.

Varför Release Management

En väl fungerande releaseprocess kan förväntas ge följande positiva effekter:

• Över tid enklare och mindre kostsamma produktionssättningar och releaser.
• Bättre koordination av releaser.
• Stabilare mijöer.
• Kortare ledtider.
• Möjligheter till experimentering för att identifiera bästa lösning framåt (A-B tester bla).

Utmaningar och mätning Release Management

Utmaningarna för Releaseprocessen varierar ganska mycket. Mest för att den ser så olika ut beroende på teknik, organisation etc. En historisk ofh dessvärre fortfarande vanlig utmaning är Releasepolicys som uppmanar till långa releaseperioder.  Oftast drivet av en önskan att sänka omkostnader, minska mängden fel tillika belastning på användare av ständiga avbrott. Men, längre tid mellan releaser innebär alltid längre ledtider från idé till realisering.  (Värt att notera här är att ibland har organisationer inget val, det kan vara yttre regulatoriska krav eller annat som är i vägen för en mer frekvent releasehantering).

Releaseprocessen kan mätas på en mängd sätt som kanske inte alltid skapar tydligt värde. Personligen är jag en anhängare av att mäta standardiserings- och automationsgrader av produktionssättningar tillika sådant som:

• Releasefrekvens (trend över tid som helst bör gå uppåt).
• Change fail rate (trend över tid som helst bör gå nedåt).
• Antal Change-ar/förändringar per release (vilket i önskat läge då ska bli färre och färre med tiden).