The other day while working with a team on a rework reduction activity the team leader learned a great lesson. He learned “Genchi Genbutsu” which literally means “actual place, actual thing”. It is commonly referred to as “Go See the Problem”.
The team had made several improvements to reduce manual entries of data to reduce reworks related to documentation errors. While following-up with the team on a pareto of loss codes it was found that a new category of defects had increased. These new reworks were packing errors which was not part of the original current state characterization.
As we were analyzing the data a rework came back for this packaging error. The team looked at it and noticed right away that the product was not completely wrapped. One team member said the usual “That is just operator error.” Obviously the data did not indicate that. It was a new problem. The team leader said “I think this is only an interdepartmental rework” but the data did not show that either. I said “Let’s go see”. To that he said “What do you mean?” Let’s look at the actual process of packaging the product.
We watched three people including the team leader perform the packing step for the product. All three did this process differently. The team recognized the need for a repeatable process that everyone would do. This is what we call “standard work” in the lean community. As we observed this process we noticed there we several different packages all of which require a plastic wrap. The product package size had increased in width by a factor of 3 about three months ago. The plastic wrap had not and this caused a number of new issues. Now there was more variation in the process from where to start wrapping, the method of wrapping, and the number of wraps. The smaller wrap and the wrapping variations was the root cause of the reworks observed since all the product packages were fixed by simply re-wrapping.
This issue is not something the team could see from the rework data. The only way to determine the wrap was too small for the package was to observe the process and ask questions at the source. This is the principle of “going to the Gemba”. Gemba is the Japanese word for “actual place.”
This is a simple story but a typical example probably in many companies. No matter what your position is or what you are working on you can not underestimate the importance of going to the Gemba. You can’t solve problems at your desk. Going to the Gemba is a great way to get the entire team involved in identifying and solving problems. It is grounded in fact finding using actual conditions from the actual workers who perform the work. This activity creates energy within the team solving the problem leading to experimentation, ideas, and discussion on improvements.
Next time you are working on an opportunity remember to go to the Gemba and the results will surprise you.
Subscribe to:
Post Comments (Atom)
This is a great example. I'm hoping that the team also reviewed the "change process" that triggered this "defect" to appear in the first place.
ReplyDeleteIt is just as relevant for Engineers and others to visit the Gemba before instituting a change so they fully understand what impact it will have on operations.
This problem could have been prevented all together.
Great example!