"Att Göra" kontra "Att Uppnå"

"Do" not, "achieve" you must.

Boda - Yoda's far distant second cousins brother (pinkie promise)

Team, i allt annat än statiska eller långsamt föränderliga marknader, arbetar idag i komplexa miljöer. Konkurenter, tecknologi, och kunder kan alla snabbt förändras. Men trotts detta så fokuserar vi allt för ofta på vad team skall “göra” istället för vad de skall “uppnå”.

När vi har en maskin så är det lätt att mäta dess “prestanda”. Antal producerade enheter per tidsperiod är ett exempel. Går detta nummer upp så är maskinen mer effektiv. Men människor är inte maskiner. Trots detta så mäter vi ofta dess effektivitet som om de vore det.

  • Telefonsamtal per timme
  • Antal stängda ärenden per timme
  • Mängden ny funktionalitet som levereras
  • Mängden enheter producerade
  • och så vidare

Även om alla dessa mätetal kan sägas mäta “prestanda” så säger de inget, eller väldigt lite, om vad vi “uppnått”. Vilket värde, om något, har vi skapat?

KPI:er och vanliga misstag med dem

När någon kommer in i rummet och presenterar ett nytt KPI (Key Performance Indicator) som vi skall börja mäta så brukar jag bli lite reserverad. Inte för att KPI:er inte kan vara värdefulla utan för att vi ofta begår misstag med dem. Det första är att vi ofta misslyckas med att kommunicera och introducera dem. Flertalet gånger har bevittnat en introduktion av ett KPI som gått till på följande sätt: 

-“Vi skall börja mäta antalet ärenden per agent”. Japp, det är allt… bara det och sedan lämnar de rummet.

Varför anser jag att detta är ett dålig… nej, uselt sätt, att introducera ett KPI? Till att börja med så förklarar det ingenting om “varför”.

En vanlig reaktion när människor inte får någon förklaring är att de försöker komma på en. Givet den uppenbara brist på transparens som finns i ovan nämnda KPI så kan agenterna ifråga börja tänka saker som:

  • “Litar de inte på oss?”
  • “Tror de inte att vi verkligen jobbar hela dagen?”
  • “Vill de få reda på vem som har minst antal ärenden? Varför? Skall de göra sig av med en av oss?”

Alla dessa kan vara legitima skäl bakom KPI:et. Hur ska de kunna veta, de fick ju ingen förklaring. Men KPI:et kan också vara ett resultat av en önskan att se till att en liten delmängd individer inte är överbelastade med arbete, eftersom man verkligen bryr oss om dem. Kanske vill man identifiera kunskapsluckor och tillhandahålla kunskapsdelning. Poängen är att mottagarna av ett dåligt kommunicerad KPI inte har något sätt att veta.

Så när man introducerar ett KPI så skall man vara tydlig med att förklara varför vi gör det. Förklara vad det kommer hjälpa oss att identifiera och vad vår plan är för att hantera det om KPI:et skulle signalera ett problem.

Den andra anledningen till mina reservationer brukar vara det faktum att vi ofta missbrukar eller missförstår de KPI:er vi mäter. Innan vi introducerar ett KPI måste vi som skapare av det förstå vad det är och vad det inte är. Om vi mäter antalet nya funktioner som levereras och misstar det för att nöjdhet hos kunder så riskerar vi att basera beslut på felaktiga data. Istället är de flesta KPI:er ett mått på effektiviteten av en process i ett ofta mycket komplicerat nätverk av beroende processer. Det är inte vad den vi faktiskt “uppnådde”. Så ett KPI i sig ger sällan en fullständig bild.

Om vi mäter “antal ärenden per agent” men inte mäter saker som

  • vilken typ av ärenden det är
  • hur många individer som var involverade i att lösa dem
  • hur lång tid det tar att lösa ärenden och hur mycket av denna tid som är bortom agentens kontroll

så kan du mycket enkelt komma att tro att den agent som egentligen levererar mest “värde” till dina kunder är den sämsta i ditt team.

Så innan du använder ett KPI skall du säkerställa att du

  • förstår vad det är du mäter
  • förstår vad numret faktiskt visar dig
  • förstår att KPI:er ofta driver beteenden i ditt team, något som ofta förbises och är oönskat. Du mäter  “antal ärenden per agent”, anser du att dålig kundsupport för att snabbt stänga ärenden är en bra sak?
  • förstå vad dina KPI INTE visar dig
  • kan förklara all detta för andra

När allt detta är på plats och förklarat är det viktigt att inte fokus på det faktum att KPI:er (oftast) visar dig med vilken “prestanda” något som “gjordes”. Det säger dig ofta ingenting om vad som “uppnåddes”.

Om du istället bryr dig om vad vi “uppnår” och inte bara vad vi “gör” så behöver vi tänka annorlunda.

KPI:er med ett annat fokus

Så om vi istället vill titta på effekterna av det arbete vi gör och se vad teamet “uppnått”, vilken typ av mätningar kan vi då använda? Exempel kan vara

  • Kundnöjdhet
  • Dagliga aktiva användare
  • Antal support ärenden per 100 kunder

-“Vänta, va? Har vi inte precis klargjort att antalet support ärenden var ett dåligt mätetal?”

Skillnaden kan verka subtil men i verkligheten är den enorm. I det första exemplet mätte vi antalet ärenden agenten stängde per dag, agenternas prestanda kring att stänga ärenden. Detta KPI kan förbättras genom faktiska positiva åtgärder men det kan också förbättras genom att en agent “stressar och arbetar övertid”, “skapar ärenden i systemet för snabba och enkla saker som agenterna vanligtvis bara fixar” eller i värsta fall “ger sämre kundservice för att stänga ärenden snabbare “. Ingenting i KPI:et självt fokuserar på att vi uppnår någon form av positiv påverkan för kunden som leder till att de blir glada återkommande kunder hos oss.

I det andra fallet mäter vi istället hur många användare som behöver support. För att detta KPI ska bli framgångsrik vill vi att den ska röra sig nedåt. Detta gör det möjligt för oss att se till att vårt arbete uppnår resultat genom att färre kunder behöver support. För att nå detta mål kan vi fokusera på saker som att rensa upp teknisk skuld, effektivisera installationsprocessen, implementera ett fantastiskt FAQ-system eller så kan vi arbeta med andra avdelningar för att se till att hela processen från försäljning till installation är sammanhängande och smidig. Den tid som sparas av att färre människor behöver kontakta support kan sedan användas för att ge de kunder som fortfarande behöver uppsöka support en ännu bättre upplevelse.

“Agile Leadership Toolkit” i “Professional Scrum Series” använder uttrycket KVI:er (Key Value Indicator). Du kan skapa KPI: er som inkapslar exakt samma sak. Men vad KVI gör är att visa ett ändrat fokus som blir en integrerad del av KVI:et. Från att fokusera på vad vi “gör” till att fokusera på vad vi “uppnår”. Av den simpla ser jag ett värde för de olika namnen. Ett KPI kan skapas för att fokusera på kundens inverkan och värde för företaget, eller inte, och ändå vara ett KPI. Men ett KVI kan aldrig INTE fokusera på detta och fortfarande vara ett KVI.

3 steg mot ditt första KVI

Steg 1:

Skapa en tydlig kundeffekt

Hur drar kunden nytta av detta? Lindrar vi en existerande smärta eller ger vi dem något nytt?

Exempel: Genom att inte behöva kontakta support lika mycket så sparar de tid och frustration. De kunder som fortfarande behöver kontakta support kommer att hälsas av agenter med mer tid och energi för att lösa deras ärenden.

Steg 2:

Visualisera hur detta skapar värde för företaget

Hur skapar kundeffekten pengar för företaget?

Exempel: Mer tid för att fokusera på de svåra ärendena gör att vi kan skapa nöjdare kunder som kan agera ambassadörer för vårt företag och generera fler affärer.

Steg 3:

Välj ett mått som mäter värde

Med kundeffekten och företagets värde identifierade kan vi skapa vårt KVI. Denna process är ofta iterativ och med input från olika medlemmar kan flera KVI:er testas över tid för att göra KVI:et bättre och bättre.

Skapa tillsammans

För att ett team ska känna ägarskap bör de vara en del av att identifiera och skapa KVI:et. Om ett team känner till och står bakom ett KVI av “Antal dagliga supportärendena per 100 kunder” kommer de att ha detta i bakhuvudet när de bygger lösningar. De kommer att göra allt de kan för att se till att deras nya lösningar inte påverkar teamets KVI negativt.

För att säkerställa att ni skapar inspirerande KVI:er för teamet kan ni använda 5xI’s (de de fem i:en)

  • Influence. Teamet kan påverka mätetalet.
  • Insight. Mätetalet är påtagligt och visuellt. Teammedlemmar kan uppdatera mätetalet själva och är angelägna om att följa de senaste siffrorna.
  • Ideas. Mätetalet är inspirerande och för idéer att flöda.
  • Intent. Tanken bakom mätetalet är tydligt. Teamets medlemmar kan förklara syftet bakom det.
  • Impact. Mätetalet fokuserar på kunden.

Helt plötsligt har vi börjat mäta vad ett team faktiskt “uppnår” i stället för vad de “gör”. Allt medan vi tillfört mer värde till våra kunder och mer syfte för våra team..

Kommentarer

Dela i ditt aktivitets flöde

Powered by WP LinkPress

Kommentarer

Dela i ditt aktivitets flöde

Powered by WP LinkPress