Accountability on Resilience Engineering

Accountability on Resilience Engineering

Resilience Engineering defines safety as the capability to be successful under varying conditions. That is not possible only by studying things that go right as things that go wrong. It is to understand the normal functioning of a technical system for knowing how it fails and how it succeeds. It is easier and effective to increase safety enhancement of the number of things that go right, than by reducing the number of things that go wrong.

Resilience has more concern on 4 ability elements:

1- Responding: Ability to address the Actual and knowing what to do, that is, how to respond to regular and irregular disruptions and disturbances either by setting up a proper set of responses or by adjusting normal functioning.

2- Monitoring: Ability to address the Critical and knowing what to look for, that is, how to effectively monitor each corner and what is or can become a threat in the near term? The monitoring capability must show both that which happens in the environment and that which happens in the system itself, that is, its own performance.

3- Anticipating: Ability to address the Potential and knowing what to expect, that is, how to anticipate developments, threats, and opportunities further into the future. This has a main focus on potential changes, disruptions, pressures, and their consequences.

4- Learning: Ability to address the Factual and knowing what has happened, that is, how to learn from experience, in particular how to learn the right lessons from the right experience either successes or failures.

Traditionally, the main focus was on which has gone wrong or could go wrong.

This sentence comes from the main definition of safety as “freedom from unacceptable risk” and the risk matrix only looks at things that can go wrong. However, it is clear that things can go right as well as wrong. Obviously things go right when they have planned or intended and that is unusual for the thing to go wrong. Therefore, safety efforts traditionally focused on unwanted or negative outcomes, and have relatively have been limited to low probability outcomes, such as accidents or incidents.

Normally, unwanted negative outcomes with high probability have been eliminated, otherwise the system would not be able to maintain its main functioning. If we assume that there is a simple relation between events and outcomes, characterizing several subsets of outcomes should be a must:

Therefore, Resilience Engineering sees the “outcomes that go wrong” as the flip side of the “outcomes that go right” and assumes that they are a result of the same underlying processes. In consequence of that, “outcomes that go right” and “outcomes that go wrong” should be explained in basically the same way.

However, it makes sense to understand why things go right as to understand why they go wrong, because there are many more things that go right than things that go wrong. If for instance, the probability of failure is 1/10,000, then humans are usually blamed for 80-90 percent of the one case out of 10,000 when things go wrong. In the same way, humans should be praised for a similar 80-90 percent of 9.999 cases where nothing goes wrong. In both cases humans should actually be seen as accountable for the full 100 percent.

In conclusion, Resilience Engineering proposes that we should try to understand a general view of a system’s performance, rather than limit ourselves to the things that go wrong, that is, try to understand all the outcomes rather than only the negative ones with the possible exception of “good luck”. In one word Resilience Engineering recognises this paradox and argues that safety should deal with safe performance as well as unsafe performance with things that go right as well as things that go wrong.