Root cause analysis
I get down to the root cause and close it with an action whose effectiveness can be measured. I do not stop at the symptom, because symptoms always come back — usually at a worse moment and under a different name.
The same defect returns despite closed corrective actions.
A customer rejected your 8D report and expects deeper analysis.
Reports name “human error” as the root cause and the analysis stops there.
CAPA actions are recorded, but nobody checked whether they worked.
The team knows the methods, yet under time pressure jumps straight to the solution anyway.
A closed analysis with a root cause backed by evidence, not by a hypothesis
An 8D report in a form the customer will accept
CAPA actions with assigned ownership and an effectiveness criterion
An updated standard and documentation, so the finding does not leave with the team's memory
Talking to the team and management, mapping the constraints: people, systems, deadlines and budget.
Mapping how the process actually runs, not how the procedure describes it.
What gives the largest effect for the smallest cost, in what order, and who owns what.
Working with users, piloting, training, correcting based on what practice shows.
Checking whether the change actually worked, then locking it into the standard.
Both, usually in that order. I run the first analyses together with the team on a real case of yours — that teaches more than a workshop built on a textbook example. The team then runs the next ones and I review them. The goal is for you to stop needing me for standard cases.
Because you cannot build an action on it. If a person could make that mistake and the mistake made it downstream, the questions are: why did the process allow it, and why did the control not catch it. Answers to those two can be turned into a process change. “Be more careful” cannot.
Usually yes. Reports come back for three main reasons: the root cause stops at the symptom, the non-detection analysis is missing, or the actions have no effectiveness criterion. Those are fixable inside the analysis itself — it is not a matter of describing the same thing more elegantly.
5 Why, Ishikawa, A3, 8D, FMEA and SPC. The choice depends on the problem: a recurring process defect, a one-off incident and a design problem call for different tools. The method serves the analysis, not the other way round.
Describe what is happening in the process and what you have already tried. I reply within one business day.
