(Please have a first read at the two former posts on Problem definition and correct root cause analysis previously to read this post)

The last and final part of the problem Solving is obviously the most important part. How is going to be the problem solved in terms of actions; Let us assume that one has gone through all the 5Whys analysis and there has been highlighted all possible root causes.

So now it is time to work about these root causes, each and any of them need to have an action implemented. One typical failure here is to assume actions on operators; If the root cause analysis is well done, no possibility should be allowed. Let me explain, the failure mode “operator did wrong the operation” should be addressed in the 5Whys for options like “working instructions were not defined” “The station was not well-defined to avoid these kind of failures”, etc… Bear in mind that we all are humans and we all make mistakes, never leave to the operator the solution, help him to work but do not rely on their performance for a solution. On the contrary please do involve them in technical solutions proposals, no one would define better a Poka-yoke than the operator that knows the machine. Conclusion is: Only apply technical actions as much as possible on the process.

Actions should have responsibles and dates clearly defined. And the responsibles should be the owners of the processes. The leader of the problem solving initiative would be responsible to follow-up and make sure that all actions close on time. So maybe it would be necessary follow-up meetings on the items. Important point is that if you choose a containment action temporary until the final is implemented, there should be a monitoring that this containment action is in place in the meantime avoiding any risk on re-occurrence of the problem.

The last part of the problem solving methodology is the so-called “lessons learnt”, to say, who are we going to learn in our organisation to avoid the problem to occur again. This is equal or plus important than all steps before, because if we do not learnt from failures and apply these learning to future projects, standardisation on product, machines etc… failure would be reproduced and there is a lot of work lost.

One very simple and good methodology of lessons learnt is the FMEA. The main reason it is because in the PFMEA/DFMEA is an alive document that many people consult in your organisation and that is taken as a reference for new projects or similar product definitions. Furthermore, many FMEAs in companies are done for families of products. Mature companies, nevertheless, have also different ways of recording the “lessons learnt” and share the information among the company.

Once everything is solved and your customer (external/internal) is informed about the closing of the problem solving analysis. It is very important to congratulate your team and give them feedback and make your people feel proud of their work.

Post by miguelbrinesconsulting.com