Why did your automated workforce management system do this? Or that?
The answer to this question is pretty straight forward – because that is what you told it to do.
The technological backbone of workforce automation relies on complex parameters and inputs that define how the scheduling algorithm will be applied to solve a scheduling problem. While at times it may seem like the scheduling algorithm does things you don’t want it to do, like all good computer programs it can only do what you configure and allow it to do. Adding to the complexity of analyzing the output is that the output itself is very subjective – so different people depending on their viewpoint will interpret the output of the solution in different ways leading to even more confusion.
Take this simple example:
If there are ten jobs that could be done today of varying priority levels but there is only the capacity to do five of the ten jobs, then the system should assign the high priority jobs first leaving the lower priority jobs unassigned. This is a pretty simple concept of course but something that is repeatedly overlooked as part of a many workforce management solutions as the focus of trying to minimize travel or some other objective supersedes the effectiveness of ensuring the right jobs are being assigned. If the dispatcher must intervene and manually assign the jobs then the investment in an automated solution is negated.
Of course this simple example does not consider other business constraints and objectives that may impact the ability of the system to achieve this desired state – but having a well-defined priority scheme is the first and most important step of having a solution that does what you want and can also be easily understood by end users.
So how do we begin to address this issue?
The first step is to define why priority is important both as an input and the resulting output of the scheduling solution.
Because priority management is how an organization defines which jobs have priority against other jobs when there is not enough capacity to do all of the work that could be done today – so winners and losers must be defined in advance or the system will fail to achieve the desired results.
Here are two categories of types of work:
- Work that must be done today – such as customer appointments, SLA driven work that is due today, or work that has fallen past due
- Work that could be done today – described as SLA driven work and the due date is in the sometime in the future, such as yearly maintenance on assets or equipment.
So it is pretty easy to define a priority scale based on the two types.
|1||Work that is due today|
|2||Work that is due in the future but could be done today|
But how does this apply when you have work that could be done today that is due in 7 days, 21 days, 3 months or longer?
|1||Work that is due today|
|2||Work that is due in the next 7 days|
|3||Work that is due in 7 days|
|4||Work that is due in 21 days|
|5||Work that is due in 3 months|
It really is that simple – by adding additional priority levels you have now told the system that the demands that have a due date closer to today are more important than demands that have due dates further from today. You can also figure out how to manage tasks that have slipped by their due date and how these tasks will be prioritized against tasks that have not missed the due date.
Prioritizing the demands against your available capacity is the most critical part of ensuring that the scheduling system and its complex scheduling algorithms are going to do what you want it to do.
A few things to think about the next time you talk to your workforce management solution provider about prioritizing things in your system:
- Priority in the scheduling system is different from a Priority defined in your CRM or host system. Although the priority defined in your CRM might be used as a parameter by the scheduling system to define the ‘scheduling’ priority, it is typically not flexible enough to use directly as the priority used by the system scheduling services to assign the work to the resources.
- The priorities defined today will change – so you need a flexible solution that allows you to redefine priority as your business needs evolve. This flexibility is best achieved in the scheduling system.
- For SLA driven work, time to due date is a big component of defining priority. As SLA driven work nears the due date the priority needs to escalate so the jobs due sooner are assigned over jobs due later.
- Your end users should understand what the Priority defined in the scheduling system means. It can be an important part of the overall business process and view into the data, using the defined Priority scheme will be an important part of how they interact with the system.
- Try to limit the number of priority levels used. 10 or less would be ideal – but the number required will depend on your specific requirements. More priority levels will likely increase the complexity of the required configuration and the ability of the system to weigh one priority against another when making scheduling decisions – especially when you get lower down the priority scale.