Proceedings ofof IMECE 05 Proceedings IMECE2005 2005 ASME International Mechanical Engineering Congress and Exposition 2005 ASME

International Mechanical Engineering Congress & Exposition November 5-11, 2005, Orlando, Florida, USA Florida USA November 1318,

IMECE2005-79453

IMECE2005-79453
DESIGN PROCESS ERROR-PROOFING: STRATEGIES FOR REDUCING QUALITY LOSS IN PRODUCT DEVELOPMENT
Lawrence P. Chao Intel Corporation Rotation Engineers Program 2200 Mission College Blvd. Santa Clara, CA, 95054, USA chaol2@asme.org Kosuke Ishii Department of Mechanical Engineering Design Division Stanford University Stanford, California, 94305-4022, USA ishii@stanford.edu

ABSTRACT Design errors are a major source of quality loss in industry today. Design Process Error-Proofing seeks to prevent errors during product development by adapting quality management techniques. Poka-yoke solutions used in manufacturing and operation aim to prevent mistakes from occurring or detect them immediately after they are committed. The goal of design process error-proofing is to extend this strategy and develop innovative structured methods and tools that understand, predict, and prevent design errors. Because the research topic is fairly new, case studies are used to both explain and demonstrate the usefulness of solutions. Through a series of design initiatives at leading global organizations, important lessons were identified in the treatment of design errors. This paper discusses these error-proofing strategies and results. KEYWORDS: design process, error-proofing, product development, industry case study, poka-yoke

Our research has shown that industry currently has limited methods in predicting and preventing errors during design. Much like kaizen (continuous improvement) is part of lean manufacturing, the engineering process continues to be compressed and must also be continuously improved and streamlined. Currently, most methods are reactive or aim to only fix one specific problem afterwards. For some organizations, the design review is the only line of defense. This research aims to identify higher level error-proofing solutions and communicate the methods through industry-based case studies. 1.2. Quality Management Innovations in quality management began around the late 19th and early 20th century with production techniques and management practices influenced by industrialists such as Taylor and Ford. After the World Wars however, quality management began to move upstream in the product life-cycle. Quality management experts such as Shewhart, Deming, Juran, and Ishikawa raised the management to Total Quality and insisted that quality improvement is a continuous process throughout the entire life-cycle, not just production. Taguchi worked with engineering approaches to improve quality by reducing loss early in design. It wasnt until the late 1960s that the term errorproofing appeared. Largely synonymous with Shigeo Shingos work with Toyota, the philosophy of poka-yoke, which literally means to prevent inadvertent mistakes is to prevent quality loss by preventing erring actions or using methods which detect them immediately. It is one in a number of continuous improvement techniques used in the kaizen concept and closely associated with the Toyota Production System. Many poka-yoke devices are used for manufacturing (including guide pins and limit switches) and even everyday operation (like polarized power outlets and automobile gas cap tethers). The principles of these basic improvement activities

1. BACKGROUND 1.1. Motivation Due to progress of quality management in production, a recent industry survey (Chao et al. 2001) showed that design errors were now the major source of quality loss at many manufacturing organizations. One Japanese electronics manufacturer even cited that 70% of their quality losses were due to design errors. Design process errors are often associated with the defects that escape and affect the end-users directly, but not all design errors are visible. A difficulty with design errors is that they can be latent errors whose effects are separated in both time and space from the causes. Errors to some degree have been accepted as part of design. However, rework and redesign loops are design defects that result in monetary or schedule.

Copyright 2005 by ASME

Design Process Error-Proofing: Reducing Quality Loss in Product Development Chao and Ishii are to build quality into the process and eliminate errors and defects (Nikkan Kogyo Shimbum 1988). Prevention devices may not always be possible or economically feasible, and in those situations detection errorproofs are used to detect errors and defect early in the process to prevent them from flowing downstream and increasing the cost of non-conformance. In production, a number of methods are common for detection devices. The contact method detects any deviation in shape, size, or other properties. The fixed value method uses devices like counters or optical sensors to check that parameters like the number of moves, rate or length of movement are within specifications. One an error is detected, the device signals that there is something wrong either through either shutting down the process or warning the operator. A shutdown stops the process and prevents further incorrect actions, while a warning will signal the occurrence of a deviation through buzzers, lights, or other alarm devices. Warnings are used particularly when some tolerance of deviation is accepted to allow a process to run but informs the operator that adjustments are necessary to keep the process within control. Figure 2 illustrates how a detection error-proof can be added to a drilling station through a limit switch that detects motion of the drill to ensure operations are completed. If the operation is not performed, an alarm/light will indicate the omitted operation.

2. ERROR-PROOFING Error-proofing has been defined as the process of striving for zero defects through techniques, devices, and standards that either anticipate, prevent, or detect errors. Shingo summarized the relationship between the two by saying that errors are the cause of defects and defects are the effect of errors. Many organizations, like Motorola, General Electric, Allied Signal, and Toyota, have actively and effectively applied error-proofs in their production systems.

2.1. Types of Error-Proofs Error-proofing devices, often referred to simply as pokayoke, fall into two major categories: prevention and detection. Prevention error-proofs do not allow the process or operator to perform an action that is not a normal part of the process or assist them in making the correct action. Devices and approaches can be active or passive. Passive prevention devices can include simple visual cues like color coding to prevent using mixed or incorrect parts. Active prevention devices include exaggerating minor differences or asymmetry to allow alignment or insertion in only one manner. Prevention error-proofs can also use control methods to stop a line or process when a problem is sensed to prevent serial defect generation. For example, if all the components in an assembly are not used, the line will shut down until the assembly is complete. In Figure 1, the device actively selects pins of only acceptable diameters by not letting oversized pins into the acceptable bin and letting gravity roll undersized pins away.

Before

After
Alarm/Light indicate omitted operation

Limit Switch

Before

After
Acceptable pin Oversized Undersized pin pin

Figure 2.

Example of a detection error-proof (HINCKLEY 2003)

Detection is not to be confused with inspection. general, there are three types of inspection: Judgment inspection: Separate defective products from good ones; prevents defects from being delivered to customers, but does not decrease a companys defect rate Informative inspection: Investigates the causes of defects and feedback this information to the appropriate so that action can be taken to reduce the defect rate Source inspection: 100% inspection at the source

In

Diameter differences exaggerated for clarity

Figure 1.

Example of a prevention error-proof (HINCKLEY 2003)

Copyright 2005 by ASME

Design Process Error-Proofing: Reducing Quality Loss in Product Development Chao and Ishii The difference is that inspection activities usually try to identify defects in completed products, while detection tries to identify the erring action or defect as soon as it is introduced into the system. Poka-yoke rely on real-time feedback and corrective action. The objective is to prevent or at least detect defects as early as possible. Minimizing the delay between action and feedback is critical in error-proofing. To help communicate and educate the use of poka-yoke, a number of resources have collected examples and explained their effectiveness. In the book Poka-Yoke: Improving Product Quality by Preventing Defects, the Nikkan Kogyo Shimbun (1988) developed a comprehensive, illustrated guide to pokayoke through collection of extensive examples of jigs, fixtures and procedures to use differing assembly and fabrication of parts and subassemblies. The solutions are simple and realworld and point towards process rather than design changes. Figure 3 shows that a majority of these devices aim at prevention and use control methods.
BEST

Prevention
Eliminate the possibility of error

Replacement
Substitute a more reliable process
BETTER

Facilitation
Make work easier to perform

Detection
GOOD

Detect the error

Mitigation
Minimize the effect

Figure 4.

Preference in error-proofing strategies

Robinson (1997) identified recommendations for creating good poka-yoke: Simple: Better to have several simple poka-yokes each with a single purpose. Specific: Identify a mistake that occurs frequently and prevent or detect it. Attributes: Look for aspects that can be verified independently. Early: Try to detect and eliminate defects as early as possible. Responsive: Correct the mistake as soon as possible. Re-use: Successful poka-yokes can be modified to serve new purposes. The simplicity of an error-proof does not limit its effectiveness. As an example, Figure 5 shows much consideration has been given to a device as simple as a gas cap used in most automobiles. The designers put in many prevention mechanisms to error-proof the task of refilling the car.

1.7% 71.7% 26.7% 73%

5%

11%

11%

Prevent Detect Both

Shutdown Alarm Control Combination

Figure 3.

Common types of error-proofing devices

2.2. Error-Proofing Principles Though devices typically aim to prevent or detect errors, there are a number of different principles and strategies in error-proofing a process or design. According to Norman (1988), though errors are not uncommon, proper consideration can help decrease the incidence and severity of them by eliminating the cause of some, minimizing the possibilities of others, and helping to make errors discoverable once they have been made. Figure 4 lists various strategies identified by GE Medical Systems in dealing with errors and processes and their desirability.

Before

After

Figure 5.

Error-proofing capabilities of a Gas Cap

Copyright 2005 by ASME

Design Process Error-Proofing: Reducing Quality Loss in Product Development Chao and Ishii
TASK

Communication

Analysis

Execution

Communication

2.3. Difficulties in design domain Design can be a time-consuming, iterative, and error-prone process. The goal of design process error-proofing is to develop tools, structured methods, and strategies to predict, mitigate, and prevent quality losses from design process errors. As opposed to the typical production process, the design process is unique with longer cycle times and greater variation between the processes. Creative freedom is valued and design engineers often dont want to be managed. Some even go so far as to say that errors are an inherent part of the process that design must execute.

Changes

Knowledge

Figure 6.

Key factors mapped on to a task

Solution level refers to the scope at which the action tries to correct: either at the problem, the process, or the system. The robustness level refers to the method by which the errorproof mitigates future errors. Figure 7 illustrates that organizations should seek a higher level of solution and robustness in dealing with their design errors.

3. DESIGN PROCESS ERROR-PROOFING 3.1. Background Though the idea of design process error-proofing is far from universal, there are many tools already available which aid the effort. Tools designed to simplify or speed-up the process can often benefit error-proofing. Through benchmarking and categorizing errors and the development of methodologies such as Design Process FMEA (Chao and Ishii 2003b), significant progress has been made in the identification, understanding, and prediction of errors to better control and improve the design process. This research also expands the customer focus from end users to include the voice of the organization. Project QFD is a tool used to help identify resources which strategically align with business needs (Chao and Ishii 2004a). Once an organization identifies problematic areas, the next step is to identify corrective actions. This research considers three dimensions while implementing design process errorproofing solutions. Error factors refer to the nature of the error that the corrective action is designed to mitigate and includes sub-categories such as knowledge, analysis, communication, execution, change, and organization. Shown in Figure 6, in any task, the agents involved must perform an analysis of the situation to determine what must be done. The agents must communicate the requirements to begin the task and the completed work once the task has been executed. Design tasks require knowledge by the agents to perform the task. The agents and information are continually subject to change from both within the organization as well as influences from systematic process noises and external, like market, uncertainties.

SOLUTION LEVEL
Level 3: Fix the system Level 2: Fix the process Level 1: Fix the specific
problem, very reactive

ROBUSTNESS LEVEL
V. Prevention: Eliminate the
possibility of performing an erring action

IV. Detection: Detect the error

immediately after being made

Level 0: Denial phase,

rationalize without fixing

III. Inspection: Source inspection

of completed process step

II. Improvement: Improvement

to simplify or guide the process

I. Tool: General tool to aid analysis

and design

Figure 7. Solution and robustness levels for corrective actions and solutions

Our study of manufacturing and assembly poka-yoke identified attributes that are similar in design which can be leveraged. Errors, whether they occur in the manufacturing, design, or operation domains, occur for similar reasons. Perception and communication errors, for example, can occur in any domain. Though the idea of error-proofing is not new, it has not been fully and properly developed for the development process.

3.2. Industry Case Studies

3.2.1. Background

In the fall of 2002, Stanford Universitys Manufacturing Modeling Laboratory (MML) initiated a series of design process error-proofing case studies. These case studies benchmarked development process error-proofing practices across industry worldwide (Chao and Ishii 2005). The goal of this effort was to share and educate on product development errors in the hopes of better understanding them to better implement solutions. Case studies have included organizations such as GE, ABB, NASA, HP, GM, and Oracle. The full case

Copyright 2005 by ASME

Design Process Error-Proofing: Reducing Quality Loss in Product Development Chao and Ishii studies are available through the MML [1]. As example, the error-proofing efforts at GE are explored in more detail below.
3.2.2. Error-proofing at GE

In response to variation in processes and analyses, GE Aircraft Engines Turbine Airfoil Center of Excellence (TACOE) wished to implement advanced techniques like process automation in product development. To make this possible, however, an accurate understanding and mapping of the process are required. Though engineering process templates have been kept, most have been at a higher, organizational level and much smaller scope. The turbine airfoil design process chosen was very complex and included many domains, including aero, cooling, and thermal design aspects. By using elements of the Six Sigma DMAIC (Define, Measure, Analyze, Improve, and Control) process, the team used meetings, databases, and existing templates to fill the map. Once detailed templates are available, the organization has the ability to error-proof through lean engineering and automation as well as train new engineers. This effort would eventually be used to propagate similar scale efforts throughout the rest of the organization through laying groundwork in Design for Six Sigma (DFSS) training.

lean manufacturing principles to engineering. Lean engineering is implemented through automation and integration on different levels. Analysis linking capabilities can be done through scripts. The lowest level uses wrappers around existing computer software tools and programs, each of which perform a different type of analysis such as aero, cooling, or stress. The next parent level is essentially one pass through the entire engineering process of a series of children. Last, the grandparent level performs higher order probabilistic analysis iteratively on one selected parent-level design process wrapper, including Design of Experiments (DOE), Monte Carlo, and Optimization.

Robust Design
optimization

Probabilistic Analysis
DOE, Monte Carlo, Fast Probabilistic Integration

Deterministic Analysis

Requirements

Templates

Design Review Process

Process Mapping

Automation

Integration

Figure 9.

Hierarchy of Robust Design Analyses

Design Practices Lessons Learned

Methods

Figure 8.

Role of templates in the design process

This engineering process template was important in improving their design accuracy. Recent experience had shown their life predictions of their turbine airfoils to be inaccurate. In response to uncertainty in the life forecasts of parts, their goal was to streamline and automate a product development process in order to implement a more rigorous engineering analysis. Design can be a time consuming, error-prone process. To run an analysis, engineers must decide parameter values, edit input files, read the simulation code, read the output, do calculations, edit the input files again, run the simulation code again, read the output files again, and cycle again and again. Probabilistic design uses sets of deterministic analyses to design a part while considering the sources of variation through distributions rather than single values. However, due to the inherent scale and complexity of the analysis, it became necessary to improve, automate, and integrate the current design process. Implementation of probabilistic design for improved productivity and quality required the application of

The General Electric case studies on process templates, lean engineering, and probabilistic design, though each of them a substantive and substantial error-proofing effort independently, together were part of a comprehensive errorproofing effort. The immediate results of each seem promising. The Engineering Process Template team at GE did some testing of the process, running through the process by hand, and making sure that everything worked as was advertised. Once drafts were prepared, it was necessary to go through quality control and the design review. The design board of experts reviewed the templates to ensure that the process was mapped out correctly. Then the Chief Engineers office ensured that the details were at the proper granularity and consistent with what they expected. They have checklists, documentation, and resources to consult. Since the effort started almost a year ago, much progress has made on the Engineering Process Template for turbine airfoil design. Currently, the engineering design template over one hundred pages and will ultimately be put on the intranet. Included in this document are checklists, the purpose/input/output of the tasks, and what is necessary to run it in batch mode. Like originally intended, it will be used for both training individuals and automating the process. In the effort of lean engineering for probabilistic design, GE currently has about a dozen working wrappers. In addition to the individual program wrappers, a "higher level" wrapper

Copyright 2005 by ASME

Design Process Error-Proofing: Reducing Quality Loss in Product Development Chao and Ishii has been written which allows for a user to run through all the wrappers in one pass. Eventually this higher level wrapper will include all the programs and processes required for performing a life estimation analysis. In addition, the TACOE has performed probabilistic analysis on one tool. The developers of the lean engineering system were largely from mechanical engineering backgrounds and not computer scientists or IT professionals. However, they expressed the belief it would have been beneficial to have more involvement from people with formal training in programming. The developers of this system also had some observations on the implementation of such a system. There are a number of languages available to use for the wrappers, including PERL, C, KSH, or various CAD languages. These languages and the programs they are associated with vary in power and flexibility. Some of the developers felt that a generic, automation language that allows communicate with any UNIX tool would be ideal. It would be easy to use and compatibility is not as large an issue. However, some features of more complex languages like inherent versioning are beneficial. The lean engineering effort has not been easy, but there is a clear shared vision of the benefits that will come from it.
3.2.3. Summary

reason, organization of these errors and solutions uses subcategories to better index them. Through this system, one can leverage experience from other domains, particularly manufacturing and assembly. This development extends capabilities to commonalities in the nature of error and the categorization of them. Table 2 shows some of the subcategories considered.

Table 2.
Solution Categories Knowledge Check Root cause Tool Methodology Tracking Check Root cause Collaboration Standards Tracking Check Automation Guide Methodology Tracking Check Check Root cause Collaboration

Summary of design process error-proofing solutions by category

EP Examples Sub-categories New problem Derivative problem Familiar problem Subcomponent Dynamics Environment System Variation simulation, meetings, User interaction guidelines Transfer/delivery Interpretation/translation Record/documentation records/documentation, Timeliness/up-to-date receipts, checklists, meetings, data management Assumptions Completion Correctness Ownership/responsibility Instructions automation, guidelines, Tools/aids checklist, templates Warnings Ownership/responsibility Unnecessary configuration and change Unknowns control, process structure, Verification reviews Oversight Structure process structure, standards Standards knowledge management databases, best practices, lessons learned

Standards Collaboration Methodology

Sub-category examples experimentation, simulation, benchmarking best practices, lessons learned templates, best practices, lessons learned guidelines, simulation, PDMs simulation, testing simulation, testing Interface Control Documents, system release model probabilistic design use cases delivery/return receipts, checklists review together, standards, Interface Control meetings assign scribe/secretary, threaded newsgroups rather than e-mail configuration control, gate meetings review together, threaded newsgroups rather than e-mail automation, checklist, templates guidelines, template, design tools, IT tools checklist, guidelines, templates, reviews, Interface Control Meetings templates, best practices, lessons learned coaching guides, manuals, case study examples configuration control and change management Change Control Board, process/workflow plans peer reviews, scorecarding experience, simulation gate/process model gate/review model, Change Control Board templates, process model experts, standardized language/units/processes

The error-proofing case studies show different methods for the various error factors during product development. Often, tools designed to simplify or accelerate the process also benefit error-proofing. Many cases demonstrate how to control design processes and implement continuous improvement, while the use case library and CAD robustness in particular, show how to bring customer focus into design. Table 1 summarizes these cases and identifies the relative importance (High/Medium/Low) of the error factors. Benchmarking of these cases plus other tools, methods, and strategies showed that knowledge tools, like electronic databases and documents and organizational models, like the life-cycle models, were more prevalent.

3.3. General Strategies by Category

3.3.1. Knowledge

Table 1.

Summary of design process error-proofing cases

Implementation Cost Robustness Level Communication Organizational

Case Data-driven CAD Robustness Lean Engineering and Probabilistic Design The Gate Model and Platform Planning Engineering Process Templates System Engineering Model Use Case Library Engineering Peer Meetings Product Data Management

Category II Automation V Automation Collaboration III II Guide Collaboration II II Knowledge III Check Collaboration II

2 3 3 2 3 3 1 3

H M L H H M L

M L L H M M L L H L L L L H

M H H

M H H H H H M H M L H

L L H L H L H L

There is certainly overlap and correlation between the various factors for both the errors and the solutions. For this

There are several challenges in managing knowledge in an engineering process. To transfer this knowledge, challenges are present in gathering, storing, validating, sharing, and accessing knowledge. Liang and Leifer (2000) found that even when projects change from year to year, there are aspects which design team members are always interested in. Simply archiving wasnt enough as accessibility is an issue as well. Based on the type of design problem, whether the challenge is a new product development or an evolutionary development, the type of knowledge will vary. The knowledge can come in several forms, whether based on past engineering experience, through best practices and lessons learned, or in general references and resources. Communication of information is important in knowledge transfer. The two design resources which emphasize the transfer of knowledge to new products are in knowledge databases and design reviews. Design reviews are an informal mechanism of transferring experience between projects and members, while knowledge databases, which can come in various formats, not necessarily electronic, are formal, searchable, and accessible. For mature technologies and familiar problems, templates, best practices/lesson learned are a good knowledge store. For new problems, more benchmarking, simulation, and even experimentation is necessary to fill in the knowledge gaps.

Usage Cost

Solve Level

Knowledge

Execution

Changes

Analysis

Org.

Changes

Execution

Comm.

Analysis

Know.

Copyright 2005 by ASME

Design Process Error-Proofing: Reducing Quality Loss in Product Development Chao and Ishii
3.3.2. Analysis

Proper analysis requires accurate and comprehensive representation of the problem. The difficulty with analysis is even when appropriate action is done to contextualize the problem, there can still be "unkunks" (unknown unknowns). It can be a challenge to fully understand the problem. Problems can not simply be decomposed and then integrated without consideration of system interactions. Dorner (1996) has researched and identified the logic of failure in complex situations. Humans have many inadequacies in dealing with complexity, dynamics, and temporal developments. They tend to extrapolate linearly and cannot handle exponential changes. The slowness of human thought often obliges shortcuts and prompts use of scarce resources as efficiently as possible. But instead of clarifying the complex relationships, humans often select one variable as central and economize around that. Analysis identifies the appropriate contextual knowledge and the actions necessary to execute the design task. Like with knowledge errors, guidelines, meetings, and simulations can help with challenges in analysis. Though they can help frame problems appropriate based on past experience, analysis can also be aided through information technology tools and better organization of system problems. Visualization, which is assisted today by virtual models and simulations, is important. Seeing a dynamic, 3D model can reveal a lot more information and better understanding than a number of static, 2D drawings. Improved communication through pre-meetings and interface control documents help clarify the system roles and interactions. Use cases help document and formalize user interaction with products to better discern the operational challenges.
3.3.3. Communication

instant message and require increasingly sophisticated tools that can verify and log communications. The completion of transfer or delivery can be guarded with delivery and return receipts as well as checklists; however, e-mail is insufficient for most complex projects because it is chaotic and unregulated. Collaborative design environments, tracking tools and metrics, and various standards aid these efforts. Threaded discussions and tools such as browser-based interactive/online meetings greatly improve communication and knowledge archival. Software can also automate the delivery (push) of information and reminders at pre-specified times as well as reveal the status of the communications.
3.3.4. Execution

Communication issues often arise with incomplete or incorrect context or execution, resulting in misinterpretation and misunderstanding. The context and assumptions need to be made explicit. According to Leveson (2000), cognitive psychologists have determined that people tend to ignore information during problem solving when it is not represented. An incomplete representation actually impaired performance because it is assumed to be comprehensive and truthful and can actually lead to worse performance than having no representation at all. Standards and forms can provide proper context of information and prevent erring actions in communication. Peer meetings can help ensure proper interpretation and translation. Documentation and records can be accomplished by assigning a project scribe or secretary. The timeliness of information can be ensured with change and configuration control software or gate meetings. Information technology can play a very large role in aiding communications. Globally distributed design and engineering teams are increasingly common as firms take advantage of educated workforces in low-cost labor centers and consolidate to achieve economies of scale. These organizations are using the Internet to collaborate on designs through e-mail and

The risks in the execution of design tasks are that they can be done incompletely or incorrectly. Some tasks may not be explicitly detailed. Other tasks whose relevance is not immediately evident are more likely to be done incompletely or even omitted. The other error factors all influence the execution. Traditional execution aids, like checklists, are passive. It is difficult to create general and re-usable guides; a checklist can only address issues on a superficial level and will only be very specific for certain applications. Guides and methodologies help with the correctness of execution while tracking and checking tools help with the comprehensiveness. Clarifying the ownership and responsibility of parties is also important in ensuring the completion of tasks. Finally, aids such as training sessions or guides, manuals, and examples can help users complete their tasks. Automation, primarily through information technology, is one solution method that is being used increasingly. The linking of analyses through scripting can accomplish automation in design. The benefits of automation include consistency, reduced cost, and increased productivity. Automation in design should aim to reduce menial efforts and down time. However, whenever theres automation, there is the fear of losing practice and expertise. Even if expertise isnt lost, there is the danger one might assume the process is doing one thing when it is actually doing something else. It is difficult to ensure that users read documentation and understand it. In assembly, automation attempted to replace operators with automatic work heads where the tasks being performed were simple. Complete automation, where the product is assembled completely by machine is essentially nonexistent. Some tasks that an operator can perform easily are extremely difficult to duplicate on even the most sophisticated mechanism (Boothroyd 1992).
3.3.5. Changes

With concurrent engineering, design teams often split up for tasks and work in parallel. The communications on responsibilities and version are not always clear, and this can be a major issue particularly when there is only one centralized repository of information which all are working off of. For this reason, clarification of responsibilities and accountability is an

Copyright 2005 by ASME

Design Process Error-Proofing: Reducing Quality Loss in Product Development Chao and Ishii important part of preventing errors from changes. Process models, reviews, or change review boards can help formalize this process. Information technology has been used in many ways to assist with product development. Most applications leverage on the strength of computers, better fidelity in storing large amounts of information and the precision in performing actions, which aids with implementing consistency into the development process. Collaboration tools are evolving rapidly and continually. Originally, access to software files and models was controlled by the operating system. If a file was in use by one designer, others were locked out until the model was released by the OS. This was very limiting because it meant that no one could use the model for reference purposes while it was being updated, leading to complex designs which became out of sync. Though not strictly marketed as such, the product data and life-cycle management applications can be powerful in mitigating errors from change and communication in design tasks. Change and configuration control provide a repository and version control. When a change is made, CCC records the time and who changed what, and possibly also what was changed and why it was changed. When working in parallel, simultaneous versions can be developed and then merged and compared if necessary. Some times, change impact analysis can also be provided.
3.3.6. Organization

4. CONCLUSIONS According to Don Clausing, influential MIT professor, Design error-proofing is very important. Together with robustness it gives reliability and shortens development time. Design errors are a major source of quality loss in industry today. The organizations and error-proofing efforts benchmarked in these case studies were all large enterprises with established product development processes. Smaller organizations with less mature development processes may take a slightly different strategy. While some solutions can be used in an a la carte fashion, for maximum effectiveness the process needs to be formalized. Most of these methods require an initial investment in infrastructure or technology. Errorproofing the product development process is not a one step effort. To have a truly robust process, several steps need to be taken. There is symmetry to this chronology where organizations starting with their new product development processes must first gain general engineering knowledge to improve the process at a lower level. However, as the processes and products mature, higher organization level decision making such as enterprise planning or market decisions improves. The next steps of error-proofing then return to the task level. A structured process is important in a robust product development and design. An organization which has experience should capture and leverage it. Structure makes weak processes stronger and burdens the system rather than the individual agents. Computers and information technology already play key roles in product development. By collecting information on industry error reporting, experiences, and standards, the lessons learned can improve other knowledge stores, like corrective action databases. It is clear that information technology has a key role in error-proofing product development (Chao and Ishii 2003a). IT tools can aid with data management, collaboration, and workflow. IT error-proofing solutions provide virtual boundaries, tracking, and checks with information which can not otherwise be handled and manipulated physically the way parts and components can be in assembly with limit switches and the like. The issue is these virtual environments often require major initial investment to put all the information, processes, and knowledge into a workable format. For this reason, they may need to be leveraged across several projects to be cost-effective, and thus might not be as worthwhile for less mature or smaller organizations. At the same time, immature organizations that are still formulating their product development process and system have more opportunity to change and optimize the first time, rather than fight the inertia of status quo. In conclusion, there are several keys in developing and implementing error-proofs, not only in design but in other domains. The first is feedback; whenever possible, the error-

Historical root cause analysis of major disasters has shown that often times it is not one single, erring action that results in failure. With the system engineering model case as an example, if individual sub-teams optimize for their own components and not the system, a sub-standard product will result, even though no team did anything wrong. Improvements of an organizations developments can be done at different levels. It is not uncommon for some organizations to deny problems and rationalize them without fixing them by saying they are a one of a kind occurrence. Ideally, an organization should aim to fix the process and the system. Many hesitate to have the organization place additional requirements on the engineers and managers as there are a number of regulations and requirements already in place. Obviously, the organization, the project, and the individual some times have differing priorities, but the overall goal of all involved should be the same. Each side will need to make some adaptations for all involved to succeed. Process structure and standards to aid with the collaboration are important in an organization. Oversight can be provided through a stage-gate or life-cycle review model or through experts or a change control board. Structure can be provided through templates, checklists, or process models. Standards, like ISO, or even standardized languages, units, and processes can make the system more robust. Tools to aid collaboration and communication are also important in this effort.

Copyright 2005 by ASME

Design Process Error-Proofing: Reducing Quality Loss in Product Development Chao and Ishii proofing solution should somehow provide information to the designers that something is going wrong or about to. Minimizing the delay between the action and its feedback ensures errors will be recognized and corrected. A second is motivation and accountability; the best insurance that methods which reduce errors will be used is if they make the task easier, faster, or cheaper to complete and if the user is accountable for the task that is being performed. Finally, given that product development errors are hard to predict, active prevention schemes are preferred to detection and inspection as it is not always clear what to look for. Taking these strategies into consideration, an organization can error-proof the system, not merely react to individual problems after they occur. [I] Hinckley, C.M., 2001, Make No Mistake, Productivity Press, Portland, OR. [J] Ishii, K. (ed.), 2005, ME317 Course Reader, Stanford University, Stanford, CA. [K] Leveson, N.G., 2000, Intent Specifications: An Approach to Building Human-Centered Specifications. IEEE Transactions on Software Engineering. Vol.26. No.1, January. [L] Liang, T., and Leifer, L.J., 2000, Re-Use or Re-Invent? Understanding and Supporting Learning from Experience of Peers in a Product Development Community. Proceedings of the 30th ASEE/IEEE Frontiers in Education Conference. October 18-21, 2000. Kansas City, MO. [M] Nikkan Kogyo Shimbum Ltd. / Factory Magazine (ed.), 1988, Poka-yoke: Improving Product Quality by Preventing Defects, Productivity Press, Cambridge, Massachusetts. [N] Reason, J., 1990, Human Error, Cambridge University Press, Cambridge, England. [O] Reason, J., 1997, Managing the Risks of Organizational Accidents, Ashgate Publishing Limited, Aldershot, England. [P] Robinson, H., 1997, Using Poka-Yoke Techniques for Early Defect Detection, Proceedings of STAR 97 (Sixth International Conference on Software Testing, Analysis, and Review, July 28, San Jose, CA.

ACKNOWLEDGEMENTS We sincerely appreciate the support of Gene Wiggs of GE Transportation over the years as a mentor, liaison, and friend to this research.

REFERENCES [A] Boothroyd, G., 1992, Assembly Automation and Product Design. Marcel Dekker, Inc. New York, NY. [B] Chao, L.P., and Ishii, K., 2005, Design Process ErrorProofing: Benchmarking Gate and Phased Review LifeCycle Models. Proceedings of the ASME DETC: DFM, Salt Lake City, UT. [C] Chao, L.P., and Ishii, K., 2004a, Design Process ErrorProofing: Project Quality Function Deployment, Proceedings of the ASME DETC: DFM, Salt Lake City, UT. [D] Chao, L.P., and Ishii, K., 2004b, Design Process ErrorProofing: Challenges and Methods in Quantifying Design Elements, Proceedings of the Tenth ISSAT International Conference on Reliability and Quality in Design, August 2004, Las Vegas, NV. [E] Chao, L.P., and Ishii, K., 2003a, Design Process ErrorProofing: Development of Automated Error-Proofing Information Systems, Proceedings of the ASME DETC: DAC, Chicago, IL. [F] Chao, L.P., and Ishii, K., 2003b, Design Process ErrorProofing: Failure Modes and Effects Analysis of the Design Process, Proceedings of the ASME DETC: DFM, Chicago, IL. [G] Chao, L.P., Beiter, K., and Ishii, K., 2001, Design Process Error-Proofing: International Industry Survey and Research Roadmap, Proceedings of the ASME DETC: DFM, Pittsburgh, PA. [H] Dorner, D. 1996, The Logic of Failure. Perseus Books. Cambridge, MA.

WEB REFERENCES [1] Design Process Error-Proofing Case Studies http://mml.stanford.edu/Research/EP.html

Copyright 2005 by ASME