| Poka yoke emphasizes 100% inspections upstream for possible causes of defects, as well as rapid feedback and follow-up actions. This implies corresponding de-emphasis on expensive downstream inspection and Statistical Quality Control (SQC), which can be reduced dramatically or eliminated in many cases. Generally the "freedom from the spell of statistics" entails a more objective use of statistics. Poka yoke differs from SQC philosophically in that it does not accept the passive inevitability of defects. "Every defect that shows up is preceded by an earlier phenomenonthe error that was the cause of the defect." This is what led Shingo to arrive at the idea of zero (defect) QC methods.[1] In an enterprise software development context, poka yoke is particularly pertinent for two broad reasons. First, SQC is difficult to apply given the low volume of statistical data compared to a mass-manufacturing environment. Second, external failure costs may far exceed internal failure costs. Poka yoke aims to correct the process rather than the product. Traditionally, poka yoke relies on inexpensive in-process quality control methods. It's closely related to the concept of jidoka, or autonomationthe low-cost "intelligent machines" that stop automatically when they detect an error. Error detection is followed by feedback and corrective action at the source to eliminate the error's cause and isolate its potential impact downstream. Effective implementation of poka yoke involves the following five principles:[1], [2] 100% inspection at the source: Shingo argued that making inadvertent mistakes is only human and therefore is unavoidable. But what can be avoided are the product nonconformities that result from inadvertent mistakes. He propounded a fundamental concept in quality management: Poka yoke, when supported by 100% inspection at the source, can, in effect, detect every mistake. This concept is discussed in more detail later in this chapter. Appropriate upstream control measures: The monitoring, feedback, and corrective devices should be as close as possible to the source of the potential defect. Poka yoke control measures should be in relation to the degree of the problem's severity. Simplicity of measures is emphasized because they are easily developed and made available. Poka yoke also entails cost-effectiveness and lack of complexity. (Complexity is a major source of defects by itself.) Simple, economical, and adequate controls work best. In an enterprise software development context, appropriate control systems consist of simple checklists, error flags, prompts, self-check of programmed inputs, successive checks, data hiding, and protecting methods. Many measures comprise elements that should be deployed anyway. Poka yoke, therefore, often involves doing things right rather than doing something new or innovative. Rapid implementation: Many effective ideas can be implemented within hours of a problem's occurrence. Overanalyzing to find the perfect solution may not be the best resort. A better solution can, of course, be developed in due course. People focus and teamwork: Enterprise software development is a highly human-intrinsic and collaborative process. As such, quality software can be developed only by nurturing discipline, team spirit, and a sense of shared pride. It is important to involve software developers in identifying solutions and taking ownership of results. Issues related to developing a superior workplace environment are discussed in Chapter 10. Chapter 20 covers the need for teamwork and organizational preparedness. Problem-solving approach: Poka yoke is implemented by asking a series of questions "5 Ws and 1 H." Ask "Why did the defect occur?" five times, followed by "How do we fix it?" This is a commonsense problem-solving approach to poka yoke deployment.
|
