Many problems in industries cannot be solved because of the unmatured problem description. Usually, the issue remains unsolved and reoccurs after some time. So what do we understand from the definition of the problem? Briefly, we should go back to the time when the problem happened and try to explain all the details at that moment. With this time journey, problem definition becomes dynamic and enriched with every new information.
In what detail should the problem be defined? Let me explain through a simple example. Imagine the production line of a regular pen. There is a %100 quality check at the end of the production line. An operator notices a crack on one of the pen tips. There are two scenes to examine in this case; the first one is when the failure was detected, and the other is when the failure occurred.
Let us try to define the problem. “At the end of the production line, a crack has been detected on a pen’s tip.” What do you think? Is this definition adequately detailed? Can the necessary analyzes be performed with this description to resolve the problem? Of course not. Let us improve and make the story more obvious.
“At the final force test, a crack has been detected on a pen’s tip. Pen traceability barcode number is 211222, and test machine no. is 301. Test definition: “Apply 30 N force on the pen tip five times”. The failure happened in the second repeat of the test ( Test acceptance requirement: “There should be no failure after the test”). No other error was found in the 3000 pens manufactured in the same lot at the same production line.
So let us just briefly go to the production step that the problem happened. During the pen’s pin installation, pushing force was read as 370 N, and the system continued to work without any warnings. Tolerance-set of the pushing system is 300 N+-20N, not over or lower pushing force has been seen on the other products in the same lot.
We should add all the information related to the problem to the description. Team members could develop the problem definition with new data in this way until passing Root Cause Analysis. If possible, the failure should be simulated and observed to get precise information to pass the root cause phase.
Consequently, if we cannot understand the problem, we can never solve it. In the first step, we need to define the problem in detail to understand it. The definition will remain alive and enriched with new learning. We should make sure that the problem is described in detail before proceeding with Root Cause Analysis. The more the problem definition is prepared with the details, the more it is close to the solution.