How Efficiency Scales Run Time but Not Setup

An efficiency or speed factor in EDGEBIC by User Solutions scales an operation's run hours, the per-piece work, but never its setup. A faster machine produces the batch in less run time, yet the changeover to get it ready is a fixed preparation that a speed multiplier does not touch. This one rule keeps machine pools honest: a slower pool member shows a longer run but is not charged a proportionally longer changeover it does not actually incur, and a fast machine's advantage appears exactly where it is real.

Machines that do the same job at different speeds are everywhere: a new mill and an old one, a primary line and a backup, a pool of interchangeable but non-identical units. To schedule across them, the engine needs a way to say "this machine is faster or slower than the reference." A factor is one way it does that. The subtlety is both what a factor applies to, and which configurations use a factor at all, because one of the three does not.

Two components, one factor

Recall that an operation is composed of a fixed setup and a run that scales with quantity, as covered in how setup time composes into a step's duration. The efficiency factor multiplies the run and leaves the setup alone.

The reasoning is physical. Run time is proportional to output: a machine that runs parts twenty percent faster makes the same batch in twenty percent less run time. Setup is not production. Loading a fixture, threading material, or dialing in a temperature takes the time it takes, and the machine's running speed does not change how long that preparation is. A fast machine still has to be set up; a slow machine's setup is not longer just because its run is.

So the composition on a given machine is:

operation hours = machine's own setup + (base run hours x machine's efficiency factor)

A factor below one means faster than reference, shrinking the run. A factor above one means slower, stretching it. The setup term sits outside the multiply entirely.

Why baking setup into the factor is wrong

It is tempting to apply one multiplier to the whole operation for simplicity. That understates changeover on fast machines and overstates it on slow ones, and the error grows with setup size. On a long-changeover work center, a paint booth or a heat-treat furnace, scaling the setup by a speed factor would produce nonsense: a booth that runs parts faster would appear to flush and mask faster too, which is not how solvent and cure times behave.

Keeping setup out of the factor also matters inside a machine pool, because a member often changes over differently from the reference, not proportionally. A work center group handles this with two separate settings per member: a Factor that multiplies the step's base run hours, and an optional setup override that is independent of it. A machine can therefore run fast and still set up slowly, which is a combination a single multiplier could never express.

A worked example: the same job on two pool members

Take an operation with a base run of 10 hours (for the order quantity) and consider two members of the same work center group.

Reference member, factor 1.0, setup 1.0 hour. Run is 10 x 1.0 = 10 hours. Plus 1 hour setup. Total 11 hours.

Faster member, factor 0.8, setup override 1.5 hours. Run is 10 x 0.8 = 8 hours, because this machine makes parts faster. But its own changeover is 1.5 hours, not a scaled version of the reference's. Total 9.5 hours.

The faster machine wins overall despite a longer setup, because its speed advantage is real in the run and its setup is its own honest number. Now flip it:

Slower member, factor 1.25, setup override 0.5 hours. Run is 10 x 1.25 = 12.5 hours. Its setup happens to be quick, 0.5 hours. Total 13 hours.

Notice the slower machine's setup did not balloon to 1.25 x something. It is 0.5 hours because that is what that machine's changeover costs. If the factor had scaled setup too, this machine would have been charged a longer changeover it never incurs, and the comparison between machines would be distorted. By scaling run only, the engine compares machines on the two things that actually differ: how fast they run, and how long they take to set up, each measured on its own terms.

Where this shows up

The rule is not academic, and neither is the question of which configuration uses a factor at all. Three situations, and they behave differently:

• Machine pools. In a work center group, each member carries a Factor that multiplies the step's base run hours and is never applied to setup, plus an optional setup override. Shopping the pool by earliest completion therefore uses honest per-machine run hours, and a slower member is not penalized on setup it does not incur.
• Synchronized parallel machines. A dependent parallel mirror carries a Parallel Factor deciding how much of the primary's hours are booked onto it, while its setup mirrors the primary one to one rather than being scaled.
• True alternatives. No factor at all. When the engine chooses between alternate machines, each candidate carries its own Setup Time and Hours Req'd, entered directly on its row, and the scheduler uses those values as they stand. An older, slower mill gets larger numbers typed in. Setting a Parallel Factor on a true alternative does nothing.

That third case is the one worth remembering, because the symptom of getting it wrong is silent: a factor entered on a true alternative reviews cleanly and changes no dates at all. If a backup machine seems to ignore its factor, check which of the three configurations it actually is before looking anywhere else.

The practical guidance is to keep setup as its own value and let a factor describe only speed, where a factor applies. If an operation on a slower machine looks entirely stretched, including the changeover, it usually means setup was folded into the per-piece run rate rather than kept separate.

For the broader pipeline, the complete scheduling engine guide shows how per-machine hours feed capacity and placement, and finite versus infinite capacity scheduling covers why honest per-machine hours matter once capacity is finite. To see the factor scale your own routings across your real machines, explore the EDGEBIC engine or bring your data to a demo.