The plan is right and the floor still cannot make it
A plant publishes a schedule that fits its declared capacity, with materials allocated from a stock ledger that was accurate on Friday. On Monday the first shift cannot start because a component set is short, the second is idle waiting for a cleaning cycle the schedule omits, and the third runs a job whose instructions changed on Saturday night.
Nothing here is a forecasting failure. The failure is in the seams: the plan knows capacity but not the cleaning cycle, the ledger knows components but not the kit that is short, and the floor records the instruction change where planning cannot see.
Three versions of the same week
The useful description of a manufacturing planning problem is that three views of the same week exist, each authoritative for something and silent about the rest. Diagnosing which view is stale, and for which decisions, is most of the work.
| View | Authoritative for | Silent about |
|---|---|---|
| Master schedule | Intended sequence, target dates, priority | Tooling, setup, cleaning, operator availability, downtime |
| Inventory record | Material on hand, allocated, in quality, in transit | The kit a line needs together, and partial availability |
| Shop-floor record | What was started, completed, scrapped, and how long it took | Future constraint, material commitment, and the reason for the delay |
Each function argues from different facts, and each argument is internally sound. The planner sees an achievable schedule, the buyer sees ample stock, the supervisor sees a line that could never have run the job assumed. Nobody is lying, and the plant still loses a shift. The plant director owns the lost shift and the late delivery that follows it.
Finite capacity is a constraint, not a data problem
This is where manufacturing differs sharply from retail and distribution, and the wrong lesson is often drawn from it. A model that shifts work to a machine that cannot run it, in a window where changeover is unaccounted for, or on material held as components in several bins, has solved nothing. It has produced a plan that is arithmetically attractive and physically impossible.
The constraint is usually a short list of named things: a line or cell, a tool set, a qualified operator pool, a cleaning requirement, a material kit. A system that suggests a sequence is useful only if those constraints are first-class inputs, carrying their meaning to the supervisor who must live with the result.
The second constraint is data quality with a specific character. Shop floor systems are usually the most accurate in the plant and the least trusted, entered at the end of a shift by somebody who wants to go home. A downtime reason code nobody has reconciled is not a record of why the line stopped. It is a record of why somebody chose that code.
Quality events propagate faster than anyone models
A quality event does not stay in the quality system. A held batch becomes an allocation the plan cannot use, that becomes a short component, that becomes a schedule slip, and a schedule slip becomes a customer conversation. The chain crosses four systems, and each hop loses information, so nobody can later identify where the delay began.
Rework behaves the same way. It consumes capacity the schedule has already promised elsewhere, because the extra hours appear in the floor record as normal production. This is the manufacturing version of the rework hours discussed in the business case for fixing small operational errors: individually defensible, collectively expensive, unattributed.
What the technology should and should not do
A language model is genuinely useful on the clerical and linguistic parts of this problem: reading a rush order, an engineering change note, a quality deviation or a shift handover, and producing a structured summary to be checked against the plan. It also helps where a supervisor describes a constraint in plain language that must become a planning input.
It should not decide the sequence, and it should not release a quarantined batch. The distinction to hold is between understanding what has been said, which language models do well, and committing the plant to a course of action, which requires authority they do not have. Where a decision commits capacity irreversibly, a named planner should approve the output. The comparison of approaches is in when to use AI, rules or conventional automation.
Where the collaboration has to happen
- Agree which system is authoritative for each decision, and write it down.
- Define the escalation path for a material or capacity shortfall, with a named owner and a time limit, so a plan in trouble has a procedure.
- Put quality holds somewhere planning can see them, because a hold only quality knows about is a hold the schedule has promised away.
What to start with on Monday
- Pick one cell and one week. Reconcile the master schedule, the inventory position and the floor record, and list every difference.
- Classify each difference by cause: a constraint never in the plan, a stale record, an undefined meaning, or a disagreement between owners.
- Record the baseline: planned against actual start times, hours lost to material or downtime, and quality events with no visible downstream effect.
- Fix definitions and authoritative sources for the first two causes before building anything for the third.
- Review at ninety days against the baseline, and decide which cause is worth funded work.
The measures are schedule adherence at the line, hours lost to material shortage, and the interval between a quality hold and its appearance in planning. The plant already keeps these records, and connecting the three views is not about producing a dashboard, but about removing the condition in which each function's reasoning is correct and the plant still loses a shift. The engineering required to hold the three views together is set out in enterprise AI engineering.