Every production team knows it. A complaint or defect you "solved" last month. And the month before. A machine that stops again a week after repair. Scrap rates that drop after adjustment and are back three days later.
At that moment, the most tempting phrase on the shop floor almost always comes up: "Just adjust it and keep going." And it works. Until next time.
The symptom gets fixed quickly. The cause comes back expensively.
The difference between a symptom and a cause is the difference between peace until the end of the shift and peace for good. When a part goes out of tolerance and you simply fine-tune the mould, you've solved that one part. The mechanism that produced the defect is still in place. Next changeover, next shift, next part — and the problem is back, often with interest in the form of another complaint.
When you solve a problem at the symptom, you've bought yourself peace until the next shift. When you solve it at the root, you've bought it for good.
Every unsolved problem has its BUT
"We'd change the procedure, BUT there's no time." "We'll sort it out properly, BUT there's another fire burning right now." That BUT is the excuse behind which a deferred solution hides. And as long as that BUT is there, the problem has somewhere to live.
Opposing it is OLIN: an approach that doesn't ask who's to blame, but what is actually happening and why. No guesswork, just data, observation and logic. The good news is that this isn't a gift for the chosen few. It's a process that can be learned and repeated.
From chaos to certainty, step by step
Structured problem solving isn't a single method, but a chain. One link connects to the next. Skip one and the whole thing falls apart.
- Name the problem in measurable terms. "We have a quality problem" can't be analysed. "Scrap rate rose from 1.8% to 4.6% from the twelfth" can. Without a number, you don't know when you've won.
- List all suspects. A fishbone diagram (Ishikawa) across the 6M categories — man, machine, material, method, measurement, environment — ensures you don't miss anything. Don't evaluate yet, just collect.
- Narrow the field. Go to the gemba, i.e. directly to the process, and open up the data. A Pareto chart usually shows that the vast majority of problems are caused by a small handful of causes. Focus your efforts there.
- Verify, don't guess. Compare where the problem is and where it isn't (Is / Is Not). Tentatively remove the suspected factor and observe whether the defect disappears. Then try to deliberately reproduce it. What passes both tests is a certainty.
- Ask "why" five times. Only with a confirmed cause does it make sense to go deeper. Five times "why" takes you from the symptom to the root, which is under the organisation's control, not chance.
- Define countermeasures. Three types, each a different task: immediate (protects the customer now), corrective (eliminates the root cause) and preventive (so the same thing doesn't start elsewhere). And don't forget the documents — FMEA, instructions, control plan.
- Verify that it works. A countermeasure isn't done when it's implemented, but when the numbers a few weeks later show the problem is gone. Otherwise you've only temporarily masked it.
What it looks like in practice. Part above upper tolerance. → granulate was insufficiently dried → drying ran for 60 instead of 120 minutes → the setter used an old setup sheet → the current sheet didn't reach the press after the parameter change → the change management process has no step to verify that the new version has actually reached all machines. That's it. If you'd stopped at "let's extend the drying time", you'd solve one machine. The root cause is systemic, not technical.
Notice that the most powerful countermeasure in this story isn't more checks or more operator attention. It's a change after which the error simply has no way to occur: the press loads its parameters automatically from the scanned part, and the paper sheet and human oversight disappear from the equation. This is called Poka-Yoke, and it's the difference between "we'll be more careful" and "it can't happen anymore".
The point: excuses have nowhere to hide
When you go through the entire chain, something interesting happens. The space for BUT disappears. The cause is documented with data, the countermeasure targets the root, has an owner and a deadline, and you know exactly how you'll recognise that it worked. That's not bureaucracy. That's efficiency without excuses.
Try it on your own case
In the iDomino platform, the Action Plan keeps the entire analysis and countermeasures together — from analytics data through Ishikawa and 5× Why all the way to corrective and preventive actions with an owner, deadline and traceability. You create a project from a fault report with a single click.
