The PLM Insider
Jyotirmoy Dutta works as a PLM Lead Consultant at Infosys with more than 13 years of expertise in PLM Strategy Consulting, Solution Architecting, Offshore Project Management and Technical Leadership. He has led several full life-cycle PLM implementations, in the Consumer Products, Electronics & … More »
Poka-Yoke Your PLM Application
November 2nd, 2012 by Jyotirmoy Dutta
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:
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 how it occurs, and how many defects are produced etc.) which can only be done when the system goes into production and a good grasp is made of the issues users are having.
How to create good Poka-yokes?
There are way too many resources out there about good interface design or human-computer interaction. Obviously covering them is out of scope for my small blog entry but I do want to cover a few aspects that I have seen in real-life implementations:
PLM Infrastructure Poka-Yoke:
Process Side Poka-Yoke:
A typical PLM system would host a number of workflow processes – NPI, Change Management, Document Approval etc. While implementing Poka-Yoke here, remember the 1-10-100 rule – one dollar spent on prevention will save 10 dollars on correction and 100 dollar on failure costs. The trick is to just fool-proof the parts of the process that repeatedly cause defects. Some examples:
Application Side Poka-Yoke
Off course end-user interaction is the most crucial part of a PLM system – hence the most critical error prevention strategies come at the UI level.
Disallowing Bad Decisions Vs. Creativity?
I read something very interesting here: “Making a process idiot-proof requires that you make it impossible for the users to make a “bad decision”. You do this by either removing all decision-making from the process, limiting choices to a set of known-safe alternatives, or by assigning all decisions to someone assumed to not be an idiot. This eliminates creativity and restricts the users’ actions.” While for some software this argument might hold true, I view PLM as a vehicle to aid users get their main work done – their creativity is shown in CAD or BIM or whatever other software they use for their work. So error-proofing shouldn’t really stifle creativity.
Becoming aware of errors at their source and thwarting their conversion to defects is the elemental principle behind poka yoke. Mistake proofing builds quality, so it is a proactive approach to quality control. Conventional approaches have been reactive, allowing rework and repair as a solution to defects. Considerable problems can be diminished swiftly by applying mistake proofing principles thereby saving time and money spent on re-work at a later stage.