This is the two-week sequence we run before we change anything in a client's operation. It is deliberately boring and deliberately repeatable, and plenty of operators run a version of it themselves and never call us — which is a perfectly good outcome. What follows is the whole thing: what to agree up front, what to watch, which data to pull, who to talk to, and how to turn the pile of findings into a ranked list somebody can actually act on.

Why diagnose at all

Almost every operation we walk into already knows it has a problem. What it usually has wrong is the location. The symptom shows up at the last station — a late shipment, an escalation, a quality reject — and the cause sits three steps upstream in a handoff nobody owns. Fix the symptom and you get a temporary improvement plus a new symptom somewhere else.

The other reason is money. Without a diagnostic you end up spending on the most visible problem rather than the most expensive one, and those are rarely the same. The single most under-measured cost in most businesses we see is turnover, because the invoice never arrives — every exit quietly takes documented process knowledge with it and the cost lands as slower cycles and more rework months later.

Step 1: agree the baseline before you look at anything

Do this first, in writing, before anyone walks the floor. Pick the four or five numbers the operation will be judged on and record today's values:

Throughput per shift, or units and orders per labor hour
Cost per unit, per order, or per service call
On-time rate, measured the way the customer measures it
Rework, scrap, credit or return rate
Overtime hours and open vacancies by department

Get the owner to sign off on those values. This takes an hour and saves the entire engagement, because without a baseline agreed in advance every improvement is arguable afterwards. The most common failure mode in operations work is not a bad recommendation — it is a good change nobody can prove worked.

Step 2: walk the floor and watch whole cycles

Stand in the operation. Follow single units of work from arrival to completion, more than once, across more than one shift. Night shift and day shift are frequently running different processes under the same SOP number, and the gap between them is often the finding.

Time the waiting, not just the working

The instinct is to time tasks. Task times are usually fine. What is not fine is the gap between them: the pallet sitting because the next station is blocked, the order held because a manager has to approve something, the technician driving back for a part. In most operations the majority of elapsed time is queue time, and queue time is where the cheap wins live because removing it needs sequencing changes rather than capital.

Count the handoffs and the human middleware

Write down every point where work changes hands or changes system. Then mark every place a person is retyping data from one screen into another, maintaining a spreadsheet that reconciles two tools, or forwarding an email so a status gets updated. That list is your automation backlog and it is usually shorter and cheaper than anyone expects, because most operations already own the software they need — what is missing is the handoff between two of them.

Step 3: pull the data that contradicts the story

Ask for operational records, not management reports. Reports have already had judgement applied to them. What you want is raw: timestamps, exception and override logs, credit memos with reason codes, overtime by department by week, turnover by role and tenure, inventory adjustment history.

Read it looking specifically for numbers that disagree with what people told you. The disagreement is the finding, every time. When a supervisor says a step takes ten minutes and the timestamps say the median is thirty-one with a long tail, the interesting question is not who is right — it is what happens in the tail, because that is where the cost is concentrated.

Step 4: interview the people doing the work

Interview operators separately from their supervisors, and ask questions that are about the work rather than about opinions. Three that earn their keep every time:

What do you work around? Every workaround is a process defect with a person compensating for it.
What do you do twice? Duplicate entry, duplicate checking and duplicate approvals are pure recoverable cost.
What would you change if nobody could say no? The answer is usually correct, cheap, and has been raised before.

The person doing the job usually knows what is broken. The diagnostic's job is not to discover it but to price it, so that it stops being an opinion and becomes a line item with a number next to it.

Step 5: score the six pillars, then rank by annual dollars

We score every operation across six pillars — quality, safety, customer service, people, flow and systems & data — because that forces the finding back to its cause rather than the place you noticed it. Quality failures are usually specification or handoff problems appearing at the last station. Service escalations are usually operations failures that reached the customer. Safety incidents are the most expensive form of unplanned downtime, and the cost lands long after the event. And the handoff between two systems, currently performed by a person, is the one almost nobody has costed.

Scoring runs across the stages as well as the pillars. Every operation moves work through the same six — plan, source, make, deliver, return and enable — and walking them in order is what stops a finding being pinned on the place it was noticed rather than the place it started. A late delivery is rarely a delivery problem. A quality escape is rarely a make problem. See the six stages for what each one covers. The structure follows SCOR, the reference model published by ASCM, because it is the language your suppliers, customers and auditors already use.

Then convert everything into annual dollars and sort. Not severity, not urgency, not how irritating it is in the weekly meeting — annual dollars, using your actual measured rates rather than industry averages. Effort and political difficulty go in a second column so the owner can pick a first move, but they never get mixed into the value estimate, because that is how expensive problems get quietly deprioritized for being hard.

What the output should look like

A ranked list, one line per finding, each with the annual cost, the evidence behind it, the proposed change, and who has to agree. Ten to fifteen items is normal. If your list has fifty, you have written down observations rather than findings.

What happens after the diagnostic

Design comes next — usually two weeks — redesigning the workflow around the constraint with the team who will run it, not in a document. Then deployment alongside your people over roughly four weeks: training, cadence, dashboards, and the first measured result against that baseline you agreed in week one. We aim for a visible, measurable win inside six weeks, because early proof funds the trust needed for the bigger change. Across 18 years of operations leadership and consulting engagements the average cost reduction lands around 18 percent.

One warning worth repeating: if the improvement depends on someone from outside still being there, the job is not finished. A diagnostic that produces a dependency has failed, however good the findings were.

Run it yourself, or have us run it

Everything above is repeatable without us, and the template library has the mapping sheets and scoring models our own consultants use if you want a head start. If you would rather see what the number looks like first, the savings calculator gives a rough annual figure from your team size, loaded hourly cost, revenue and the pillars where you feel pain.

And if you want the diagnostic run properly, that is a 30-minute call to start — no deck, no pitch, and a straight answer about whether we are the right team for it.

How to run an operations diagnostic