Operating processes examples compared: the usual blame versus the real cause

What to take away

Process problems present as symptoms, and the symptom usually suggests the wrong cause. That is why the same fixes get applied to problems they do not touch.

Operating processes examples compared here include Kanban at Toyota, value stream mapping from Lean, and poka-yoke by Shigeo Shingo. The list also covers standard work in the Toyota Production System, CAPA under ISO 9001 and FDA rules, HACCP for food safety, and the Theory of Constraints from Eliyahu Goldratt.

The sections are organized by what you observe. Each entry gives the usual blamed cause, the cause that is usually true, and one action for this week. None describe a real organization; they are ordinary shapes. Match on the symptom rather than on a story.

ITIL knowledge management: the same question keeps arriving

Usually blamed on: people not reading the documentation.

Usually true: the answer exists somewhere the question does not. Somebody hits the problem at a particular moment, and the documentation is in a system they are not in, phrased around a topic rather than around the moment. Occasionally the document answers a different question that looks similar, which is worse, because people stop asking and start guessing.

ITIL 4 names this practice knowledge management. ServiceNow sells a Knowledge Management module, and Atlassian makes Confluence, both used for this job.

This week: collect the exact wording of the last five times it was asked. Not your summary: the actual sentences. The wording tells you where the person was and what they were trying to do, and it usually points at a spot in the flow where the answer could sit. Then put it there, in one line, and see whether the question stops.

If it does not stop, the question is a decision in disguise, and people are checking rather than looking up. That is a delegation boundary problem, which belongs with team management rather than with documentation.

Kanban: everyone is busy and nothing finishes

Usually blamed on: not enough people.

Usually true: too many things started. Work in progress is invisible while work not started is visible, so the natural response to pressure is to start more, which lengthens every queue including the ones that were nearly done.

Kanban, developed at Toyota and adapted for software by David J. Anderson, limits work in progress. A WIP limit caps how many items a team can carry at once. Toyota's Taiichi Ohno developed kanban cards to signal replenishment.

This week: count two numbers for one team. How many pieces of work are open right now, and how many were finished in the last week.

If the first is several times the second, adding people will not help and may not even be affordable in coordination cost. Stop starting things, finish what is closest to done, and watch what happens to the finishing rate.

This one is usually met with an objection that everything is urgent. Sometimes true, and in that case the queue is being fed faster than it can drain, which is a decision about intake rather than about effort. The productivity systems view of the same problem covers the personal version.

Poka-yoke: the improvement worked for a month

Usually blamed on: people reverting out of habit or resistance.

Usually true: the improvement depended on somebody's attention, and attention moved. If the new way is even slightly more effort than the old way, and the old way still works, the old way returns as soon as the person who cared is busy.

Shigeo Shingo developed poka-yoke at Toyota to make errors impossible or obvious. The term means mistake-proofing, not blame.

This week: find out whether the previous path is still available. Not discouraged: available. If a form can still be sent by email when the point was to route it through a system, email wins, because it is one step shorter for the sender and the cost lands on somebody else.

A change survives when it is the easiest route. When it is not, it needs continuous enforcement, a running cost most teams cannot pay.

So prefer the version that removes the alternative over the version that forbids it. Design the work so the wrong route is unavailable, not discouraged. That is poka-yoke.

Standard work: two competent people do it differently

Usually blamed on: a lack of standardization.

Usually true: some of the differences matter and most do not, and enforcing uniformity across all of them costs more than the variation. The important question is whether the difference is visible downstream. If whoever receives the output cannot tell which of the two did it, the variation is free.

Toyota's standard work defines takt time, work sequence, and standard inventory for a job. It does not require every keystroke to match.

This week: take one recent case from each person and follow the output to whoever uses it next. Ask them, without saying why, whether these two look different to them and whether it changes anything. The answer sorts the differences into the ones worth a standard and the ones worth leaving alone.

Where a difference does matter, resist writing a rule immediately. Find out which one is better first, because there is a decent chance the standard you would have written is the worse of the two, and the person doing it the other way has a reason nobody asked for.

Value stream mapping: the work is fine and always late

Usually blamed on: the people doing the step.

Usually true: most of the elapsed time is spent waiting rather than working, and the waiting is invisible to everyone except the person at the front of the queue. Speeding up the step improves a small share of the total and is the most expensive place to intervene.

Value stream mapping, described by Mike Rother and John Shook in Learning to See, charts process time against lead time. Toyota uses it to separate value-adding work from waiting.

This week: take five recent completed items and, for each, write down when it arrived and when it was finished. Then ask the person who did it roughly how long the actual work took. The gap between the two totals is the size of your real problem, and it is usually uncomfortable.

Once you have that gap, ask what it was waiting for. Approval, an answer, a system, another team, or simply its turn. Each has a different fix. Only the last is about capacity.

Watch when you start the clock. A queue that forms before work is formally received will not show up in anything you record now.

CAPA and HACCP: a step nobody can justify, and everyone defends

Usually blamed on: bureaucracy.

Usually true: the step catches something, and the person who knew what has left. Controls outlive their explanation more often than they outlive their purpose. The defenders are not being irrational; they have seen the step matter once and cannot articulate why.

CAPA under ISO 9001:2015 clause 10.2 and FDA 21 CFR 820.100 exists to find causes and prevent repeats. HACCP uses critical control points to manage food safety hazards.

This week: instead of debating it, look at the last several times the step produced a result. If it never fires, it is genuinely dead and can go.

If it fires occasionally, find out what it caught and whether anything else would have caught it. Then write the reason down next to the step, which is the thing that should have happened originally.

Removing a control that proves load-bearing is the most expensive mistake here. Damage shows up later, in another part of the operation, where nobody connects it.

Dropping one safeguard because nothing happened, then the next, is the drift called normalization of deviance. The quality management treatment of controls covers what is worth keeping.

Theory of Constraints: a modest rise in volume broke everything

Usually blamed on: the volume.

Usually true: one step was absorbing variation using slack that has now gone, and everything downstream of it is starved while everything upstream piles up. Processes rarely degrade smoothly; they run fine and then stop running.

Eliyahu Goldratt set out the Theory of Constraints in The Goal. Its five focusing steps start by finding the constraint, then exploiting it before adding capacity.

This week: find where the queue is. Not where the complaints are, which is usually downstream of the problem where people are idle and visible. The step with work stacked in front of it is the constraint, and effort spent anywhere else changes nothing.

Then check whether that step is slow or merely interrupted. A step that could run at twice the rate if the person doing it were not also handling questions is a scheduling problem, not a capacity one, and it is much cheaper to fix.

How to use these: A3, DMAIC, and blameless postmortems

Match on the symptom, then check the boring explanation before the interesting one. Most of the diagnoses above are dull, which is why they get skipped in favor of explanations about culture or motivation.

Toyota's A3 problem solving keeps a problem, analysis, and action on one page. Six Sigma's DMAIC cycle came from Motorola and was popularized by General Electric. It adds define, measure, analyze, improve, and control. Google's SRE book describes blameless postmortems for incidents.

Then change one thing and write down what would make you put it back, which is the discipline the operating processes pillar returns to repeatedly. Situations involving people rather than flow are handled differently, and there are worked ones in management foundations examples.

Common questions

What if two of these are happening at once?

They usually are. Start with the queue, because a system with work piled in front of one step will produce several of the other symptoms as side effects, and fixing those first gets undone.

How much investigation is proportionate?

Almost all of the checks above take under an hour and use cases you already have. If a diagnosis needs a data collection project before you can begin, either the problem is large enough to deserve it or you have chosen a measurement that is more precise than the decision requires.

People will not tell me the real story. What then?

Look at artifacts rather than asking. The private spreadsheet, the folder of past examples, the message thread where the real coordination happens. None of those are opinions, and all of them show where the designed process is not sufficient.