What Poka-Yoke Are And Are Not, And How To Sustain Them

Chet Marchwinski recently exhumed a 2011 discussion about Poka-Yoke that had been started by the following question:

I’m a manufacturing engineer and since I have started participating in kaizen workshops, I have noticed that production supervisors tend to disconnect some of the poka-yokes we’ve put in place in the machines. When I challenge them about this they argue that operators can’t run production and cope with the complexity of our machines. I am perplexed by this and wondered whether you’d have a comment.

In short, I can think of two reasons for production supervisors to disconnect Poka-Yoke:

  1. No production supervisor in his right mind would disconnect devices that make the work easier for operators. If they do disconnect them, the most likely explanation is that the devices described as “Poka-Yoke” actually add work for the operator. If you have to pick a part from one of ten open bins in front of you, you will spend precious seconds finding the right one; if all bins are covered with lids except the right one, not only are you physically prevented from picking the wrong one but you don’t have to look for it. It makes your job easier. On the other hand, if you have to scan a bar code on the part to validate the pick, it adds to your work load and your supervisor will pull the plug on the next production rush.
  2. The manufacturing process is not ready for Poka-Yoke. A production supervisor is quoted in the question as saying “operators can’t run production and cope with the complexity of our machines.” This suggests that the line has process capability issues that must be addressed before implementing Poka-Yoke.

The following paragraphs elaborate on these points.

Continue reading

Not Exactly Poka-Yoke and Chaku-Chaku

“Japanese automobile manufacturing methods are adopted by American competitors. Watch the concept of poka-yoke, meaning “correct” and chaku-chaku, meaning “one worker, several tasks” in the manufacture of rear view mirrors.”

Source: www.youtube.com

Michel Baudin‘s comments:

An interesting video, but “Poka-Yoke” and “Chaku-Chaku” don’t mean what the narration says they do. And they are not “Japanese” methods but methods invented by specific individuals in specific companies that happened to be in Japan. Likewise, the assembly line is not an “American” method but a method invented by P.E. Martin, Charles Sorensen and others at Ford.

“Poka-Yoke” doesn’t just mean “correct.” More specifically, a Poka-Yoke is a device integrated in the production process to prevent human error or detect it immediately without adding any labor. Checking bar codes on parts, as shown in a video, doesn’t qualify as a Poka-Yoke because it adds labor, and error prevention devices that add labor are ineffective because they are by-passed under pressure.

The video shows an operator attending to a sequence of tasks and calls it “Chaku-Chaku.” There is, however, ,more to Chaku-Chaku than this, such as automatic processing at each station, with automatic unloading and chutes between stations, so that the work of the operator is focused on checking the part after an operation and loading it into the next.

See on Scoop.itlean manufacturing

Using Poka-Yoke Techniques for Early Defect Detection | Accelerate Management | Jennifer R.

“Shigeo Shingo developed processes, called “devices,” which made errors much less likely. In one of the examples used by author Harry Robinson, Shingo created a process where workers were required to take two small springs and put them into a dish before assembling a switch (which used the two springs). While this seems like a waste of time, it stopped the workers from forgetting to put the springs into the switch to start with, which saved an enormous amount of time by preventing technicians being sent to customer locations for repair.”

Source: www.compaid.com

Michel Baudin‘s comments:

What could possibly go wrong? Placing two springs in a dish prior to assembly not only adds a handling step, but it neither physically prevents a mistake, nor immediately detects it once made. A new operator, or one who fills in for another who has the flu, is likely to skip this step, particularly if necessary to sustain the pace.

This example not like any Poka-Yoke I am used to, like the slots in my printer that are shaped so that an ink cartridge of the wrong color won’t go in, or the food processor that is started by pressing on the lid. These devices actually make mistakes impossible without adding any work, so that there is no incentive to bypass them.

And it’s not difficult to imagine methods that might have worked with the switches. For example, the springs, presumably prop the buttons up, and a whisker hanging over the assembly line might be triggered only if the switch is tall enough…

This article made me wonder whether Shingo, the inventor of the Poka-Yoke concept, had actually come up with this dish idea. It is indeed on p. 44 of his book, “Zero Quality Control: Source Inspection and the Poka-Yoke System,” and he does call it a Poka-Yoke, even though he didn’t coin the term until two years later.

It is the only example I remember seeing in the Poka-Yoke literature that does not meet the requirements of being 100% effective and not adding labor.

Devices and methods that make errors less likely are useful too, but not mistake-proof. It is usability enginering. If you make operations easy to understand with intuitive, self-explanatory user interfaces, mistakes may be so rare that you don’t need mistake-proofing. It’s fine, but it’s not mistake-proofing.

See on Scoop.itlean manufacturing

Poka-Yoke in User Interface Design | Six Revisions

 

“Poka-yoke is a Japanese term that means “mistake-proofing”. It surfaced in the 1960s, and was first applied in the car manufacturing industry. Poka-yoke is credited to industrial engineer Shigeo Shingo.”

Source: sixrevisions.com

Michel Baudin‘s comments:

That IT specialists should be interested in the Poka-Yoke concept is natural. There are, however, consequential inaccuracies In the way it is described in many English-language sources, including Wikipedia.

The example given as the first Poka-Yoke is a redesign of a switch assembly process that involved presenting springs on a placeholders so that the operator would not forget to insert one.

Assuming this is a true example, it has two characteristics that make it different from the other examples given in Shingo’s book or in Productivity Press’s big red book of Poka-Yoke.

First, having a placeholder does not physically prevent the operator from making a mistake. A classical example of a system that does is one that puts a lid on every bin except the one the operator needs to pick from.

Second, this example adds labor to the operation, which means that the preparation step of placing the springs in the placeholder is likely to be by-passed under pressure. This is why it is a requirement for a Poka-Yoke not to add labor to the process.

For the same reasons, a multi-step deletion process in a software interface does not qualify as a Poka-Yoke. If you do multiple deletes, you end up pressing the buttons in rapid succession, occasionally deleting items you didn’t intend to, while cursing the inconvenience of these multiple steps.

Having different, incompatible plugs certainly made it impossible to plug the keyboard into a port for an external disk. USB, however, was an improvement over this, because, with it, the machine figures out the purpose of the connection. A connector that you can insert in any orientation is even better. It saves you time, and there is no wrong way to plug it in. This is a genuine Poka-Yoke.

There are other, useful approaches that make mistakes less likely without preventing them outright. Don Norman and Jacob Nielsen call them “usability engineering.” They should certainly be used in user interface design, but not confused with Poka-Yoke.

What a Coffee Cup Taught Me About Poka Yoke and Human Errors | Peter Abilla

See on Scoop.itlean manufacturing

“Human Errors, Poka Yoke are concepts brought to life from my experience with coffee cup. One can learn a lot about Poka Yoke and Human Errors. This is a story about what a coffee cup taught me about how poor design in our products and systems invite human error.

Many years ago, I had to travel to Dublin every few months for work. […] One very early morning while waiting for the taxi to pick me up at my hotel to take us to the airport, my colleague with whom I was traveling with at the time had ordered coffee while I ordered a Coke since I’m not a coffee drinker. They brought him his coffee in this cup.”

Michel Baudin‘s comments:

With its unsightly bumps and nooks, the “fancy cup” you show is not even pretty, which makes you wonder what the designer had in mind. The issues you bring up, however, are more about usability engineering in Don Norman’s sense, than Poka-Yoke.

A properly designed handle is self-explanatory in that any user who has never seen a cup will immediately understand what it is for. But it doesn’t make the cup mistake-proof: there is nothing physically preventing you from pouring coffee onto it while it is upside down.

Usability engineering is about controls that look and feel distinctive to the touch — as opposed to rows of identical buttons — that give you feedback when you have activated them, that have shapes that naturally lead you to use them properly, that respect cultural constraints in the meaning of shapes and colors, etc.

Applying these principles in designing human interfaces reduces training costs and the risk of errors. It is valuable, but it does not prevent errors.

Double-walled cup

Incidentally, why do so many cultures, including Japan and China, use cups with no handles? An alternative to handles to avoid burning your fingers is the double-walled cup, and I have seen some from China. Otherwise, I have resorted to the Arab way of holding a handleless tea cup: between my thumb on the bottom and my index finger on the rim.

See on www.shmula.com

Perfection Through Mistake-Proofing | IndustryWeek

See on Scoop.itlean manufacturing

“Mistake proofing can make a significant difference in the output of any process [….]  Mistake-proofing devices should meet three criteria:

          1. Simple
          2. Infallible
          3. Effortless”
Michel Baudin‘s insight:

The article makes the point that mistake-proofing must be “effortless.” The way I usually say it is that a mistake-proofing/poka-yoke device must not add labor, a point that is frequently missed in discussions of this topic in the US.

Why is it essential? Because any device that adds labor is guaranteed to be by-passed under pressure. If preventing a mistake requires one more gesture, on any day where “we have to ship all this by 6:00PM,” the organization will find a way around it.

Mistake-proofing makes a difference in any process where human error is a major cause of failure. Many processes qualify, but not all. If the main cause of defects is the machine’s  inability to hold tolerances consistently, mistake-proofing will not do much good.

Yes, a device that is fallible cannot be considered mistake-proofing. Usability engineering, for example, provides user interfaces  that make mistakes unlikely, but not impossible. Sometimes it is sufficient, but it is not mistake-proofing.

The one criterion I have an issue with is simplicity. A mistake-proofing device must be simple to use, I agree, and its design should not be anymore complex than necessary. However, where the stakes in human error are high, as in airliner cockpits or semiconductor process equipment, preventing mistakes may require elaborate technology. If a device for this purpose  works every time and adds no labor, I see no reason to deny it the “mistake-proofing” label.

See on www.industryweek.com

Yet Another Post About Poka-Yoke

A week ago, José Roberto Rolim Nunes  started a new discussion on the TPS Principles and Practice discussion group on LinkedIn by asking “What is Poka-Yoke?” As of today, it has had 42 contributions, including several from Sid Joynson, Jerry O’Dwyer, and Peter Winton. Sid recounts personal communications from Shigeo Shingo, Jerry adds a semiconductor industry perspective, and Peter discusses Poka-Yoke with current production machinery versus what it was in Shingo’s days. Discussion groups often revisit the same topics, but with different participants exploring different details. On Poka-Yoke, I have posted the following before:

  1. Key details on Poka-Yoke/Mistake-Proofing (11/22/2011). A compilation of my inputs to a discussion of Poka-Yoke in the AME discussion group on LinkedIn. Several sections of this post are repeated here, with illustrations added.
  2. Poka-Yoke at Toyota: the Current State (3/10/2013). A review of Mikiharu Aoki’s 2013 book on the subject.

The featured image above is of my favorite Poka-Yoke. The press punches a hole in a fiberboard with no metal parts. At a later step, a metal bracket is mounted in this hole. One day, an operator mistakenly loaded into the press a board that already had a bracket in it, which put the press die out of commission for 36 hours. The device mounted in front of the press  is a permanent magnet, which sucks up any board already containing a bracket.and preventing it from going in. It was designed and implemented by Hormoz Mogarei‘s team a few years ago.

The topics covered here are as follows:

Definition, applicability and boundaries

A Poka-yoke is a device integrated in a manufacturing operation to prevent human error. As an approach to quality improvement, it is therefore relevant where human error is the main cause of defects, which means that your process is capable and that discrete malfunctions, such as tool breakage, either stop the line automatically or are promptly detected thanks to one-piece flow.

Once you have a capable process and one-piece flow, human error percolates to the top of the Pareto chart of defect causes, and Poka-Yoke can take you to the next level. One feature of Poka-Yoke that is often missing in the literature is that the defect-prevention devices must not add labor.

The reason this is vital is that, otherwise, operators will stop using them under pressure and they will be ineffective. For example, validating picks by reading bar codes adds labor if an operator has to wave a reader and is therefore not a Poka-Yoke. If the ID Is read automatically while the part travels on a belt, then it is a Poka-Yoke.

Poka-Yoke and Inspections

A common misconception is that only devices that prevent defects being created qualify as Poka-Yoke. Poka-Yoke inventor Shigeo Shingo, however, disagrees. To Shigeo Shingo, “inspection” was not a dirty word. In ZQC, p.92, he wrote: “Poka-Yoke systems involve carrying out 100% inspections and requiring immediate feedback and action when errors or defects occur.”

Although he does not say this explicitly, what I read between his lines is that, since Poka-Yoke exist to prevent human error, they do not prevent defects from being created by machines, but they ensure that these defects are detected and acted upon immediately when the workpiece is unloaded.

We should remember that Poka-Yoke is about prevention of human error, not machine malfunction. Even in the best processes, machines will occasionally malfunction, in ways that will damage a workpiece and preventing this from happening is out of the scope of Poka-Yoke.

On the other hand, it is a human mistake to let this defective part escape and proceed to the next operation, and a device that keeps this from happening performs mistake-proofing and is therefore a Poka-Yoke, as Shingo defined it. It should also be noted that Lean/TPS includes other forms of 100% inspections as well, such as go/no-go gauge checking on every part, or successive inspection, in which each operator on an assembly line starts by touching every component that was supposed to be installed at the previous station.

Nobody likes inspections, but, if they find defects, they are necessary. An inspection step that fails to uncover a single defect in a million consecutive units is probably unnecessary. When you find that 100% inspection is unnecessary, you don’t replace it with sample inspection, because drawing samples would disrupt the production routine. Instead, you go to first and last piece checking on a production run. And the next step is complete elimination of the inspection step.

An inspection system that just filters bad parts is not a Poka-Yoke, because it does nothing to prevent the generation of more bad parts. If you have a process that is out of control and routinely produces 5% of defectives or more, human error is not the problem, and Poka-Yoke not the solution. You need to fix the process. The following is an example of a Poka-Yoke to detect empty packages coming out of a machine, from Mikiharu Aoki’s Poka-Yoke at Toyota: the Current State (pp. 168-169):

Poka-Yoke Aoki with  translated captions

Poka-Yoke example from Mikiharu Aoki

It does not prevent the machine from putting out an empty box, but it prevents it going forward. This Poka-Yoke could have been built in the 1960s. For this purpose, a engineer’s first instinct today would have been to use an electronic check-weigher, and program it to trigger the Andon as needed.

This mechanism in this example can be implemented by a shop floor team with mostly mechanical skills. An even simpler device that has been used to filter empty boxes on a conveyor is to blast air at them: the empties fly off, while the full ones are unaffected; it does not, however, trigger the andon.

Poka-Yoke and Statistics

About Poka-Yoke versus Statistical Methods, following are two quotes from Shigeo Shingo’s ZQC book and Mikel Harry’s Six Sigma, that I posted a few days ago in another thread on the TPS+1 subgroup:

Shigeo Shingo: “When I first heard about statistics in 1951, I firmly believed it to be the best technique around, and it took me 26 years to be completely free of its spell.” ZQC, p. 54

Mikel Harry:”We believe that statistical knowledge is to the information age what fossil fuel was to the industrial age. In fact, the future of industry depends on an understanding of statistics.” Six Sigma, p. 24

Shigeo Shingo’s and Mikel Harry’s perspectives seem diametrically opposed. Neither Shingo nor Harry, however, takes the trouble to specify the context of their remarks. Shingo’s world is primarily automotive; Harry’s, electronics. My take on this is that they are both right, in non-overlapping universes.

My first experience in manufacturing was in the semiconductor industry, where lack of process capability, at the level of the whole 500+ step wafer process, is the main cause of defects, and is fought by armies of yield enhancement engineers who use statistical design of experiments. In this context statistical tools are indispensable. Later, working in automotive, it was not the case.

When I last looked at this, the semiconductor industry, along with pharmaceuticals, was the largest industrial user of statistical software products. The motivation in pharmaceuticals is compliance with legal mandates for drug approval; the motivation in semiconductors is internal, technical needs.

Poka-Yoke and Usability Engineering

Usability engineering is also an approach that, while falling short of Poka-Yoke, goes a long way towards reducing human errors by leveraging intuition and pre-existing habits. The idea is to make the human interfaces of tools and machines so intuitive that people naturally tend to use them correctly. It does not mistake-proof processes, but it makes mistakes unlikely and reduces training needs. The following picture shows features of the alarm clock I used before switching to a smartphone app. It included both usability engineering and mistake-proofing.

Poka-Yoke and Usability Engineering in Alarm clock

Swiss Army alarm clock

Usability engineering is applied to the clock face. It is analog, and consistent with the style developed over  hundreds of years, that is now a cultural constraint, even for digital clocks.  The hours are marked in bold numbers with high contrast and a consistent orientation. The hour and minute hands have markedly different lengths, and the hour-hand has an arrow. These hands will not be confused, and they glow in the dark.

The alarm and clock time settings, on the other hand, are mistake-proof. On traditional alarm clocks, you set the alarm time by turning a button on the back while looking at the clock face in the front, and often turn the wrong button, changing the clock time instead. The mistake-proofing device here is a cover that you have to open if you want to access the clock time knob. With the cover closed, you can only change the alarm time.

Mistake-proofing and usability engineering are two different disciplines, with overlapping goals. By making user interfaces intuitive, usability engineering makes mistakes unlikely but does not prevent them. Conversely, you could have a fully mistake-proof machine that would require you to study  a manual in order to operate it.

In a car, for example, you could prevent starting the engine while in gear — which is mistake-proofing — and still make the controls unintelligible by confusing captions or unusual locations. In the Ford Edsel, for example, you shifted gears by pressing a button in the center of the steering wheel, which violated a cultural constraint on shifter location established over 70 years of car making.

Ford Edsel shifter: pressing buttons in the center of the steering wheel

The push-button shifter on the Ford Edsel

The reason you can rent a car from any brand and drive it off without opening a manual is usability engineering, not mistake-proofing. Usability engineering is widely used in consumer goods, which are bought their end-users, but not in production machines, which aren’t. The principles of Lean equipment design include usability engineering, even though it is not explicitly referenced. Production machinery should have both; most of it currently has neither.

The best source on usability engineering is Don Norman’s Design of Everyday Things. For its application to airliner cockpits, see Asaf Degani’s Taming HAL. The application of usability engineering to production machinery is discussed in Part I of Working with Machines (pp. 9-84). In is also discussed in an earlier post on Avoiding Lean Wallpaper. Here is an example of Don Norman’s recommendations for a stovetop design:

Natural mapping of knobs to burners

Natural mapping of knobs to burners

The relative positions of the knobs match the relative positions of the burners they control. It is not a Poka-Yoke, because it doesn’t prevent you turning the wrong knob; in practice, however, it is the only layout in which nobody does.

Poka-Yoke in Production versus Household Appliances

Why is production machinery so lacking in mistake-proofing and usability engineering?  I think the suppliers are just catering to their customers, the people who select equipment and make purchasing decisions. In most companies, the operators are out of this loop, and their needs are not addressed. Household appliances are loaded with mistake-proofing and usability engineering features because they are bought by their end-users.

As a consequence, manufacturing Poka-Yoke are usually retrofits introduced as part of continuous improvement. To the extent that they are specific to the plant’s use of the machines, this is inevitable. Machine suppliers, however, can help by building in Poka-Yokes that apply to all uses of their equipment, and by making it easy for users to add custom Poka-Yokes.

Poka-Yoke, Jidoka, and Technology

Logically, Poka-Yoke belongs under the Jidoka column of the TPS house. There are only two columns, the other one is Just-In-Time, and Poka-Yoke is not part of Just-In-Time…

The engineers who program control systems to prevent using the wrong recipe in semiconductor wafer processing or car engines from starting while in gear are definitely mistake-proofing. What the literature has encouraged us to do, however, is to think of Poka-Yoke as small, cheap devices developed by the people who do the work as part of continuous improvement. I don’t see anything wrong with applying the term to the work of design engineers, as long as we don’t forget about the Poka-Yoke from the floor.

The Poka-Yoke concept relevant in semiconductor manufacturing even though process capability issues are dominant, because operator errors have catastrophic consequences. An operator who starts the wrong recipe on a diffusion furnaces may lose an entire load of 200 wafers, worth about $250K. The prevention of such errors is mistake-proofing, but it is pursued through high-technology methods by engineers specialized in computer systems to control process equipment. The following is an illustration of how this was accomplished in the 1990s:

Poka-Yoke recipe control in semiconductors

The control systems embedded in the production machines were themselves powerful computers, and communicated with outside computers using industry-specific protocols. Using commercially available packages, in-house computer engineers  programmed an external computer to communicate with both the embedded controller on one side and with the plant-wide Manufacturing Execution System  to prevent the wrong process program being executed.

The literature on Poka-Yoke gives the impression that Poka-Yoke devices are always low-tech, but that is because they use examples from the 1960s. Relying on size differences between products to make them trigger or not trigger switches is fine as long as these differences exist. If, however, you are building differently configured computers in the same cases, the outer dimensions are identical, but you can use RFID tags to achieve the same result.

Imagine a mixed-flow assembly line as in the following picture:

Mixed-flow assembly line

Mixed-flow assembly line

This picture focuses on one assembly station within a mixed-flow assembly line.  The line makes a variety of different configured products. At a supermarket just off the line, a water spider picks kits of parts for the work done at this station and sequences them on a gravity flow rack a few minutes before they are used.

The pick-to-light system itself is not a Poka-Yoke, because it does not physically prevent picking the wrong parts or the wrong quantities. Systems that pop up lids to make parts accessible only in some bins are closer, because they only make the right parts accessible, but they still don’t control the picking quantity. Pick-to-Light systems are popular because they are cheaper than automatic dispensers, increase picker productivity, and reduce, if not eliminate, picking errors. But the pick-to-light controller has to know which bins to light up.

How do you go about making sure it does, and the water spider  delivers the kits in the proper sequence to the flow rack, knowing that you cannot rely on the outer dimensions of the product to pinpoint its configuration? Following is a possible solution based on RFID technology:

Mistake-proofing configuration with RFID

Mistake-proofing configuration with RFID

The entire bill of materials for the product configuration is loaded onto a high-capacity RFID tag attached the fixture at the start of the line. Past that point, all the data is locally held, and the operation of the line is decoupled from the central information system of the plant. An RFID proximity reader is located a few stations ahead. Through it, the product sequence and pick lists are fed to the pick-to-light controller just early enough for the water spider to pick the kits in time for assembly.

Poka-Yoke Implementation

When a Poka-Yoke is a simple device, as described in Shingo’s ZQC book, in Productivity Press’s big red book of 240 examples, in Hinckley’s more recent “Make no mistake” (2001), or in Aoki’s “Poka-Yoke at Toyota (2012), it is implemented differently from when it is a larger-scale project. For these classical Poka-Yoke, the challenge is the idea, and it usually comes from a production operator or a technician.

The implementation cost is petty cash, and it takes a few hours to do, as part of continuous improvement. It does not require a formal economic justification or business case. The barrier is low. If you kind of think it the current setup is a mistake waiting to happen, and a $50 change to the operator work station will prevent it, you do it.

Preventing a diffusion furnace in semiconductors from running the wrong recipe is a different story. With the technology as it was when I was involved, you were talking about a $50K retrofit to the local control system, with integration to the overall plant system, so you had to look at the economics. In one case, there had been recipe mistakes about once a quarter, resulting each time in a total loss do a load of wafers, worth at this stage about $250K, which worked out to about $1M/year. Investing $50K to save $1M/years sounds like a good investment, but, for this kind of Poka-Yoke, you need to have that conversation, and it needs to be documented.

How to avoid human mistakes in production? The Lean approach | Renaud Anjoran

See on Scoop.itlean manufacturing
Human operators make mistakes. But there are solutions: adopting the right philosophy, mistake-proofing each process, and self-inspection. (How to avoid human mistakes in production? The lean approach.

 

Michel Baudin‘s insight:

Renaud Anjoran shares his experience of mistake-proofing in Chinese factories, and quotes “Lean Assembly.” Thanks.

See on www.qualityinspection.org

Poka-Yoke at Toyota: the Current State

Mikiharu Aoki's "All About Poka-Yoke in Toyota Factories" (2012)

Mikiharu Aoki’s “All About Poka-Yoke in Toyota Factories” (2012)

Mikiharu Aoki kindly sent me his 2012 book on mistake-proofing (Poka-Yoke) in Toyota factories. I had asked him for it out of curiosity about new developments in this field.

The classics on Poka-Yoke are Shigeo Shingo’s Zero Quality Control (1986) and Productivity Press’s big red book (1987), both of which are useful but leave you hungry for more examples that do not date back to the 1960s and 70s.

In Make No Mistake (2001) Martin Hinckley reused many of the same examples, but added a few using more electronics, discussed the relationship between mistake-proofing and statistical methods, and included a directory of  suppliers for tools and devices. I spot-checked the websites of a few of them and, 12 years after publication of the book, found they were all still around.

While Taiichi Ohno and Shigeo Shingo were men of my grandparents’ generation, Mikiharu Aoki is my contemporary. He is not a founding father of the Toyota Production System, but he has worked in its modern incarnation for 26 years before becoming a consultant. He has written several books — only available in Japanese — and all but one with  “Toyota” in the title.

Part I  is a discussion of the steps needed to implement Poka-Yoke; Part II, 72 actual examples explained through conceptual diagrams and cartoons.

Part I, about 1/3 of the book, first discusses 5S, standard work, process capability, and one-piece flow as prerequisites to mistake-proofing. It then distinguishes the categories of mistake-proofing devices, such as the ones that physically prevent mistakes versus those that prevent defectives from escaping to the next process. It describes the use of Andons to trigger responses to problems detected by mistake-proofing, and expresses a preference for devices that involve direct, mechanical contact with work pieces over sensors and electronics, because their operation is visually obvious.

On the other hand, I did not see recommendations on how you organize the implementation of mistake-proofing, monitor progress, and make sure that the devices do not deteriorate or fall out of use over time. This is not covered either in any of the other books I have seen on the subject.

The examples in Part II are more similar to those in the older books than I expected. The tangs used to prevent mounting the button in the wrong position on a music player control panel are a classic, and the same method is used in my HP inkjet printer to prevent mounting ink cartridges in the dock for a different color.

Mistake-proofing assembly of music player buttons

Mistake-proofing assembly of music player buttons

In the following case is also consistent with the older Poka-Yokes: the outer dimensions of products are used to tell them apart and make different sets of parts available for assembly.

Bin cover Poka-Yoke

Bin cover Poka-Yoke

Clearly, the way it works, and whether it works, is obvious. By a method that relies on differences in the outer dimensions of a product is only applicable where such differences exist. With car engines, they do; with computers, they don’t, and many different configurations of the same product are mounted in the same chassis. In such a context, you have to resort to bar codes, QR codes, or RFID tags and the computer systems that go with them.

I expected to see more use of this kind of technology in current Poka-Yokes, but I understand that Aoki’s book is about car manufacturing and that you want, as much as possible, the devices to be invented on the shop floor by production people.

Among Aoki’s books, the one without Toyota in the title  is called “All about car factories” (自動車工場のすべて, November, 2012), and its purpose is to explain in an integrated manner both the production process and production control sides of car making. Aoki also included it in his package to me, but I have not had a chance to look at it yet. I will keep you posted.

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.