Background
The Systemic Occurrence Analysis Method (SOAM) is a process for conducting a systemic analysis of data collected during a safety occurrence investigation, and for summarising and reporting this information using a structured framework and standard terminology. It aims to remove the spotlight from the errors of individuals and to identify factors at all levels of the organisation or broader system that contributed to the safety occurrence. A correct application of SOAM will identify systemic safety deficiencies and guide the generation of effective recommendations to prevent recurrence of such events. SOAM helps to:
• Establish what happened
• Identify local conditions and organisational factors that contributed to the occurrence
• Review the adequacy of existing system controls and barriers
• Formulate recommendations for corrective actions to reduce risk and prevent recurrence
• Identify and distribute any key lessons from the safety occurrence
• Detect trends that may highlight specific system deficiencies or recurring problems.
Key Concepts
The Systemic Occurrence Analysis Method is one of several accident analysis tools based on principles of the well-known "Swiss Cheese Model" of organisational accidents. SOAM is a process for conducting a systemic analysis of the data collected in a safety occurrence investigation, and for summarising this information using a structured framework and standard terminology. As with some root-cause analysis investigation methods, SOAM draws on the theoretical concepts inherent in the Reason Model, but also provides a practical tool for analysing and depicting the inter-relationships between all contributing factors in a safety occurrence. SOAM allows the investigator to overcome one of the key historical limitations of safety investigation - the tendency to focus primarily on identifying the errors - those intentional or unintentional acts committed by operators - that lead to a safety occurrence. Reason's original model has been adapted and refined within SOAM. The nomenclature has been altered in accordance with a "Just Culture" philosophy, reducing the implication of culpability and blame by both individuals and organisations. In SOAM, 'Unsafe Acts' are referred to as Human Involvement, 'Psychological Precursors of Unsafe Acts' as Contextual Conditions, and 'Fallible Decisions' as Organisational and System Factors.

Benefits
SOAM forces the investigation to go deeper than a factual report that simply answers questions such as “What happened, where and when?" First, data must be collected about the conditions that existed at the time of the occurrence which influenced the actions of the individuals involved. These in turn must be explained by asking what part the organisation played in creating these conditions, or allowing them to exist, thereby increasing the likelihood of a safety occurrence. SOAM thus supports the fundamental purpose of a safety investigation - to identify and understand the factors that contributed to an occurrence and to prevent it from happening again.
SOAM is aligned with, and supports, "Just Culture" principles by adopting a systemic approach, which does not focus on individual error, either at the workplace or at management level. It avoids attributing blame by:
• Removing the focus from people's actions, and instead seeking explanation for the conditions that shaped their behaviour;
• Identifying latent organisational factors that allowed less than ideal conditions to exist, under which a safety occurrence could be triggered.
As with the original Reason’s Model, SOAM can be applied both reactively and proactively. The process can be applied to any new occurrence, and is also suitable for the retrospective analysis of previously investigated occurrences in an attempt to extract additional learning for the promotion of safety. SOAM can also be applied proactively to generic occurrences or hypothetical events. These applications result in a comprehensive analysis of the absent or failed barriers and latent conditions that are commonly found to contribute to such events, thereby identifying areas of organisational weakness that need to be strengthened to improve safety and prevent future occurrences.
How It Works
The SOAM process follows seven specific steps that are Gathering data, identifying barriers, Identifying human involvement, Identifying contextual conditions, Identifying organizational factors, Prepare SOAM chart and Formulate recommendations.
GATHERING DATA:
While there is no definitive or prescribed method for the gathering of investigation data, it is useful to gather data within some form of broad descriptive framework, to help with the initial sorting of facts. The SHEL Model provides the basis for such a descriptive framework.
Data should be gathered across five areas (the four original areas of the SHEL model, and an extra fifth element - organisation):
• Liveware
• Software
• Hardware
• Environment
• Organisation
While the data gathering and analysis phases in an investigation are typically depicted as discrete, in reality they are part of a recursive process. After an initial data collection phase, a preliminary analysis can be conducted, which will identify gaps that can be filled by further data gathering. This process will continue until the systemic analysis has eliminated unanswered questions and reached a logical conclusion.
Having collected the data, the first stage of the SOAM analysis involves sorting each piece of factual information into an appropriate classification. This is a progressive sorting activity which can be conducted as a group exercise if the investigation is being conducted by a team.
IDENTIFYING ABSENT/FAILED BARRIERS:
Barriers protect complex socio-technical systems against both technical and human failures. Absent or failed barriers are the last minute measures which failed or were missing, and therefore did not (a) prevent an action from being carried out or an event from taking place; or (b) prevent or lessen the impact of the consequences.
As with each stage of the SOAM process, a check question is applied to ensure that the item being considered fits within the definition of the category it is being considered for.
BOX
Check Question 1: Barriers
Does the item describe a work procedure, aspect of human awareness, physical obstacle, warning or control system, or protection measure designed to prevent an occurrence or lessen its consequences?
IDENTIFYING HUMAN INVOLVEMENT:
Following identification of the relevant absent or failed barriers, the next step is to identify the contributing human actions or non-actions that immediately preceded the safety occurrence. The question at this stage should not be why people behaved as they did, but simply what their actions/inactions were just prior to the event.
The information-processing model selected for use with this methodology is Rasmussen's Decision Ladder technique (1982). Like similar models, it assumes that information is processed in stages, beginning with the detection of information and ending with the execution of an action.
The Decision Ladder uses a six-step sequence which has been adapted for use within SOAM to present a simplified view of common controller tasks such as ATCO. Using this model, human involvement in a safety occurrence can be analysed in terms of:
• Observation
• Interpretation
• Choice of goal
• Strategy development
• Choice of action plan
• Execution of action plan
BOX
Check Question 2: Human Involvement
Does the item describe an action or non-action taking place immediately prior to, and contributing to the occurrence?
IDENTIFYING CONTEXTUAL CONDITIONS:
Contextual conditions describe the circumstances that exist at the time of the safety occurrence that can directly influence human performance in the workplace. These are the conditions that promote the occurrence of errors and violations. In the occurrence investigation process, contextual conditions can be identified by asking “What were the conditions in place at the time of the safety occurrence that help explain why a person acted as they did?"
Five categories of contextual conditions can be distinguished, two relating to the local workplace, and three to people:
• Workplace conditions
• Organisational climate
• Attitudes and personality
• Human performance limitations
• Physiological and emotional factors
BOX
Check Question 3: Contextual Conditions
Does the item describe an aspect of the workplace, local organisational climate, or a person's attitudes, personality, performance limitations, physiological or emotional state that helps explain their actions?
IDENTIFYING ORGANISATIONAL FACTORS:
The organisational factors (ORFs) describe circumstances which existed prior to the occurrence and produced or allowed the continued existence of contextual conditions, which in turn influenced the actions and/or inactions of staff. The following categories of ORFs are identified:
• TR - Training
• WM - Workforce Management
• AC - Accountability
• CO - Communication
• OC - Organisational Culture
• CG - Competing Goals
• PP - Policies and Procedures
• MM - Maintenance Management
• EI - Equipment and Infrastructure
• RM - Risk Management
• CM - Change Management
• EE - External Environment
BOX
Check Question 4: Organisational Factors
Does the item describe an aspect of the organisation's culture, systems, processes, or decision-making that existed before the occurrence and which resulted in the contextual conditions or allowed those conditions to continue?
THE SOAM CHART:
The final product of the systemic occurrence analysis process is a summary chart depicting:
• The individual contributing factors - grouped according to the layers of the methodology as Barriers, Human Involvement, Contextual Conditions and Organisational Factors; and
• Horizontal links representing the association between a contributing factor at one level (e.g., a human action), and its antecedent conditions (i.e., the context in which the action took place).
FORMULATING RECOMMENDATIONS:
The formulation of recommendations for corrective action is a critical final element of the occurrence investigation process. In order to be effective, the recommendations should have the following characteristics:
• Be directly and clearly linked to the SOAM analysis;
• Be focussed on findings that are amenable to corrective action;
• Aiming to reduce the likelihood of a re-occurrence of the event, and/or reduce risk.
In formulating recommendations, the SOAM process requires that the following two elements be addressed:
• The deficient Barriers (absent or failed), and
• The Organisational Factors.
Illustrative Example
Aircraft runway collision
The Linate Airport disaster occurred on 8 October 2001 at Linate Airport in Milan, Italy, when Scandinavian Airlines Flight 686, a McDonnell Douglas MD-87 airliner carrying 110 people bound for Copenhagen, Denmark, collided on take-off with a Cessna Citation CJ2 business jet carrying four people bound for Paris, France. All 114 people on both aircraft were killed, as well as four people on the ground. The subsequent investigation determined that the collision was caused by a number of non-functioning and non-conforming safety systems, standards, and procedures at the airport. It remains the deadliest accident in Italian aviation history.
The SOAM Chart of the Milan Linate accident highlights the role played by a number of latent failures in the chain of events that brought to the disaster. For example, in the analysis the boxes highlighted in blue show the path of contextual conditions, organizational factors and other system factors that acted as precursors of the error committed by the flight crew of the Cessna aircraft causing the runway incursion.
Illustrative Example: Collision between Hampoel and Atlantic Mermaid
On 7 June 2001, the Panamanian- registered refrigerated cargo vessel Atlantic Mermaid, collided with the Cypriot-registered general cargo vessel Hampoel, off the Varne in the south-west bound lane of the Dover Strait traffic separation scheme (TSS). An investigation of the accident was conducted by the UK’s Marine Accident Investigation Branch (MAIB).
The SOAM Chart of collision between Hampoel and Atlantic Mermaid highlights the role played by a number of failures in the chain of events that brought to the accident. The SOAM Chart was developed based on the identified root caused and findings obtained from the investigation.