Why One Average Cycle Time Breaks When Jobs Share Machines

The plan you cannot explain to the floor

Your plan holds one number per operation: a cycle time in a spreadsheet column, an ERP standard minute, a line speed in units per hour. Whether it is a time per unit or its inverse rate, it is one number standing in for the operation. Every job on that operation takes its timing from it. On the floor the number stops holding. The job runs longer than the plan says, or it waits where the plan shows nothing, and the natural verdict is bad data or bad luck. Usually neither is the cause. The problem is the abstraction itself: one number cannot carry which machine runs which job, when, or how contention for the shared pool resolves. Once a stage has machines that run at different rates, change over differently, or follow different calendars, the single average stops representing the stage.

A stage with two machines

Take one small hypothetical stage with two machines. Machine A runs at 100 units per hour, machine B at 60 units per hour. The planner enters one average of 80 units per hour per machine, because the plan holds one number per operation. A job of 10,000 units needs the stage. Table 1 carries the whole example. Every figure in it is invented for this walkthrough; none is measured.

Table 1. Hypothetical two-machine stage (illustrative only)

The average plan's 62.5 hours is 10,000 divided by 160: it times the job against the whole stage as one 160 units/h capacity bucket, splitting the job across both machines. It does not time the job against one machine at the per-machine average of 80 units/h, which would be 125 hours; no machine in this example runs at 80 units/h. The job takes 100 hours on machine A alone and 167 hours on B (10,000 divided by 60, rounded to a whole hour). The 90-minute changeover on B is listed separately so the changeover effect has its own line.

Effect 1: which machine the job actually lands on

On a stage whose machines run at different speeds, the same job has a different duration on each machine. Averaging folds both machines into one number, and that number matches neither. The plan's own timing shows the gap: it gives the 10,000-unit job 62.5 hours because it reads the job against the stage's pooled 160 units/h capacity. The schedule must instead place the job on one machine at its real rate: 100 hours on A, 167 hours on B. The overrun is not a data error; it is the gap between a pooled average and the machine the schedule will actually use. The plan cannot even say which machine that is. Machine assignment, the decision a schedule exists to make, was erased when two rates became one number.

Effect 2: when each machine is free (contention)

Two jobs that both need machine A at the same clock time contend for it: one starts when the other finishes, with a possible changeover between them. In the average plan the stage is a single 160 units/h bucket, so both jobs appear to progress side by side. On the floor, machine A processes one job at a time, so the second job queues. A downstream stage is then timed from a start the machine pool cannot honor, because the plan shows no waiting where waiting will occur. Contention is machine-level: a job waits on the machine it is assigned to, and only that machine's occupancy produces the wait. The plan built from one number per operation has no place to hold the queue, so the queue happens anyway, off the page.

Effect 3: a changeover penalty that exists only once the machine's sequence is known

A changeover time belongs to a machine and to a pair of product families in sequence: how long machine B takes to switch depends on what ran on B before the next job. Until a machine holds a sequence of jobs, the penalty does not exist. The per-operation average cannot contain it, because the average was computed before any machine or sequence existed; there is nowhere in a single number for the minutes to attach. The result is understated production time: the plan shows run hours, omits the changeover minutes, and comes out short by exactly the switching it never scheduled. The 90-minute changeover on B is real machine time whenever B's sequence puts two product families together, and a plan that holds only averages has no way to know those minutes exist.

Effect 4: per-machine availability

Machines carry calendars: planned maintenance, cleaning windows, holiday shutdowns, gaps between shifts. A machine down on Thursday cannot process work that day, and a schedule that models machines routes around the gap. One average rate per operation has no hook for that fact. The average cannot distinguish a Thursday when both machines run from a Thursday when one is down, so the plan loads work into the unavailable window and the promised finish time slips by the window's length. The machine pool keeps its calendar; the plan does not.

When the average is legitimately fine

None of this makes the average worthless. It is the right unit for a capacity check at the right horizon. For medium-term questions about whether the stage has enough capacity for next month's volume, an aggregate rate is a reasonable and standard tool; hierarchical planning is built on exactly that pattern, aggregating for the medium term and disaggregating toward the schedule. The claim here is deliberately narrower: the average is the wrong unit for a machine-level finite-capacity schedule on a heterogeneous stage, a schedule whose entire job is to say which machine runs which job, and when.

What machine-level modeling changes

The fix changes the level of the data, not the data itself. The standard times and line speeds behind the average already exist. Entering them per machine and per product class, each machine with its own changeover times and its own calendar, puts the same numbers where they can decide machine assignment. The scheduling algorithm then places jobs on machines, and contention stops being invisible: jobs on the same machine queue in time, and the schedule minimizes total production time across them.

What changes for the person reading the schedule is the last step. Group the schedule by machine so each machine is its own lane, and run durations, changeovers between consecutive jobs, waits, and downtime gaps all appear where they happen. The four effects above were invisible because the plan had no machine to attach them to; a lane per machine is where they become visible. The schedule a floor manager can point at, machine by machine, is one that has named its machines. The product's guides cover the entry and reading steps in detail.

Takeaway: a finite-capacity schedule names its machines

One number per operation is the right unit for a capacity check and the wrong unit for a schedule that must decide which machine runs which job. These four effects are what a single average cannot represent once a stage holds machines that differ; the abstraction, not the data, is the problem. A schedule whose timing reflects the real machine pool is one that models the pool: its machines, rates, changeovers, calendars, and downtime, and the material that flows between stages within the schedule. Nothing beyond that modeled pool is claimed.