Workforce optimisation fails before the algorithm runs

Scheduling optimisation has a reputation problem in maintenance and field service, and the solver is the wrong thing to blame for it.

The solvers are good. Constraint-solving engines of the OptaPlanner lineage, now carried forward commercially by several supported forks, will take a set of jobs, a set of people, and a set of rules, and return a feasible week that respects the rules. They have been doing that reliably for a long time. When a scheduling project fails, the post-mortem rarely finds a bug in the solve. It finds that the solve was handed a description of a workforce that did not exist.

The inputs a solver needs

To schedule a technician onto a job, the engine needs to know whether that technician is qualified for it, whether they are available in the window, whether the part is on the van or at the site, whether the site can be accessed that day, how long the job takes, and what else depends on it. Each of those is a record. Look at how most maintenance systems hold them.

Skills are a free-text tag, if they exist, maintained by no one after the implementation. Certifications with expiry dates live in an HR folder or a spreadsheet rather than against the person in the work system, so “was this person’s arc-flash certification current on that date” is not a query anyone can run. Availability is a department shift pattern with no absences, so a person on leave is schedulable. Parts are in an inventory module that does not know which job they are reserved for. And the work order has a due date and no planned start, because most systems never separated “when it is due” from “when we intend to do it”, which means the solver’s output has nowhere to land.

Then there is the workforce that is not in the system at all. In a contractor operation a large share of the field work is subcontracted, and subcontractors are not users, so the solver is optimising a fraction of the labour pool and treating it as the whole.

What happens on Tuesday

The solver produces a week. It looks plausible on Monday morning. By Tuesday the planner has moved a third of it by hand, because the person assigned to the switchgear job is not certified for it, the person assigned to the northern sites is on leave, and the job that needed a fan kit has been scheduled two days before the fan kit arrives. None of that was the solver’s fault. It respected every constraint it was given. The constraints were fiction.

From then on the planner treats the schedule as a suggestion to be overridden, the overrides are not fed back, and within a quarter the optimisation project is a line item that someone will quietly stop renewing.

The order of operations

Get the records right first, and make the system enforce them before any algorithm sees them.

Competency as data: a catalogue of skills and certification types per tenant, certifications per person with issue and expiry dates and the certificate attached, status derived (valid, expiring, expired), reminders before expiry. That applies to subcontractors reached by a link as much as to employees; a person does not need a licence to have a certificate on file.

Competency as a gate: a maintenance plan or work order type declares what it requires, and assigning or delegating to someone who lacks it is blocked with the missing item named. Safety-critical requirements are hard blocks. This is what turns certification tracking from an HR list into a scheduling constraint that is true.

Availability as a calendar: absences and leave per person, effective availability as shift pattern minus absences, exposed as an API over a planning horizon.

A planned window on the work order, distinct from the due date, with provenance recording whether a person set it or a plan published it. And parts reserved against the job, with sister-site stock visible.

Only then does a solver become useful, because only then is the model it is solving against the workforce that is in the vans. Gaps in the data should surface as data-quality items (“no availability calendar for crew C”), never as silent defaults.

Do not build the solver

The other lesson from failed scheduling projects is that application vendors should not write optimisation engines. The good ones are APIs now, maintained by people who do nothing else. The application’s job is to hold honest records, assemble them into constraints, call the solver, and present the result for a planner to approve, pin, move, or re-solve. A job with no available part, no competent person, or no valid permit should come back as unschedulable with the missing element named. That is a hard constraint.

Where Facterra stands

Facterra holds the asset, work order and evidence records, and we are building the competency, availability and planned-window records described above, with competency enforced as a gate at assignment and at delegation. We do not build scheduling optimisation and will not; that layer belongs to a solver such as OptaPlanner, which we integrate and call. The distinction is deliberate. An application that tries to be both usually ends up with a mediocre version of each, and the records were the hard part anyway.