What’s better than a KPI number?
Author: Israel Beniaminy
Imagine the following scenario, in which you manage a field service operation. And since we’re imagining it, let’s go ahead and make it a nice scenario, so let’s get right to it.
Congratulations: You’ve just unwrapped your new and shiny analytics solution, and you already have some KPI numbers: Key Performance Indicators that you can use to assess the performance of your operation.
And even more congratulations: The numbers look good. Specifically, one of your KPIs is the number of tasks performed per day per field service engineer (FSE). You set yourself a target of 5.5 for this KPI, and the numbers show your operation really hums, hitting the value of 6.1.
You have every reason to be proud. It’s not just that the numbers are good, and I’m sure it took a lot of hard work to get to this level of performance. It is also impressive that you are actually capable of getting any numbers at all. Unless you’re Dilbert in the cartoon accompanying this post, measuring any kind of KPI is a challenge, even for a simple kind of operation. Field service is a far cry from a simple operation, and collecting reliable performance information from a busy and widely dispersed workforce is notoriously difficult. You probably had to invest in mobile real-time communications, flexible analytics with back-end power and front-end friendliness, and in tools that would highlight the WIIFM (What’s In It For Me) so that the field workforce supported and adopted the solution.
So now you feel justified in wanting to enjoy the moment. Go ahead, but afterwards, ask yourself: What else can I do with this result?
Here is one answer: Go beyond the single number. That number is an average. There are many ways to get to the same average. Here are two ways, assuming that you have 100 engineers:
Case 1: 90 engineers perform 6 tasks per day and 10 engineers get to 7
Case 2: 61 engineers perform 3 tasks per day and 39 engineers get to 11
Statisticians would look at these two cases as two different distributions that just coincidentally happen to have the same average. They would be right, but we cannot know this when the difference is hidden behind the same KPI average. If you take the time to find out whether your operation behaves more like case 1, or like case 2, or something else altogether, you’ll learn a lot about your business. You’ll also learn a lot about how to improve it. Look for an analytics package that lets you explore the data, “slice and dice” it, drill down into it and so on, to reveal the hidden complexity behind the simple averages.
Let’s take the more interesting case, case 2. It is obviously made up to be simple, and your own data will be more complex. Still, let’s imagine it is real. What would you do? Should you fire the 61 “slow” engineers? Probably not. They may be working in a region where you have low demand for your services, in which case you should consider ways to align your work capacity with the demand for your work. Aligning demand with capacity can be done in many ways – for example additional marketing to increase demand, or relocation to reduce capacity in this region and move that capacity to where there is higher demand for it. Another possibility is that these “slow” engineers are only dispatched to a certain type of work, requiring specific certification, and that demand for that work type has been falling. It’s easy to imagine other possibilities, but the main point is clear enough: Once you discover the patterns forming the single-number average, you can start to understand what the patterns mean. And once you understand the pattern, you can take steps to bring the whole organization to the highest performance level. 6.1 may be great in our scenario, but if case 2 is correct, maybe you can get even higher.
The analysis can go deeper than looking at the distribution of numbers that make up the average. For example, think of more than one KPI. Is there any correlation, for example, between number of tasks per day and number of tasks which missed the SLA (Service Level Agreement) time window? In other words, could it be that in regions where the SLA violation KPI is low, the tasks-per-engineer-per-day KPI is high? If so, what would you do about it?
So take a deep breath and dive into the world of data analysis. Analysis of the kind discussed here is really easy, and it can give you more insight than just about any other method. Why not try it?