Als zelfs korte klussen maar niet af komen... 

 De service organisatie van een fabrikant van telefoon centrales had een probleem! Er waren afspraken gemaakt met de belangrijkste klant over het tijdig oplossen van klachten. Voor urgente klachten maximaal een dag. Voor belangrijke klachten had men een week oplostijd. Andere klachten mochten langer. Elke klacht die op tijd werd opgelost betekende een bonus. 
 
Echter, het kwam zelden voor dat deze termijnen gehaald werden. Toen ik erbij getrokken werd was er een forse achterstand. Er was al veel onderzoek gedaan en data verzameld. Het kostte me dan ook enige tijd voor ik, enigzins intuitief, de kernvraag wist te formuleren: “Hoeveel echte hands-on tijd gaat er nu zitten in het oplossen van een gemiddeld probleem?” Het antwoord gaf reden tot nadenken, voor het oplossen van een klacht had men normaliter een paar uur tot maximaal een dag werk nodig.
 
Maar hoe kwam het dan dat er gemiddeld weken nodig waren om een probleem op te lossen? Fascinerend. Een hoge discrepantie tussen de hands-on tijd en de doorlooptijd, dat wees op veel onderhanden werk. Dus de volgende vraag was aan hoeveel klachten een engineer gemiddeld werkte? Het antwoord: tussen de 50 en 100.
 
Het patroon was nu duidelijk. Maar er moest nog een vraag beantwoordt worden, waarom waren er dan zoveel klachten in voortgang? Na enig doorvragen bleek er een afspraak met de klant te zijn dat er onmiddellijk met een klacht zou worden begonnen. Een van de centrale KPI’s voor de engineers was hoe snel men aan een probleem begon te werken zodra dat werd toegewezen.
 
Wat ik zag was niet revolutionair, er was teveel onderhanden werk, er was een sterke beloning om al het werk zo snel mogelijk te beginnen, er waren geen goede prioriteiten en dus duurde het een maand om een urgente klacht af te ronden waarvoor slechts een paar uur effectieve werktijd nodig was. Die klacht lag 99% van de tijd te wachten op beschikbaarheid van een engineer!
 
Mijn aanbeveling was niet eenvoudig uit te voeren en ook niet zonder risico: zorg dat elke engineer slechts aan een beperkt aantal actieve problemen werkt. Maar dat er daarmee wel veel meer problemen opgelost zouden worden: Meer met Minder! Maar hoe konden we dat doen zonder het risico te lopen dat nieuwe klachten (af en toe, even) zouden moeten wachten op beschikbaarheid van een engineer?
 
Na veel wikken en wegen werd er besloten om het team te splitsen in een 'front-end' en een 'back-end' team. Het front-end team zou elke nieuwe klacht zo snel mogelijk opstarten, een eerste snelle analyse maken en daarna aan een engineer van het back-end team toewijzen. De engineers van het back-end team werkten maar aan een beperkt aantal klachten, 5 stuks maximaal, met een duidelijke prioriteit gebaseerd op de tijd die er nog beschikbaar was om de deadline te halen. De score ging eenvoudig naar bijna 100%, zonder dat de klant ooit doorhad dat er niet aan alle klachten actief werd gewerkt.

 

Alle blog berichten