A Mining Guest Blog Series by Jim Joy – Part 13: Defining accountabilities and the reporting process

The above illustration suggests three levels of ownership. The example PUE is related to vehicle collisions. Two example critical controls involving specific driving acts and road signage are provided.

Explaining the example

In the example, two verification activities have been identified for critical control 1 (CC1) and three for critical control 2 (CC2). An owner is assigned for each of the verification activities. They are accountable for gathering the verification data with the defined frequency and forwarding that data to the critical control owner. Note that some assembly or interpretation of the data may be required before it is forwarded to the control owner. Acceptable levels of critical control effectiveness should have been defined as part of the performance requirements (see article 10). Formats such as stoplight reports, considering defined performance levels, might be helpful to concisely communicate verification data.

The illustration shows two critical control owners. Note that there may be more critical controls for a single PUE. The critical control owners assemble the data information from the verification activity owners to provide a single indicator of control effectiveness to the PUE owner.

As a result of this process, the PUE owner should get regular reports on the effectiveness of all critical controls related to his/her PUE with low and unacceptable effectiveness results highlighted. Action should be taken to address unacceptable effectiveness as soon as possible, including the decision to stop the activities where the risk exists.

Verification data

Managing the data and generating concise reporting can be a big challenge in this step of CCM. The above illustration shows only a small example segment of the process. If a site has 10 PUEs with 6 critical controls for each, there may be 5 verification activities for each control. That results in 300 sources of data and a team of 370 owners at various levels.  Clearly a ‘hard copy’ paper-based approach to this size will be very punishing for a site or organisation. Data management technology should be considered.

The example verification process outline from article 12 can be used to discuss electronic gathering of data and computer-assisted assembly and analysis.

Verification data report

^{Decision tree, click here for a full version of the image}

In the above example, there are four verification data sources (left boxes) that need to be gathered, assembled and reported to the appropriate owners. Each of the four sources has a different defined frequency for data gathering ranging from continuous to quarterly. Part of reporting system design should include the required reporting frequency. The site or company will decide on whether each of the four data sources is reported to the relevant owner separately or as one report. The latter is recommended.

If one report format is used for communicating verification information from several sources, such as the four areas illustrated above, then the report should be sent to the PUE owner at least weekly with information on the continuous and weekly verification activities. The monthly and quarterly verification data would be updated on the report when data was available. A rough illustration is provided below as an example.

The previously established verification areas and frequencies have been included in a basic stoplight report that critical control owners would create, including their comments on any results including potential recommendations for addressing a yellow or red light. Trigger levels for verification data should be defined to establish green, yellow or red reports. For example, for “Act observations are 90% positive, at 90% or greater the result would be green. Red would be observation results below a figure usually identified in the verification design, for example 75%. Yellow would be an observation data levels between the 75 and 90% level. Other verification questions may require a more subjective guideline.

Computer systems and dashboards for your data

Computer systems offer an opportunity for streamlining input to this and other reports by gathering and aggregating data electronically, rather than using paper-based reports. As mentioned earlier, the data gathering magnitude for a site may be quite large, so it is recommended that electronic data input and analysis be part of the design of the verification and reporting system from initial setup.

Executive committees or company boards may also require summary reports that include critical control status for all priority unwanted events at relevant sites. Of course, a good data management approach should facilitate the provision of effective ‘dashboards’ for the organisation. A basic example is provided below.

The above example suggests that a dashboard that includes all data about priority unwanted events, critical controls, verification activities, ownership and required actions for all sites or locations where the events may occur. Reports generated from this dashboard should be designed by engaging the recipients for input. Executive committees and boards will want CCM summary reports that answer the questions that are important to the organisation. If the data is well managed and analyzable as the above example suggests, this dashboard can be used to provide a report or answer any questions from the executive committee or board.

To conclude

Clearly verification and reporting are major components of an effective CCM initiative. The time and establishment costs should be considered in the design of the CCM initiative. The next article will address the learning opportunities from CCM that can not only improve the process but also optimise critical controls. Huge opportunities exist in sharing critical control learnings between sites and companies that offer more rapid and more effective improvements for major mining risks.

Other blog posts from this series

1. Welcome & Introduction
2. A short history of Australian mining ORM – one perspective
3. Key words and concepts in ORM – getting the conversations and thinking consistent
4. Making the argument – risk is all about controls and their Effectiveness
5. Good practice Operational Risk Management
6. It’s a Journey – using journey models to analyse and plan ORM improvements
7. Overview of critical control management and a few of its challenges
8. Identifying critical controls
9. Considering ‘acts’ as critical controls and the challenge of their measurability
10. Challenging critical performance requirements
11. Evolving operational risk management in the mining industry
12. Linking the Critical Control performance requirements to the design of the verification process
13. Defining accountabilities and the reporting process
14. Continuous improvement and learning opportunities with Critical Control Management

© Jim Joy. 2020 – The copyright of the content of this guest blog belongs to Jim Joy who has authorized CGE Risk Management Solutions B.V. to provide this content on its website.