Schedule Instability

A rush job is any work order inserted with a priority that displaces something already on the schedule. In a healthy month, a discrete shop sees 5–15% of orders flagged as rush. In a stressed month, that climbs above 30%. Every rush job bumps at least one other job — usually three or four, cascading through downstream operations.

The instability is not the rush itself. It is the un-modeled consequence: the bumped jobs were promised dates that no longer reflect the schedule. Sales does not know. The customer does not know. The downstream work centers do not know until the material does not arrive.

The right response is not to refuse rush jobs (the business often requires them) but to recompute the full impact of each insertion immediately, surface the bumped commitments, and allow the planner to choose which trade-offs to absorb. That is dynamic replanning applied to the rush-job event.

ERPs typically store one setup time per operation. Reality: the setup time depends on what ran before, who is doing the setup, whether the program is proven, and whether the fixture is on the cell or in storage. A 30-minute standard setup can be 15 minutes on a good day and 90 minutes on a bad one.

When the standard is wrong, every subsequent operation on that machine is wrong. The schedule for the rest of the day quietly drifts. By end of shift, two operations that should have completed did not, and the next shift starts behind.

The architectural fix is sequence-dependent setup modeling (an explicit setup matrix between jobs) and live setup tracking that updates expected duration as the operator performs the changeover. The scheduler then revises the downstream sequence on the fly.

A schedule that assumes full crew on every shift is a schedule that is wrong every Monday morning. Call-offs, vacations, certifications expiring, training rotations, and cross-training gaps all change which operations can actually run on which machines. A 5-axis without a qualified operator is not a 5-axis on the schedule — it is a paperweight.

Modeling labor as a finite, certified resource (not a background assumption) eliminates a class of instability that most APS deployments never close. The right scheduler knows which jobs require which certifications and which certifications are present this shift.

Two practical metrics every operations leader should track:

1. Resequence rate. Percentage of operations that change position in the dispatch list between publication and execution, weighted by remaining work hours. Below 15%: healthy. 15–30%: workable but eroding trust. Above 30%: the system is no longer scheduling, it is suggesting.
2. Plan-to-execution gap. At end-of-shift, compare the published run sequence to the actual run sequence on each work center. The percentage of operations that ran in the published position is the directly observable plan adherence.

Both metrics are usually invisible to ERP reporting because the ERP only stores what happened, not what was supposed to happen. Capturing them requires logging the dispatch list at publication time and comparing to completion records.

Skody treats instability as the normal operating state of a discrete manufacturing floor. The engine reads ERP, MES, and operator events continuously; recomputes the affected slice of the schedule within seconds; and preserves stability on in-process work. Planners see a diff with the cause attached ("rush job W-4192 inserted; bumped W-3891 to Thursday").

All six instability sources above are modeled as first-class constraints, not afterthoughts: rush-job impact, material readiness, sequence-dependent setup, outside-processing partner calendars, labor certification, and live queue.