Verification activities validate that we are doing what we say we are doing.
For example, verifications can be used to verify that:
- a Critical Control in a Bowtie is being inspected, tested and maintained such that it is delivering the risk reduction claimed;
- a Bowtie is being reviewed as often as the company policy dictates; or
- a Performance Standard which is used to verify a Critical Control is being regularly reviewed to ensure it contains best practice and includes the latest incident experience.
Because there are so many things which can be verified, RiskView provides a lot of options in configuring the verification process.
This article describes how the verification process works and how you might use it to drive verifications in your business.
This journey begins at the bowtie. For it is on the bowtie that the Critical Controls, which are the backbone of our any verification process, are first defined as Controls.
Flicking the Classification switch on a Control from “Non-Critical” to “Critical” means that this control can participate in the verification process. If a control is Non-Critical, it is essentially a bowtie flower.
Risk Controls & Base Controls
Many people confuse Risk Controls, Base Controls and Critical Controls.
A Risk Control is one control box on one bowtie in a register. It can be marked as critical, but to get it to participate in a verification is very difficult, because the only links to it are via the bowtie in which it occurs, and it could be one of hundreds, so the those links are not especially targeted.
A Base Control is a global control definition that simply by being linked to one risk control, links to any number of bowties in any number of registers. With Base Controls we get a lot of leverage.
So, while both Risk Controls and Base Controls can be Critical Controls, if we want time-saving leverage, it’s best to set criticality at the Base Control and drive verifications from there.
Critical Controls are controls whose function has been assessed as critical to the reliability and safety of the operation. In other words, they are controls we can’t do without, and because of that, we verify them to make sure that when we need them to function, they will.
Of course, that verification overhead comes at a cost, so calling a control on a bowtie “critical” when it isn’t is a two edged sword:
- it takes focus off the other controls, or lack of controls on a particular causal or consequential pathway; and/or
- it diverts resources from where they might be better spent.
For some clients, Critical Controls make up less than 30% of all bowtie controls, so coming up with a consistent set of rules to categorise which controls are “critical” is, well, critical. Here is one method by which the criticality of a control can be determined:
Material Accident Event
Another key link in the verification process is the MAE. Just as the Base Control uniformly categorises Risk Controls, the MAE globally links Bowties.
More to come.
The diagram below describes the overall Verification process in RiskView.
The overall process divides into 3 main roles:
Admin users are responsible for ensuring that the system is well configured prior to setting up a Verification Template.
Some of the essential components for Verification are:
- Performance Standard with valid Performance Criteria
- Critical Base Controls connected to Bowties
- Major Accident Events linked to Bowties
- Correct Permissions for Users who will be completing Verifications
- For the Action section in Verification Wizard (may vary depending on the system configuration):
Once the core elements are present and configured properly, admin users can then create the Verification Template. You can find out more about the Verification Template here.
Admin users can also monitor the progress anytime via the Verification Activity Timeline Dashlet.
When the users completed the Verifications, admin users can review the results from the available reports.
In the Verification process, RiskView will gather relevant information defined in the Verification Template and generate the Verification Wizards. You can read more about how the contents are generated here.
RiskView will also generate and send email notifications to relevant users when Verification Wizards are generated.
End users are responsible for completing the Verifications by filling out the Verification Wizards with relevant information.
Once the user receives an email notification from RiskView, he/she can click on the link from the email to access the Verification Wizard (read more about it here).
Fill out the required fields with relevant information to progress through the Verification and submit once everything is completed (read more about it here).
The RiskView Mobile application allows users to perform in a mobile context on a smartphone or tablet device. RiskView Mobile is able to function offline and is ideal for performing verifications on remote sites without connectivity; verification changes are queued on the device and synchronised when connectivity is regained. RiskView Mobile is intended to replace the original web based offline functionality which is in the process of being phased out.
RiskView Mobile is available on Apple App Store and on Google Play. Access to RiskView Mobile requires an elevated subscription package from the standard.
For more on RiskView Mobile and the mobile verification process see the following knowledge base links: