“There isn’t enough clean time in this sequence.” “That mold isn’t on this line.” “The parts aren’t here yet.” “This batch won’t have enough shelf life.” “We don’t have the people.”
These are the five most common reasons a schedule gets sent back by the shop floor. They have one thing in common: a constraint that wasn’t in the model. The solver wasn’t too weak. It was solving a different problem from the one the plant actually has.
1. A sequencing problem
The schedule allows 20 minutes between two products. The shop floor says it needs two hours, because the previous product contained an allergen.
Changeover time isn’t a constant — it depends on what ran before. Once it’s modeled as a changeover matrix (including allergen levels), the solver can group similar products while still meeting due dates, cutting the number of cleans.
In food and beverage plants, cleaning commonly takes 15–20% of available line time. Get the sequence right and that time goes back to output; get it wrong and no amount of solver speed helps. Electronics is the same story in a different form: a dozen line changeovers a day can eat up to 30% of available time.
2. A resource problem
The schedule puts a job on Line 5, but the mold is still mounted on Line 3. Moving it takes 40 minutes — a number that has to be in the constraints, or the schedule stalls on the day it’s released.
The same pattern applies to tools and fixtures, SMT feeder setups and operator certifications. What they share is exclusivity and pairing: one set of tooling can’t be on two machines at once, and one feeder setup can’t hold every product. A database table can’t easily express that. In an ontology, it’s a conditional relationship.
3. A materials problem
The traditional flow schedules production first, checks materials second, and goes back to reschedule when something’s short. That’s the core problem with sequential planning: each step makes decisions using constraints it doesn’t know about yet.
The right order is to check before releasing — the BOM-exploded requirement can’t exceed what’s on hand and in transit at that time. When something’s short, the schedule adjusts automatically instead of the line finding out when it stops. In industrial equipment, this matters even more: long-lead materials can take months, so shortage risk has to be traced down every BOM level well in advance.
4. A time problem
The schedule shows Thursday completion and Friday shipment. Fine — until the shop floor points out that the retailer requires at least two-thirds of shelf life remaining on arrival, and Thursday is too late.
Shelf life is a chain constraint: ingredient shelf life → production window → finished-goods shelf life → shipping window. If any link is missing from the model, the latest start time is wrong. Too early and remaining shelf life falls short; too late and ingredients expire. Either way, the schedule comes back.
5. A capability problem
The schedule assumes three shifts a day. In reality, only two people on that shift are certified to run that machine. Capacity isn’t the number on the nameplate — it’s what’s available for this line, in this time window, with this crew, for this product.
A proper capacity model includes line capabilities, routings, changeover rules, shift calendars and skills. Leave any of them out and the load numbers are fiction.
One root cause, one fix
| Why it was rejected | The missing constraint | How it’s represented in the ontology |
|---|---|---|
| Not enough clean time | Changeover depends on the previous product | Changeover matrix with allergen levels |
| Mold on the wrong line | Tooling exclusivity and pairing | Tooling–equipment relationships |
| Parts not here | Material availability | BOM explosion + on-hand and in-transit |
| Not enough shelf life | Time chain | Shelf-life chain constraint |
| Not enough people | Real available capability | Shift calendars + skills |
Optimization turns scheduling into a mathematical problem: the decisions are where, how much and when; the objective is lowest cost or best service; and the constraints must match the shop floor. The five rows above are where those constraints come from.
Where problems are small enough, the solver proves global optimality. At larger scale, it returns a plan that satisfies every constraint along with a measured quality gap. For the shop floor, the first requirement is simply that no constraint gets quietly dropped. Optimal only matters once the plan is executable.
One more thing: the plan has to explain itself
Planners won’t run a schedule they can’t explain. Convect highlights the binding constraints and bottleneck resources behind every plan and supports scenario comparison and what-ifs. When an order can’t ship, a root-cause agent traces it to something specific — “this line is full this week and the alternate line doesn’t have the right mold” — instead of a vague “insufficient capacity.”
See how this works in food & beverage, electronics and industrial equipment, or book a demo.
