posted 16 October 1998 04:22 PM               

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?

posted 19 October 1998 08:35 AM               

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.

posted 19 October 1998 12:32 PM               

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.

posted 20 October 1998 07:55 AM               

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.

posted 24 November 1998 11:20 AM               

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.