Problem solving

In French: Résolution de problèmes

Solving a problem, in the Lean Six Sigma sense, means going back from an observed symptom to a demonstrated cause, then checking that the action taken has indeed removed it — in that order, and without skipping a step.

Describe before explaining

The first step is not to look for why, but for what. A well-stated problem says what happens, where, when, on what, since when, and in what proportion. As long as those elements are missing, any explanation is an unverifiable hypothesis.

The gap between what is observed and what was expected must be quantified. "There is too much scrap" cannot be solved; "the scrap rate went from 1.2 % to 3.8 % on line 2 since 14 May, only on reference A" can — the description has already eliminated three quarters of the possible causes.

This step regularly consumes half the time of a successful resolution, and it is the best investment in the process.

Going back to the causes

The five whys chain the questions until a cause one can act on is reached. Simple and quick, they have a known flaw: they follow a single chain, the one the group has in mind, and miss parallel causes.

The Ishikawa diagram corrects that by sweeping the families of causes — manpower, material, method, machine, environment. It produces a broad inventory, whose merit is to bring out leads nobody would have proposed spontaneously.

Neither of them PROVES anything. They produce hypotheses, and the next step consists of checking them against data — comparison of groups, statistical test, or simply going back to the shop floor to observe. A cause validated by consensus in a meeting room remains an opinion.

Checking that the problem is really dead

A corrective action is judged on the measured disappearance of the symptom, not on the fact that it was implemented. The tracking board must show the indicator before and after, over a long enough period to rule out coincidence.

It then remains to prevent the return: standard updated, check built into the process, error-proofing device where possible. Without that, the problem comes back at the first shift change — and it comes back with the conviction, among those who treated it, that it had been settled.

The common mistakes

Jumping from description to solution. It is the most natural and the most expensive shortcut: one knows the remedy before having made the diagnosis, applies it, the symptom recedes a little, and the real problem remains. The recognisable sign is an action plan written before any data.

Stopping at the human cause. "The operator did not see it" is not a cause, it is an observation. The cause is what made the error possible — an ambiguous screen, two parts that look alike, a verbal instruction. Looking for someone to blame stops the investigation at the moment it was about to become useful.

Treating the problem without quantifying it. With no measurement before, no measurement after proves anything, and the resolution becomes a matter of conviction.

On the shop floor — Industrial maintenance

A recurring breakdown had for months been attributed to a component defect. The precise description showed that it occurred only on Monday mornings. The cause was the weekend shutdown and the associated condensation, never raised in meetings because nobody had dated the occurrences.

An article that covers it

Réviser par fiches ou par questions ?

Frequently asked questions

Are the five whys enough?

For a simple problem with a single cause, often yes. As soon as several factors combine, they lock you into a single chain of reasoning and give a plausible answer that is not the right one. The practical marker: if two different groups obtain two different causes on the same problem, the tool has reached its limit.

Are statistics always needed to validate a cause?

No. Direct observation at the station, a comparison between two batches, a trial that challenges the cause are often enough. Statistics become necessary when the effect is small compared with normal variability — that is, when the eye can no longer decide.

What is the difference between corrective action and remedial action?

Remedial action restores the situation — the part is reworked, the customer is called back. Corrective action removes the cause so that it does not happen again. Both are necessary, in that order, and confusing one with the other closes a problem that is going to come back.

When should you move to a DMAIC project?

When the problem resists a short resolution, when its causes are multiple or scattered, or when the stakes justify several weeks of work. A problem whose cause can be demonstrated in a day does not need a DMAIC — imposing one on it is the best way to discredit the approach.