Real-time rescheduling means the production schedule is recalculated within minutes of a machine going down, using live machine status, order priorities, and material availability, so the remaining shift runs the best available plan instead of a plan that stopped being true the moment the machine faulted.
Every plant has lived this scenario. A machine faults mid-morning. The operator knows instantly. The schedule does not. For the rest of the day, the plant runs on a document that describes a factory that no longer exists, and the gap between the paper and the floor is closed by phone calls, hallway conversations, and overtime. This post walks the timeline honestly, first the way it plays out with a static schedule, then the way it plays out when the schedule is a live layer connected to the machines. The difference is not the breakdown. Breakdowns happen either way. The difference is how long the plant runs on fiction.
What happens to the schedule when a machine goes down?
The moment a machine goes down, the schedule becomes fiction, and it stays fiction until someone rebuilds it. Every job queued on that machine now has no start time. Every downstream operation fed by those jobs inherits the slip. Every promise date built on the old sequence is now a guess. None of this appears on the schedule itself, which continues to display the original plan with complete confidence.
What happens next depends entirely on how the schedule lives. If it is a spreadsheet built Monday morning, it cannot know. If it is an ERP schedule refreshed nightly, it will find out tonight, and respond tomorrow. If it is a live layer reading machine states, it knows within seconds, and the question shifts from who finds out when to what we do about it, which is the question that actually matters.
How does a breakdown play out with a static schedule?
Here is the timeline, hour by hour, the way it actually goes. The times are illustrative; the pattern will be familiar.
Notice what the timeline is really measuring. The repair took most of a day, and that cost is real but bounded. The unbounded cost is everything decided against the stale plan while it sat on the board: the materials staged for runs that moved, the changeover crew prepped for a changeover that never came, the hot order that could have jumped to Line 2 at 10:00 but did not, because at 10:00 nobody with authority to move it knew the option existed. The repair cost is what you pay the mechanic. The fiction cost is what you pay everywhere else, and it is usually larger. You can put your own numbers on the downtime side of that with the calculators on ROI calculators and tools, and the framework for the full cost picture is in cost of unplanned downtime.
Who finds out, and when?
Information about a breakdown travels through a plant at the speed of conversation, and it degrades as it goes. The operator knows at fault time, to the second. Maintenance knows when someone finds them. The supervisor knows when they walk the floor. The scheduler, the person whose entire artifact just became wrong, is routinely among the last to know, and often learns the repair estimate secondhand. Customer service finds out when a due date is already missed. The ERP finds out at the nightly batch run, or never, if nobody logs the event against the order.
This ladder is why so many plants feel like the schedule is a rumor. It is not that people do not care. It is that the schedule has no connection to the machines it describes, so every update requires a human to notice, translate, and retype. The structural fix is closing that gap, which is the whole argument of from static to live production scheduling.
What does rescheduling look like with a live layer?
With a live layer, the same 9:42 fault triggers a different day. The machine signal, read directly from the PLC, opens a downtime event within seconds, the mechanics of which are covered in machine monitoring. The scheduler and supervisor get the alert at the same moment, with the machine, the fault, and the jobs at risk attached. As soon as maintenance enters a repair estimate, the system reruns the schedule against the constraint set: which jobs can move to alternate lines, which are locked to the down machine, which orders are due soonest, what materials and crews are actually available. Within minutes it proposes a revised sequence, moving two jobs to a sister line, resequencing the down machine's queue for after the repair, and flagging the one order that cannot make its date no matter what, so customer service can call the customer today instead of apologizing next week.
A human approves the new plan. That matters, and it is worth being precise about. The system does not silently rewrite the factory. It does the recalculation that used to take the scheduler half a day, presents the tradeoffs, and executes on approval: updated sequences to the line displays, updated staging lists to materials, a note against the order in the ERP. The judgment stays with the planner. The clerical work, the retyping, the phone tree, moves to software. The plant still lost the machine for the same number of hours. What it did not lose is the rest of the day.
What does the replan actually trade off?
A replan is a set of tradeoffs, and being honest about them is what separates a useful system from a demo. Moving a job to a sister line buys schedule protection at the cost of an extra changeover and maybe a slower rate on the alternate line. Resequencing the queue behind the repair protects the hottest due dates at the cost of pushing someone else's order. Splitting a batch keeps a customer partially served at the cost of two setups. None of these are free, and the right choice depends on which orders can slip, which the software can only know if commercial priorities are synced from the ERP.
Repair estimates deserve the same honesty. The first estimate is usually wrong, and that is fine. The replan should update as the estimate updates: a two-hour estimate that becomes five triggers another pass, and jobs that were worth holding for the repair may now be worth moving. The loop runs as many times as the situation changes. That is the real meaning of live: not one heroic replan, but a schedule that tracks reality for as long as reality keeps moving.
What has to be connected for real-time rescheduling to work?
Real-time rescheduling is an outcome of connections, not a feature you toggle on. Six things have to be true, roughly in this order.
- Machine states are captured automatically. Fault and running states come off the PLC or sensors in seconds, without an operator filling in a form. Manual downtime logging is too slow and too incomplete to replan against; see machine downtime for what automatic capture involves.
- Downtime events carry an estimate. A replan needs a repair-time estimate, even a rough one, entered by maintenance in one tap and revisable as the repair unfolds.
- The schedule knows real constraints. Alternate routings, changeover times, sequencing rules, and crew skills have to live in the system, or the proposed replan will be as fictional as the original schedule.
- Materials are visible in real time. Moving a job to another line only works if the components can be staged there, which requires live inventory rather than yesterday's snapshot.
- Orders carry priorities and dates. The system needs to know which order can slip and which cannot, synced from the ERP, so tradeoffs reflect commercial reality.
- Every role sees the same plan. The revised schedule has to reach line displays, supervisors, materials, and planning simultaneously, or the plant splits back into competing versions of the truth, the problem described in real-time manufacturing data.
What do the numbers say?
Public data puts boundaries on the problem, even though every plant's downtime economics are its own.
- The Department of Energy's O&M Best Practices guide reports that mature predictive maintenance programs have been associated with breakdown reductions on the order of 70 to 75 percent and downtime reductions of roughly 35 to 45 percent, which is a measure of how much of this scenario is preventable in the first place.
- U.S. manufacturing runs with roughly 12.7 million workers per the Bureau of Labor Statistics, and thin crews mean fewer people available to absorb a breakdown with heroics.
- Census Bureau survey work shows AI use among U.S. businesses is still in the single digits to low teens depending on sector, so plants adopting live, AI-assisted scheduling now are ahead of most of their competitors, not behind.
How does Harmony AI handle the moment a machine faults?
Harmony AI treats the fault as a signal, not a story someone tells later. Because it connects machines, software, and paperwork in one layer, the PLC fault opens a downtime event, the event alerts the right people, and the scheduling module reruns the sequence against live constraints: orders, materials, capacity, and changeovers. The AI proposes the replan with its reasoning attached; the planner approves or adjusts; and the approved plan lands everywhere at once, floor displays, staging lists, and a citation back into the system of record. Nothing is ripped out to get there. The ERP remains the system of record and the PLCs keep doing their jobs; Harmony AI is the layer that finally lets them talk. That is the working model on floors like the one described in the CLS case study, where plant data across shops feeds one real-time operational layer.
Getting there is a white-glove process, not a software download. Harmony AI's engineers come on-site, walk the floor, map which machines can signal what, and build the constraint model with the schedulers who will live in it. The first time a machine goes down after go-live, the difference is simple to describe: the same breakdown, minus the day of fiction.