Lead Time as the Sum of Its Parts

Lead time is the sum of setup, run, queue, move, and transit, and on most busy floors queue time is the largest of those by far. A job that needs only a few hours of machining routinely spends days on the floor, because between each operation it waits for a busy machine and travels between work centers. Knowing the breakdown tells you where to cut: speeding up machines attacks run time, which is usually the smallest slice, while the days actually live in queue and transit. EDGEBIC by User Solutions schedules each component explicitly, so the dates it produces show you where your lead time really goes.

The plain definition sits in glossary: lead time. This post breaks lead time into its parts so you can aim reductions at the parts that matter.

The five components

Every operation's contribution to lead time is built from a small set of pieces, and the job's total lead time is these summed across its routing:

• Setup time. The time to prepare a machine for the job before it runs. Sequence-dependent, so it depends on what ran before.
• Run time. The actual processing: pieces times the time per piece. The part everyone thinks of, often the smallest.
• Queue time. The time the job waits for a busy work center before it can start. Usually the largest.
• Move and transit time. The time spent traveling and staging between operations, or between plants. A routing step can also carry its own move and teardown hours, which extend the operation's footprint past setup and run.
• Wait or flow gating. The time an operation waits for its predecessor, reduced when operations overlap through lot streaming.

The engine places each of these explicitly. Setup and run consume machine hours; queue emerges from finite capacity when the machine is busy; transit is a modeled delay between steps; overlap is controlled by the transfer batch.

A worked example: 3.5 run hours, 3 days on the floor

A part runs Saw (0.5 h setup, 1 h run), Mill (0.5 h setup, 2 h run), Inspect (0 setup, 0.5 h run): 4.5 hours of setup plus run combined. Here is where the three days come from:

Roughly 29.5 hours of elapsed time, about three working days, from 4.5 hours of setup and run. Queue is 20 of those hours, more than four times the run time. The machining was never the problem. The waiting was.

Why speeding up machines disappoints

This breakdown explains a common frustration. A shop invests in faster tooling, cuts run times by a third, and watches lead time barely move. Of course it barely moves: run time was 3.5 of 29.5 hours, so cutting it by a third saves about 1.2 hours out of 29.5, a rounding error against the total. The tooling was worth doing, but it attacked the smallest slice. To move lead time you have to attack the queue.

Where each reduction actually lands

Aim each lever at the component it touches:

• Queue time. Lower it by planning below full load so there is protective capacity, since queue explodes as utilization approaches 100 percent, the subject of why 100 percent utilization is a trap. Resequence so fast jobs do not wait behind slow ones. Offload to an alternate work center to spread the load.
• Setup time. Cut it with sequence-dependent setup and campaign sequencing, grouping like jobs so changeovers shrink, as in how sequence-dependent setup shapes a schedule.
• Move and transit. Cut the distance work travels, which is where transit time between plants can add days, and where a dedicated cell removes transit almost entirely.
• Wait between operations. Overlap operations with transfer batches so the downstream step starts before the upstream one finishes, the batch size versus flow time trade-off.
• Run time. Faster tooling and better methods, worth doing but usually the smallest lever.

The diagnostic value of the breakdown

The reason to decompose lead time is that it turns a vague goal ("cut lead time") into a targeted one ("cut Mill queue"). Once you can see that queue is 20 of 29.5 hours and all of it sits at the Mill, you know the Mill is either a bottleneck or badly sequenced, and you know that faster tooling anywhere else is wasted effort. This is the same reasoning behind finding your bottleneck: the component breakdown points straight at the constraint, because the constraint is where the queue piles up.

A finite schedule gives you this breakdown for free, because it places setup, run, queue, and transit explicitly rather than lumping them into one lead-time number the way a fixed catalog lead time does. This is the difference between a schedule that tells you a job takes three days and one that tells you why. Over 35-plus years, from GE Railcar's climb to 90 percent on-time delivery to job shops quoting realistic dates, User Solutions has cut lead times by attacking the queue, not the run time. The full engine pipeline is in the scheduling engine guide, and the fundamentals of the schedule itself are in what is production scheduling. To see where your own lead time goes, component by component, bring your data to EDGEBIC.