We’re polishing off an upgrade to our dynamic scheduler, which is a field service route optimization system that allocates engineers to jobs based on a number of criteria.
The technical details of how exactly it works are a bit of a trade secret, so I won’t get very much into detail about it, but I’ll give some broad hints – the field service optimization software works by assigning “costs” to decisions (does the engineer assigned have the right qualifications, does it bring the engineer into overtime, is it at the requested time, cost of the engineer’s hours, total hours worked, etc), and trying to minimise those costs.
In route optimization, field service is not really well covered in the market. Most route optimization systems are very simplistic. For example, they might assume that all engineers can do all jobs, or that we can simply assign a time to a job and the customer will be happy to work that into their schedule. You know how phone installation engineers keep turning up at your house when you’re not it? Yeah – bad optimization in their field service management software.
In my head as I’m building it, I keep imagining the job criteria as “pressures” – each of the criteria we are balancing acts as a kind of spring or elastic, trying to push and pull things this way or that to bring everything into place. Another way to imagine it is like how bubbles are created – they minimise their surface area efficiently, based on pressure from within.
From the user’s perspective, this must all be invisible – they should simply create a job and have it automatically assigned to the right person, or select a load of jobs, click “Schedule”, and have the field service job management software sort them into a reasonable solution.
Solving all of this so that it’s easy for the user is not a straight-forward thing for the developer. I mentioned “costs” – but what values should they be? Deciding exactly how “strong” the springs and elastics in the model should be is a difficult problem in itself! We’re considering writing a system after the current phase of development which will use neural networks to try figure out the right answer to this one. In the meantime, we have some pretty good values that give us results that look right.
The final parts we’re finishing off involve making sure that engineers get home after their day’s work at a reasonable hour (no routes that spend 8 hours meandering them 300km away from home and leave them stranded), and taking individual work hours and holidays into account. The field service engineer management software needs to take all of these into account, or the engineers will not be happy.
Our field service management software features are already impressive, but we think that after this phase is finished, it will leave the competition smoking 🙂
We have a number of clients already using this in their day-to-day work. If you’d like to join them, contact us for a demo.