Dynamic Replanning

ERPs were built to log transactions: a part arrived, an operation completed, an invoice issued. The schedule, in this world, is a static document attached to a snapshot of those transactions. Reality, in this world, only updates when someone re-runs the planner.

A real factory is not a transaction log. It is a continuously evolving system of machines, operators, materials, tools, and partners — each with its own state, each interacting with every other. The state changes every few minutes. A schedule that does not update with the state is not a schedule of the factory; it is a memory of one.

Dynamic replanning rebuilds the planning system around the live state instead of around the transaction log. The plan becomes a function of current state rather than a snapshot archive. The floor sees one consistent, current priority list — not a printed plan plus a verbal override from the supervisor.

A continuously replanning engine has three parts: an event stream, an incremental solver, and a publication channel.

1. The event stream. The engine subscribes to the ERP, MES, and operator interfaces. Every state change — op complete, machine down, material received, hot job inserted, ECO released, operator skill update — produces an event with a timestamp and a payload.
2. The incremental solver. Each event is classified by what it invalidates. A machine going down invalidates only the queue on that machine and any downstream operations that depend on its output. A scrap event invalidates only the affected job's remaining operations. The solver recomputes only the affected slice, respecting stability constraints on in-process work.
3. The publication channel. The updated priority list is pushed to operator dispatch screens, supervisor dashboards, and the planner exception view. The planner sees a diff — what changed, what caused it — not a brand-new plan to re-learn.

On a typical floor, the engine processes hundreds of events per day and produces a handful of meaningful priority changes per hour. The rest are absorbed without operator-visible change. That ratio — many events, few visible changes — is the signature of a well-tuned continuous replanner.

The events that matter, in rough order of frequency:

1. Operation complete — especially early or late. Downstream queue times shift; alternates may now be attractive.
2. Machine down / back up — invalidates the queue on that resource and propagates to downstream operations.
3. Hot job insertion — bumps a priority recalculation across every overlapping resource.
4. Material receipt or shortage — releases or blocks operations the schedule was holding.
5. Operator call-off or shift change — labor coverage changes invalidate any operation requiring the missing skill or certification.
6. Outside-processing receipt — returning work re-enters the schedule on its next operation.
7. Scrap event — re-runs the affected work order and resequences downstream operations.
8. ECO release — routing changes invalidate affected operations.

Skody recomputes the schedule three ways: on demand, on a significant ERP event, or continuously where it is wired that way for a specific customer. All three use the same engine, the same stability constraints, and the same diff-based review — the only difference is what pulls the trigger.

On demand

The planner presses Compute plan and the whole shop recalculates in under a minute — machines, labor, material, and hot jobs resequenced against the live state of the floor. Most customers run Skody this way each morning. That is a deliberate choice: the planner stays in control of when the plan changes, which is why they trust it.

On ERP event

A significant change upstream — a new order, a date move, material landing — triggers a recompute automatically. The schedule absorbs the change without waiting for the planner to ask.

Continuous

For customers who want the event-driven ideal described above, continuous replanning is available and wired on request. The same stability constraints apply: in-process and in-setup operations are protected by default.

Three Sigma Manufacturing in Kent, Washington runs 47 work centers on Skody, and their planner accepts the computed baseline about 99% of days.

• Whole-shop recompute in under a minute — on demand or on a significant ERP event.
• Diff-based planner UI. The planner sees what changed and why, not a brand-new plan.
• Live operator dispatch. The current priority list is always visible on the floor — no re-printing, no whiteboard updates.
• No ERP replacement. Skody reads from the ERP and writes back completions, so the financial side of the system is untouched.