34. Poka Yoke (Mistake Proofing) Overview Poka Yoke or Mistake Proofing is an important Control tool. It is also the strongest form of Control, except for designing out the process step completely. In simple terms, Poka Yoke ensures that an action cannot be done incorrectly and defects are prevented from ever occurring. Mistake Proofing has been sometimes referred to as Fool Proofing, or Idiot Proofing. It is certainly best to steer well clear of these terms due to the negative connotations. Also, from my experience, it seems to be that the cleverest "Fools" and "Idiots" make the biggest mistakes! Defects in processes rarely tend to "just happen." There is usually a sequence of events that lead up to the defect, and this is the focus of Poka Yoke. The Team must be able to track back through the series of causal events that can lead up to a defect and place a Control as early as possible in that chain. Traditional defect Control systems often focus on detection as shown in Figure 7.34.1. The defect has to occur before any remedial actions are taken. Figure 7.34.1. Traditional defect control path. Systems of this form rely on the ability to successfully detect a defect after it has occurred. Only then are any actions taken to control the situation. Poka Yoke takes the more proactive route by using the philosophical approach of Y = f(X1,X2,..., Xn). If it is possible to identify Xs that drive most of the behavior in the Y and can cause the Y the exhibit defects, then by focusing on the Xs it should be possible to even prevent the defect occurring at all. Thus, if there is an error in an X and it is detected, then it is possible to predict the impending defect and react ahead of time, as shown in Figure 7.34.2. Work in Poka Yoke, therefore, is focused heavily on error detection as early as possible in the chain of events, to give enough of an early warning to an operator prior to a defect ever happening. 7.34.2. Poka Yoke defect control path. Logistics Poka Yoke is one of a series of Control tools, which are done as a team sport and best performed by the people closest to the process, running the process on a day-to-day basis. It is not typically done as a separate event, but is usually built into the Team meetings during the Control Phase. Roadmap The following roadmap assumes a reactive effort in that a problem already exists, such as during a Process Improvement project. Ideally, however, mistake proofing is best used in a proactive mode during Process Design to design out the defect from the beginning. The roadmap is iterative at times and involves some trial and error; such is the nature of preventing humans from making mistakes. Step 1. | Describe the defect or potential defect. Refer back to the VOC work done in the Define Phase, along with the FMEA. Mistake Proofing takes time and resource, so focusing on the highest Risk Priority Numbers (RPNs) in the FMEA pays dividends. If this is a defect that currently occurs in the process then determine the approximate defect rate. | Step 2. | Identify the operation where the defect is or could be discovered and also the operation where the defect is made. These are often different operations. | Step 3. | Detail the sequence of process steps and actions as documented in the standard operating procedures or work instructions: | Step 4. | Watch the actual process steps and actions being done and identify any steps that differ from the standard. | Step 5. | Identify the error conditions that could be contributing to the defectfor example, tools, environment, gauging, incorrect information, and so on. Referring to the observations made in Step 4 (using the 5 Whys approach) ask why the error happens repeatedly, to track back in the causal chain of events until the root cause (or source error) is identified. Do not try to develop a device until you determine the root cause. | | | Step 6. | Identify feasible mistake-proofing devices required to prevent the error or defect. This is the most creative element of the tool and can be the trickiest. In training, Belts are often asked to identify as many mistake-proofing devices as possible, for example, in a car, then consider how each achieves its goal to get their creative juices flowing. There is no easy guide to generating ideas, but some hints include Keep the device as simple as possible. Complex devices tend to fail more regularly, completely defeating their purpose. Keep the device as tangible and physical as possible. Don't rely on a device that requires intelligence to operate. The most inexpensive solutions tend to work the best. In fact the most elegant solutions often cost nothing or are even cheaper than the existing approach. The device must give immediate or prompt feedback. Any delay can cause the operator to miss the sign. Devices that give a prompt reaction work best to prevent the mistake. Create devices with focused application. Don't try to solve all the potential pitfalls with a single complex device. Create small, focused devices. Always get input from the right people. This is generally the actual process operators, but it is often worthwhile to bring in an equipment vendor or someone similar.
Belts in transactional businesses or service industries sometimes struggle to see the analogies to their processes. In fact, Poka Yoke tends to give greater return in these kinds of processes because it often eliminates layer upon layer of "patches" that have been put on the process over time. Some example devices might include Use templates to provide a box for entry of each character, or demonstrating what should appear in a field, for example, DD-MM-YY. Use masks to make non-required fields invisible to the user so incorrect entries are not placed in them. For example, placing a mask over the copier, so that unneeded buttons are hidden. Ideally the mask is more than just visual and the buttons themselves are switched off. Replace freeform text fields in databases with pull-down menus (combo boxes) to force selection from a designated list. To demonstrate this, it is an interesting exercise to pick a common client or product in a company database and count the number of variants. Use protected fields in databases so that accidental entries and overwrites are prevented. Use color-coding of documents to emphasize distinction; for example, overnight parcel shipment documents are typically a different color than those for ground shipments. Use bar coding to identify items. Note that this method relies heavily on getting the correct bar code on the entity in the first place, which is often overlooked. Create dedicated tools, for example, a single computer dedicated to shipping manifests. Create security permissions for the ability of a user to edit, delete, and read to prevent accidental deletion and overwrite. Create decision criteria aids, such as decision trees and expert systems. These are used heavily by product support groups for IT; for example, the person on the other end of the phone asking you a series of intelligent questions to pinpoint the exact reason why your printer has failed is, in fact, just following a standard series of questions.
For a complex problem, more than one solution is evolved with the notion of trying each. | Step 7. | Give it a go. The Poka Yoke term here is to "try-storm" the device, quite an apt description. If it doesn't work, try again with a subtle variant or with another idea that came from Step 6. | Step 8. | Mistake proof the mistake-proofing device. After something workable is in place, try to see ways to make it simpler and impossible to override or remove. |
After the roadmap is complete for one device, it has to be repeated until you account for all high RPNs in the FMEA. It is fortunately an acquirable skill and Teams quickly become adept at identifying quick, simple mistake-proofing devices for the Xs in the process. |