Nov 22 2011
Key details on Poka-Yoke/Mistake-Proofing
The following are my inputs to a discussion on AME’s LinkedIn group initiated last August by Xola Qhogwana, which also included contributions from Steve Bathe, Richard Foster, Karen Wilhelm, Steven Wade, Wesley Bushby, Ron Turkett, and Trevor Krawchyk.
When to use Poka-Yoke
Poka-Yokes prevent human error, and are therefore relevant when and only when human error is the main cause of your quality problems.
If you have process capability issues, focus on resolving them, not on preventing human error. What you need is deep understanding of your technology combined with statistical tools to enable your process to consistently hold tolerances.
If your process is capable but you are still producing in batches, focus on converting to flow to prevent your defectives being buried in WIP. Your problem is that it takes you too long to detect problems, not human error.
If your process is capable and you practice one-piece flow, then the defects you still produce are due to human error. At this point, and not before, Poka-Yoke is the relevant technique.
For details, see When to use statistics, one-piece flow, or mistake-proofing to improve quality.
Poka-Yokes do not require extensive a-priori analysis
Poka-Yokes are usually small devices, such as a permanent magnet to suck up a panel already containing a metal bracket, or a hole in a container to prevent overfill.
Doing an FMEA do decide whether to design and implement a Poka-Yoke is more expensive than just doing it. If you sort of think a process might need a Poka-Yoke and you have an idea of what it might be, just go ahead, try it, and document it in your company-specific Poka-Yoke library to inspire others. Don’t over-analyze it upfront. On the other hand, if you are building a spacecraft, you should definitely do an FMEA.
If it adds labor, it’s not a Poka-Yoke
By definition, also a Poka-Yoke device adds no labor. Manually scanned barcodes on parts to validate picks, for example, do not qualify as a Poka-Yokes because they add labor. A barcode that is automatically read or an RFID tag , on the other hand, would qualify. A Poka-Yoke has to become part of the process in the long run. If you look at the old big red book of Poka-Yoke from Productivity Press, you will notice that none of the examples adds labor, and there is a reason: any device that adds labor is likely to be bypassed under pressure.
This even happens with safety. Take, for example, the traditional approach of requiring the pressing of two buttons to start a press. How many times to you see plants where one button is taped down so that you can start the press with just the other one? By contrast, safety light curtains add no labor, and are not bypassed.
Using bar codes reading for data acquisition effectively eliminates the errors due to keyboarding because it is faster. If it weren’t, operators would revert to keyboarding and typos would creep back in. This is exactly what you see happening after two or three failed attempts at scanning a code. A barcode on a workpiece that is automatically read can be a Poka-Yoke. The workpiece passes under a reader in the proper orientation and under good lighting conditions and the barcode is reliably read. Under these conditions, it can even drive the lighting of the proper bins in a pick-to-light system. It does not work as a Poka-Yoke s if an operator has to wave a bar code gun in front of a part for pick validation.
Just because you use a device with the intent of preventing mistakes doesn’t mean it works. You have to make sure it does, and not just at the time you implement it. If you don’t pay attention, Poka-Yokes tend to deteriorate and to be set aside, for example when new operators are assigned to the station.
Dec 5 2011
Total: All Encompassing or Involving Everybody?
“Total” is used in the names of improvement programs like Total Quality Control (TQC), Total Productive Maintenance (TPM), Total Quality Management (TQM), or Total Flow Management (TFM), but the meaning is different on both sides of the Pacific. In the US, a Total program addresses all the issues related to its object; in Japan, it involves everybody.
When Armand V. Feigenbaum coined the term Total Quality Control in 1951, he meant that Quality Control should start with product development and end with customer support. When Kaoru Ishikawa took the concept to Japan, the acronym TQC was retained, but “Total” translated as “Zensha teki” (全社的), meaning “Company-Wide,” implying the involvement of every department in the organization. A more precise translation “Zenyin sanka” (全員参加) was later introduced, which means “with participation by every employee” and shifts the emphasis even further. Back in the US, the notion of involving everybody arrived in the 1980s when TQC morphed into TQM, but elsewhere, as in Euclides Coimbra’s TFM, it means encompassing an entire supply chain.
Programs that “involve everybody” are programs that every employee is the company must participate in. They are not volunteers but draftees. Understandably, such programs are difficult to implement, and often result in individuals just going through motions to humor their bosses and wait out the program. When joining a company, employees accept rules pertaining to working hours, compensation, expense reports, and interpersonal relations, but these general rules at the corporate level do not specify, for example, which tools are to be used in each job. Individuals don’t necessarily get to choose, particularly in production, but the standards they follow are set at a lower level than top management.
Starting a program that is “Total” in the Japanese sense means extending the reach of corporate mandates. It is easier to do in organizations to which employees have a career commitment than where employees are recruited for specific skills that they have acquired and can re-market elsewhere. Be it easy or hard, you have to consider whether it is wise. A company-wide program is a centralization effort and reduces the autonomy of lower-level business units. As most companies are trying to go in the opposite direction, you really don’t want to start such a program unless (1) its benefits are obvious, and (2) there is no other way.
A TQM program may mandate that the Plan-Do-Check-Adjust (PDCA) process be used when implementing any change throughout the company. Since everybody must participate, the PhD-level scientists at R&D will be required to undergo PDCA training and to formally use it to organize all their activities. As a group, they will be offended and some may quit. Elsewhere in the company, project leaders will dutifully reports their action items as being in a state of P, D, C or A. The organization can claim to be on board with the program but truly is not.
5S, on the other hand, is a program that can only be successful if everybody participates. The benefits of 5S are not easy to quantify, but everybody likes the outcome: given the choice of working on a shop floor with or without 5S in place, few would choose without. The problem is that even fewer show any enthusiasm for doing the work necessary to achieve and sustain this outcome, and this resistance can only be overcome if everybody from top management on down gets physically involved. When touring Japanese plants, you so often see the plant manager pick up a stray scrap of paper off the floor and put it in a dustbin that you feel the incident has been staged, but the message is clear: everyone should behave as if the tidiness of the whole plant depends on the individual behavior of each.
A more modern and successful program involving all employees is Hoshin Planning, a strategy deployment approach that is well described in Pascal Dennis’s Getting the Right Things Done. It results in employees having small, actionable sets of strategic directions, determined with their input and consistent across levels. It is much more sophisticated than the target numbers game that management-by-objectives has degenerated into in many companies, and the vertical and horizontal interactivity of the process makes it impossible for any segment of the organization to opt-out.
A company-wide program is implemented top-down, starting with top management and cascading to the shop floor, with appropriate training at each level. It is different from Robert Schaffer’s Breakthrough Strategy, which starts with a pilot projects effecting a deep transformation of a small segment of the organization, whose success makes it go viral. By providing rapid improvements and building the skills base, the breakthrough strategy bootstraps the Lean transformation of a plant but can take it only so far. Once the leaders of local projects start wondering what their successes add up to and where they are leading, they are ready to pull together and take on the challenge of involving all employees in the parts of Lean for which it is necessary. It is top management’s role to sense when an organization is ready for this transition.
Share this:
Like this:
By Michel Baudin • Management 0 • Tags: 5S, Continuous improvement, Hoshin, Kaizen, Lean, Quality, TQM