Hi everyone,
The number of problems or the severity of problems due to human error has been increasing recently in my organisation. In order to help mitigate / prevent the impact of human error in the future, I have prepared the attached brief guidance document, which is based, in part, on some of the opinion given in the cove. Please could you review and give me your expert and learned opinions, so that I can improve the advice.
This will be much appreciated.

Hi everyone,
The number of problems or the severity of problems due to human error has been increasing recently in my organisation. In order to help mitigate / prevent the impact of human error in the future, I have prepared the attached brief guidance document, which is based, in part, on some of the opinion given in the cove. Please could you review and give me your expert and learned opinions, so that I can improve the advice.
This will be much appreciated.Professor Grout used to have his website on mistake proofing at his school's website. Apparently costs have forced him to move it to a commercial site. In my opinion, Grout has some of the best, unbiased stuff around about mistake proofing.
http://www.mistakeproofing.com/

I was also gonna mention the mistake proofing.

and add another page from the Toyota system, and that is the training aspect. It is not enough to just make sure the SOP is read and understood, behaviour is learned, so increase the amount of time that a well trained operator spends with a untrained operator. Put the best with the worst.

Also automation, limit the impact of of error by removing any variable you can.

Flow chart out the processes and see where the failures occur.

Any human error should be a call to action to improve the process, and that is managements responsibility. If one area has more than a few errors is it the system to blame or the operator. Why does the system allow errors to pass to the next step in the process?

I am not discounting that once in a great while a operator is the problem. I will say it is the very last thing to look at in the process.

You could also have a look at this post - Nonconformity Caused by Human Error - How to make a Corrective Action? (http://elsmar.com/Forums/showthread.php?t=26269)

Thanks for the responses so far.
I am familiar with Poka Yoke devices and their ability to detect the causes and prevent the defects, but what about the prevention of the human error causes? I have also skimmed the recent thread on human error. I don't agree that 'any human error' should be a call to improve the process - it could be the first minor human error with that process, or there could be a handful of minor human errors in other processes, so an improvement may seem unnecessary.

Thanks for the responses so far.
I am familiar with Poka Yoke devices and their ability to detect the causes and prevent the defects, but what about the prevention of the human error causes? I have also skimmed the recent thread on human error. I don't agree that 'any human error' should be a call to improve the process - it could be the first minor human error with that process, or there could be a handful of minor human errors in other processes, so an improvement may seem unnecessary.


Yeah thats why I said a "few", it really depends on the chances a error can occur if the "system" has broken down. A study of the system can give you the visual "aha" moment where you see the chance for the failure of the system. You have a alpha and beta risk and you have to correlate those to see if a process change will be cost savings or a waste.

The way Toyota did it was to double the amount of time a person had a training partner, that ensures the training was complete, then errors after that was almost always the system breaking down. It created a flag that is a chance for improvment to the system. You would ask the 5 whys once the flag is raised.

EG, You know a wrong label was placed on a unit. Now ask WHY, I am willing to bet only managment can be blamed for the failure, either they do not provide enough adequite training, the process is ill defined, the instructions do not follow the process.

There is such a small amount of people that will with proper knowledge of expections make a mistake. If mistakes are common, find a way to remove that varible. Do that by first finding out WHY.

The only way to ever prevent a mistake is with automation, humans are human, we all make mistakes.

Also by the way you are trying to improve the process with your .DOC posted. Just I do not agree with it, to me it is a scapegoat to shift the blame for a error to the operator and not address why the error occured. IMO

What is poka yoke? It is mistake proofing a process, it forces the removal of the chance for a mistake.

Thanks again. I am familiar with Gemba Gembutsu and Poka Yoka but have not had the opportunity, yet, to incorporate it here, or try it out or train anyone else. To illustrate my starting point, consider this example please:

Items are stored. Paper storage records state 1 item remaining. Operator removes last item and records 0 remaining. Next operator finds more identical items and removes 1, then records 0 again in the records. This is repeated a few more times by different operators. Records and / or actual stock levels are incorrect. Some of these operators are 'senior' in post. Cause as stated: Human Error. I want to know why did they make the same error multiple times?

Maybe they did not want the responsiblity of sorting the problem of record and stock errors. Maybe they were rushed? I don't know yet.

The system has failed to stop the process on the error. If they record the "0" on a computer you can cause it to shut off any future inputs into that paper number until a further action is made, such as adding more product to the count. A computer would "automate" that step and provide a way to mistake proof the process.

What is the action when a stock hits zero? From my experince when a certain number is reached a flag for purchasing is raised so more can be ordered. Who is to be contacted to maintain a supply? Why were they not contacted? Why was the process not stopped?

Applying poka yoke does not have to be a big ordeal, you have a chance to improve the process, you have justification for automation, as a side benefit records can be retained and viewed with much more ease. Saving time = saving money.

This is management failure to provide a tool. Or This is management failure to provide enough time to stop the process and take corrective action. Or this is management failure to instill process ownership to the operator.

I suggest training, send the managers back to school. :D

The system is broken, retraining "senior" will not fix the problem, since they are the process experts. You might get a few weeks/months with no recurring errors, but you will not fix the root problem. I am also sure the management will all sit around patting themselves on the back for placing the blame on the operators, and implementing harsh new penalties for failure.

And you have to also understand me personally will 100% of the time blame the management, I do have a bias, since I still have to break a sweat every now and then.:lol:

I am familiar with Poka Yoke devices and their ability to detect the causes and prevent the defects, but what about the prevention of the human error causes?
The aim of Poka Yoke - or mistake proofing - is the prevention of human error causes...no?

Prevention of failure caused by human error through the use of automation?

I recall a movie and book called "Fail Safe"

Regardless of the level and detail taken in automation guess what....the potential for failure is always present and you can never take people out of the process.

And it look's like it's always managements fault, whereas the actual cause could be a breakdown with identifying what was required to begin with, or in communication, or competence of all involved or any combination of these and other contributing factors.

If we were to honestly work under the concept that no matter how well defined and controlled "S**t happens" then we would focus more on the "S" and less on the who. The who can never and will never be under total control or guarantee.

Prevention of failure caused by human error through the use of automation?

Oh boy my spelling has caused a failure in understanding autonomation
is the correct word.

http://en.wikipedia.org/wiki/Autonomation

Yeah wiki is awful but it came up first in google. And there is errors on that wiki. But the basic is correct.

We know there is potential for the sun to go nova, but it has not happened in billions of years. :notme: And Randy you lost me totally with your direction:confused:

Kanban is also a valid way to control the running out of stock.

The error I was most interested in was that each subsequent operator had apparently removed another item, recorded this on the record, and then stated that the remaining stock was 0, just like the preceeding entries, but did nothing about it.

In actual fact, we are replacing the paper trail with a bit of off-the-shelf software which will do the job and more, and we have validated the software for our own use. Also responsibilities for adding / removing stock will be assigned to a privilaged few, and access to the stores will be restricted to these individuals. Have I got my Poka Yoke devices now?

Please explain how I gently break the news to management that it is their fault that these errors have occurred and not the operators, which they believe are 'to blame'. We are yet to 'optimise' this and other critical processes, so maybe when we complete this exercise, some of the creases will be ironed out.

The aim of Poka Yoke - or mistake proofing - is the prevention of human error causes...no?

I thought it was the prevention of the EFFECT of the cause, rather than preventing the cause?

Please explain how I gently break the news to management that it is their fault that these errors have occurred and not the operators, which they believe are 'to blame'. We are yet to 'optimise' this and other critical processes, so maybe when we complete this exercise, some of the creases will be ironed out.

I have had to do this a few times since the beginning of the earth...feeling mighty old today.

It is not easy, and you have to approach this cautiously. Something like, "well, it is true that Joe there could have gotten a new inventory of that, but if you think about it, what exactly did we fail to implement that allowed him to do that? I think we thought we had covered all the bases, but (bless his heart) Joe managed to find the way that the system would fail. It's actually a blessing in disguise, because now we have the opportunity to improve the system.

Otherwise, if you are feeling lucky, you could do what I did today and say "what do you mean why didn't I take the initiative to take care of the problem? I didn't see you there following me around while I asked everyone I could find if they knew how that dispenser worked. When I could not find anyone who knew, I came to you to contact the contractor to do the job he was supposed to have done last night. I kinda thought that was taking initiative." needless to say both the manager and I came away from that conversation with less than warm and fuzzy feelings. :frust:

(the first option, while it may gag you to spit it out is probably perferrable)

You pat them on the back for providing the new computer controled system eliminating the chance of this error reocurring.

No reason to expose the negatives, in doing it this way you reinforce that management has done its job by providing the tools needed for the task.

The next time you ask for something needed they will fondly remember the problem solved and sign off on the project. Also once the errors stop they each in time will relize they had failed to provide the tools.

Since they no longer have to record a number or track the inventory, you no longer have to train them to do it. You have cut the wasted time the operators spend writing down a number, which means cycle time to complete the process has been cut. "worker saving" is a term you can use, you have freed up more time for them to work. :applause:

Oh boy my spelling has caused a failure in understanding autonomation
is the correct word.

We know there is potential for the sun to go nova, but it has not happened in billions of years. :notme: And Randy you lost me totally with your direction:confused:


Autonomation still requires human interaction, and guess what? When the system broke down the responsible person was in the can!

The sun could go nova in the next 15 minutes, California can drop into the Pacific tomorrow and people no matter how well trained, motivated, or controlled by fancy "reduce-the-potential-for-failure-flavor-of-the-minute-programs" will still try to put the square peg into the round hole.

The Toyota system has been evolving for over 100 years, the tools that they use are more than proven. It took 10 years to get kanban accepted in Toyota, and was first used company wide in 1962. The autonomation was first used on a loom in the late 1800's. My point being history proves these tools work.

This thread is about a found error in a process, instead of beating up the operators a solution has been found. Will it with 100% certainity eliminate any chance of error, NO. But it will reduce the chance for the error to reocurr, and in a cost effective way. This is a winning case example of process improvment thru the use of autonomation. This is poka yoke in action.

I see this as a great move, not a negative. I have a little more faith in people than Randy I think.

The Toyota system has been evolving for over 100 years, the tools that they use are more than proven. It took 10 years to get kanban accepted in Toyota, and was first used company wide in 1962. The autonomation was first used on a loom in the late 1800's. My point being history proves these tools work.

This thread is about a found error in a process, instead of beating up the operators a solution has been found. Will it with 100% certainity eliminate any chance of error, NO. But it will reduce the chance for the error to reocurr, and in a cost effective way. This is a winning case example of process improvment thru the use of autonomation. This is poka yoke in action.

I see this as a great move, not a negative. I have a little more faith in people than Randy I think.


You had better add something to the mix that seems to escape you........a very good reason behind the success may be part culture as well.

As for having faith in people........that got me shot on a traffic stop once and I still have the hole in my right leg. People will do what they have to do when they have to do it and no matter how well trained and experienced a pilot can still forget the landing gear. You will always have a variable when people are involved, and that has nothing to do with faith.

No as a matter of fact Ohno had to wait for a entire generation to leave before his projects were accepted. The Toyota culture fought every single project, every supervisor complained, every worker fought it. Sakichi Toyoda understood the big picture. Ohno was later removed from upper ranks and consulted suppliers. No the culture hated the changes.

As for faith in people, I personally can not imagine walking thru life with no trusting people to do things right. I trust the kid at wendys to cook my burger as ordered, I trust the can of coke to have 12 ozs, I trust so much stuff each day to something another person has touched, and I do not think twice about it.

As for faith in people, I personally can not imagine walking thru life with no trusting people to do things right. I trust the kid at wendys to cook my burger as ordered, I trust the can of coke to have 12 ozs, I trust so much stuff each day to something another person has touched, and I do not think twice about it.


We don't want to get too far off track here, but are you sure it's trust and faith or just hope? Jack-in-the-Box makes excellant burgers and they lost a couple of customers a few years back from undercooked meat that was prepared according to procedure.....the procedure was a bit off and the meat was underdone. Air France is an excellant airline and we trust the pilots, but still one came in too fast in Toronto and burnt in a ditch along the 401 (I watched it happen from my plane that had just landed). US military pilots are well trained with all kinds of automation in the cockpit and still place ordinance in the wrong place (there's lots of faith and trust in people and systems there). Doctor's are incredibly well schooled and trained, we trust and have faith in them and they still cut out the wrong thing and prscribe contradictory medication. Mistakes happen and will always happen regardless.

I trust and have faith in the fact there will always be variables beyond control and accept that square pegs will try to be placed into round holes regardless.

Get rid of emotion, look at things objectively and manage the variable.

Therein is the "common cause" and the "special cause" of process variation.

This thread is a "common cause" failure, the system failed.

Randy cites examples of "special cause" system failures.

We know from the OP that all of the operators failed to document the correct number, the entire system failed to do what was expected.

Jack in the box, which makes the best tacos I might say, makes thousands of burgers a day with a proven process. Due to some unknown reason burgers were released undercooked. This is a rare occurence, not "normal" to the process. It is a "special cause" error, a 1 in a million chance happening, the system did not fail, since we know many burgers are cooked to perfection.

We can guess as to why the burger was undercooked, we can say the temp of the grill was to low, and a way to error proof the low temp grill could be a light bar with red and green lights that show when the grill is at cooking temp. This would be a example of poka yoke, you remove the chance of error due to temp, by the use of a automated signal.

As for landing planes that now is being automated, we are seeing more and more drones instead of human pilots. Also 50 years ago all planes had a flight engineer to plot the planes location in flight. Now we use on board computers to plot the flight plan. How many lives have been saved thru the intelligent use of automation of a process? Planes have moved from pure human touch to autonomation, automation with a human touch.

Yes, but you are trying to evade the the fact that none of it happens without human involvement and humans will err, not can err, but will err.

Ask JPL the significance between metric and English measurements....or the designers of the Hubble or the decision of American industry to not pay attention to PDCA-CI until it was too late..............error proofing is not error guarantee.

Chernobyl had good safety procedures, but a person decided to circumvent them to run an experiment.

BP had good procedures for oilline maintenance but people decided to set them aside.

The USAF had excellant procedures for maintenance of Titan ll's and they still blew one up in Arkansas because they weren't followed and the emergency procedures weren't followed either. (It was real, real loud)

These are all square pegs and round holes and all have common cause...human. You can have KanBan, kaizan, poopan, Tarzan, poka yoke, egg yolk or holey oak, and nothing, but nothing will guarantee no error or remove the word oops from the vocabulary.

Great discussion!

I think maybe you are confused as to what mistake proofing is. It is not a 100% certanity that a mistake will never happen again.

The auto-loom that Toyoda invented stopped when a thread broke or ran out. It did not stop the thread from breaking or running out.

I am off until the 7th.......:bigwave:

OK, hey it's been fun:bigwave:

Hi Wes,
Thank you very much for sharing the mistake proofing center. :thanks:
Hi Ajit,
Thank you for the path for the nonconformity caused by Human Error.
Discussions were informative.:thanx:
Raffy :cool: