Find the process bottleneck before adding people or software

Choose a flow with a clear finish

A busy team may describe the problem as “not enough staff” or “we need an ERP”. Those are possible responses, not diagnoses. First identify what is waiting, where it waits and what counts as a completed job. Keep the initial review small enough to trace actual work.

For a distributor, the boundary might be a valid customer order through to dispatch confirmation. For a service business, it might be a complete request through to an accepted deliverable. In a finance team, it could be an invoice received through to an approved, reconciled payment record. Do not compare these different units as though an “item” represents the same effort.

Agree the working calendar and cutoff times. A “day” might mean a working day for one team and a calendar day for another. When work crosses markets, reconcile local calendars, time zones and customer commitments explicitly. This is an operating question; no single GCC-wide calendar or service rule is assumed.

Observe the work, including the waiting

Sketch the current steps with the people who do the work. At each hand-off, record the responsible role, the input needed, the output produced and the reason an item cannot move forward. Include rejected work returning to an earlier step; a neat one-way diagram can hide repeated effort.

Use a representative observation window that includes ordinary and busy periods. For each job, capture arrival, ready-for-work, work-start, work-finish and final-completion timestamps where practical. These distinguish missing-information delays from queues of work that is actually ready. Record exceptions separately rather than quietly removing difficult jobs from the sample.

Keep three measures distinct: touch time is time spent actively working on the item; elapsed lead time runs from the agreed start to the agreed finish, including waits; completed output is the number of acceptable jobs finished in the period. A faster task is useful only if it helps the required outcome. Use consistent definitions before comparing teams.

A fictional order-flow example

A fictional distributor receives 20 comparable orders per working day. Every order requires entry, review, fulfilment and dispatch. The capacities below are assumed acceptable orders per working day after normal interruptions and quality losses. They are not measured benchmarks, staffing recommendations or promises for a real business.

For this simplified, adequately supplied flow, the slowest required stage sets an output ceiling of 16 orders a day. With 20 new orders arriving, unfinished work can grow by 4 orders a day. Faster entry alone does not change that ceiling.

The example starts with 60 unfinished orders and assumes the pipeline can sustain the stated rates. If the flow achieves that ceiling over five working days, 100 new orders arrive and 80 complete: 60 + 100 − 80 = 80 unfinished orders. This is an aggregate balance illustration, not a simulation of individual order dates or queues.

All figures are invented. The output ceiling is not a forecast or a customer delivery commitment.

Compare the whole-process effect

Consider three proposed changes against the baseline. The figures are deliberately simple so the limiting step is visible. The improvement capacities are hypotheses to validate in a controlled trial, not benefits already delivered. The five-day balances assume each stated ceiling is achieved throughout the period.

At an output of 24 and arrivals of 20, the net reduction is 4 unfinished orders per working day. Clearing the opening 60 would take 60 ÷ 4 = 15 working days under the constant-rate assumptions. Once that opening backlog clears, output cannot sustainably exceed new arrivals without more demand. The calculation does not provide an individual customer delivery date.

Raising review capacity to 30 does not create 30 completed orders a day: fulfilment is still limited to 24. Its queue may grow even while review’s own queue shrinks. Track total unfinished work as well as stage queues so the reported improvement cannot simply move the problem out of one team’s dashboard.

Test a change without removing the safeguard

Ask why review is slow. Is information missing? Are several people checking the same field? Does every routine order wait for one approver? Are specialist exceptions mixed with standard work? Different causes need different remedies; the smallest capacity number alone does not identify the cause.

A possible trial might standardise the input checklist, remove duplicate data entry, make approval limits explicit or separate exceptions for qualified review. It must preserve the required credit, quality, fraud, safety and compliance checks. A queue is not a reason to bypass an approval or weaken an independent check.

Before the trial, agree the responsible owner, the change, its time and cost, the observation window and a stop condition. Compare acceptable completions, queue age, total unfinished work, rework, complaints and control failures against a comparable baseline. Include the time spent checking the new process; an apparently faster system that creates more review work elsewhere may not improve the business.

Know when the simple calculation stops helping

The minimum-capacity comparison assumes comparable work, a required sequence, adequately supplied stages and effective rates that are meaningful over the chosen period. It does not model daily fluctuations, different job sizes, shared staff, batching, parallel routes, changeovers, priority overrides or correlated downtime. An average can conceal a difficult peak.

Do not infer an exact lead time from the capacity table. Measure actual timestamps and the age distribution of work. If orders need different routes, use separate families or a more detailed process model. If one person serves several stages, do not count that person’s hours as independently available at every stage.

Keep the commercial question in view. Faster completion matters when it improves service, releases constrained capacity or changes avoidable cost. It is not automatically additional revenue or cash savings. To assess an investment, connect the tested operating change to actual demand, contribution, implementation cost and the timing of cash. Recheck the constraint after any change.