
-
Can't find what you're looking for?
Feel free to contact us, if you are looking for something special, because we also provide personalised training online or on-site.
In production, everyone wants to solve a problem, but few people know what the exact problem is.
In most companies, the problem definition is “quality is not good”, “the plan is not fulfilled” or “there is a lot of downtime”. But these are not problems, they are symptoms.
To start a real analysis, you need information, not opinion. Problem solving starts with a logical definition of what we are dealing with , based on data. It’s not complicated, you just need a system.
And just as importantly, the problem description should be written by those who are involved. Those who see it, experience it, deal with it on a day-to-day basis.
It should not be done by an external consultant or a dedicated “analysis officer” – it should be done by the team that actually works on the process.
👉 This is the first step towards breaking down the silos. If a common, fact-based description of problems is shared, it automatically builds links between areas. It’s not just problem-solving – it’s collaboration.
The biggest mistake we often see is that people start thinking about the solution without knowing exactly what happened.
This is where two simple but effective methods come in: 5W1H and Is / Is Not.
This method breaks the problem down into six questions. It works well because it doesn’t allow you to stay in the “broad generalities” of the mistake – you’re forced to be specific.
Suppose that “the daily production plan is not met”. This cannot be examined in this way. But if we go through the questions, the picture becomes clearer:
It is no longer just “not ready in time”, but a clear picture of what, where, when, whose territory and how is being damaged in the process.
If the scope of the problem is not clear, the Is / Is Not method is a good supplement. It helps to exclude what is not part of the problem and thus narrow the scope of the problem.
Example: cycle time problem on a line
What is true (IS) | What is not true (IS NOT) |
---|---|
Production line 1 | Other rows not concerned |
Morning shift | Afternoon and night no |
Red model | No problem with other colours |
Same operators | Does not occur with other operators |
That narrows the focus: something about the red model, the line, in the morning, and the people who work there. The “machine is to blame” may no longer be true.
Without a clear problem description, everything that follows – analysis, action plan, improvement – is guesswork.
A structured description gives you the basis on which to build.
The 5W1H helps to quantify, the Is/Is Not helps to delimit. Used together, it is much quicker to focus on reasons rather than guesswork.
But more importantly, if the problem description is prepared by the team itself, it is no longer a one-sided report, but a collective reflection. From the very beginning, the areas involved in the process are linked – and this is the first concrete step towards breaking down the silo approach 🧩.
It’s not a paperweight. It’s the basis for quality improvement.
Writing down the problem is not one step of many – it’s the step that, if you do it right, the solution is often halfway in front of you.
Attila Jezsó
Have a question? Contact us and together we will put together a tailor-made development package. We can even support you on the spot with consultants and coaches to make the change a success!
Visit us and follow us on social media!