I have seen it multiple times, there are problems in the production floor; a situation that happens very often and everybody is looking for a solution. Very recently during a routine cycle count, somebody read the label very carefully and realize the label did not match the product. After verification of the product, we found that the last three times we packed that product the wrong description was used on the label. How it is possible that during four different production days the product had the wrong information on the label and nobody picked up the problem.
Maybe we need to add an inspection point to verify the label, wait; we have quality inspectors coming once every hour to inspect some information on the label, not all of it. Do we need more inspection? The question is, can the same person who changes the coder information, inspect the label right after choosing the new code?
Quality at the Source is a concept or tool where product quality is measured or inspected every step of the process. If the operator of every step treats the next step operator as his/her customer, then they aim to deliver the customer the product they need, with the quality and quantity desired on time. The use of specialized tools or technology helps the operator to accomplish the quality expectations. We can combine quality at the source with the use of Poka-yoke or “mistake-proofing” devices.
With employees participation, the process of selecting the best process to ensure quality will be a good first step towards a problem solving and continuous improvement mentality. After selection of the right process, training to all affected employees on who, when, where, what and how to perform the inspection is the second step. Then we go to the plan execution and the subsequent analysis to determine if additional changes are necessary. If no changes are necessary then the new process becomes the standard and quality at the source has been implemented.
The other day browsing through my twitter account I read a tweet from Mark Graban about a problem-solving tip for 5 Whys: “it’s not always magically five whys to get to a possible root cause”. That tweet and some of the subsequent conversation reminds me of an experience I had recently.
One activity that we have been doing a lot lately is root cause analysis. Our quality program requires the completion of a root cause analysis to support all corrective and preventive actions proposed. After our most recent third-party audit, we decided to complete an analysis for all the observations reported, including some issues we identified as a group but not pointed out by the auditor. When the Quality team recruited me to facilitate the sessions, I was happy to help.
My only doubt was which tool to use, the Five Whys or Fish Bone. I decided to do both, which immediately raised up questions from my fellow managers, why both? Are we are doing the same analysis twice? Which one is more effective? Honestly, I did not know the answer to any of those questions but I proposed the group to start doing both for a couple of non-compliances and then after we all have a feel of it, decide which way to go.
Practice makes perfection, after a couple of exercises I was able to tell that it was better to do the Fish Bone to identify all possible causes, and then the 5 whys to find each possible cause’s root. That worked for me in the past, and with this experience I validated it. The whole team agrees and this analysis method becomes our new standard for root cause analysis.
The team members were representative of all departments so the discussions were sometimes intense but always productive. Through brainstorming and a bit of group discussion, we were able to choose the most probable cause(s) from the fishbone based on criticality and impact on quality, cost, and delivery. For that cause or causes, we completed the five whys and just like Mark’s tweet; sometimes with two or three whys we find the root cause but in some of them we went as far as six or seven whys before we hit the root.
After we identified the origin of each cause or causes we create and implement the corrective actions. We also set a date in the future to meet just to check that all corrective actions were completed and verify if there is any other incident after their completion. The most important part about doing a root cause analysis is to check if we really identify the root cause of the problem. If it happens again probably we did not, which means that we have to sit down and put more efforts this time to find the real root cause.
Is good to learn to do things on our own but is even better when we can validate with other people experiences that what we are doing is good. Thank you for the lesson Mark!
Recently we have an external audit at our plant and while the results were good, they were not as good as expected. The audit results did not match the excellent team effort and great preparation work done during the whole year. The auditor managed to see a good amount of non-conformance, most of them were very simple things.
During the staff meetings right after the audit, we reviewed all the observations, some of us were pretty upset by the results. At the end of the meeting our general manager pointed out the teamwork done and how hard we worked during all last year and the current to make the plant visible which helped the auditor to determine what was out of standard. Of all people, I failed to notice that our plant is so visible that basically, we made the auditor job easier!
Lesson learned this story is now part of our Five S and Visual Management training. These programs work, the audit as proof of that. Visual standards make easier to understand when situations are out of standard. The next step after detection is to fix the situation, that is where we need to work more. Daily follow-up is important, training for new employees and why not? Maybe we need to revise the standards and go back to the drawing table after all the Plan-Do-Check-Act cycle never ends!
The benefits of standardized work include reductions in variability, injuries, and strain. Standards are perfect for new operators training and provide a baseline for improvement activities. Standardize work is a powerful lean tool; it is the baseline for kaizen or continuous improvement. There are different standardization techniques: poka-yoke, visual management, SWIS, checking and auditing. I like visual standards because they are easy to follow but the downside is that once you post a standard we need to follow it.
When we post standards, is to use them as a reference, to know what is in compliance and what is not. Visual standards are meant to highlight out of compliance situations. If the standard is no longer good, then change it first. Never ask an employee to do something different from the current standard. As soon as you break the rule, you give the wrong signal and show no respect for the people who work to create the standard. As the standard is improved, the new standard becomes the baseline for further improvements, and so on. Improve the standard, change the visual and start the continuous process again, this part is a never-ending process.