AI for scheduling in manufacturing: preparing the reschedule, not publishing the plan
Most conversations about scheduling software start with the wrong picture: a planner with a blank week, a demand signal and a set of machines, solving for the best sequence. That happens about once a week, for about an hour, and the output survives until the first phone call.
The real job is what happens after that. A supplier confirms a part for Thursday that was promised for Monday. A spindle fails mid shift. Two people call in sick, one of them the only person on that crew certified for the pressure test. Each event invalidates part of a plan other people have already begun acting on, and someone has to decide what moves, what slips, who gets told and what it costs.
The planner spends most of the week re-planning
That is where an AI system can earn its keep in a plant, and not by publishing a schedule on its own. Watch a planner for a few days and the pattern is obvious: the initial plan is a small part of the work, and the rest is absorbing disruption. Take a change, work out which orders it touches, check whether the recovery is physically possible, tell the people affected in terms they can act on.
The hard part is rarely the arithmetic, because a planner who knows the plant sees quickly which options are viable. What takes the time is assembling the facts behind that judgement. Where is the material now. Is the fixture free. Who is on shift and what are they signed off for. Which customer promise is contractual and which is a habit. An AI system that gathers those facts and shows the consequences of each option is doing the tedious part and leaving the judgement where it belongs.
Finite capacity is a promise about one constraint
Every plant has a real constraint, and it is usually narrower than the capacity model suggests. It might be an ageing press, a furnace with a fixed batch cycle, or a test rig everything funnels through before it ships.
Finite capacity planning in theory balances all resources. In practice a plan that respects the true constraint and treats the rest as roughly flexible beats one that spreads its attention evenly and models the constraint badly. So you do not need a model of the whole works, only an honest model of the resources that decide throughput and a clear statement of what is not modelled, so nobody mistakes silence for capacity.
Changeover sequencing and the matrix nobody maintains
Sequence dependency is what makes production scheduling genuinely difficult. The cost of running an order is not a property of that order. It depends on what ran before it: light colours before dark, parts sharing a fixture, grade separation, a tool change that takes most of a shift rather than minutes.
Almost every plant has a changeover matrix somewhere, and almost every matrix is out of date, built when the line was commissioned and abandoned when the person who cared about it moved on. Setters know the real numbers and carry them in their heads. The schedule inherits the written ones.
So a useful, unglamorous job for an AI system is to compare what the matrix claims against what happened at the machine, and put the pairs with a large, consistent gap to a planner as a question rather than overwriting them quietly. That is not optimising the sequence. It is making the sequence worth optimising.
Maintenance and production competing for the same hours
Planned maintenance is the clearest case of two plans written by different people against the same resource. Maintenance works to intervals and compliance dates, production to customer promises. Both are reasonable, and neither sees the other until the week it bites.
The usual failure is not that maintenance gets skipped. It is that it gets deferred informally, again and again, until it becomes a breakdown that costs several times the planned window. The subtler failure runs the other way: maintenance takes a slot that looked free of firm orders, and then demand lands there.
A system that reads both calendars can say useful things before either side commits. It can show which tasks have slack and which are near a hard date, and identify the windows that cost the least production, including shutdowns and the gaps created by a long changeover you are taking anyway. It can flag when a deferral is about to become a management decision rather than a planner's workaround.
Who is actually qualified to run the cell
A production plan assumes people, and people are not interchangeable. Crewing it means matching the orders you intend to run against who is present, what they are signed off to operate, and the rules governing rest between shifts.
The constraint that bites is almost always a certification held by too few people: a weld qualification, a pressure authorisation, an inspection sign off. On paper the shift is fully staffed. In practice one absence has removed the only person who can release the batch.
An AI system helps here in two ways, neither of them autonomous rostering. First, by making the single points of failure visible in advance: this cell runs only when one of two named people is present, and both are on the same crew. Second, by preparing coverage options when an absence lands, so the supervisor chooses rather than searches.
Inbound slots, the yard and the gate
Scheduling the plant and scheduling the gate are the same problem from opposite ends. A dock has finite slots, finite unloading labour and a yard that fills. The connection that gets missed is that an inbound delay is a production decision, not a goods in problem. If a part lands at the end of a shift instead of the start, the order that needs it cannot start on time, and someone should know that in the morning rather than at the machine.
A system that watches confirmations and booked slots against what production expects can raise the link early: this delivery is slipping, these orders depend on it, here are the sequences that avoid an idle machine.
Routings and cycle times that were true once
Every schedule is built on master data, and most master data is quietly wrong. Routings include operations that no longer exist and omit ones that always happen. Cycle times reflect a commissioning figure rather than the rate the machine holds with current tooling. Shift calendars show patterns that changed long ago, and setup times are whatever someone typed once.
Planners cope by applying private corrections: add a shift to this family of parts, ignore that work centre's stated rate. None of it is in the system, so the output is never trusted on its own, which is why so many plants run a spreadsheet alongside the planning system.
If you are putting AI anywhere near scheduling, this is the highest value starting point. Comparing planned against actual at the operation level, and surfacing the fields where the gap is persistent rather than noisy, turns private corrections into maintained data. That improves every schedule afterwards, automated or not.
What a prepared reschedule looks like
The useful unit of output is not a schedule. It is a small set of candidate responses to a specific disruption, each one explained.
A good candidate states what changed and how it was detected, lists the orders affected and the promises at risk, separating the contractual from the customary, then gives a few options, each with what moves, what it costs in changeover and overtime, and what assumption it rests on. It names what it could not check, and it ends with an action a human takes or declines.
That shape matters because it is reviewable. A planner can agree or disagree with a stated assumption in seconds, but nobody can review a re-sequenced week that arrived with no reasoning attached, so it gets accepted blindly or ignored, and both are worse than the spreadsheet.
Making a change the floor will believe
The explanation is not a nicety. If the reason behind a change is invisible, supervisors and setters assume it is arbitrary and keep their own order of work, at which point the published plan is fiction and your data gets worse. So write the change as the person receiving it experiences it: this job moved to the later shift because the material lands at midday, this one runs first because the two share a fixture.
Where AI fails here
Autonomous publishing is the main failure mode. A system that writes sequences straight into the planning system will eventually publish a plan that is feasible on paper and absurd on the floor, because the constraint it broke was never written down anywhere it could read.
Soft constraints are where credibility goes fastest. The agreement that one customer's order always runs before close of business Thursday. The work centre you do not load at the start of a shift because of a noise restriction. The operator nobody puts on that machine, for reasons nobody will write down. None of that is in the data model, all of it is real, and a plan that breaks it is rejected by people rather than by software. Give a solver confident cycle times and a stale changeover matrix and it will break those rules with more conviction than a planner ever would.
Cascading change is a trap. One upstream slip can re-sequence the whole week if you let it, and a plan that churns is worse than one that is slightly suboptimal, because people have already committed to it. Prefer the smallest recovery that holds the promises.
Finally, these systems fail when they are measured on adherence to plan alone, because a plant can hit adherence by planning what it was going to do anyway. What matters is whether disruption is absorbed faster and whether the master data is improving.
A sensible first build
Start where the pain is loudest and the risk lowest: a disruption watcher. Pick the handful of events that currently reach your planner by phone, and build something that notices them, works out what they touch and prepares explained options, with no writes to the planning system.
Run it alongside the current process long enough to compare. If the prepared option matches what the planner chose, you have an assistant that saves real time. If it does not, the disagreement tells you which constraint or field is wrong. Master data work usually comes next, because by then you know which numbers are lying to you. Sequencing automation, if you ever want it, belongs last and belongs on one constraint rather than the whole plant.