Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software

Poka yoke should not be approached as a panacea for all kinds of mistakes. It is important to understand that poka yoke may be more suitable in certain situations than others. Grout provides guidelines for situations where it works well and where it does not (see Table 9.1).[9]

Table 9.1. Applicability of Poka Yoke

Works Well

Does Not Work Well

In manual operations where worker vigilance is needed Where mispositioning can occur

Where adjustment is required

Where teams need commonsense tools and not another buzzword

Where SQC is difficult to apply or apparently ineffective

Where attributes, not measurements, are important

Where training costs and employee turnover are high

Where mixed-model production occurs

Where customers make mistakes and blame the service provider

Where special causes can reoccur

Where external failure costs dramatically exceed internal failure costs

Where product nonfunction can be catastrophic

Where destructive tests are used

Where the production rate is very rapid

Where shifts occur more rapidly than they can be responded to

Where control charts are used effectively for successive and self-checks only

Poka yoke can be very effective in software development processes. Its applicability is supported by the various considerations listed in Table 9.1. People affected by the process must be involved in designing a poka yoke system. Such systems should be simple and free of complexity (itself a cause of defects). Simple, commonsense tools work best. But poka yoke is not rocket science, nor is it a silver bullet, so it should not be approached as such.

Related

Категории