This post will be included in the three ones dedicated to the Problem solving analysis introduction, dividing the problem solving in three phases: problem description, root cause analysis and action plan.
Let us start for the problem definition. This is the most important part and the one that one usually dedicates less time. A bad definition of the problem combined with giving less information than necessary to a supplier can lead to a wrong root cause analysis and obviously to an incorrect corrective/preventive action… and the worst: problem to appear again.
When my team reported me about a problem I realized in general I keep asking, what happened, how many parts are affected, where was it found? But why do I asked? Because information was missing or the fire was too much “burning” all over the place for them to analyze well the situation. The first thing someone needs to do for a good analysis is hide himself/herself from production fire five minutes and try to grasp the situation. And this is serious: being answering five phone calls; explain situation to six managers, does not allow you to have time to understand the situation and obviously react. Get out of the fire five minutes and analyse the situation before taking decissions or address the issue.
Try to grasp the situation is asking himself/herself the W’s Questions: What, Where, When, Who, which, How Many, .. Ask yourself things like this: “what happened, what is the problem? Where Was it found? Who detected the problem? How many parts will be affected? Which is the effect/impact of the problem? Why was not detected ?” etc..
Any of the questions that have no answer, please do contact production/ Customer quality / supplier, and other interlocutors … because they can provide you the required information.
In my opinion, the latter sometimes is not enough. We know roughly the problem, now we need to delimitate the problem more accurate to avoid risks. Spend other 5 minutes asking your self the IS/IS NOT technique. That means you need to define the problem not only about the area but excluding other areas. For example “it is a single issue it is not a repetitive”. “It is an incident in the surface it is not a functional issue”. “It is a single customer product it is not a whole range of products issue”, etc…
Only by knowing exactly the problem can you explain it. A quick understanding can lead to a quick containment action which would be the next point. And at least stop occurring the problem until the final actions are taken. To be continued…
Post by miguelbrinesconsulting.com