Vårt mätsystem Torgny Göransson 2012-05-08
ICA i korthet ICA AB Per Strömberg Koncernchef / VD Sonat Burman Olsson vvd & CFO Mats Holgerson Chief Operating Officer ICA Sverige Anders Svensson VD ICA Norge Thorbjørn Theie VD Rimi Baltic Edgar Sesemann VD ICA Banken Jörgen Wennberg VD ICA Fastigheter Lena Boberg VD ICA Special Björn Abild VD HR Group/ ICA School Åsa Gabriel Direktör HR & ICA Skolan Omsättning MSEK 100 000 80 000 60 000 40 000 20 000 0 07 08 09 10 11 Region Antal butiker 30 september 2011 Sverige 1 335 Norge 554 Estland 82 Lettland 110 Litauen 46 TOTAL 2 127
Innehåll Vad är mätsystemet Hur vi identifierar och beskriver mätningar Sex olika exempel på hur vi analyserar och förbättrar baserat på mätresultaten
Vad är mätsystemet?
Mätsystemet grundar sig på ett helhetsperspektiv på vår verksamhet Intressenter: Kund Ägare Medarbetare Ägare Krav Nöjd ägare Ledning Kund Krav Enhet A Enhet B Enhet C Nöjd kund Medarbetarna Nöjda medarbetare
Mätsystemet innefattar alla intressenterna och säkerställer ett helhetsperspektiv Ledning SLA-mätningar, per tjänst Process- & leverantörsmätningar, per process Kundnöjdhetsmätningar, per kund Finansiella mätningar, per linjeenhet Mål, Rapport teringsnivåer Uppföljning Medarbetarmätningar, per linjeenhet Syfte, Definitioner, Avgränsningar, Beräkningsregler Mätspecifikation
Hur identifierar vi mätningarna? Genomförd av Eva-Lena Lettesjö, Leif Carlström och Torgny Göransson 21 februari 2011 = mätningar vi implementerar = mätningar med lägre prioritet = mätningar som redan är implementerade Matrisdiagram med processkrav och processmätningar och deras samband: Processkrav Vikt Processmätning Syfte: - att sänka antalet incidenter - bidra till stabila driftsmiljöer Antal olovliga change (processavvikelser) incidenter orsakade av change CAB-möten, återremitterad Antal change per e change kategori Tid att skapa changeärende % framgångsrika change Alla ska följa processen 5 H M H M Alla change ska registreras 5 H L M Loggning av ärenden ska vara enkel 3 L H M Framförhållning av change - registrering ska ske i god tid (4 veckor) 5 M Rätt kompetens för att ta beslut på CDB 5 L Följa upp och dra lärdom av genomförda change (PIR) 5 Processen har mallar och rutiner som är anpassade utifrån produkternas behov (change-inventering) 3 H L Change-koordinatorn och granskaren ska vara klar över sin roll och sitt ansvar 5 L M L M Säkerställa att relevant dokumentation är tillgänglig och uppdaterad i samband med change 5 Stabila driftsmiljöer 5 H H Effekt 93 59 105 55 72 30 Genomförbarhet H H H
Mätspecifikationen Inledning Mätningens namn Syfte, Användningsområde Målgrupp Definition Definition enligt SLA eller annan formellt överenskommen specifikation Fördelning av changeärenden Syfte: Att förstå hur vi arbetar i changeprocessen. Exempel: - hur många change vi hanterar ger underlag för resursplanering (change category) - att vi tillämpar vi processen som tänkt och använder "urgent" på rätt sätt (change priority) - att vi är bra på planering och genomförande av change (change status) Användningsområde: - Processmätning IT Services ledning. ODM och förvaltningsledare för att förmedla till kund Definitionen av kategorier, prioritet och status finns i Change Managements processdefinitioner. Change som påbörjats (SC: actual start) under mätperioden ingår. Framgångsrik change = change med status 1 och 2 Misslyckad change = change med status 3 Tillbakarullad change = change med status 4 Förtydlingar av definitionen Inställd change = change med status 5 I uträkningen av framgångsrika change ingår endast stängda change. Söksträng: actual.start>'yy/mm/dd hh:mm:ss' & actual.start<'yy/mm/dd hh:mm:ss' För att en change ska prioriteras som brådskande måste den vara av kategorin Major eller Medium. Brådskande change definieras som oplanerad. Måttenheter Ärenden, % Beräkning % Framgångsrika change = framgångsrika change / totalt antal stängda change % brådskande change = brådskande / totalt antal registrerade change med kategori Major eller Medium Totalt antal genomförda change = Totalt antal stängda change - Inställda change Avgränsningar N/A Avrundningsregler +- 0,1% Process Var hämtas mätdata? Service Manager - Changemodulen. Exporteras ut till excel. Mätfrekvens Service Manager uppdateras dagligen Rapportering Antal per kategori, totalt registrerade samt % framgångsrika change Antal per prioritet Rapportering Antal per status (completion code), totalt genomförda samt % brådskande change Särredovisning sker också för brådskande change Bank - IT Services KPI processer. Sökväg: I:\Solna\IT\Group IT\0 - Ledningssystem Group IT\4 - Mätningar\Mätresultat Publicering, var och vem - SAC Processes månadsrapport - Leveransrapporter till kund Periodicitet Månatlig Mätningens ägare Ansvarig för mätspecifikationen Eva-Lena Lettesjö Godkänd datum 2011-10-05
Hur vi analyserar och förbättrar baserat på mätresultaten
Exempel 1 Normal linjestyrning
Exempel på mätningar där vi driver förbättringsarbete antal öppna incidenter incidenter orsakade av change brådskande change incidentlösningstid antal öppna problemärenden infrastruktur utan relation i CMDB granskningsanmärkningar per projekt applikationer som når/ej når tillgänglighetsmål ärenden lösta vid första kontakt, svarstid i växel och helpdesk kundnöjdhet med systemförvaltningen tjänster som ska ha, respektive har giltiga SLA
Exempel 2 De häftiga kasten i resultaten i incidentprocessen
Ett inte ovanligt sätt att analysera trender Har vi en positiv trend sedan juli när det gäller att lösa incidenter i tid? Diagrammet ovan ger en vink om att så kanske är fallet. Processledaren kunde inte identifiera orsaker till de kraftiga kasten i lösningsgraden. Vi har en kultur där man i hög grad inskränker analysen till data som rör den senaste kalendermånaden.
Varför blir det så? Vänstra diagrammet: Vi övertolkar konsekvent utfallet. Man kan t.ex. inte påstå att vi var sämre i maj än i april utifrån dessa resultat. Högra diagrammet åskådliggör slumpens inverkan på vårt resultat och hur variationen påverkas av antal incidenter. I princip kan resultatet variera från drygt 50 till nästan 90% utan att peka på någon uppseendeväckande förändring i processen. Verkliga trendförändringar blir svåra att se.
Sannolikhetsfördelningar som kan vara av intresse för våra fokuserade processer Process Önskad analys Sannolikhetsfördelning Alla Sannolikhetsfördelningen för väntetider mellan Exponentialfördelningen processteg Incident Sannolikhetsfördelningen för lösningstider Lognormalfördelningen Sannolikheten att en incident är löst i tid Binomialfördelningen Problem Sannolikheten för n antal incidenter, antal stopp Poissonfördelningen Sannolikhetsfördelningen för tider mellan incidenters Exponentialfördelningen inträffande Change Handover Sannolikheten att ett problemärende är hanterat i tid Sannolikheten för antal incidenter orsakade av change, även sannolikheten att en change ska orsaka n incidenter Sannolikheten att en change ska orsaka incident (ja/nej) Sannolikheten att begäran om en change avvisas Sannolikheten att en granskningspunkt ska ge en granskningsanmärkning Sannolikheten att ett granskningsmöte ska ge n granskningsanmärkningar Grön text = Dessa har vi börjat analysera regelbundet Binomialfördelningen Poissonfördelningen Binomialfördelningen Binomialfördelningen Binomialfördelningen Poissonfördelningen
Vi har börjat analysera trenderna på ett nytt sätt Vi plottar ut månadens incidenter. De som ligger över ett kontrollvärde (>10 timmar) ska analyseras i detalj för att vi ska förstå vad som orsakar lösningstider Kontrollvärdet är baserat på en modell (se diagram nedan) där sannolikheten att hamna över denna gräns är 3,5%. Vi studerar utfallet över längre perioder än en månad. Om utfallet avviker mot den sannolikhetsfunktionen kan det indikera att enskilda incidenter avvikit från den normala processen. I exemplet är det incidenterna med extrema lösningstider som orsakar detta. Men det finns även andra exempel.
Exempel 3 När vi får färre incidenter kommer den genomsnittliga lösningstiden att öka
Exempel på nytt sätt att analysera trender - utdrag ur analysen efter november Jan-Juni Juli-Nov Antal 0-1,5h 78 29 Antal >1,5h 32 28 Studerar vi större datamängder än enskilda månader får vi en tydligare indikation. Lösningsgraden jan-juni är 75% lösta inom 2h och för juli-nov 61%. I exemplet ser vi att vi har en trend mot minskad lösningsgrad sedan juli Vi har alltså en ny situation sedan juli där vi har lika många incidenter som tar > 1,5h att lösa som tidigare medan vi mer än halverat antalet incidenter som tar 0-1,5h att lösa. De som är kvar kräver längre lösningstid.
Exempel 4 Trend för prio 2-incidenter liknar den för prio 1
Trenden För de stängda användarrapporterade prio 2-incidenterna har vi jämfört två tidsperioder: januari-mars 2012, antal: 170, varav 106 lösts inom en timme Juli-december 2011, antal 330, varav 147 lösts inom 1 timme Diagrammet nedan visar att en påtagligt större andel löses snabbt. Skillnaden mellan mätperioderna är som störst kring 1 timmes lösningstid, sedan konvergerar mätserierna och vid 8 timmars lösningstid ser vi inte längre någon effekt. Varför? Vad består förändringen av? Kan det bero på slumpen? Sannolikheten att få utfallet 106 eller fler lösta inom en timme i jan-mars 2012 baserat på utfallet vi hade juli-december 2011 är 2,3 på miljonen. Det är en statistiskt säkerställd förändring i processen. Mätfönster för prio 2-incidenter är 8-17 mån-fre. Övriga tider står klockan stilla
Trenden I diagrammet nedan visas hur andelen lösta incidenter av samtliga fördelar sig för varje timme. januari-mars 2012 har 62% lösts inom en timme Juli-december 2011 har 45% lösts inom en timme Två hypoteser (som vi kunnat verifiera): Vi löser incidenter utanför mätfönstret (8-17 måndag till fredag) i högre grad Vi påbörjar lösningsarbetet tidigare
Hur påverkar detta totalresultaten? Lösningsgraden uttrycker hur stor andel av ärendena som löses inom överenskommen SLA-tid. Den tiden är 8 timmar för prio 2-incidenter. Den genomsnittliga lösningstiden sjunker över hela linjen. Lösningsgraden förblir däremot opåverkad. Det här belyser också att det är intressantare att analysera incidentprocessen utifrån lösningstid än lösningsgrad. Målet för genomsnittlig lösningstid för prio 2-incidenter är 5 timmar. Målet för lösningsgraden är 85% Organisation Mv lösningstid juli-dec 2011 Antal inom parentes Mv lösningstid jan-mars 2012 Antal inom parentes Lösningsgrad juli-dec 2011 Applications 2,79 h (109) 2,47 h (61) 88% 89% Operations 4,37 h (172) 3,40 h (82) 87% 88% Group IT 4,20 h (330) 3,58 h (170) 86% 87% Lösningsgrad jan-mars 2012
Exempel 5 Vi har fler logistikincidenter än tidigare
Har antalet logistikincidenter ökat i år? Fyra incidenter under en och samma vecka upplevs av kunden som en kraftig kvalitetsförsämring. Internt kommuniceras även detta på så vis. Analys med hjälp av poissonfördelningen Att vi får fyra eller fler incidenter är inte osannolikt med nuvarande prestationsnivå. I mätserien har vi 1,09 incidenter/vecka. Sannolikheten att få 4 eller fler incidenter är 2,5%. Vill vi att den ska minska till osannolikt t.ex. <0,2%, måste antalet incidenter minska till under 0,52/vecka. My=1,088, Sigma=1,043 Det kräver alltså mer än en halvering av antalet prio 1-incidenter inom logistik.
Exempel 6 Korridorsnack
Exempel på sambandsdiagram En synpunkt som emellanåt framförs är att vår lösningsgrad, dvs vår förmåga att lösa incidenter inom överenskommen tid, påverkas av antalet incidenter. T.ex vi löste färre incidenter i tid under maj eftersom vi hade så ovanligt många allvarliga incidenter Diagrammen ovan visar sambandet mellan antalet användarrapporterade koncernincidenter, och lösningsgraden för varje månad från oktober 2009 till maj 2011. Det stöder inte synpunkten varken när vi betraktar samtliga incidenter (i praktiken prio 3 som utgör den största volymen) eller enbart prio 1-incidenternas påverkan på lösningsgraden för samtliga incidenter.