Recently I was perusing a relatively unknown corner of ISO 31000 Risk Management —Principles and Guidelines— and long dormant memories flooded back.
The ISO section I was reading, Monitoring and Review (s 5.6), deals with the sorts of metrics that should be monitored to ensure the risk management system’s working. For example, it suggests monitoring indicators of control effectiveness, incidents (near misses), issues, key risk indicators, loss events, and other relevant variables important to the risk management process.
Years ago, I was appointed manager of accounting for what was then a mid-sized oil and gas company with operations in Canada, Russia, and Indonesia. I had a staff of about 200 people and one of my first assignments was to design and implement a completely new financial accounting system.
Eager to begin, I met with the project team and asked them for their plan. I was told that implementation could not begin for several months. The first step in the financial systems project plan was developing a new chart of accounts. And developing the new chart of accounts required a detailed analysis of what the system needed to report for the business to be managed successfully. After all, why develop a new financial accounting system if it didn’t help us manage our business?
It strikes me now that the same principle could be applied to implementing enterprise risk management (ERM). Basically, ERM implementation could start with gleaning the information we want from what ISO calls monitoring and review.
This would involve a process flow that’s nearly the opposite of what risk management practitioners currently follow:
- Step 1: Determine the ERM information that’s the most important to the business managers and external stakeholders. In my example, as an upstream oil and gas company, the critical information was related to finding and developing new oil and gas reserves, and reporting oil and gas production. We needed financial, economic, operating, and engineering data.
- Step 2: Determine what information the managers need to know about these key identifiers. Essential information regarding reserves and production could be categorized as:
- Control failures (not just the accounting kind – think of well blow out preventers that fail)
- Incidents, such as delays in drilling
- Loss events, such as dry wells or spills
- Key risk indicators (KRI), such as trends in finding and development costs, production rates, etc.
- Step 3: Determine the organization and process structure where this information can be found or where it’s created.
- Step 4: Figure out why the control failures, incidents, and losses occur, and/or what risks they cause, and why the KRIs are over the threshold (or why they aren’t). The answers to these questions will provide the list of risks that must be managed.
I’ve just outlined an upside-down risk management process— pretty much the opposite of traditional risk management. Of course it’s a little more complicated than this, but not by much (after all, this is just a blog).
This risk management system implementation uses the same principles as my financial system implementation years ago, which, by the way, was successful, on time, and on budget. It boils down to figuring out what’s important, how to measure it, and how to report on it. The rest pretty much takes care of itself. Conversely, if I’d based my financial system implementation on today’s risk management practices, I would’ve begun instead by guessing what numbers I would have in the accounting records.
What’s the Lesson Here?
One lesson is that risk managers need a laser focus— not on the risks, but on the information that tells them how risk’s managed.
The second lesson is that extraneous information is avoided with this approach. By starting with the essential information needed to drive the business, all the secondary stuff’s avoided.
And the third lesson is to follow the principle of “begin with the end in mind”.
The good news is that never in the history of risk management have better tools been available. We have mobile devices, the cloud, business intelligence, predictive analytics, in-memory processing, web scanning, and more available to build and maintain the dashboards we need to monitor and review risks. These tools should be the backbone of risk management.
Risk managers should use them. The purpose of ERM is not to create pretty heat maps of risks, but to create information about how risks are being managed to drive business performance. We need to start ERM implementations with a dashboard of what information is required to manage the risk.
I’m interested in your experiences. Please share them with me.Comments