How to configure and customise critical risk software to suit your risk approach
When it comes to mining critical risks, the terminology may change, but the core concepts remain strong. Getting your critical risk software to accommodate your risk approach need not be an arduous task (especially when you work with software which is configurable and customisable by the user).
The core of an effective safety management system continues to be the focus on the highest priority hazards and most important controls. It is essential to make sure that your system is configured and customised to use the terminology and methods that are part of your daily business.
In this post, we’ll be looking at some of the ways that RiskView can be customised to accomplish this.
Configuration vs customisation in critical risk software
Good critical risk software should allow you to change a range of different settings to suit your business. This can include things like terminology (labels, names), risk matrix, cause likelihood picklists, and so on.
Configuration is about selecting the particular combination of settings that are needed to make the system work. When you configure the settings and make changes to suit your business, you’re customising your instance of the software. Customisation could also include getting the vendor to modify your instance of the software with different features that your business needs.
Having a configurable critical risk software package makes sense. It improves the accessibility of the system to workers, and increases the likelihood of worker engagement with the system. The more familiar and useable the software is, the more workers use it, and the more benefit the organisation gains from it.
To take a simplistic example, we might be looking at configuring the critical risk software package as part of the implementation project for a mining business. We might need to:
– Set up the organisation’s risk matrix inside the software, and configure the likelihood values, consequence values, and risk ratings accordingly.
– Change some of the default terminology in the software to suit the wording that workers are used to.
– Enable features that the business intends to use (such as major accident events), and switching off features that are not required (such as risk domain).
The list of required configuration items will vary for each business. Here, we’re going to focus on how different parts of RiskView can be configured to suit a mining business.
Configuring hazards and risk scenarios
One of the main building blocks in a mine safety management system is hazards: also known sometimes as risks, and closely linked to material unwanted events and principal hazards.
The Work Health and Safety Act 2011 (based on the model WHS Act) differentiates hazards from risks. Taking the common approach in industry, a hazard is a potential source of risk to health and safety. A hazard is an integral part of a risk or a risk scenario.
RiskView already recognises this distinction. In a risk assessment, we are prompted to identify the hazard, and then identify the risk scenario and top event that follows on from it.
RiskView uses the generic term top event to describe the loss-of-control scenario that is associated with a particular risk scenario. The top event initiates potentially harmful consequences. In a mine safety management system, we might be more familiar with the term material unwanted event. We might choose to change the terminology in our critical risk software to suit this: we can open the configuration editor and navigate to the terminology section.
Any changes we make here will be applied to our instance of RiskView. If we apply the change, we’ll always see “material unwanted event” instead of “top event”.
In safety risk management, our risks are also linked to meta-level risks which need to be defined and managed. In process safety and oil and gas, we would commonly refer to these as major accidents or major incidents. RiskView uses the generic term major accident event. Here we’re talking about potential multiple-fatality scenarios which can result from a range of different risks. In mining, the terminology we’re seeing more commonly is principal hazards or principal mining hazards. We can easily change the terminology in RiskView to suit this.
The naming configuration in RiskView is called Terminology. Changing the terminology we use in RiskView will not change how these items behave in the system: but they are already set up to provide the level of visibility we need. Let’s take the example of a mine site where all the principal mining hazards are already defined by the Regulator. We can build these into RiskView, and map every risk in the system to the appropriate principal mining hazard.
This then gives us the ability to review the aggregated risk of each principal mining hazard. We can rank our principal mining hazards to get a sense of which hazards actually present the greatest risk to us. We can also filter our reporting according to principal hazards to review our risk register from different angles. This is the power of good critical risk software.
Managing critical controls
The next essential element of a mine safety management system is controls: particularly our critical controls. The term “critical controls” is fairly universal, and is unlikely to need configuration. We do have the option of changing that label if we choose, and we can add a third level if we want (non-critical, critical and important controls). RiskView offers a few different ways to identify which controls are critical (see our full article here).
One of the clever ones is using the advanced analysis panel to review all our risk controls together. This allows us to identify duplicated controls across multiple bowties, which makes the control a good candidate for selection as a critical control.
RiskView provides a functionality for base controls, which are standardised controls that apply across multiple instances within the risk register. In the mining sector, there is synergy between base controls and principal hazard controls. In lay terms, a principal hazard control makes a significant difference to reducing the risk associated with a principal mining hazard, and is used again and again where the principal hazard presents itself.
Take the example of a fall arrest or fall restraint system: it is almost certainly a critical control, because it has a particularly strong risk reduction effect. We might use it for working on scaffolding at height, while working in an EWP, or while working at the edge of a deep excavation. It makes sense to identify it as a principal hazard control, with a standardised set of characteristics.
RiskView provides a few different selection options for risk controls that we can customise. Control adequacy describes the effectiveness of the control: meaning the risk reduction effect that it has. The pick-list options and their scoring can be customised. The default selections look like this:
These scoring options will affect how RiskView calculates risk reduction during the risk assessment process. For this reason, it is important to plan out how we want our control effectiveness ratings to work. The scoring makes a much bigger difference than the labels.
We also have the ability to select the control strategy used for each control. This can be useful if we want our risk assessment teams to carefully consider what types of controls they are using to reduce risk. The default strategies are from the hierarchy of risk controls.
We can change the risk strategy names if necessary to suit the organisation. One important additional thing we can configure is whether the risk strategy has a scaling effect on the control. For example, the hierarchy of risk controls suggests that personal protective equipment (PPE) is a last line of defence. PPE is generally regarded as a poorer risk control than one that re-designs a task to eliminate, substitute or isolate the risk. We can configure RiskView to apply a scaling factor to each control based on what strategy it uses.
For instance, we could reduce the score next to PPE in the pick-list configuration from 1 to 0.3. RiskView will then multiply the score from the strategy to the score from the control adequacy: meaning that a PPE with “adequate” effectiveness might be scaled down to an overall effectiveness of “weak”, because the control relies on PPE.
The control option configuration (and also the configuration of other items such as control improvement or audit criteria) is called Lookups. Changing the label name will have no practical impact on the risk assessment calculations in RiskView. Changing the score values will affect the risk assessment calculations, and should be done with care.
Making things simpler or more complex
Sometimes, a mining business will want to take the default functionality of its critical risk software and remove unnecessary complexity. This can help to make the software easier to use for users at lower skill levels. At other times, the risk team might want to see more detail or have more features available to analyse risk in depth.
The Register Policies tab in the RiskView configuration editor allows us to moderate the level of functionality we want to see. RiskView offers a range of different features: a big part of the implementation project plan will be to determine which features should be enabled and configured, and which are not required.
To change what features and connections are available, we can configure the Register Policies. For example, the business may determine that control strategies are not required for their risk assessments. We can navigate to the Controls section and switch off control strategies. We then won’t see the control strategy as a selectable option in RiskView.
We can also use this area to switch on the scaling factor associated with risk strategies. If we want the strategy to scale effectiveness up or down, we can switch on the effectiveness scaling option.
RiskView is a versatile critical risk software solution which has a lot of room for customisation. There are many options available for detailed analysis of risk, which allows you to learn more about your risk during the risk assessment process.
It is crucial to have a clear sense of what the business needs to get from the software, and how much information it can maintain and digest. The good news here is that we can start out with a very simple setup (with most optional features switched off), and later add in more detail as we mature and get more sophisticated about our risk approach. The software scales as the business grows in size and maturity.
This post has focused on just a few of the important configuration options that RiskView offers. The next time you review your risk profile, consider how some of these options might help to reduce the effort and improve the quality of your risk work.