A Job's Schedule Bar Is Wider Than Its Hours Suggest

A schedule bar that spans far more calendar time than the job's work hours is showing real elapsed time, not wasted capacity: the width comes from a low utilization cap on the order, a large queue time between steps, a sequence-dependent setup charge, or a job spread thin across many shifts. Each factor is visible, and once you name it the wide bar either makes sense or points to a data-entry slip to correct.

EDGEBIC by User Solutions draws each operation's bar across its true scheduled window, which is elapsed time on the calendar, not a count of work hours. When the two diverge sharply, this post, part of the EDGEBIC troubleshooting guide, finds the factor.

Work Hours Versus Elapsed Time

The confusion behind this symptom is treating a bar's width as its work content. It is not. A bar's width is the span from the operation's start to its end on the calendar, and several things add elapsed time without adding a single work hour. Start by confirming the numbers actually diverge: compare the sum of allocated hours on the job against the routing's expected hours (setup plus per-unit hours times quantity). If those match but the bar is wide, the width is coming from elapsed-time factors, which is normal. If they diverge, that is a different symptom covered under a job showing fewer hours than its routing requires.

Cause 1: A Low Utilization Cap Stretches the Window

Every manufacturing order carries a schedule-at-utilization percentage that caps how much of a work center's daily capacity that one job may consume. At 100 the order takes whatever it needs; at 25 it may take only a quarter of each day. Twelve work hours at a 25 percent cap spread across roughly four times the calendar time, because the job is allowed only a fraction of each day even on an empty machine.

How to tell: the work hours match the routing, but the bar spans several times that in days. Open the order and read its schedule-at-utilization percentage, which caps how much of a work center's day that one job may take.

Fix: if the cap is a data-entry slip (10 or 25 entered where 100 was meant), correct it on the order and re-run scheduling. See the schedule-at-utilization setting. If the low number is deliberate, because the machine is genuinely shared and you wanted headroom held open, the wide bar is correct and reflects the real pace.

Cause 2: Queue Time Adds Buffer Between Steps

Queue time is intentional buffer between operations, for curing, drying, cooling, or inspection. It counts as elapsed time even though nothing is running. A 24-hour queue adds a full calendar day to the gap between two steps, and several queued steps compound.

How to tell: the width sits between operation bars rather than inside one, and the routing steps carry queue time. Queue time can run in calendar days or shift days depending on configuration, so a 24-hour queue can consume a full day off the clock.

Fix: if the queue is genuine process time, the bar is correct. If it was set too high or in the wrong units, adjust it. See how to add queue time before an operation and how queue and transit times work.

Cause 3: A Large Setup Charge

A sequence-dependent setup matrix charges changeover hours based on what the machine ran previously. A dark-after-light color transition on a paint booth can carry hours of solvent flush, and that time is real reserved capacity that widens the operation's bar.

How to tell: the schedule row's setup source reads matrix product or matrix family, and the setup hours are substantial. The setup reason column names the transition and the minutes charged.

Fix: if the changeover is genuine, the bar is correct and the setup is doing its job. If the charge looks larger than any real changeover, audit the matrix cell for that pair, since a bad import value can inflate one transition. This is the same family of causes behind a job whose setup time looks wrong.

Cause 4: A Job Spread Thin Across Many Shifts

When a job spans many shifts a few hours at a time, its window widens even though the total work is small. This happens when each day only has a little free capacity, so the job takes whatever is available and stretches across the calendar. Making a job span shifts is a legitimate behavior (see how to make jobs span shifts); it becomes a surprise only when the daily slices are unexpectedly small.

How to tell: the daily allocations are each a few hours, spread across many days, and the work center has other jobs competing for the same windows.

Fix: this is real contention, not an error. If the wide span matters, free capacity by rescheduling lower-priority work, adding a shift, or routing to an alternate machine. The width honestly reflects how the machine's remaining time was available.

A Quick Triage

1. Confirm the hours match the routing. If they do not, it is an under-emit, not a width problem.
2. Check the order's utilization cap. A low percentage is the single most common stretcher.
3. Look between the bars. Queue, flow, and transit time live in the gaps.
4. Read the setup source. A matrix changeover adds real reserved hours.
5. Look at the daily slices. Many small allocations mean contention, not a bug.

Prevention

• Sanity-check the utilization cap on order entry. Leave it at 100 unless you deliberately want headroom held open, so a stray 10 never masquerades as a scheduling problem.
• Document queue time. When a process needs a wait, record why in the routing notes, so a wide gap reads as intended rather than suspicious.
• Audit the setup matrix after imports. A single inflated changeover cell can widen every bar that transitions through it.
• Watch load, not just width. The resource load view shows whether thin daily slices are a contention story worth acting on or a one-off.