Root cause system

The following case study describes the investigation work process for a hypothetical occurrence using a logic tree based multiple root-cause systems approach. An example incident investigation report follows the work process description. The example is intended for instructive purposes only descriptions of process equipment and conditions are not intended to reflect actual operating conditions. 

Check whether a documented system is in place, which covers the reporting, investigation, root cause analysis and corrective actions taken. 

An FMEA is a qualitative, systematic table of equipment, failure modes, and their effects. For each item of equipment, the failure modes and root causes for that failure are identified along with a worst-case estimate of the consequences, the method of detecting the failure and mi "ation ofits effects. Tables 3.3.5-2 and 3.3.5-3 present partial examples ofFMEAs addressing the Cuoling Tower Chlorination System, and the Dock 8 HF Supply System. 

FMEA is particularly suited for root cause analysis and is quite useful for environmental qualification and aging analysis. It is extensively used in the aerospace and nuclear ]iowei indiistrii-s but seldom used in PSAs, Possibly one reason for this is that FMEA, like parts count. ,s not chrectlv suita lundant systems such as those that occur in nuclear power plants Table i 4... 

In addition to incident reporting systems, root cause analysis techniques can be used to evaluate the causes of serious incidents where resources are usually available for in-depth investigations. A practical example of root cause investigation methods is provided in Chapter 7. 

In the shorter case studies, only the immediate causes of the errors are described. However, the more extended examples in the latter part of the appendix illustrate two important points about accident causation. First, the precondihons for errors are often created by incorrect policies in areas such as training, procedures, systems of work, communications, or design. These "root causes" underlie many of the direct causes of errors which are described in this section. Second, the more comprehensive examples illustrate the fact that incidents almost always involve more than one cause. These issues will... 

Error analysis techniques can be used in accident analysis to identify the events and contributory factors that led to an accident, to represent this information in a clear and simple manner and to suggest suitable error reduction strategies. This is achieved in practice by identification of the causal event sequence that led to the accident and the analysis of this sequence to identify the root causes of the system malfunction. A discussion of accident analysis techniques is included in Chapter 6. 

Root cause analysis systems, intended to provide in-depth evaluations of major incidents... 

The types of data required for incident reporting and root cause analysis systems are specified. Data Collection practices in the CPI are described, and a detailed specification of the types of information needed for causal analyses is provided. 

However, in the case of a root cause analysis system, a much more comprehensive evaluation of the structure of the accident is required. This is necessary to unravel the often complex chain of events and contributing causes that led to the accident occurring. A number of techniques are available to describe complex accidents. Some of these, such as STEP (Sequential Timed Event Plotting) involve the use of charting methods to track the ways in which process and human events combine to give rise to accidents. CCPS (1992d) describes many of these techniques. A case study involving a hydrocarbon leak is used to illustrate the STEP technique in Chapter 7 of this book. The STEP method and related techniques will be described in Section 6.8.3. 

In the case of root cause analysis systems, more comprehensive evaluations of PIFs will normally be carried out as part of a full-scale human factors audit. This could make use of the types of comprehensive PIF evaluation methods described in Chapter 2 (see Section 2.7.7 and Figure 2.12). 

For a major incident investigation using a comprehensive root cause analysis system, teams will be formed to acquire information relevant to determine the structure and analyze the causes in depth. In addition to evaluations of the immediate causes, imderlying causes are likely to be evaluated by investigations in areas such as safety and quality management. Both paper- and computer-based systems will be used to acquire and record information for subsequent detailed analyses. 

MORT excels in terms of organizational root cause identification, as factors such as functional responsibilities, management systems and policies are well covered, but this strength of the method requires an accurate description of the incident process, and an experienced MORT analyst who is knowledgeable and well-practiced in the methodology. 

The method is well-structured and provides clear, standardized procedures on how to conduct an investigation and represent the incident process. Also it is relatively easy to learn and does not require the analyst to have a detailed knowledge of the system under investigation. However, the method alone does not aid the analyst in identifying root causes of the incident, but rather emphasizes the identification of the propagation of event sequences. This is an important aspect of developing a preventive strategy. 

Workforce Support for Data Collection and Incident Analysis Systems Few of the incident investigation and data collection systems reviewed provide any guidelines with regard to how these systems are to be introduced into an organization. Section 6.10 addresses this issue primarily from the perspective of incident reporting systems. However, gaining the support and ownership of the workforce is equally important for root cause analysis systems. Unless the culture and climate in a plant is such that personnel can be frank about the errors that may have contributed to an incident, and the factors which influenced these errors, then it is unlikely that the investigation will be very effective. 

The root causes for this critical event both concern the operations department and the service department who ran the contractor maintenance team. The operations department (i.e., the day shift operations supervisor) failed to provide adequate supervision and instructions to the contractor team. Explanations of the nature of the permit-to-work systems (i.e., the need to report back at end of shift) should have been given, and the possibility and implications of work not being completed before the end of the shift should have been considered by both parties. 

On the part of the contractor team, two root causes were identified, root cause 1 being insufficient training of the contractor team leader. He was uncertain of permit systems, specifically whether they should report in at the end of shift, and, if so, who should do it. The second root cause relates to the procedure used at the end of the shift for supervisors to sign back permits. Although according to procedure all workers should hand back permits to supervisors in person, in practice this did not occur. If no one is present, or they are busy, it had become common practice to either leave the permits on the supervisor s desk, or to sign them back in the morning. 

Root cause 6. The system was not error tolerant. The error made was not detectable. 

Development of reactive programs including data collection and root cause analysis systems... 

---