An order passes through several departments. Each one does its part quickly, and the customer still gets the result days later. The reason often isn't the work itself. It's the gaps between activities: waiting for a free slot, a decision, a delivery or the end of another stage.

That matters when you're choosing what to improve. Automating a task that takes 20 minutes may save effort. But if the order then sits for two days before the next stage begins, the delivery date may not move at all. For the company, that's the difference between making one department more efficient and improving the date it can promise a customer.

Two clocks worth keeping apart

The first is the full lead time as the customer sees it: from placing the order to receiving the result. The second runs from the moment the company has all the information it needs to start work until the result is delivered. Separating the two isolates the waiting that happens before work can begin. It doesn't mean every later delay is the company's fault.

Both measurements need care. If an order is waiting for the customer to reply, that time still affects the delivery date. Flag it in the analysis instead of simply cutting it out. In the same way, don't assume that the time between a task being opened and closed in the system equals the time someone actually spent working on it. As the previous part showed, a status in the system doesn't tell you everything about what really happened.

The longest gap doesn't always delay the customer

Take a simplified example. Two independent parts of the work, A and B, start in parallel. Part A contains two days of waiting but still finishes on day three. Part B finishes on day four. The order is ready only when both parts are done.

Removing both days of waiting from A won't change the delivery date. The company still has to wait until day four for B. The change may have other benefits, such as a bigger buffer against disruptions, but on its own it won't shorten this order.

It's a different story if B can be cut from four days to three. With A unchanged, both parts now finish on day three and the whole order closes a day earlier. The model doesn't say whether shortening B is feasible or worth the money. What it shows is the kind of effect on the delivery date to look for before you decide.

So the longest wait is a starting point for the analysis, not automatically the best place to invest. In different types of orders, the dependencies between stages can look completely different.

Where do the gaps between activities come from?

Waits that look alike can call for entirely different fixes. Research on waiting times in business processes distinguishes, among other causes, work being batched, competition for the same resources, prioritization and resources simply being unavailable.

If cases sit in a queue, look at the team's workload and capacity. If orders are only handed over once a day, the problem may be the schedule, not how hard people work. When the next step depends on a supplier or the customer, you may need to agree dates earlier or organize the collaboration better.

Some gaps are there because the process requires them, such as a mandatory quality check. Its purpose isn't to slow things down but to make sure the job can be closed safely. Corrections and rework, on the other hand, may mean the cause of the errors needs fixing, rather than the check itself being sped up.

The practical conclusion: first name what the time is being spent on, then judge whether changing it would bring the end of the whole case forward.

How to find the change that will actually shorten the lead time

You don't need a new process-analysis platform to start. The process owner can reconstruct the path of a few dozen similar orders in a spreadsheet. That's a first diagnosis of the mechanism, not a representative measurement of the whole company.

A time and delivery-impact map in four steps works well here.

1. Set the start and the end from the customer's side. Write down when the order was placed and when the result was actually delivered. Mark separately the moment the company could have started work with complete information. Don't swap the customer's date for one team's working time.

2. Trace comparable cases. Pick orders of one type that came in over a set period. Mark work, waiting, rework and parallel stages. Look at the oldest cases still open too, because analyzing only finished ones can hide the cases that take longest. If the real working time is unknown, don't derive it from system statuses alone.

3. Check what moves the end date. For the significant gaps, establish the cause, how often it recurs and its effect on the whole order. Ask: if we shortened this stretch, would the customer get the result sooner? With parallel work, take the other stages into account. At this point the answer is a hypothesis to test, not a certain result of a simulation.

4. Choose one small test. Depending on the cause, that could be more frequent handovers, a different schedule, new priority rules, extra capacity, a system integration or automating one specific task. Name the test owner and how results will be compared before and after. Compare cases of the same type and allow for differences in workload.

What exactly should the board get?

The diagnosis should end in a short note that lets someone decide: which cases were analyzed, what was delaying their completion, what that conclusion rests on, what we propose to change, who owns the test and how we'll know the result.

A hypothetical conclusion might look like this:

In the standard orders we reviewed, some jobs waited for the daily handover window before work could start. In the cases analyzed, that wait affected the delivery date. We propose handing over selected orders twice a day for a set period. The process owner is responsible for the test. We will measure the time from order to delivery, the number of corrections and the backlog at the next stage.

That isn't proof that more frequent handovers will help every company. It's an example of a result that ties the diagnosis to a specific action and makes its effects checkable.

If, after the change, one department works faster but the delivery date doesn't improve, the investment has to be judged against its real purpose. Automation can still save labor, improve quality or increase the number of cases handled. Just don't present those benefits as a shorter lead time for the customer if the measurement doesn't back it up.

Faster delivery starts with picking the right place to change. What counts isn't the length of the most visible gap but its real effect on when the order is done, confirmed by the result of the whole process rather than the statistics of one department.