Root Cause Analysis definitions

Consider having one incident reporting system with one approach for teaching employees the definition of a near miss and with one approach for doing incident investigations including one approach for root cause analysis. 

A key word in the above definition is correctable. Managers at all levels need the root cause analysis to provide them with practical guidance—something that will help them correct their problems, and thereby improve their culture. The need for defining root causes that can help lead to solutions is demonstrated in the following paraphrased definition, adapted from Mark Paradies,... 

In this paper, the author attempts to integrate general assmnptions about the structure of safety management into one picture which constitutes the backgroimd for root cause analysis, nowadays the most recommended investigation method. Initial representation of the structure (Fig. 2) is complemented by the definition of the boimdary of internal safety management. The definition e q)loits the tool called Root Cause Map. After the addition of two basic assumptions... 

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. 

The natural consequence of the causality credo, combined with the Domino model, is the assumption that there is a basic or first cause, which can be found if the systematic search is continued until it can go no further. This is often called the root cause, although definitions differ. In the Domino model, the root cause was the ancestry and social environment, which led to undesirable traits of character. Since this was the fifth domino, it was not possible to continue the analysis any further. Other approaches, particular if they subscribe to some form of abstraction hierarchy, suffer from the same limitation. The type of analysis (which actually is a family of methods) that tries to find the root cause is unsurprisingly called Root Cause Analysis (RCS). 

Root cause analysis is attractive because it promises to provide a simple but definitive answer to a problem. It thus satisfies what Friedrich Nietzsche called a fundamental instinct to get rid of (these) painful circumstances. It is therefore hardly surprising that this set of methods is widely applied in many industries, for instance in health care. Indeed, the first response to a major... 

Probably the most interesting and enlightening analysis you could ever perform is to analyze why failure analysis fails. By its pure definition, it is impossible for failure analysis to fail—so how come it does The answers (root causes) often lie with the problem solvers themselves, as well as their management support groups. 

Whenever a proactive maintenance strategy is applied, three steps are necessary to ensure that its benefits are achieved. Since proactive maintenance, by definition, involves continuous monitoring and controlling of machine failure root causes, the first step is simply to set a target, or a standard, associated with each root cause. In oil analysis, the most important root causes relate to fluid contamination (particles, moisture, heat, coolant, etc.). 

The procedure continues until there is a root cause. It is possible that analysis does not uncover a root cause that meets the definition. 

In broad terms, the process for producing a specification for a safe design involves hazard identification (HAZID), which asks what sort of accidents do we need to worry about , followed by detailed analysis to identify the magnitude of potential accidents. From a safety perspective, a most important step is the clear and robust definition of the safety functional requirements, i.e., the requirements for the control and protection systems on the completed plant. The history of accidents involving design failures shows a frequent root cause to be inaccurate or inadequate definition of the safety functional requirements (see Fig. 2.3). 

In system safety, inductive analysis tends to be for hazard identification (when the specific root causes are not known or proven), and deductive analysis for root cause identification (when the hazard is known). Obviously, there is a fine line between these definitions because sometimes the root causes are known from the start of an inductive HA. This is why some analysis techniques can actually move in both directions. The PH A is a good example of this. Using the standard PHA worksheet, hazards are identified inductively by asking what if this component fails, and hazards are also identified by deductively asking how can this UE happen. 

---