Hur mäter vi effektiv leverans inom IT?

Går det att mäta effektiv leverans inom IT? I princip alla branscher och yrkesområden mäter på viktiga leveranstal och KPIer. Utgångspunkten är i princip alltid att mäta ”output” på något sätt. Fabriker mäts på hur mycket gods/produkter de producerar, butiker på hur många varor de säljer, transportföretag på hur mycket gods de levererar. Men inom IT är vi inte alltid lika duktiga på just mätning.

Hur gör andra yrkesgrupper

Inom hantverksyrken så mäter man på en massa olika faktorer. Rörmokare (inom servicerabeten) till exempel mäts i första hand på hur många timmar man debiterar, vilket ju inte är olikt konsultbranschen inom IT tex. Skillnaden är dock att en bra service-rörmokare ska debitera 14 timmar om dagen (man räknar tex att serva en läckande kran ska ta max 4 timmar men i praktiken behöver man bara 1-2 om inget oväntat händer).

Hur gör vi inom IT

Inom IT är vi dock inte lika duktiga alla gånger. Gång efter annan träffar jag IT-organisationer där man egentligen saknar relevanta KPI:er för att mäta IT-leveranser och i princip bara mäter på tillgänglighet, budget och i viss mån supportärenden. Vad gäller tillgänglighet mäter man ofta det fel då man mäter tillgänglighet på CPU, I/O, nätverkskort och liknande snarare än det som kunden egentligen bryr sig om vilket är om tjänsten fungerar. Dvs om alla komponenter tillsammans fungerar som de ska så att kunden kan utföra sina affärsprocesser). Här är några av konsekvenserna av att inte mäta (alls eller på relevanta mätetal):

• (IT)Personal får inte en möjlighet att bedöma om de gör ett bra jobb, åtminstone inte ett faktabaserat sådant.
• Vi kan inte kontrollera/validera om vi möter kundkrav eller inte.
• Vi lyckas inte undvika åsiktsbingo eller hypotesrouletten. (NI vet den där situationen när en mängd olika förklaringar fram till varför något inte kan göras utan att det är baserat på något annat än en känsla eller ogrundat påstående).
• Vi kan inte se om vi utvecklas, står kvar eller försämras i vår förmåga att leverera till kund.
• De problem vi har i våra leveranser blir inte synliga och vi blir därmed upptagna med att försöka åtgärda problem som inte finns. Ofta med resultatet att saker blir värre.

Vad ska man mäta

Vi betraktar IT-organisationer i huvudsak som en slags fabrik. Det kanske inte låter så sexigt men vad det handlar om är att IT-organisationer tar gods varor och tjänster, förädlar dessa och skickar sedan vidare till kund. Förädlingsprocessen är vad fabriken är upptagen med. För att då effektivt kunna mäta sin IT-leverans så måste man känna till vilka förädlingsprocesser vi har. Här är några typiska:

• Ny funktion (tex User Story, RFC eller liknande), antingen som egen entitet eller som en del av en release.
• Rådgivning, förstudie eller analys/utforskning.
• Service Requests (fråga eller beställning från användare)
• Ny/utökad kapacitet
• Daglig rutinaktivitet typ kolla loggar, körningar etc. (Den här vill vi visserligen oftast minimera).
• Incidenter (dem vill vi definitivt minimera)
• Projekt (även om de egentligen kan betraktas som en större RFC).

Sen kan man självklart dela upp dessa i undergrupper. Service requests kan tex ha ”kontohantering”. User story/RFC kan ha ”new feature/update existing feature/delete feature”.

Det viktiga är att varje leverans som vi mäter skall utifrån kundens perspektiv betraktas som värdeskapande. För att mäta dessa leveranser kan vi ha nytta av ett ärendehanteringssystem av något slag men det kan lika gärna vara en excel-lista, verktyg som stöder (eller inte stöder) kanbanfunktionalitet, post-itlappar på väggen etc. Vilken metod man använder är inte så viktig. Att man använder en metod och att man är lojal mot denna metod för att kunna få ut relevant fakta och därmed lyfta diskussionen till högre höjder snarare än hypotesdueller och åsiktsbingo, det är vad som är viktigt.

Tips för mätning

Nedan har vi samlat några tips som vi tycker är bra när man vill börja mäta sin IT-leverans och identifiera relevanta KPI inom IT:

• Börja enkelt och utveckla allteftersom
• Mät det som är av värde för kunden/mottagaren av det som avdelningen gör
• Bara för att du kan mäta det så är det inte nödvändigtvis viktigt att veta
• Mät inte för att dölja brister, mät för att visa var kundupplevelsen blir negativ (love the problem)

Nästan alla avdelningar kan och bör mäta på följande grund-KPIer:

• Antal “ärenden/jobb” in (nya) och antal motsvarande ut (stängda/levererade)
• Antal “ärenden/jobb” ännu inte levererade (ibland refererat till som Backlog men inte samma sak som en Sprint Backlog från Agile/Scrum
• Ledtid för leveranser (dvs från in till ut) i genomsnitt och median.
• Leveranskapacitet (över tid) i personalresurser. Dock inte antalet anställda utan hur mycket tid som finns för personalen att lägga på leveranser.
• Fördelning planerat och oplanerat arbete (den här är lite spännande och är ofta helt okänd) 

Vad säger de olika ramverken om mätning

 Inom de olika ramverken som finns inom IT idag finns det en mängd olika föreslagna och diskuterade mätetal och KPIer. Det är dock ett ämne som blir mer än vad som får plats här så jag nöjer mig med att notera de 5 viktigaste DevOps-KPIerna:

1 – Change Failure Rate (Incidents/change)
2 – MTTR (Mean time to restore)
3 – Frequency of Change (number of deploys)
4 – Change Lead time (Time from Reqs to Deploy)
5 – PCE (Process Cycle Efficiency)