The value of APS is obvious
APS should be an easy sell: a better schedule can unlock capacity the factory already owns, reduce costs, meet delivery dates and cut firefighting.
Manufacturers understand the prize. In Deloitte’s 2025 survey of large manufacturers, 35% ranked advanced production scheduling as a first- or second-highest systems investment priority for the next two years. Yet McKinsey found that around 65% of APS programmes missed their expected return.
rank advanced scheduling a top-two investment priority
of APS programmes missed their expected return
Why does software with such clear value so often disappoint?
Because an optimiser does not schedule a factory. It schedules a model of one. If that model misses an important constraint, relationship or objective, the optimiser can solve the wrong problem perfectly.
The hard part of APS is not producing a schedule. It is keeping the model close enough to reality that its schedules remain useful.
Customisable—at a price
In practice, manufacturers face two bad compromises.
A lightly configured APS stays close to the vendor’s standard model. It may handle familiar constraints while missing the local rules that decide whether a schedule will work: a customer approval, a shared setter, or a sequence that depends on a particular fixture and material. When the model has nowhere for one of these facts to go, the planner must repair the answer.
An optimiser that does not reflect reality is essentially useless.
The alternative is an eye-wateringly expensive custom implementation. Deep customisation is possible, but fitting an APS closely to a factory often means months of workshops, proprietary configuration, custom code and testing. The details are where the value lives, and where the cost accumulates.
Even after go-live, deep changes often depend on trained administrators, developers or implementation specialists. A rule the model was not designed to represent can trigger another specialist modelling, testing and release project.
It works, but every deeper change remains slow and expensive.
The manufacturer has paid for an accurate snapshot of its factory, but rented the ability to keep it current.
A model that cannot evolve starts going stale the day it goes live.
Factory knowledge grows continuously. APS models change by project.
Factories run on accumulated experience: the exceptions, dependencies and trade-offs that experienced people understand but standard master data rarely captures. The factory changes constantly, so that knowledge keeps growing.
A machine breakdown changes data the APS already understands. A newly discovered factory rule changes the model itself.
A planner may discover that a job can run on a second machine, but only when a particular fixture, certified operator and first-off inspection slot are all available. Inside the factory, that knowledge fits into one sentence.
Inside the APS, there may be nowhere to put it. Representing the rule could require new properties, relationships, scheduling logic and tests. The factory learns it in an afternoon; the planning system absorbs it through another project.
This is the important distinction: the data can be current while the model is stale.
Every field can be up to date while its structure still describes yesterday’s factory. The APS may exclude usable capacity, promise capacity that is not real or repeat a sequence the planner knows will fail.
The planner is left to make it work
The planner closes the gap.
They remember rules the APS does not know, override implausible decisions, maintain parallel spreadsheets and call the shop floor before trusting the schedule.
This is often described as poor adoption. That reverses cause and effect. The response is rational: the optimiser recommends; the planner answers for the missed delivery, wasted shift or unnecessary overtime.
The planner is accountable for what happens next, so they cannot simply accept the APS’s answer. They need to understand why it made a decision, challenge the constraints behind it and correct anything it has missed. Without that, trust never develops.
An override fixes today’s schedule, not tomorrow’s model. If the next solve repeats the mistake, the planner must carry the correction forward again through spreadsheets, meetings and memory.
The system has not removed planning work. It has added a verification tax.
Spreadsheets hold what the APS has failed to learn.
What flexibility should actually mean
APS flexibility is usually described in terms of settings, parameters and custom code. That measures the wrong thing.
A configurable system lets the manufacturer choose among possibilities its designers anticipated. A teachable system can absorb a distinction they did not.
Legacy APS starts with a prebuilt model, then uses configuration and custom code to force it around your factory’s reality. Orvixo starts with your factory, learns its concepts, relationships, constraints and objectives, and builds the planning model from there.
Orvixo: an APS that evolves with the factory
With Orvixo, planners and engineers can describe operational changes in the language of the factory. AI quickly turns that knowledge into a proposed model change, tests it against current factory data and shows how it would affect the plan before it is adopted.
Model change becomes a capability the factory keeps, not another service delivered by specialists.
The result is the fit of a bespoke APS without making every change another bespoke software project.
Orvixo is the APS that learns your rules and evolves with you.