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 is event-driven from the ground up. The engine subscribes to the ERP and MES as live data sources, processes events as they arrive, and replans within seconds. Stability constraints are configurable per resource; in-process and in-setup operations are protected by default.

• Sub-30-second replan on a typical 200-machine shop after a floor 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.