Root causes product design

Consider again a batch polymerization process where the process is characterized by the sequential execution of a number of steps that take place in the two reactors. These are steps such as initial reactor charge, titration, reaction initiation, polymerization, and transfer. Because much of the critical product quality information is available only at the end of a batch cycle, the data interpretation system has been designed for diagnosis at the end of a cycle. At the end of a particular run, the data are analyzed and the identification of any problems is translated into corrective actions that are implemented for the next cycle. The interpretations of interest include root causes having to do with process problems (e.g., contamination or transfer problems), equipment malfunctions (e.g., valve problems or instrument failures), and step execution problems (e.g., titration too fast or too much catalyst added). The output dimension of the process is large with more than 300 possible root causes. Additional detail on the diagnostic system can be found in Sravana (1994). 

A common error is to limit the types of deviations reported to and evaluated by the APR system to just deviations from finished-product specifications. All deviations should be evaluated, including deviations from manufacturing procedures, in-process specifications, deviations from raw material specifications, and other expected results. Each of these occurrences could indicate changes are necessary to prevent recurrence. For example, the cause of deviations from manufacturing procedures is frequently evaluated as a lack of training. If there are several of these occurrences by different individuals, however, it is also likely that there maybe another root cause, such as unclear or insufficient batch record instructions or inadequately designed or unclear batch record data forms. 

If your innovation isn t performing as expected or specified, or if you want to anticipate what could go wrong with your design before going into production, you can use a C E Diagram. Just make sure that your team is knowledgeable about the system or process in question, and that they re open to getting to the root cause of any issues. 

The stage for an accidental course of events very likely is prepared through time by the normal efforts of many actors in their respective daily work context, responding to the standing request to be more productive and less costly. Ultimately, a quite normal variation in somebody s behavior can then release an accident. Had this root cause been avoided by some additional safety measure, the accident would very hkely be released by another cause at another point in time. In other words, an explanation of the accident in terms of events, acts, and errors is not very useful for design of improved systems [167]. 

When we look at the factors that are identified in the interviews, we can see that the different factors, and hence, the related explicit uncertainty that is caused by them, can all be related to the different stages of the product lifecycle as, for example, defined by Bedford, Quigley and Walls (Bedford et al. 2006), i.e. concept and definition, design and development, manufacturing and installation, operation and maintenance. We see for example that the concept root-cause analysis (here, uncertainty is caused by this concept because we do not know the extent to which we are able to find the root-cause) can typically be related to the operation and maintenance phase. On the other hand, the concept supplier management (here, uncertainty is caused by the unknown level of quahty with which supplier management is applied) typically relates to the design and development phase. 

---