Guidance for avoiding human error

[curryassassin]

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.

 

[Wes Bucey]

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/

 

[justncredible]

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.

 

[Ajit Basrur]

You could also have a look at this post - Nonconformity Caused by Human Error - How to make a Corrective Action?

 

[curryassassin]

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.

 

[justncredible]

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.

 

[curryassassin]

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.

 

[justncredible]

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.

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.

 

[Cari Spears]

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?

 

[Randy]

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.