A couple of months back I was in a meeting with a group of client business process leaders when the topic of idiot proofing their new PLM system came up. Pretty interesting discussion ensued for some time which led me to think, read and eventually write about the topic. Idiot proofing and more formally fool-proofing essentially means to build products which can be used or operated with very little risk of breakage or failure, by predicting all possible ways that an end-user could misuse it, and designing the product to make such misuse unworkable, or to at least diminish the negative consequences. Euphemisms like Hardening, Defensive Programming, Bullet Proofing, Fault Tolerant, Gold-Plating, Human Proofing, Worst Case Scenario Proofing, Robustification also exists which essentially show the equivalent.
A related Japanese term used in the manufacturing industry is “Poka-Yoke” (poka joke) from the words “poka” (which means inadvertent mistake) and from “yoke” (which means to prevent) means “fail-safing” or “mistake-proofing”. “A poka-yoke is any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur. The concept was formalised, and the term adopted, by Shigeo Shingo as part of the Toyota Production System or Lean Manufacturing.” [http://www.shmula.com/category/lean/poka-yoke/]. Mistakes are inevitable; people cannot be expected to concentrate on all the time, or always to understand fully the directives they are given. On the other hand, defects result from allowing a mistake to reach the end-user, and are entirely avoidable. The goal of Poka yoke is re-designing/engineering the process so that mistakes can be prevented or immediately detected and corrected.
Why would you want to poka-yoke your PLM application?
So you have bought a commercial PLM application which has been reasonably well-developed and well-tested and you have it implemented in your company. Why would you then want to poka-yoke (mistake-proof) your PLM application (apart from regular testing that happens before it goes live)? Two reasons:
- Reduce support calls after system goes live: PLM administration is costly because it needs a highly trained/experienced person to administer the installation and troubleshoot issues – You do not want to burden the administrator with frivolous snags because the end users are breaking stuff all the time and need help.
- Garbage In – Garbage Out The quality of the data in the PLM systems is as dependent on what goes in. As the book Universal Principles of Design says: “The garbage-in metaphor refers to one of two kinds of input problems: problems of type and problems of quality. Problems of type occur when the input provided is different from the input expected. Problems of quality occur when the input received incorrect information in the correct type.”
Poka-Yoke in Software Development vs. Poka-Yoke in Enterprise Software Implementation
Software developers like Harry Robinson in “Using Poka-Yoke Techniques for Early Defect Detection” and Gojko Adzic in “The Poka-Yoke principle and how to write better software” and Aaron Swartz in The Pokayoke Guide to Developing Software have advocated the use of poka-yoke in software development. However enterprise software deployment/implementation is different – there are now and then way too many users and a plethora of permutations/combinations which they can (or would) use/misuse the software – such use cases are sometimes hard to predict upfront (while developing the software) and hence the need to implement poka-yoke devices during the real life implementation. I cannot comment about users of other enterprise applications, but PLM users often work in situations necessitating substantial technical skills, where training/adoption or employee turnover cost is high and where interruptions and distractions are all too common. Such settings result in human error (whether due to Distraction, Tiredness, Confusion, De-motivation, Lack of Practice/Training, Uncertainty, Lack of standardization, Willful (ignoring rules or procedure), Inadvertent or sloppiness etc. is a different issue altogether) which might as an end result lead to GIGO and more support calls.
Poka Yoke Before or After Implementation?
Mistake proofing can be done upfront only till the point where it is known what mistakes might be made (which can happen only after a thorough system testing). However to add a good poka-yoke solution for a problem, the problem needs to be defined first (along with things like when where and (more…)