Mistake Proofing: human paperwork errors

I am trying to address human paperwork errors for my employer. We have difficult with verification of paperwork. Our parts go through many inspection steps, aquire a lof of paperwork, and perwork verification is confusing. I am looking for a problem solving tool that could help us identify ways to reduce human errors. Mistake proofing seems to be centered on product design. Is there any hope?

Steve,

Sure there's hope. Without knowing anything about your system, it is very difficult to determine the best method to employ. I would be glad to help if you want to furnish some details, but, here are a few ideas in the meantime:
1. Checklists
2. Reduce the number of forms by combining information onto 1 or 2 records.
3. Assign a unique identifier for verification purposes.
4. Re-evaluate the information you are gathering, do you really need it all? Maybe you are recording too much.
5. Must your system be manual or can you automate it somewhat?

Let me know if you want some indepth analysis, be glad to help, just need the details

Leslie thank you. That gives me a start.

Is there a formal process for this or do books just reference a bunch of case studies. If you have a recommended text for reference that would be helpful.

I have seen a lot of material on the net that talk about how great it is, but nothing to explain how to do it.

-Steve.

Steve,

Mistakeproofing is also called dummyproofing (not very politically correct), foolproofing or poke yoke. these methods refer to mechanical or electrical design process but the techniques can be applied to operational or information systems also.

What you are looking for isn't really documented as it is a new field. Use basic problemsolving techniques along with common sence.

Good luck, doing what you're taking on is difficult and frustrating. Best advice I can give you is to question everything! If it's not value added, get rid of it. this is very hard to do since all the people using the information will be hard pressed to admit that there is information collected just for the heck of it.

Decide what you absolutely need, work backwards, then forwards and then back again. Run the system.

I hope this helps.

[Marc]

I believe the answer is basically laid out in Leslie Garon's first response. There are two aspects to any 'job':

Folks making systems and defining what to do and how to do it

Folks doing what the other group of folks have defined.

Typically summarized as bosses and everyone else.

The failure mode is almost always with the bosses who make up overly difficult and/or complex systems and processes - which is what it sounds as if you have. Typically when the systems are adequate and clear yet there are failures to complete paper work it's because the bosses hadn't paid attention. The bosses don't pay attention, someone doesn't fill out a space, no one notices and the next time is easier. I could go on at length here (believe me, this is always a failure mode when I take a client on), but suffice it to say:

Step back and walk thru the process and ask yourself - is this process too complex or have people gotten lazy.

A big part of all this comes down to attention to detail.

Only way to solve paperwork problems completely is to computerize where data must be input before anyone can move material/subassemblies to the next process step.

Leslie's and Marc's responses are right on the money. For our paperwork errors we initially threw "training" at the problem because, as everybody knows, when there is a problem, it's always training related. When I finally convinced my managers that maybe it wasn't a training problem, they allowed me to do a quick front end analysis - a type of gap analysis - to actually see what the problem was. It was, in fact, an overly complicated system that caused the problems. The problem was eliminated with checklists and unique markers. Dropped our errors by 75%.

Whenever I design a new system or re-engineer one, I add a couple of things into the system design to help with these problems. They are as follows:

1. Visibiity: This is pretty easy to build into your system. Just make it impossible to cover up things. The KISS principle applies here as well as the principle of checks and balances. The benefits are that it is a two edge sword. On one hand, it will show all problems as soon as they happen and will make the cause (if designed correctly it is the root cause) evident and thus more easily remidied. On the other hand, when the system works well, it will also show. If you take this to application, it shows employees as being consistant, quality minded, and proactive or in need of training, overcomplexity of the system or in need of discipline.

2. Consistancy: Build your system so that it is foolproof. During the design process run through the process 3 times; backwards, forwards and then backwords again. flow charting can help but it is still possible to miss internal and external affecting factors. Play devils advocate relentlessly during this process. It may be a harsh technique but if you can throw everything possible at the system and it still holds true when you're done, you have something that will be reliable.

3. Documentation: Documenting the system is very important. Going through all the detains of exactly what steps must be peformed, where it will be recorded, what information is desired to be kept and who will do it lead toward reliable system integrety. Even if you are not in an ISO or QS environment, the exercise is essential. The document is not a waste because you can then use it as a trainint tool. Documentation is not ment as an end all and be all as most currently expect it to be. It is only another tool. but by documenting the steps, rules and policies, management has something to stand upon and hold people to.

4. Training & Implementation:
How you implement is very important. I am a firm believer in documention where it's needed, but the documentation must be accompanied by training and then coaching. Whenever you re-engineer or develope a new system and desire to implement it, you are inflicting change. The success of implementation is all in how you manage the change process. Change management is the key. 1st document the system, make sure that all involved in the system have been part of the process, providing input and helping you to run the system to find holes. pay attention to likes and dislikes. This is cultural and is a very important part of your system design. 2nd, train those who will use the system. Tell them why, what is behind it, educate them, don't just teach them what to do. This does not lead to understanding, smooth implementation, longevity or continuous improvement. 3rd, coach. Once implementation has begun, the designer/trainer should be on the sceen, gently guiding the users of the system. humor and sarcasism are great tools, make the mistake seem silly, laugh at it and move on. We're all learning afterall. It is the attitude that makes the implementation successful. If you make it a stressful experience, implementation will not be successful, so make them understand, comfortable with the adaptation process, OK to make a mistake then fix it. This also breeds teamwork and discourages finger pointing. it also breeds higher quality because there is less fear.


These of course are not generally new ideas but they are applied in a unique manner. If ndone correctly, not only will you have a successful implementation but it will happen alot quicker than you expected at a much higher reliablility level yeilding higher quality.

[Marc]

Also see: http://Elsmar.com/ubb/Forum31/HTML/000052.html