8 Manufacturing Routing Mistakes That Distort Your Schedule

Most schedules that planners refuse to trust are not broken by the scheduling engine. They are broken by eight recurring errors in the routing data, and every one of them has a visible symptom. This post lists them in the order of how much damage they do, with the symptom you will actually notice first and the fix.

For what each routing field means, start at the bill of routing explained. For how the engine consumes those fields, how EDGEBIC reads a routing is the mechanism.

1. Batch Hours in the Per-Unit Field

Symptom. One operation takes days of Gantt on a job that should take hours. The routing header's Estimated Hour per unit reads something like 12 on a part that takes twelve minutes.

Cause. Hours Required is time for one unit. EDGEBIC by User Solutions multiplies it by the order quantity itself. A batch total for 100 pieces therefore inflates every order by a factor of 100.

Fix. Divide by the typical batch size, or use the pieces-to-hours converter beside the cell rather than doing the arithmetic by hand. Then check the header total against a number you know: a one-minute part should read roughly 0.017 per unit.

This is first on the list because it is both the most common inherited error and the one that destroys credibility fastest. A shop that sees one obviously impossible bar stops reading the rest of the schedule.

2. Trusting the Sequence Number Instead of the Chain

Symptom. Steps schedule in an order nobody recognizes, while the grid shows a perfectly tidy 10, 20, 30.

Cause. The sequence number sorts the grid. Execution follows the next-in-sequence link on each row. The two can disagree completely, and only one of them is visible at a glance.

Fix. Open each row's next-in-sequence picker and repair the chain. Watch for the warning marker beside a step name: it means the link is empty or points at a step that was deleted. Repairing links is a two-minute job when the marker appears and an afternoon of confusion when it does not.

3. An Unterminated Chain

Symptom. The routing looks complete but the diagram shows it disconnected from the end product, and step ordering behaves oddly at the tail.

Cause. The last production step must point at the end item, not at nothing. That link is how the system knows the recipe finishes, and it anchors the level calculation that gives every upstream step its depth.

Fix. On the final step, open the next-in-sequence popup and click End Item. On imported routings, keep automatic sequence generation on so the terminal step gets the end-product link stamped for you.

4. Setup Folded Into the Run Rate

Symptom. Small orders look far too expensive in time. A five-piece order books nearly as many hours as a fifty-piece order should.

Cause. A one-hour changeover added into the per-unit hours scales with quantity. On a 500-piece order the routing charges 500 changeovers.

Fix. Move one-time work into Setup Time, where it is added once per run. The routing header shows the two sums separately for exactly this reason: Estimated Hour per unit and Setup Time should look like different kinds of number.

If your changeover genuinely depends on what ran before, a flat setup value is the wrong model entirely and the setup matrix is the right one. Sequence-dependent changeover is also where the biggest capacity recovery usually hides, which is the subject of changeover time reduction.

5. Hour Fields on Component Rows

Symptom. Timing cells read N/A on a row and cannot be edited, and the planner concludes the grid is broken.

Cause. The row is a component step. It names a product rather than a work center, books no machine capacity, and gets an instant assignment in the plan. Hours have no meaning there.

Fix. Enter the per-unit Quantity and the Lead Time (days) instead, and link the row to the step that consumes the component. If the component has a routing of its own it is a sub-assembly, and the scheduler expands it at scheduling time. That structure is covered in sub-assemblies on the design canvas.

A related version of this mistake is setting transit days on both the component row and the consuming step. The component's travel is already inside its own availability, so the second value double counts it.

6. Expecting a Routing Edit to Move Live Jobs

Symptom. You correct a mill rate from 0.50 to 0.40 hours per unit, save, and the job on the Gantt does not budge.

Cause. This is designed behavior, not a bug. Every scheduled job carries a frozen copy of the routing it was planned with, so a standard-routing edit never silently re-routes work in progress. Shop-floor paperwork stays valid.

Fix. New orders pick the change up on the next scheduling run. To push it into a live job, reschedule that job against the current standard routing, or edit the job's own copy directly. Editing a live job's routing walks both paths.

The arithmetic is worth seeing: at 100 units, 0.50 hours per unit plans 51.0 hours of milling and 0.40 plans 41.0. A full shift-day of difference, applied to every new order from the moment you save.

7. Combining a Queue With an Overlap Gate

Symptom. A cooling or inspection buffer stops having any effect the moment lot streaming is added to the same step.

Cause. When a transfer batch or a flow step fires, the gate it produces replaces the successor's release time, and the queue time on that step is discarded even if the queue would have ended later. The two do not compose.

Fix. Put the handling lag in the transfer-delay field, which does compose with the streaming gate, or move the buffer onto the downstream step. The anomaly report flags every step carrying both a queue and a flow value so the intent can be confirmed rather than guessed.

Three sibling configuration traps live in the same family, and all four are surfaced by the diagnostics:

Choose one overlap model per step. The full comparison is in lot streaming and queue and transit times.

8. Filling Fields the Scheduler Never Reads

Symptom. A planner adds move and teardown time between operations, the schedule does not lengthen, and nobody can say why.

Cause. Move hours and teardown hours exist for cost calculations. The scheduler does not read them, so setting them has no effect on dates whatsoever.

Fix. Express the intent in a field the engine does read. Time waiting for a forklift belongs in queue time when it is shift-aware waiting, in transfer delay when it sits on top of an overlap gate, or in transit days when the parts leave the building. The anomaly report lists routings carrying these dead values precisely so the intent can be relocated rather than lost.

Catching These Before the Shop Does

Two habits catch most of the eight without anyone hunting.

Read the routing header before you save. Estimated Hour per unit and Setup Time are live sums, and they make a batch total or a folded setup obvious in one glance. This is the check that finds mistakes one, four and five.

Run the anomaly report after any bulk change. It catches the structural half: broken chains, cycles, overlap-model conflicts, dead fields, transit configured in a mode the work center cannot support. How to run and read the anomaly report is the two-minute routine, and what the checks look for explains each family in plain language.

What neither habit catches is a value that is structurally valid and factually wrong. That gap closes only when the shop logs real hours and the difference between planned and actual becomes visible per operation. Structure is checkable; accuracy is earned. The broader symptom-first companion is the EDGEBIC troubleshooting guide, and the whole platform is mapped in the complete EDGEBIC guide.

Send US a routing you suspect and we will tell you which of the eight it has. Contact US or start at the EDGEBIC hub.