An Efficiency Factor Change Barely Moved a Pieces Line: Why, and the Fix

A speed factor edit that leaves a pieces-based line running the same length almost always means the factor you changed is not the number that step consults, or the plan has not been rerun since you changed it. In EDGEBIC by User Solutions the output rate a pieces line is planned from comes from its routing step, so an edit made somewhere else can be entirely valid and still leave that step's duration untouched.

This post lives in the EDGEBIC troubleshooting guide and pairs with pieces-based versus hours-based capacity and the wider question of what is production scheduling.

What You Are Seeing

You have a pieces-based line, and you changed a factor somewhere to reflect it running much faster, or much slower, than the number on file. You expected the schedule to react in proportion. Instead the operation came back at almost exactly the length it was before, as if the scheduler ignored the change. The field accepted the value and saved cleanly, but the plan did not follow it.

Why It Happens

There are four causes, and they are quick to separate.

• The plan has not been rerun. Saving master data never reschedules by itself. Bars already placed stay where they are until the next Drive Schedule run, so a change can look ignored when it is simply pending.
• The factor belongs to a pool, and this step does not use the pool. A speed factor is a property of a machine's membership in a work center group: it multiplies run hours for steps bound to that group. A step that names the machine directly never reads it.
• The factor was entered on a true alternative. That is a documented no-op. A true alternative is not a scaled copy of the primary; it carries its own hours required and its own setup time, entered on its own row.
• The work center has no efficiency editor. Capacity type and unit of measure show as read-only columns on the work center grid, and piece-rate math is configured on the routing step rather than on the work center dialog. If you went looking for a rate multiplier on the machine record, there is not one to turn.

None of these is a bug. Each one is the engine reading the number that genuinely governs that step, which is a different number from the one that was edited.

How to Fix It

Find the number the step actually reads, change that, and rerun.

1. Rerun scheduling first. Run Drive Schedule and re-check the operation before investigating anything else. If it moves, the edit was correct and only the plan was stale.
2. Check how the step is routed. If it names a machine directly, a pool member's factor has no bearing on it. Either bind the step to the work center group so the pool's factors apply, or correct the step's own numbers.
3. Put a pieces line's real rate on the routing step. The per-piece time on the step is what the plan is built from. If you know the line as pieces per hour, use the converter beside the hours value to turn that rate into the decimal hours per piece the step stores.
4. Give a true alternative its own numbers. Do not expect a factor to derive them. Enter that machine's real hours required and its real setup time on its own alternative row.
5. Re-run and check one operation. The duration should follow from the step's own piece requirement and per-piece time. If it does, the model and the plan now agree.

How to Prevent It

• Decide where speed differences live before you enter them. Interchangeable machines of different speeds belong in a work center group, where each member's factor is read on every run. A single named machine's real rate belongs on the routing step.
• Treat "the plan did not move" as a rerun question first. It is the most common answer and the cheapest to rule out.
• Keep the per-piece time honest. A line's real sustained output is the number worth maintaining, because every job through that step is sized from it.
• Do not confuse this with capacity. A speed factor and a per-piece time size the work; shift hours, downtime, and per-day capacity overrides size the day. Those are the levers when the issue is how many hours the line offers, not how fast it runs, as covered in pieces-based versus hours-based capacity.

If your pieces work center is scheduling in run hours rather than by output at all, that is a different symptom covered in a pieces work center scheduled in hours.