Applying LEAN thinking to everyday problems - Part 4: Mistake Proofing

In my previous blog I gave some illustrations of the concept of waste, the simple problem solving tool and the 5S. In this blog I want to introduce the concept of mistake proofing.

We all know that to err is human. And if one person can make a mistake, anyone can. By putting processes and systems in place that either warn us that a mistake has occurred or that prevent mistakes from occurring, defects will be eliminated. The aim is to have zero defects because not conforming to a specification in materials, process or product produces waste and waste costs time and money.

You all come across many examples of warning or control mistake proofing on a daily basis – here are just a few:

  • You can no longer put petrol into diesel cars as the pump doesn’t fit (and no, those stickers on the petrol lid did NOT do the job…!).
  • Medicine and cleaning products are fitted with screw taps that little people can’t open. (Sometimes as an added precaution cleaning products have bitter compounds added to discourage children from swallowing any such liquid accidentally.)
  • Fuse boards stop overloaded circuits.
  • Swipe cards for hotel rooms prevent unwanted access.
  • Height bars at household recycling centres prevent unauthorised access by stopping certain vehicles from dumping waste.
  • Applications need passwords to enter an account.
  • Lift doors don’t close if something is in the way.
  • Ink tags on clothes destroy the garment should they be forcefully removed.

The principle of mistake proofing can be applied to any process – ideally mistakes are prevented at the source (see the above petrol / diesel example). If that is not possible than mistakes should be controlled (the process stops, warning signals are emitted after the error occurs). Obviously it wouldn’t be cost effective to eliminate all possible errors, so the pareto rule should be applied (focus on the top 20% of mistakes and you will eliminate 80% of the costs).

To finish this article, here is a little exercise for you: How would you prevent the below scenario from happening?

20150707 143119