Why Queue Time Is Not Wasted Time

Planned queue time in a routing is a protective buffer, not waste: it is a deliberate wait between two operations that covers a real need like cooling, curing, drying, or staging, and it keeps the downstream step from starting before its input is genuinely ready. EDGEBIC by User Solutions counts this queue only during active working shifts, so it behaves like the real pause it represents. The queue you should cut is a different animal entirely: the involuntary pile-up of work in front of an overloaded machine. Confusing the two leads shops to delete a buffer that was protecting quality while ignoring the congestion that is actually inflating lead time.

Two things called queue

The word "queue" covers two opposite ideas, and the difference is everything.

The first is planned queue time, a field on the routing step. You put it there on purpose because the process demands a wait: a weldment must cool before grinding, a coating must cure before assembly, a plated part must drip before inspection. This wait is not idle time in the wasteful sense. It is part of making the part correctly, and skipping it scraps the work.

The second is congestion queue, the time a job spends waiting its turn because too much work was released into an overloaded work center. This queue is involuntary, it grows with load, and it is genuinely waste, the kind that inflates lead time without adding value. This is the queue that dominates job-shop lead time and that finite capacity scheduling exists to control, as queue time as a scheduling lever explains at length.

Both appear as a gap on a traveler. One is a designed buffer; the other is an accident of overload. A shop that treats them the same will cut the wrong one.

Planned queue is shift-aware

What makes planned queue behave like a real buffer is that it is shift-aware. The engine consumes queue hours only during active working shifts. It does not tick on nights, weekends, or holidays, because the physical process it represents effectively pauses when the shop is closed.

So a four-hour queue that starts at 14:00 on a Friday, with a shift running 08:00 to 16:00, uses two hours that Friday and the remaining two the next working morning. The overnight and weekend gap does not count. This matches reality: a staging or cooling wait measured in working hours does not expire just because everyone went home. The downstream step becomes eligible when the queue has genuinely elapsed in shop time, not before. For the definition on its own, see what is queue time in manufacturing scheduling.

A worked example

A weld-then-grind routing needs two hours of cooling after welding. Welding ends Friday at 15:00. The plant runs one shift, 08:00 to 16:00, Monday to Friday.

The engine sets a two-hour queue from Friday 15:00. There is one hour left in Friday's shift, from 15:00 to 16:00, so it consumes one hour there. The overnight gap and the whole weekend do not count. The second hour is consumed Monday morning, from 08:00 to 09:00. So grinding becomes eligible to start at Monday 09:00.

A flat, non-shift delay would have said Friday 15:00 plus two hours equals Friday 17:00, past the shift end, implying grinding could begin that evening when the shop is closed and the parts are staged in an empty building. The shift-aware queue gives the honest answer, Monday 09:00, which is when the parts have actually cooled during working time and someone is there to grind them. The buffer did its job: it protected grinding from starting on parts that were not ready, and it placed the wait where it really falls.

Queue, transit, and the right tool for the wait

Planned queue is one of three ways to model a gap between operations, and using the right one keeps the plan honest.

Queue time is for a shift-bound wait inside the plant: cooling, curing, drying, staging. It counts only working hours. Transit days are for a whole-day move off-site, such as heat treatment or plating at an outside vendor, and count calendar or working days regardless of the shift clock, because the vendor's calendar, not your shift, governs the parts. A flat transfer delay is for an instantaneous handling lag, like a conveyor move, that is genuinely elapsed hours rather than shift hours. The full composition is laid out in queue and transit times explained, and the way these gaps sum into lead time is in lead time as the sum of its parts.

One interaction to know: when a step overlaps its predecessor through lot streaming, the overlap gate replaces the queue-adjusted end, so queue on that step has no effect. Both mechanisms answer "when may the next step start," and the overlap wins. If you need a handling lag on top of an overlap, use the transfer delay, or place the queue on the downstream step where it applies after that step's own work.

The takeaway

Planned queue time earns its place. It represents a real, necessary wait, it is measured in the working hours that actually pass, and cutting it does not speed the job; it just moves the wait to somewhere that costs quality or a scrapped part. When someone points at queue time on a routing and calls it waste, ask which queue they mean. If it is the cooling buffer, leave it: it is protecting the part. If it is parts stacked in front of an overloaded machine, that is the real waste, and the cure is controlling load with finite capacity, not deleting a protective buffer.

Distinguish the designed wait from the congestion wait and you will cut lead time where it actually hides, without breaking the process. See how a shift-aware queue lands on your own routings in EDGEBIC, and follow how every gap composes into a schedule in the scheduling engine guide.