A few years ago, I had the pleasure of managing a UK-wide field service operation with around 100 engineers and some sub-contractors providing IT hardware break-fix services to corporate customers. Typical engineering activities would range from replacing a failed monitor, through to restoring the service of a failed network server or router. The work was all reactive, with response times, fix times, and first-time completion rates being primary success factors.
Daily measurements of the service operation were holistic – not just focusing on engineer utilization but also on productivity (how many jobs completed per day), efficiency (time taken to restore versus the norm), first-time completion, parts per event, and the number of visits per event. This way, monitoring how the performance of one measurement affects the others is transparent.
What was interesting to note was how the engineers’ workloads directly affected the total service quality. It’s easy to imagine that engineers with an excessively high utilization may generate a deterioration – too many jobs, engineers rushing to get through the workload, more parts used than necessary to save time but increasing costs instead of accurate diagnostics – and this is visible through the metrics. For example, high utilization (busy engineers), high productivity (busy engineers), low efficiency (not fixing the fault), increased parts per event (replace everything to get the customer restored instead of diagnosing the cause), reduced first time fix rate (engineers rushing to get through the workload and not resolving the fault correctly), and an associated downturn in customer satisfaction. The engineers are not coping with the high workload.
There’s probably no surprises there so the aim is to try and plan the number of engineers, their availability, and geographic dispersal so that a reliable, regular, and good level of service is delivered.
That’s easier said than done. Now consider this, you have planned for a certain volume of work (remember, it’s all reactive work so forecast accuracy is another challenge that’s thrown in here) but today you have enough work for just half of the engineers. So there’s low utilization, the engineers have time to operate without the pressures of being overloaded. But the same thing happens – service quality suffers because now the engineers can take too much time to resolve a simple fault, there’s no adrenalin to ‘get it done’ and move on to the next job: “I only have one more job today, so what’s the rush”? The engineers are coping too easily with the low workload – are they becoming lazy?
So how do we manage this? Too-high and too-low utilization can both harm service quality – there’s a happy and efficient medium to be found. But where and how? Let’s discuss...
Author: Stewart Hill
Tuesday, August 12, 2008
Subscribe to:
Post Comments (Atom)




2 comments:
What would happen if we threw monetary reward into the equation; performance payment based not only on the quantity of work performed but also quality of work? Would this complicate the issue more? Less?
A possible solution is to have a workforce that is on performance (quantity and quality) based payment. Simply doing more work will not ensure that the technicians will be paid more... they need to temper this with the quality of work to perform. Hence, the onus is on the technician to perform a high number of quality jobs each and every day.
As with most things, there is no simply answer to the above. There are too many variables that need to be taken into consideration. Additionally, something that works in one company/region might not work in another company/region.
This is an interesting suggestion and certainly one that merits some attention. As George has rightly stated, there is no simple answer and the management of this situation will vary by organization due to culture, processes, ethics, working practices, geography, union influence, etc – a multitude of factors are involved.
But let’s look specifically at the monetary aspect of George’s suggestion. In my mind, and from my experience, this only stands to make the situation worse and an increasing management headache.
Firstly, there is the need to implement an indisputable quality measurement system – this may be simple (for example, is the customer’s problem resolved or not?) or it could be far more complex and intangible by measuring the end-to-end customer experience however ‘quality’ is not just an indication of the field engineer because it is reflective of the entire experience. So, a customer is unhappy that their product has failed, the assistant on the help desk wasn’t able to help much other than to schedule a field visit, and they weren’t very friendly thereby leaving the customer dissatisfied from the outset. Despite the best efforts from the field engineer, the replacement part that he has received from the Parts Warehouse is DOA (Dead on Arrival) thus requiring the engineer to return in a few days time. By the time the customer is fixed they feel bitter and this is reflected in the customer satisfaction questionnaire that was left with them to complete (I mean, who fills out a satisfaction survey much because you’re happy? More often, it’s used as a way to vent your frustrations). I am sure that the field engineer wouldn’t be too impressed with this affecting his monetary reward therefore the ‘quality’ aspect needs to be precise.
Secondly, and more importantly, paying field engineers in accordance with their utilization (in terms of jobs-per-day or time utilized – depending on what method suits the service organization) is dangerous from an operational efficiency perspective. Let me explain why.
As individual payments are influenced by how much work an engineer is attending to, this requires the allocation of work to be equal and fair – workload balancing. Today’s service management markets are readily promoting ‘efficiency’, ‘optimization’, and ‘increased productivity’ (which in itself should be a factor of quality and quantity, but that’s a subject for another day) so balancing workload can have the opposite effect and increase travel while reducing productivity. This happens because field engineers may be sent longer travel distances just to balance the workload thereby ignoring the fact that the most efficient decision is to send the closest skilled engineer. As a result of the movement of field engineers’ greater distances, they then tend to be in the wrong place when a service call appears in an area that is placed within their original proximity. So what happens? We send someone else back the other way because the engineer who was there originally is now busy miles away - engineer paths are crossing, travel is rising, carbon emissions are rising, operational costs are rising, and there can be a negative impact on customer satisfaction because the engineers have moved away thus increasing response times. But the engineers are happy as the monetary aspect is fair!
So in short – introducing monetary payments is often a good idea for morale and fairness if balanced appropriately. From a service efficiency perspective, this is fraught with immense challenges so tread very carefully!
Post a Comment