The Swiss cheese model has proven to be one of the dominant safety metaphors of our time. Over the years, multiple barrier based methods have been developed using this metaphor, often with slightly different goals and interpretations of the original Swiss cheese model. However, because most still share enough commonalities, these methods can be combined to create a unified model that combines the benefits of each individual method.
This article will describe the integration between three of these barrier based methods.
The first is the Bowtie method, a barrier based risk assessment model that provides an overview of possible incident scenarios and the barriers that have been put in place to prevent those scenarios from happening.
The second is Tripod Beta, a barrier based incident analysis model that analyses barrier failures down to the organizational factors, and categorizes them using Basic Risk Factors (BRF’s). The third is Tripod Delta, an audit tool that examines BRF’s directly. We’ll combine the overview of the Bowtie with the incident information from Tripod Beta and the audit information from Tripod Delta. This combination will lead to more insight on barrier performance than the individual methods can provide.
This paper also tackles some of the challenges that arise when combining these three methods. In Tripod Beta, we’ll explore simplifying the diagram by discarding the object element. In Tripod Delta, we’ll examine the BRF’s. Because Tripod Delta focuses directly on BRF’s, it’s link to barriers is more implicit. The Bowtie will allow us to explicitly connect the BRF’s to various barriers. We’ll also evaluate and discuss how using the BRF’s like this impacts their value and relevance.
In the early nineties, James Reason developed the Swiss Cheese model. It is a metaphor that made barrier thinking popular (see Figure 1). In the past two decades, barrier thinking has really taken off and has become one of the dominant safety metaphors.
Several barrier based tools and methodologies have been developed by different organizations during this period. Most notably Shell developed Tripod and popularized the Bowtie method as part of their HEMP efforts (Zuijderduijn, 1999). All these efforts have resulted in a collection of tools with a similar background, but different applications.
This paper will look at the possibility of combining three of these tools: Tripod Beta, Tripod Delta and Bowtie. We’ll examine some difficulties, advantages and disadvantages and what the path forward could be. Before doing that, we’ll start with a quick overview of the three methods.
Bowtie is a risk assessment tool that represents risks and barriers in a diagram that is used for communication. It is a causal diagram, which means the diagram models risk scenarios that might happen, and identifies which barriers control that particular scenario. The method takes its name from the shape of the diagram that you create, which looks like a men’s bowtie.
Tripod Delta is a questionnaire tool that measures the Basic Risk Factors (BRF). These are eleven high level organizational factors which indicate the parts of the organization that require attention. It is not a causal method. It just identifies how weak an organization is on these eleven categories.
Tripod Beta is an incident analysis tool. It is a causal diagram that models both the direct accident sequence, the barriers that should have been in place and the reasons for barriers not to work. The underlying causes that make the barrier fail are also categorized using the same eleven BRF’s as Tripod Delta.
2. Bowtie & Tripod
To combine these three methods requires an overview of how they relate to each other. Both Tripod Beta and Tripod Delta can be viewed as data collection methods. They provide us with incident and audit data. Bowtie on the other hand, can be viewed as a framework or structure that models the risks and control measures in an organization without providing empirical data.
Treating the Bowtie as the central model, into which both Tripod Delta and Beta feed data to monitor the structure defined in the Bowtie, will create a combination of these methodologies. The main reason for doing this is to combine different types of information into one overview. This allows us to see new patterns that were not apparent when using these tools in isolation.
But there are several challenges that need to be dealt with first. In general, the challenges stem from structural and philosophical differences in these various methods. For instance, Tripod Beta is much more specific than Bowtie in its description of events, but also structures causal relationships more specifically. Tripod Delta on the other hand, goes to the other extreme and focuses solely on basic risk factors. It does not link to specific risks at all. These differences mean we need to do some mapping to combine these methods. The next sections will explain what needs to happen before Bowtie can use the information from Tripod Beta and Delta.
3. Bowtie & Tripod Beta
The main challenge when combining Bowtie with Tripod Beta, or indeed any risk assessment method with an incident analysis method, is that Bowtie is on a higher level, whereas Tripod Beta is more specific. This is most evident in two areas: language use and structure.
The language used in incident analysis is more specific than in Bowtie, even though they might relate to the same concept. For instance, in Tripod Beta, one might talk about a single smoke detector, whereas in Bowtie, it would be more common to talk about a fire fighting system. This difference in language use is unavoidable, and currently the mapping between them is manual.
On a structural level, Tripod Beta has a more strict treatment of where barriers are placed. For instance, in Bowtie, a barrier can be placed before an event, whereas it takes an effect after the event (and the other way around). This is not allowed in Tripod Beta, which means the placement of barriers can be different when looking at a Bowtie or Tripod diagram on the same subject.
Both language use and placement of barriers cannot be changed. They are inherent to both methods and part of the reason why they work. But even though we can’t change those aspects of the methods, we still want to minimize the mapping difficulty between Tripod Beta and Bowtie. There is one last structural difference that can be made more compatible: the causality model.
Causality between events is modeled differently in Bowtie and Tripod Beta. Bowtie has a simple model where an event can cause the next event. Tripod splits the first event out into an agent (the source of change) and an object (the object being changed), which come together to shape the next event. Looking at both these models for causality, we take the most complex one (Tripod Beta) to analyze when the addition of an object is useful and when it is not.
There are situations when objects can be a useful addition to an incident analysis. First, when there are multiple stories coming together which cannot be correctly displayed in a single causal line. This is also important when investigating multiple storylines. An example could be a fire, where we want to investigate both the source of ignition, and why the fuel was available. This is difficult to do in a single causal line, and will quickly lead to mistakes in the causal model (for instance, saying that the presence of fuel caused the ignition source, which is obviously not the case). Secondly, adding an object can be beneficial to force an analytical way of thinking when we want to make sure we think about both the affecter and the affected.
There are also situations in which objects are not useful and can actually become obstructions. First, when the object does not help us to analyze our incident, but becomes an obligation to adhere to. It can cause confusion if the incident being investigated does not require an object to be understood correctly and can actually lead to non-sense objects being created just to adhere to the rules. Secondly, when the communication of what happened in an incident becomes more complicated than it needs to be to understand it. Complexity should not be added for the sake of complexity, but only in proportion to what is necessary to achieve some desired level of understanding. We can always add more complexity and more detail to any model. What we need to keep in mind is what goal we hope to achieve and what level of complexity is best served to achieve that goal. This is very clearly the case in incident investigation, where there is often a lot of information and complexity. The correct approach would be to investigate an incident thoroughly, and then condense it to its core. Sometimes an object can help us do that, but sometimes it adds unnecessary complexity.
Because of this, we propose to make objects optional. This small change to the Tripod Beta method will reduce the difficulty of mapping onto a Bowtie, and at the same time also creates easier to understand and build Tripod Beta diagrams. If needed, an object can be added, but if it is not necessary, the object can be omitted.
4. Bowtie & Tripod Delta
The challenge with Tripod Delta is to map high-level organizational categories to specific barriers. This section will discuss two issues that will allow us to make the results of Tripod Delta more illustrative by using the Bowtie.
The first discussion focuses on the use of Defenses as a Basic Risk Factor. The definition given in the Tripod user guide (Tripod-Foundation, 2008) is: ‘Failures in the systems, facilities and equipment for control or containment of source of harm or for the mitigation of the consequences of either human or component failures’. This has a lot of similarities to the definition of a normal safety barrier as it is defined by Sklet (2006): ‘Safety barriers are physical and/or non-physical means planned to prevent, control or mitigate undesired events or accidents’. From the similarities between these two definitions, we can conclude that Defenses as a category is mostly concerned with barriers that are used in operations and less with a higher level organizational factor. Bowtie explicitly identifies these barriers, whereas Tripod Delta aggregates them into a single score. Defenses are so closely related to barriers in Bowtie that we can treat Defenses separately from the rest of the Basic Risk Factors. Bowtie provides a framework for the questions, which used to be grouped under Defenses, to be linked directly to individual barriers in the Bowtie. We can go back to the original idea of Defenses, as a separate category from the other ten (see Figure 2 and table 1). This also means that Defenses in Tripod Beta should not be used to categorize underlying causes. They correspond to the barriers in Tripod Beta as well.
Two kinds of basic risk factors
After discussing Defenses, we still need to decide how to map the remaining ten BRF’s to a Bowtie. As stated before, Tripod Delta is much less specific than Bowtie because it measures only organizational categories. We need to make a link between the categories that Tripod Delta measures and the barriers in the Bowtie. This will work for some BRF’s but not all, because they have different abstraction levels, even though they are treated equally. For instance, maintenance can be linked to barriers that involve engineering like a pressure safety valve, but not to procedural barriers like a double check. Incompatible goals on the other hand, can be linked to any and all barriers because its effect is general. It has a possible effect on all barriers, including the pressure safety valve and the double check. This means there are two kinds of BRF’s, the ones that link only to specific kinds of barriers and the ones that link to all barriers.
Table 1 lists a possible distinction between the two types. This distinction is not absolute. It’s just an example of a likely distinction. Which category a BRF falls into will depend on the industry or even the individual Bowtie. For instance, if a highly technical subject is chosen like aeronautics, maintenance might be judged as being a generic BRF, whereas in a hospital it might be a specific BRF.
Once we have determined which BRF’s are specific, we can start to link them to the barriers that they affect. The result will be a Bowtie that can show us which risk scenarios are more likely if we score poorly on a BRF category. The generic BRF’s on the other hand, will make every risk scenario more likely.
Once the challenges with mapping Tripod Beta and Delta onto Bowtie have been dealt with, how can we use it? The barriers that were identified in the bowtie become central to our communication of the risks. For instance, a pressure switch might have failed in 5 different Tripod Beta incidents, with some BRF’s identified as root causes (see the pink boxes in Figure 3). The specific BRF maintenance that has been linked also scores poorly in Tripod Delta audits (see the bar graphs in Figure 3). This gives us a combined view across multiple incidents and audits, to make a more informed decision about where we have a higher risk. Combining these different data sources and mapping them onto a unified barrier model is the goal and will allow us to increase our understanding of risks.
The next step is to work out this concept with practical data, and work out other practical difficulties. Especially mapping the BRF’s to barriers requires more research. Once that is done, there are other data sources that might also be mapped onto the barriers, like maintenance logs, permit to work systems or weather data.
- Jop Groeneweg. Controlling the controllable: preventing business upsets. Global Safety Group, fifth edition, 2002.
- James T. Reason. Managing the risks of organizational accidents. Aldershot: Ashgate, 1997.
- Snorre Sklet. Safety barriers: Definition, classification, and performance. Journal of Loss Prevention in the Process Industries, 19:494-506, 2006.
- Tripod-Foundation. Tripod Beta User Guide. Stichting Tripod Foundation, November 2008.
- Cees Zuijderduijn. Risk management by shell pernis, the netherlands refinery / chemicals. In Proceedings of the Seveso 2000 European Conference, 1999.