Why do most APS systems use snapshots?

Snapshots are computationally simpler and were the only viable approach when scheduling engines took hours to run. Modern engines run in seconds, so snapshot-based scheduling is now a legacy choice, not a technical necessity. Most installed APS products were designed in the snapshot era and never re-architected.

How current does the schedule data need to be?

For dispatching, within minutes of the last floor event. For longer-horizon planning, hourly is usually sufficient. The dangerous middle ground is the once-per-shift snapshot: too slow for dispatching, too frequent to provide planning stability.

Can my ERP feed a live schedule?

Most modern ERPs support REST or ODBC access for near-real-time reads of work orders, operation completes, inventory, and capacity. Some require an event hook or a polling job. Skody handles either pattern and abstracts the difference.

ERP Snapshot — Manufacturing Scheduling Glossary

Definition

An ERP snapshot is a point-in-time copy of work orders, routings, inventory, and capacity pulled from the ERP — typically at the start of a shift or overnight — that an APS or scheduling tool uses to generate a schedule. The snapshot is the source of the common failure pattern in which the published schedule is correct at the moment it was built and progressively wrong from then on.

Why it matters

A schedule built from an 11 p.m. snapshot does not know about the machine that went down at 6 a.m., the job that finished early at 8, the material that did not arrive at 10, or the hot order that came in at noon. By lunch it is fiction. Snapshot-based scheduling is structurally incompatible with high-variability shop floors.

Common failure mode

The APS runs nightly on a snapshot. By 9 a.m. the snapshot is wrong in seven ways. Operators discover this one job at a time. Planners spend the rest of the day patching the schedule by hand. The APS investment was supposed to eliminate manual scheduling; it just moved it three hours later in the day.

How Skody approaches it

Skody does not work from a snapshot. It maintains a live model of the floor — work orders, completions, machine status, labor, material, outside processing — and replans against the live state on every relevant event. The schedule the floor sees is always built from current reality.

Dynamic Replanning

Recalculating the production schedule continuously as floor conditions change.

Finite Capacity Scheduling

Scheduling that respects the real, limited capacity of each machine, operator, and tool.

Schedule Instability

When the schedule changes so often that the floor cannot rely on it.

Operational Trust

The condition where the floor believes and executes the schedule the planner publishes.

Dispatching

Telling each operator and machine which job to run next, in what order, right now.