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

twitter What a Coffee Cup Taught Me About Poka Yoke and Human Errors38facebook What a Coffee Cup Taught Me About Poka Yoke and Human Errors38linkedin What a Coffee Cup Taught Me About Poka Yoke and Human Errors52google What a Coffee Cup Taught Me About Poka Yoke and Human Errors5email What a Coffee Cup Taught Me About Poka Yoke and Human Errors
Review of: Poka Yoke, Human Errors

Reviewed by:
Rating:
5
On January 13, 2014
Last modified:October 17, 2014

Summary:

Poka Yoke is a concept in lean manufacturing that teaches us how to prevent errors. Training in Lean will help us look into systems, processes, and the conditions that lead to errors. Online training in lean six sigma will bring professional training and allow us to improve our companies immediately bringing cost savings, safety, and improvement.

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. Often, organizations just aren’t versed in good Poka Yoke System Design.


Many years ago, I had to travel to Dublin every few months for work. I had team members there and part of my responsibility was to be a good leader and spend time with face to face. I was living in Salt Lake City at the time and it was a pleasure to spend time with them, even though it took me away from my family every few months or so.

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.

coffe cup poka yoke shmula abilla What a Coffee Cup Taught Me About Poka Yoke and Human Errors

At first glance, I thought to myself “Wow, that’s a fancy cup” because, in America, cups mainly look like, well, cups. This, on the other hand, was no ordinary cup – this was a fancy European cup.

But, wait. Take a closer look. Do you see any problems?

Let me tell you my friend’s experience. Perhaps you’ll see the issues as I tell you his ordeal.

  • When my friend stirred the spoon, it hit the bumps on the inside of the cup.
  • The handle is a not really a handle that allows your fingers to securely hold the cup. Instead the handle is a ceramic stub, forcing my friend to use every muscle available in his thumb and forefinger to hold this fancy coffee cup.
  • The handle has a little well, allowing the coffee to occupy the space. Coffee is hot. And, hot coffee on a handle where your thumb and forefinger is means you will burn yourself with every courageous attempt at a sip of coffee.

Here’s another picture to see what I mean:

coffe cup poka yoke shmula abilla design explained What a Coffee Cup Taught Me About Poka Yoke and Human Errors

Poka Yoke, Human Errors

For practitioners of Lean and Six Sigma, we know that Poka Yoke means error proof or designing our processes, products, and systems in a way that helps to prevent errors. But what many of us, I think, underestimate the power of poor design and how it invites us to make errors without us even realizing it.

The System: Organization, Team, Individual

Moving from a product context to a service context, design can occur at, I believe, 3 levels: the organization, the team, and the individual. Let me use a case study to explain.

Back in 1999, a seminal paper entitled 1 “To Err Is Human: Building a Safer Healthcare System” by Kohn, et al, examined the state of the healthcare system. The numbers the authors presented shook the industry. They reported that 44,000 people died in US hospitals every year from preventable medical errors. They estimate that number could be up to 98,000. Even at the lower estimate of 44,000, deaths from preventable medical errors were higher than the mortality rate of breast cancer and HIV/AIDS.

This finding shook the industry and led to many patient safety initiatives thereafter.

But the authors made one very significant conclusion that perhaps received the most scrutiny because it flew against the commonly held belief that human errors were due to personal recklessness and general sloppiness in the delivery of care from healthcare professionals 2. That conclusion was this:

The majority of medical errors did not result from individual recklessness, but instead were caused by faulty systems, processes, and conditions that led people to make mistakes or failed to prevent them.

In other words, pointing the finger at individuals for mistakes made is not the entire story. Perhaps we need to look into the design of the systems, processes, and the conditions that led to the errors also.

Back to the Coffee Cup

Suppose my friend burned his hand. He didn’t, but let’s suppose he spilled his coffee that morning and burned his hand. Knowing him, he would’ve blamed himself. He would called himself stupid. He would’ve felt like spilling the coffee and burning himself was all his fault.

Would he be right?

NO.

The design of our systems, processes, and the conditions that led to the event have everything to do with whether human errors are made or not. Just like looking at the poor design of the coffee cup brings insight into why coffee is easier to spill and burn the person holding the cup, looking into the design of systems, processes, and the conditions that led to the error will also bring the same insight and allow us to make longer lasting improvements that may truly prevent human errors.

ad templates page 1024x852 What a Coffee Cup Taught Me About Poka Yoke and Human Errors

  1. I haven’t read the entire report, but I plan on doing so.
  2. My good friend Mark Graban – I’m sure – could share many stories from his work in improving healthcare. If you’re a healthcare professional, check out Mark. They guy is all about improving healthcare. I’ve learned a ton from him.

Comments

  1. says

    Yeah, we shouldn’t make people feel stupid for making en error that’s caused by the system. For example, we shouldn’t blame a person for showing up at the wrong Toyota plant entrance for a tour when the directions and signage are non-existent:

    I wrote about this just today: http://www.leanblog.org/2014/01/toyota-tour-thoughts-yes-they-have-opportunities-for-kaizen/

    As for the medical errors… there is a new study that says the number is 400,000 a year, not 44 to 98k. It’s really frightening that the main failure modes in healthcare aren’t being addressed fasts enough.

    http://journals.lww.com/journalpatientsafety/Fulltext/2013/09000/A_New,_Evidence_based_Estimate_of_Patient_Harms.2.aspx

  2. Paul Astle says

    Great article Pete. Poka Yoke is such a simple but powerful concept. Coupled with DMAIC or DMADV it’s the ultimate process control. It’s such a pity that more Healthcare providers aren’t bought into Six Sigma for their continuous improvement programmes. Just think of the lives that could be saved and the millions saved in clinical liability case costs.

  3. says

    Someone is making the assumption that this cup is a LEAN disaster, but is it? Upon first viewing, I thought – Wow! what a clever cup for pouring and drinking! Then, the internal nubs provide an excellent defense against the ceramic material frictionally binding and causing the cup to fracture. This cup is a great design, however, its use must be questioned. So, lets beat up the proprietor of the bistro and not the design team: they probably delivered “The Cup of the Year!”

  4. Mike Peacock says

    Great analogy Pete! Processes are great when designed well. Management often demands process to be followed and if individuals do not, then they are penalized – so therein exists built-in conflict. I’ve never seen a process written in stone – so they are made to be changed! It is also great to know that there are indeed coffee/Coke drinkers in SLC – I was one!

  5. Raj says

    I tend to agree with Martin Sala.

    I see some uses of the stubs on the inside bottom of the cup, and the matching slots on the outside, which will make it very useful for stacking the cups – less space being occupied.

    I am sure its use was not for drinking coffee or any beverage; just that the coffee shop proprietor thought he would look cool if he served coffee in such a cup! I see such utensils (made of stainless steel generally) which the mothers use to feed milk to infants, where they may not be able to hold and drink with a sipper.

  6. says

    I think your friend got it wrong, Pete. The “handle” is obviously a spout. Your friend was supposed to hold the cup in his palm and pour the coffee down his throat. Much more efficient than sipping. This cup has kaikaku-ed coffee drinking! (great article)

  7. says

    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, including 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.

    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.

  8. Sandip Ghosh says

    Sometimes I wonder why the simple concepts of Lean are not introduced in high schools and Universities! These really are learning for life and need not be restricted to those who have some work relation to the factory! Would make life safer …even in our homes.

  9. says

    This is a system problem, as are most. These are some examples of things that lead to such troubles– that are built into systems everywhere.
    1. Lack of a product designer. Product is developed by a team, to requirements or specifications that are delegated out. A team leader facilitates and keeps the project on schedule. But NOBODY has a responsiblity to see that the Product will actually work or be any good. All of the effort is to get each of the specifications met. Without a designer—- it is likely that key specifications are NOT written up and are not part of development, and further it is likely that compromises will reduce the utility of the product. If you could see the wants list that made this cup happen, you will likely see that it meets or exceeds every listed requirement. Then look at what happens next because if the want or need isn’t listed explicitly— it won’t be addressed. These are the things the graphic points out.

    2. List of wants by survey or by marketing committee delivered to the development team for realization of the product. The survey is a list of desirables, as are the wants that may be assembled by a marketing group. These are not engineers or designers with a holistic view of the complete product. They will list key points of interest, and leave the ASSUMPTION of the core needs of the product as just that, “assumptions” that of course “everybody knows that”. But these lists are passed on to Engineering functions who by nature will act precisely, and will have that precision enforced by budgets and economics— that if it is NOT on the LIst, then don’t do it. Again a true DESIGNER on the project would serve to stand up and point out what is missing. But if you hand a list of “wants” to the engineers— they are going to address those wants. Only. So you end up with a coffee cup that will do EVERYTHING on the list except deliver coffee to a human being for consumption— because that is the one thing that was never put in the specification— because of course everybody knows that is a core basic requirement and doesn’t need writing down or even discussion. Does it?

    • says

      And then there is this trouble——-

      All of this trouble is sourced in what Deming pointed out as “sub-optimization”. Who said “if no ONE is responsible, then NO ONE is responsible”? P. Crosby? It is the crux of the matter.

      The individual who CHOOSES the product to be implemented, never has to USE it THEMSELVES. They are not a “stakeholder”. Their only care is to again, meet the written job requirements.

      So you end up with Point of Sale terminals that have 80% failure to read rates when cards are “swiped”. The individual who had criteria in hand to choose a “vendor” only had to put “guarantees and warrantee” in the contract, but did not have to worry about actual performance. That is a problem for the service department in the field.

      You end up with “standard floor plans” for supermarkets put in place, with shelving locations that take no account for the fact that — in this building or that, there are support columns that end up blocking the aisle.

      You end up with “customer service systems” that have “select 1 for x and 2 for y” and when you follow the directions you get to a point where NONE of the choices fit, so the “voice menu” just hangs-up.

      You end up with a coffee cup that is stackable, storable in small space, light, easy to make—- in short does everything a modern coffee cup should do except deliver coffee to a human customer.

      You have examples you will observe everyday.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>