Open side-bar Menu
 The PLM Insider
Jyotirmoy Dutta
Jyotirmoy Dutta
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.


YouTube Direkt

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:

  1. 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.
  2. 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 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:

  1. Disks Running out of space: Quite often vaults and log files grow so fast that disks run out of space and one doesn’t know about it until late. A good poka yoke in this case would be to get one of those disk monitoring software to send an alert out when free disk space falls below a particular threshold.
  2. Status Page of servers: A full-blown PLM implementation would have a number of servers which keeps on going higher as one starts adding redundancy/fail-over mechanism and remote site replicas. A good poka-yoke device here would be to implement something akin to Facebook Engineering’s cache monitoring tool Claspin

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:

  1. Process health monitoring tool – Similar to the Status Page of servers mentioned above. Facility to drill into active workflows can be helpful.
  2. Fail Over Mechanism – What happens when a user resigns from the company, his/her user accounts are deleted and a task was assigned to that user in a workflow long time back – Does the workflow get stalled now or a message goes back to the process initiator (or administrator) to do something about the task?
  3. Redundant Data Entry – Sometimes due to poor workflow design there redundant data entry over the life cycle of a process – immediately mistake proof this by having data entered only once and propagating that data downstream (once it’s reviewed or approved).

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.

  1. Usability – As Oleg points out in his post “PLM Innovation: Who will provide PLM to Boeing in 2015?” “The most disappointing reason is related to usability of PLM systems. The usability of PLM tools is going down, which confirms the fact PLM is struggling from complexity and user experience”. “New” features sell software. For many companies, putting users on the version upgrade treadmill is their business model; its how they generate revenue. Modern PLM systems are vast, and in the attempt to be everything to everyone the UI’s are cluttered and loaded chock full of features (which probably a user will never need) that they look more like an airship cockpit. Such Feature creep/Software bloat might be needed to satisfy a lot of requirements, but which at times might be overkill and likely to result in errors. While I wouldn’t necessarily advise a lock down with an UI being too minimalist to the point of being unusable, I would however go in to say that the UI options presented to the user should at least be configured for the role the user plays. For example if my role is that of a document approver I shouldn’t necessarily see dozens of options related to pushing the bom to manufacturing.

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.

Further Reading:

Poka-Yoke: Improving Product Quality by Preventing Defects

Zero Quality Control: Source Inspection and the Poka-Yoke System

Related posts:

Tags: ,

Category: PLM

Leave a Reply




Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy Advertise