Finite capacity, infinite optimism.
The constraint model is built once, from nominal rates and standard changeovers, and then defended for years. The machines quietly stop matching it.
FINITE CAPACITY SCHEDULING · REAL CONSTRAINTS
Finite capacity scheduling is only as honest as its capacity
Finite capacity scheduling fails for a boring reason: the capacity it defends is a number someone typed in 2019.
THE SHORT ANSWER
Finite capacity scheduling builds a sequence that respects real constraints — machine availability, changeovers, labour, materials — instead of assuming infinite capacity like classic MRP. It works when the capacity model reflects how each machine actually behaves, and when the schedule is rebuilt as soon as a constraint moves.
WHERE FINITE CAPACITY PROJECTS GO WRONG
Maintenance is left outside the constraint set.
Capacity is modelled as if every machine is equally likely to be there next week. The one drifting towards failure is scheduled hardest, because it looks free.
A schedule that cannot be rebuilt is a schedule that gets ignored.
If replanning takes a day of manual work, the plant reverts to the spreadsheet and the finite capacity engine becomes an expensive record of intentions.
The market models capacity once.
Atherya learns capacity from the plant and keeps it honest.
WHAT ATHERYA DOES INSTEAD
Capacity learned per machine and per recipe.
Real durations, real changeover behaviour, real shift effects — taken from the plant's own history rather than a standards table.
Health is part of the constraint.
A machine with a predicted failure and a required window is not full capacity, and the schedule treats it accordingly.
Rebuilt when reality moves.
A stop, a late material or a new priority triggers a fresh proposal in the same working session — not a rebuild project.
Proposed, then approved.
Atherya shows the revised sequence and the trade-off behind it, and waits for the planner's sign-off before anything is committed.
READ FROM ONE REAL PLANT — BEFORE INSTALL
6years of raw history6Mreadings · 42 machines · 5 families141machine × recipe signatures98 → 7open questions closed from data
Rubber moulding, northern Italy. Figures from a real onboarding, read from existing data before any installation. Anything beyond them is a scenario, and we declare it as a scenario.
THE CAPACITY A REAL PLANT DIDN'T KNOW IT HAD
- Six years of history, roughly 6 million readings, 42 machines across 5 asset families — read before installation.
- The plant's real average utilisation was 47%, while 60.8% of the bottleneck concentrated on the presses: the constraint was narrower and more specific than the plan assumed.
- The same recipe produced 5.9% more output at night — capacity that existed already and was invisible to the scheduling model.
What makes Atherya different
Most predictive maintenance tools score signals. Atherya builds an operational memory of the plant first, then reasons on top of it — with the evidence in plain sight and the decision left to a person.
Operational memory
Every event, anomaly, intervention and shift becomes shared memory. What was a log yesterday is experience tomorrow, and the model reads new signals against it.
Déjà Vu: it has seen this before
Not just "anomaly detected", but when it already happened, how similar it was, how it evolved and which action worked. The senior maintainer's memory, available to everyone.
Context that kills false alarms
Machine defects, weak points, how the crew actually works and the environment around the line. A deviation that is normal for that machine, that shift or that season stays quiet.
Living FMEA
FMEA, manuals and procedures become an active part of the reasoning: causes, effects, sensors and suggested actions are connected, instead of sitting in a document nobody opens.
Explainable, not magic
Every alert arrives with the signals involved, the comparable history, the failure mode and a confidence level. Data, interpretation and decision stay separate and verifiable.
It acts, with your sign-off
Atherya does not stop at the warning: it proposes the maintenance window against real orders and shifts, and replans when something changes. Nothing is applied until a person approves it.
On the data you already have
It works on PLC, SCADA, MES, ERP, maintenance records and feedback as they are — fragmented and legacy included. Sensors are added only where no existing signal carries the degradation.
One brain, not a maintenance silo
Maintenance, production and planning read the same operational state, so a predicted failure immediately becomes a scheduling question instead of a separate dashboard.
QUESTIONS, ANSWERED
Straight answers.
What is finite capacity scheduling?
Scheduling that respects real, limited resources — machines, labour, tooling, materials — when sequencing orders, instead of assuming unlimited capacity as classic MRP does. The output is a sequence that could actually be executed.
How is it different from MRP?
MRP plans material requirements against lead times and generally assumes capacity is available. Finite capacity scheduling checks whether the work fits the resources that exist, in the order proposed.
Why do capacity models drift?
Because they are entered once and maintained rarely, while machines age, recipes change and teams find better ways to run. A model learned from current history does not drift in the same way.
Does it need a new system?
No. Atherya reads ERP, MES, historian and CMMS data and proposes into your existing process; it does not replace the stack.
Is rescheduling automatic?
The replanning is automatic, the commitment is not. Every revised sequence is proposed with its trade-off and waits for human approval.
YOUR PLANT · YOUR DATA · THE PROOF
Check your capacity model against your own history.
One export is enough to see where nominal capacity and real capacity disagree.
Discover Atherya