One of our academic colleagues once described ERM as nothing but a bunch of “blah, blah, blah.” Apparently, they were not so impressed with the academic merits of ERM, despite ERM being one of the more popular courses for students in our executive programs and even though an increasing number of students are choosing it as a profession. The issue we believe that our academic colleague was referring to was that on the surface the entire field seems to be so much common sense. We have some respect for this view, but as we all know, common sense is not at all that common. When it comes to ERM implementation, it takes more than “blah, blah, blah,” and more than just common sense. It takes attention to some details, and in some cases a bit of luck doesn’t hurt. Conceptually, implementing ERM should be relatively straightforward. The reality is that implementing ERM is practically quite difficult and the low success rate of companies that have attempted an ERM implementation is testament to this.
There are many practical hurdles to successful ERM implementation. In an insightful review article, Fraser and Simkins outline what they believe are eight key internal challenges of ERM implementation:1
(1) corporate culture, (2) board of director’s knowledge, (3) not applying a keep it simple silly (KISS) mindset, (4) training without having risk workshops, (5) identifying too many risks, (6) no timeframes, (7) not making ERM enjoyable or meaningful, and (8) not recognizing ERM as change management.
In addition to these challenges, we view ERM implementation as a systems problem. Part of ERM implementation is composed of simple processes. Another part of ERM implementation is composed of complicated processes. Finally, a major part, and the most difficult part of ERM implementation, are the parts that are complex. As ERM implementation involves three different types of systems, it should also involve three different types or styles of implementation. The first task of ERM implementation is thus to consider which tasks are simple, which are complicated, and which are complex.
Components of ERM that are simple can be handled using simple processes. For instance, many simple processes can be automated, or handled through checklists.2 Likewise, most complicated issues can be automated, and we would argue that as many of the complicated tasks should be automated as it is reasonable to do so. It may sound crass, but for the complicated tasks of ERM, the less that humans have to deal with, the better. Those issues that cannot be easily automated, or for which the costs of doing so would be prohibitive should be dealt with through appropriate training and processes developed to make the management of them as unambiguous and as straightforward as possible. Examples of such simple and complicated tasks are: in-flight safety announcements which many airlines now have as a recorded message; checking the fluid levels in your car, which are now checked by computer monitors; collecting sales data, which is now done by point of sale systems; individual credit checks which are now down by credit agencies which use big data techniques; manually operated firm alarms which are done by smoke and fire detectors and managed by automatic sprinkler systems, and so on, as the list is endless.
While automation sounds good in practice, the reality is that few important parts of ERM involve simple or complicated processes. Thus, we view ERM implementation as mostly a complex process. ERM involves getting a variety of agents (employees of all levels, various stakeholders, suppliers, and perhaps even customers) to interact, to communicate, to develop new systems, to prioritize risks, to agree on definitions of risk and risk management, and to buy into a common approach that involves developing an enterprise wide congruence on dynamically managing risk. As a complex system, the implementation will involve emergence of ideas, levels of acceptance (and rebellion), amount of congruence (and disorganization with what occasionally appears to be chaos) and evolution of the path(s) going forward. As with most emergence, we do not see the complexity as necessarily a bad thing, but instead as a feature that can be levered as long as it is accepted and recognized for what it is.
As with managing any complex system, the first principle is to accept and recognize that the task is indeed complex. This involves discarding the tactics of implementing and managing complicated systems which is a top down command and control driven approach. The second principle is to think in terms of “manage, not solve” the ERM implementation problem. ERM, as a complex management strategy, to solve the complex task of risk management, should as much as possible be allowed to grow organically. This is a large part of the reason why, as discussed in Chapter 3, that we are not fans of rigid ERM frameworks. Like a good pair of leather loafers, the ERM system should be something that over time flexes to conform to one’s foot, rather than having the foot conform to the shoe, or worse having continuous chafing that evolves into a painful blister.
It can be argued that ERM implementation is difficult because of a wide variety of complicated factors, (such as outlined by Fraser and Simkins), as well as the complexity of the task. To this end we suggest a set of five principles for implementation: (1) ERM as a process that has as its aim progress, not completion, (2) congruence of the strategic objective of the firm and the strategic objective for having ERM, (3) ERM as an adaptive evolution based on communication amongst stakeholders, (4) ERM is a learning system; learning both for ERM itself, and for the organization as a whole, and (5) ERM as a system based on resilience.
In the sections that follow, we will refer back to these five principles for implementation. Although there are undoubtedly other principles and processes, we believe adherence to these five principles will greatly enhance probability of ERM implementation success.
Setting the ERM Objectives
The first step for embarking on an ERM implementation is to properly set the ERM objectives. Very simply, “why is the organization choosing to implement ERM?” Chapter 4 discussed the steps of setting the objectives, and we reiterate the point here of how important having a clear set of objectives for ERM is. The entire ERM implementation flows from the answer to this single question. Although there are a wide variety of legitimate answers, ultimately the reason must be that ERM adds value to the organization in some way, shape or form.
The objectives for ERM set the basis for how the organization’s ERM will function both internally as well as externally. With the objective(s) set, they must be communicated to the range of the affected stakeholders. If nothing else, ERM is an exercise in effective communication. The communication begins with the implementation.
Upfront communication of the ERM objectives helps to generate both buy-in to the concept, as well as ideas for implementation. It also starts the process and should get everyone thinking in the same direction.
It is important that the objectives of the ERM program be communicated to all the relevant stakeholders; both internal as well as external. In fact the stakeholders should have been involved from the very beginning in terms of setting up and clarifying the objectives. Once everyone is on board with the objectives, it is time to begin the actual design and implementation of the specific processes.
Designing Processes
As previously stated, there are key elements to every successful ERM implementation. One of the first elements is to choose a framework for ERM. The elements of a desirable ERM framework were discussed in Chapter 3. We will simply reiterate here that a good ERM framework will be flexible yet robust, adaptable, and most of all resilient. A too rigid framework will be difficult to implement, costly to maintain, and worst of all, likely to be ineffective in making ERM a value-added activity.3
In Chapter 3, it was suggested to finish the sentence, “ERM is successful in our organization because … .” In setting up the process for ERM it is again useful to consider the response to this question and to begin by thinking of what metrics will be needed to definitively respond to the query of whether ERM is being effective. These metrics will likely form the basis of the ERM risk dashboard. The risk dashboard in turn will likely be one of the key outcomes from the ERM process and thus it is useful to begin with one of the end outputs in mind from the beginning.
Designing models for what the firm’s ERM dashboard will look like helps to guide the ERM implementation process. The dashboard helps to keep a central focus on the key elements and to avoid the temptation to include an exhaustive list of risks in the ERM process. Remember that simplicity is one of the key elements of a successful ERM launch, while trying to do too much generally leads to failure. The risk dashboard is the simplest distillation of the key ERM metrics and thus appropriate for keeping the ERM implementation simple as well.
Case Study: SCOR(Risk Dashboard)
Founded in 1970, SCOR, whose headquarters are in Paris France, has established itself in Life and Health Insurance and Property and Casualty market as a Tier 1 Insurance reinsurer around the globe. Reinsurers are in the business of sharing or diversifying insurance risk with insurance carriers. So, their business is inherently risk management. However, they have a responsibility to be solvent and be able to pay their portion of all future claims. For this reason they are very sensitive to both external and internal risks. One of the key pillars of success for SCOR is their ERM system.4 SCOR’s approach is somewhat unique in that they clearly define that their risk management is based around the alignment of their risk appetite framework and their ERM framework. Furthermore they have built their risk appetite into their decision making process and their corporate strategy.
Over the years SCOR has continually developed and worked on their ERM. In 2009, Standard & Poor’s upgraded SCOR’s ERM to “strong” as a reflection of the solid risk management culture along with the strategic risk management.5 One of the key tools that have helped them manage their risks is their risk dashboard. While setting up an ERM framework can be a daunting task for many large frameworks, SCOR has done an incredible job with their risk dashboard tool. It is simple, it provides the measure and it provides trending which assists organizations in seeing the growth of risks to enable them the opportunity to strategically avert or capitalize on situations as they see fit.
The design of the dashboard is often left to the final stages of implementing ERM. By putting the dashboard design upfront, there will be a greater focus on the key elements and ERM implementation will likely be much more efficient. Note however that as the ERM implementation proceeds, it is likely, and it is to be expected that the dashboard design and the dashboard elements will be tweaked. After all, one of the principles for successful ERM implementation is that it is a learning process as well as an evolutionary process.
After the objective and at least the shell of a risk framework has been chosen, the next steps are to develop strategies, tools and information systems necessary for identifying, measuring, and prioritizing the risks. These tools and measures are the subject of the following two chapters. The tasks of identifying, measuring, and prioritizing risks are what many consider to be the guts of any ERM system. Indeed, these components are like the engine of your automobile. However, just like the engine of your automobile, they are generally hidden from view and it is the visual components of both your automobile as well as the ERM system that most people interact with. The process of gathering and analyzing many, but not all, of the risk metrics is either a simple or complicated process, and as such, should be automated as much as possible.
This brings us to the reporting and communication component of ERM. ERM is about action and making decisions. To make effective decisions, the appropriate data and information must get to the appropriate decision makers in a timely and user-friendly manner. Too often there is a disconnect between the brilliant work that has gone into developing the risk measuring and prioritization and the ultimate information that gets to the decision makers.
The communication design is a bit of a Goldilocks problem. Too little information and the decision makers may be missing key points that would significantly alter their decision making. However too much information and the decision making are also likely to suffer as decision makers will be “drowning in data.” We have seen some ERM systems that provide decision makers with over 2,000 pages of information on a quarterly basis. It is simply not humanly possible to process that much data in a timely manner. Perhaps with the development of artificial intelligence the data will become useful, and indeed big data techniques are being developed for just such a use, but in terms of human decision makers such a volume of data is very sub-optimal.
It is tough to decide upon the data to collect and report, as well as how to best report it. It is an exercise in design and an exercise in prioritization. Experience shows that there tends to be an inverse correlation between the amount of data being reported and the amount of serious thinking that went into the ERM implementation design. It is tempting to believe that more data is better, but that is also lazy thinking. There also appears to be a direct correlation between the amount of data collected and an unwillingness to accept responsibility for risks. If every piece of data is reported, then it is easy to claim that someone should have spotted the risk as all of the data was readily available. Again, this is lazy thinking, combined with a lack of accountability and responsibility.
A separate issue is the risk reporting that needs to be done for legal and regulatory purposes, and the risk reporting that needs to be done for effectively managing the organization. It is tempting to try to get efficiencies by combining the two tasks. While tempting, it is very difficult to effectively do. The data needs for legal and regulatory purposes is generally quite different, and needs to be analyzed quite differently, than the data needed for managing. There is a parallel analogy with financial reporting. All companies of a certain size and complexity will keep separate financial and accounting statements for tax calculation purposes and for their public reporting. They will then have a separate set of accounting and financial reports for their internal managerial reporting that is actually used to run and manage the organization. To carry this analogy over to risk reporting, it is generally best if the firm develops two risk reports; one for the regulators, and one for managing the risks of the organization. This may seem like a duplication of tasks, but unless the regulators have the same objectives as the corporation, (which they almost never do in terms of risk), then two sets of risk reports will be necessary.
There generally needs to be an experimentation phase in which the proper amount of data, as well as the proper presentation of the data is made. It is a very important step and one that should not be overlooked or skimped on. The desired data should be an ongoing discussion between the risk management team and the various stakeholders and users of the risk data. In large part this is a training and communication issue. The risk data experts need to be educated to understand the needs and wants of the stakeholders, and the stakeholders need to be educated to understand what is possible in terms of data collection and analysis.
This brings us back to risk dashboards. Risk dashboards should be as simple as possible without being so simple as to lose their effectiveness. Characteristics of good risk dashboards include; quality and accuracy of data, timeliness, usefulness for stakeholders and decision makers, and user-friendly.
As we have frequently emphasized, risk management is as much of an art as it is a science. For this reason we recommend that risk dashboards focus more on how the risks are changing, rather than on the absolute metrics. For instance, are the risks moving on the proper direction? Are the good risks increasing in probability and magnitude, and are the bad risks decreasing in probability and severity? Risk dashboards that illustrate the relative change of the relevant risks through time are a more effective storyboard than actual measure. Also, there should be trigger signals on the risk dashboards that show when something is not normal—just like the check-engine light on your car.
One feature that is generally part of a firm’s risk dashboard is a risk map, which maps the various risks on a two-dimensional grid showing their probability and impact. Most traditional risk maps focus on risk as a negative, and thus plot the negative impact of the risk, and the probability of each of the negative risks. Risk maps are covered in Chapter 6, and there a new style of risk map that plots both good risk as well as the more traditional bad risk is presented.
Having a risk map that tracks the progress of risks through time in terms of their probability and impact gives a clear and easy to understand picture of how risk management is evolving in the firm. It is just one of many methods that can be used to effectively convey the evolving set of risks to decision makers.
Another key component of ERM implementation is training. Training is necessary for a wide variety of reasons; actually getting the work done, developing consistency in risk management throughout the organization, ensuring proper responses, achieving buy-in, giving stakeholders the knowledge and tools they need to accept responsibility and be accountable for the appropriate risks, and developing a healthy and helpful risk culture.
Training also needs to be more than a regurgitation of organizational risk policy and procedures. The training should also focus on developing an understanding of risk and how everyone plays a role in risk management. The training should encourage people to think about risk, rather than just know about risk. In part this comes back to the complexity of risk. The complicated parts—that is the “knowing” parts of risk management—should be automated as much as possible. While it is important that employees are knowledgeable on the complicated processes and procedures, there is minimal high-value risk thinking that comes out of this. Conversely, if employees are trained to think about risk, then high value can be obtained by appropriately responding to complex risk situations where complicated responses are ineffective or counterproductive. Additionally, if the training focuses on thinking, rather than just knowing risk, then the organizational staff will be attuned to look for risk situations and thus the organization has created a high-value-added risk monitoring system, namely its employees.
A related to training component of ERM implementation that is generally not thought about is the development of mechanisms for organizational risk learning. This is not learning as in the training component, but learning from the successes, and the mistakes of risk management. It is designing and embedding a component into the ERM process for developing and building the institutional knowledge about best risk practices. Organizational learning is increasingly being seen as a tool for competitive advantage. We believe that mechanisms for formalized institutional risk learning is a potential killer app for making an organization stand out in terms of its risk management capabilities. There are a variety of techniques for organizational learning, from developing risk mentorships, through to skunk works type initiatives on risk management.
The final component, (ignoring for a moment that the ERM system should always be evolving), is ensuring that the risk culture and the ERM system are in alignment. The best ERM system in the world will not work with an unhealthy risk culture. We have tried to empathize risk culture at various points, and we will reemphasize it here. To the extent possible, the development of a healthy risk culture should be part of the design of the ERM process.
ERM, just like the strategy of the company should be constantly evolving. This does not imply that the organization is constantly overhauling ERM, but it does imply that tweaks are ongoing. To reiterate, ERM is not a passive process. Organizations evolve, and ERM needs to evolve as well. For this reason it is ok to not have everything perfect in the design of ERM before the process is begun. Even if somehow an organization came up with a perfect ERM design, it is likely that by the time it was implemented that the definition of a perfect ERM systems for that organization would have changed.
We like the “Starting Lean” model that is used by entrepreneurs for ERM implementation.6 The point of the starting lean model is to build a minimally viable product, go out and test market it, learn, adapt, revise the minimally viable product and continually repeat the process. Such a process works well for the complex task of starting a new company, and it can work equally well for the complex task of implementing ERM.
Concluding Thoughts
Conceptually ERM implementation should be an easy, straightforward, common sense process. The reality is that ERM implementation, just like risk itself, has components that are simple, complicated, and complex. This implies that ERM implementation itself is a process that itself is composed of simple, complicated, and complex components.
ERM implementation should be viewed not as a task, nor as a project, but instead as a process. It is a process that will evolve and develop through time. Thus, it is not necessary for it to spring forward from an all-encompassing design from the very beginning. Starting small, and letting the process grow organically is often the best and most efficient way to implement. The key point is to keep the focus on the objective of why the company is implementing ERM and the benefits it hopes to achieve from ERM.
1Fraser, J.R.S., and B.J. Simkins. 2016. “The Challenges of and Solutions for Implementing Enterprise Risk Management.” Business Horizons 59, no. 6, pp. 689–98.
2For an excellent reference on using checklists for managing simple systems risk see Gawande, A. 2011. The Checklist Manifesto: How to Get Things Right. Picador Reprint Edition.
3For more on the downfalls of a too rigid ERM framework. See Chapter 5 “Are frameworks evil?” In Nason, R., ed. 2017. Rethinking Risk Management: Critically Examining Old Ideas and New Concepts. Business Experts Press.
4https://scor.com/en/risk-management
5https://scor.com/en/media/news-press-releases/standard-poors-upgrades-scors-enterprise-risk-management-erm-strong
6Ries, E. 2011. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Currency/Random House.