Replacing the optimisation engine is not enough

A team migrates from an unmaintained OptaPlanner line to a supported engine. The harness goes green, the stack is current, the risk register line is closed. Three months later the planner is still rebuilding half of Tuesday by hand. The migration was not wasted, but it did not fix the thing people expected it to fix.

What the solver was never told

A solver optimises the model it is given. If the model says a technician is available all week, the solver will schedule them all week, and it will do so optimally. Whether they are on leave is not a solver question.

The recurring gaps, in the order they cause overrides: certifications not held as data against the person, with dates, so competency cannot be a hard constraint; no absence calendar, so availability is a shift pattern that ignores reality; parts not reserved against the job, so work is scheduled before the kit arrives; no planned start distinct from the due date, so the solver’s output has no field to write into; and subcontracted labour absent from the system entirely, which in a contractor operation can be most of the field capacity.

Each of those turns into a manual correction, and manual corrections are how a planner learns to distrust the schedule.

How to tell which problem you have

Measure one number for a month: what proportion of the approved schedule was still intact on Friday. Then ask, for each change, why it was made. The reasons sort quickly into two piles.

Genuine disruption, a breakdown, a customer emergency, weather, is what re-planning is for, and a good engine handles it well.

Everything else, wrong person, absent person, part not there, permit not valid, job that should never have been scheduled that day, is a record that was wrong before the solve started. If that pile dominates, no engine change will help, because both engines will believe the same fiction.

Fixing the upstream

The work is unglamorous and mostly not algorithmic. Skills and certification types as a catalogue; certifications per person with issue and expiry dates and the document attached; competency requirements declared on work order types and maintenance plans, enforced as a gate at assignment and at delegation, hard-blocking for anything safety-critical. Absences and leave per person, so effective availability is the shift pattern minus reality. A planned window on the work order, separate from the due date, with a record of whether a human or an approved plan set it. Parts reserved against jobs, with visibility of stock at sister sites.

Do that and the solver stops being handed fiction. Gaps should surface as data-quality items, “no availability calendar for crew C”, rather than being silently defaulted, because a named gap gets fixed and a silent default does not.

The sequencing argument

If you are already migrating off an unmaintained OptaPlanner line, that project is the cheapest moment to fix the records, because the migration audit surfaces exactly which constraints were disabled for want of data. That list is your work plan.

Facterra is the records layer: assets, work orders, competency, availability, evidence. We assemble constraints and call the solver; we do not build one. If you are mid-migration and the audit has turned up more data problems than solver problems, that is the conversation to have with us.