Cool Email Mistake Proofing

My main desktop computer runs Ubuntu Linux. The default email client is called Evolution. A recent upgrade introduced a very cool feature. When I hit “Send” it looks for language in the email that might indicate I meant to include an attachment. If there is no attachment, it pops up this handy reminder:

Maybe Microsoft Outlook does this too, I haven’t used the latest version, so I don’t know. But in any case, this is a great example of catching a likely error before it escapes the current process. I can’t count the number of times I have hit “Send” only to get an email reply “You didn’t include the attachment.” Obviously I was about to do it again, or I wouldn’t be writing this. 😉 Since I am sending out things like resumes right now, that is something I would really like to avoid.

When talking about mistake proofing, or poka-yoke, there are really three levels.

The first level prevents the error from happening in the first place. It forces correct execution of the correct steps in the correct order, the correct way. While ideal, it is sometimes easier said than done.

The next level detects an error as it is being made and immediately stops the process (and alerts the operator) before a defect is actually produced. That is the case here.

The third level detects a defect after it has occured, and stops the process so that the situation can be corrected before any more can be made.

Each has its place, and in a thorough implementation, it is common to find all of them in combination.

Related to this are process controls.

Each process has conditions which must exist for it to succeed. Having some way to verify those conditions exist prior to starting is a form of mistake-proofing. Let’s say, for example, that your torque guns rely on having a minimum air pressure to work correctly. Putting a sensor on the air line that shuts off the gun if the pressure drops below the threshold would be a form of stopping the process before a defect is actually produced.

A less robust version would sound an alarm, and leave it to the operator to correctly interpret the signal and stop the process himself. Your car does this if you start the engine without having the seatbelt fastened. (back around 1974-75 the engine would not start (see above), but too many people (i.e. Members of Congress) found this annoying so the regulation was repealed.)

Consider the question “Do I have all of the parts and tools I need?” What is the commonly applied method to ensure, at a glance, that the answer to this question is “Yes?”

If you answered “5S” then Ding! You’re right. That is one purpose of 5S.

A common question is how mistake-proofing relates to jidoka.

My answer is that they are intertwined. Jidoka calls for stopping the process and responding to a problem. Inherent in this is a mechanism to detect the problem in the first place.

The “respond” part includes two discrete steps:

• Fixing or correcting the immediate issue.
• Investigating, finding the root cause, and preventing recurrance.

Thus, the line stop can be initiated by a mistake-proofing mechanism (or by a person who was alerted by one), and mistake-proofing can be part of the countermeasure.

But it is not necessary to have mistake proofing to apply jidoka. It is only necessary for people to understand that they must initiate the problem correction and solving process (escalate the problem) whenever something unprogrammed happens. But mistake-proofing makes this a lot easier. First, people don’t have to be vigilant and catch everything themselves. But perhaps more importantly, they don’t have to take the (perceived) psychological risk of calling out a “problem.” The mechanics do that for them. It is safer for them to say “the machine stopped” than to say “I stopped the machine.”

Back to my email…