What Is Factor-from-Base in Work Center Groups?

Factor-from-base is the rule in machine-pool scheduling that a member's speed factor is always applied to the original planner-entered base hours of a routing step, never to hours that were already factored on a previous run, so a 0.5-factor mill always halves the original estimate rather than compounding down toward zero across reschedules. It is the guarantee that a fast machine's numbers stay honest no matter how many times you replan.

This entry is part of the EDGEBIC by User Solutions glossary; the broader dictionary lives in the manufacturing glossary.

The Problem It Prevents

A work center group lets each member carry an efficiency factor: a run-time multiplier against a step's hours. A factor of 1.0 is baseline, 0.5 runs the work twice as fast, 1.5 runs it 50 percent slower. That is how a pool expresses real speed differences between a new machine and an old one.

The hidden danger is compounding. If the engine multiplied the factor against whatever hours the step happened to have going into a run, and that value carried forward, every reschedule would multiply again. A step at 4 base hours on a 0.5-factor mill would read 2 hours after one run, 1 after the next, 0.5 after the third. A few cycles of normal replanning and the hours would be fiction.

How It Works

Factor-from-base removes the danger by fixing the starting point. On every run, the member's effective run hours are computed as the base hours times the factor, where the base hours are the planner-entered value on the step, not the result of any previous run.

Two consequences follow. First, the factor is applied exactly once per run, always to the same base, so the answer is identical every time: 4 base hours times 0.5 is always 2. Second, setup is never factored. The speed multiplier touches run time only, because a changeover does not get faster just because the machine runs the job quicker. A member can override setup with its own value, but that is a separate number, not the run-time factor.

A Concrete Example

Group MILLING has Mill-1 at factor 1.0 (baseline) and Mill-2 at factor 0.5 (twice as fast). A routing step is planned at 0.04 base hours per unit with 0.5 hours setup, for an order of 100 units.

• On Mill-1: 0.04 times 100, plus 0.5 setup, is 4.5 hours.
• On Mill-2: 0.02 times 100, plus 0.5 setup, is 2.5 hours. The run time halved; the setup did not.

Reschedule the job ten times across the week as load shifts. Every single run recomputes from the same 0.04 base, so Mill-2 is always 2.5 hours, never 1.25 or 0.625. The factor did its job once per run and never stacked on itself.

How EDGEBIC Uses It

In EDGEBIC, factor-from-base is a work-center-group invariant. When the engine performs a group explosion, each member candidate's effective hours are computed fresh from the step's base hours times that member's efficiency factor, with setup taken from the member's override or the step default but never scaled. Snapshots persist the un-factored base step, so no already-factored number can leak into the next run.

This is what keeps re-shopping trustworthy: because every reschedule starts from base, a step that re-shops the pool onto a different mill gets that mill's honest hours, not a distorted figure carried over from a prior machine. The factor concept sits alongside the identical-machine model of machine instances, where a group handles different-but-interchangeable machines and instances handle identical ones. For the wider picture, see the work center groups overview.