Optimisation and Operations Research
Scheduling, routing, allocation and planning solved against the constraints you actually operate under, producing plans your planners will run rather than override on the first morning.
Optimisation is the least fashionable and most reliably valuable technique in this pillar. It has decades of mature theory, solvers that are extraordinarily good, and a failure mode that has nothing to do with mathematics: producing an optimal plan that violates a rule nobody wrote down, which the planner then discards along with the system.
Optimisation and operations research is the mathematical formulation and solving of decision problems with an objective and constraints: scheduling, routing, rostering, allocation, network design and capacity planning, producing the best feasible plan under rules that reflect how the operation actually runs.
The constraints are the project
Solvers are excellent. Formulation is where engagements succeed or fail, and the hard part is not the mathematics but the archaeology: finding the rules that live in people's heads.
- The written rules. Contracts, working time regulations, licensing, safety limits, service level agreements.
- The unwritten rules. This driver does not do that route. These two cannot work the same shift. That customer is always served first. This machine needs longer to change over on Mondays.
- The soft preferences. Fairness across a roster, continuity of relationship, and the things that do not affect cost but do affect whether people accept the plan.
- The exceptions. What happens when someone calls in sick, a vehicle breaks down or an order arrives late, and how much the plan should be allowed to change in response.
We spend the first fortnight with planners extracting these, because an optimiser that ignores one of them produces a plan that is dismissed on the first morning and never given a second chance.
How we build an optimisation system
Measure the current plan first
Cost, utilisation, service level, overtime and the number of manual adjustments, measured on real historical plans. This is the benchmark, and it is frequently better than expected because experienced planners are genuinely good at this.
Formulate honestly, solve pragmatically
Exact methods where the problem size allows, heuristics and metaheuristics where it does not. Most real operational problems are too large for guaranteed optimality within a usable time, and a very good solution in ninety seconds beats an optimal one in six hours that arrives after the depot has left.
Make constraints soft where reality is soft
Hard constraints that cannot be violated, soft constraints with penalties that can be traded off, and a clear report of which soft constraints a given plan breaches and by how much. Real operations bend rules deliberately, and a model that cannot express that produces infeasible results rather than useful ones.
Explain the plan
Why this vehicle takes this route, why this shift is assigned this way, what the binding constraint was. Planners will not run a plan they cannot explain to the people affected by it, and an unexplained optimal solution is an unused one.
Support re-optimisation, not just planning
Days go wrong. The system needs to re-solve from the current state with minimal disruption to what has already been communicated, because a technically better plan that changes everyone's afternoon is worse than a slightly worse plan that changes two things.
Let planners adjust and learn from it
Manual overrides are captured with reasons and reviewed. They are the fastest way to find the constraints that were missed, and after a few weeks the override rate becomes the honest measure of whether the formulation is right.
Optimising the wrong objective is the expensive failure
Minimising distance and minimising cost produce different routes; minimising cost and maximising service produce different plans again. We agree the objective and its weights explicitly with the people accountable for the outcome, and we show the trade-off curve rather than presenting a single answer as though it were the only one.
Where optimisation delivers
| Problem | Decision | Typical constraints |
|---|---|---|
| Vehicle routing | Which stops, in what order, on which vehicle | Time windows, capacity, driver hours, skills |
| Workforce rostering | Who works when and where | Working time rules, skills, fairness, preferences |
| Production scheduling | What to make, in what order, on which line | Changeovers, maintenance, due dates, materials |
| Network and inventory placement | What to hold where | Lead times, capacity, service targets |
| Field service scheduling | Which engineer to which job | Skills, parts, travel, appointment windows |
| Capacity and shift planning | How much resource, when | Demand forecast, contracts, ramp limits |
Each of these depends on a forward view of demand or volume, which is why optimisation pairs naturally with demand forecasting and time series forecasting.
How the engagement runs
Constraints are gathered from planners first, and the current plan is the benchmark throughout.
Constraint discovery and baseline
Written and unwritten rules extracted with planners, current plans measured on cost, service and adjustment rate.
Formulation
Objective and weights agreed, hard and soft constraints specified, and a first model validated against historical plans.
Solver and performance
Exact or heuristic approach chosen for the problem size, tuned to produce usable plans inside your planning window.
Explanation and re-optimisation
Plan explanations, disruption-minimising re-solve from current state, and the override capture mechanism.
Parallel running and handover
Optimised plans produced alongside the planners' own, compared and reviewed, then handover with the constraint maintenance guide.
What you receive
Plans your planners will run, with the constraints written down at last.
Constraint specification
Every rule, hard and soft, written down and agreed, including the ones that were only in people's heads.
Optimisation engine
Deployed solver producing plans inside your planning window, as infrastructure as code.
Baseline comparison
Optimised plans against historical actual plans on cost, service, utilisation and overtime.
Plan explanations
Why each assignment was made and which constraint was binding.
Re-optimisation
Re-solve from current state with disruption minimised against what has already been communicated.
Override capture
Manual adjustments recorded with reasons, reported so missed constraints surface quickly.
Is this the right engagement?
Worth being direct. Optimisation and Operations Research is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Planning is done manually or in a spreadsheet and takes significant time.
- The problem has a clear objective and rules that can be written down.
- Planners will engage for a fortnight of constraint discovery.
- Historical plans exist so the benchmark is real.
- The plan can be delivered into the operational system.
Choose something else if
- The rules change daily and nobody can articulate them.
- The problem is small enough that a person solves it well in ten minutes.
- There is no appetite to run plans in parallel before switching.
- The decision is sequential with delayed consequences, which is reinforcement learning territory.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
Is optimisation the same as machine learning?
No. Machine learning predicts what will happen; optimisation decides what to do given constraints and an objective. They pair naturally, because most optimisation problems need a forecast as input, but the mathematics and the failure modes are different.
Will the optimiser produce the mathematically best plan?
For small problems, often yes. For realistic operational sizes, a very good solution within your planning window is the practical goal, and it beats an optimal one that arrives after the decision had to be made. We are explicit about which regime your problem is in.
What if our planners disagree with the plan?
That is expected early and is the most useful signal in the project. Overrides are captured with reasons, reviewed, and almost always reveal a constraint that was never written down. The override rate becomes the honest measure of whether the formulation is right.
How much better than our current planning will it be?
We benchmark against your actual historical plans rather than against a naive alternative, and experienced planners are genuinely good, so the honest answer is measured rather than promised. The gains are usually largest in consistency, in speed of replanning and in the long tail of awkward cases.
Can it handle disruption on the day?
Yes, and this is often where most of the value sits. The system re-solves from the current state while minimising disruption to what has already been communicated, because a technically better plan that changes everyone's afternoon is worse than a slightly worse one that changes two things.
Often paired with this
Most clients combine two or three engagements from the Machine Learning & Predictive Analytics pillar. These are the ones that most often run immediately before or after.
Demand and Sales Forecasting
SKU and location level forecasts with promotions, seasonality and hierarchy handled, measured where error costs money.
Read more →Time Series Forecasting
Forecasts for any metric over time, backtested properly and delivered with usable uncertainty.
Read more →Reinforcement Learning
Sequential decision systems with safe exploration and offline evaluation, and honest advice when a simpler method wins.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.