Shortening lead times: find the waiting, not the working

Lead time starts the moment a case arrives in the company: the customer call, the incoming order, the fault report, the delivery note at the ramp, the leave request in the mailbox. It ends when the case is complete from the recipient's point of view: goods dispatched, invoice issued, information provided, repair accepted. Everything in between counts — including nights, weekends and the periods when nobody is working on the case at all. That consequence is what makes the metric uncomfortable and useful at the same time.

In practice three figures get confused. Processing time covers only the minutes somebody actively works on the case. On-time delivery describes whether a promised date was met — it can look excellent while lead time is long, simply because generous dates are promised. Lead time is the span in between. Only once these three terms are cleanly separated can statements about a workflow hold up in a management meeting.

A second point determines whether the figure is usable: the boundaries of the case. Does measurement start at first customer contact or only at order confirmation? Does it end with dispatch or with payment received? Both are defensible, but the definition has to be written down and kept stable over time. Otherwise you end up comparing figures that rest on different definitions half a year later. This definition belongs in the process documentation, not in a spreadsheet row nobody can find again.

The most common reason lead times are not measured is the fear of effort. It is usually unfounded. In almost every company, day-to-day operations produce timestamps that nobody records deliberately: the arrival date of an order in the inventory system, the moment a status changes from open to in progress, the date of the order confirmation, the time of dispatch, the posting date of an invoice, the arrival time of an email in a shared mailbox, the modification date of a file in storage.

Those stamps are entirely sufficient for a first analysis. You export them from the systems involved, join them on a shared case number and calculate the differences between stations. The result is not a measurement accurate to the minute, but it reliably shows between which two stations the days disappear. For prioritising measures that is enough — and it costs staff no extra second of data entry.

What matters is the distribution, not just the average. A mean of six days can mean that nearly all cases take six days — or that most are done within a day while individual cases sit for weeks. Two figures are useful in practice: the median as the typical case, and the range of the slowest cases. Only the slow cases reveal the breaking points, because that is where the workflow has no answer ready for a deviation.

Many workflows grew historically as a chain, even though the individual links do not actually depend on each other. The order is checked commercially, then assessed technically, then material is scheduled, then a date is planned. Examining the real dependencies often reveals that the technical assessment does not need the commercial check, and material scheduling could run at the same time as the technical assessment. Four consecutive steps become two stages.

The test for this is simple and fits into one meeting: for each step, ask which information or result it strictly requires from the preceding step. If that question cannot be answered concretely, there is no real dependency, only a habit. Distinguishing technical necessity from grown sequence is the core of any process analysis.

A related lever is pulling forward steps that need no approval. If material availability can be checked independently of the final order, that check does not have to sit at the end of the chain. Learning that a part will not be available for several weeks should happen on day one, not on day eight.

Every query costs at least half a working day of lead time, often more. The case is interrupted, the question formulated, the answer awaited, the context rebuilt on resumption. The trigger almost always lies at the start: during initial intake, details were not requested that turn out to be essential later.

The countermeasure is unspectacular and effective. Collect the queries actually raised over a few weeks, group them and add the missing fields to the intake form or entry mask. Frequently five to ten recurring questions account for the bulk of all queries: the exact delivery address, the contact person on site, accessibility, a meter number, the cost centre, the preferred time window.

Where cases arrive through a website form, a customer portal or an entry mask, mandatory fields and simple plausibility checks can be configured directly. Where intake happens by phone, a short and binding checklist at the workstation helps. Both are part of sensibly scoped process automation: the workflow is not clocked faster, the conditions are set so that interruptions occur less often.

The assessment does not have to burden operations. A pragmatic approach works without a dedicated staff function and delivers an analysis suitable as a basis for decisions after roughly four weeks. The decisive point is to limit it to a single workflow — the one with the highest volume or the greatest frustration.

Only once this round is complete is it worth looking at technical implementations. Automated handovers between systems, clean interfaces instead of manual transfer and automatic notifications for overdue cases have a far stronger effect once the workflow has been untangled. Automating a disorderly workflow only speeds up the disorder.