Enterprise Risk Management (ERM) Software, unfortunately, is a poorly defined (and often poorly executed) concept, but by structuring your vendor selection around the core concepts of Enterprise Risk Management, Risk Managers can mitigate the inherent risks that accompany a software implementation.
Common Pitfalls of ERM Programs
The common maturity process of an ERM programs looks something like this: define our purpose with an ERM charter, define our process, and then seek automation to support the process.
The reasoning behind that sequence of events is sound. Organizations have been hurt before by software that locks them into a way of operating, and how can an organization correctly identify the best risk management software vendor if they haven't learned from their current process.
The challenge behind that sequence is that Enterprise Risk Management doesn't provide value through steps one and two. As we've covered previously, creating ERM charters, policies and procedures is often the misguided focus of risk managers. The value risk managers can provide is in the standardization of risk assessments, prioritization of mitigation plans, and continuous monitoring of risk. The slower a risk manager is in getting to that point, the more likely their program will find themselves stuck in a cycle of defining their purpose and developing their process without ever adding value to the organization.
Key Questions to Ask an ERM Software Vendor
To reconcile the challenges ERM programs face in immediately providing value to their organizations while not getting stuck with a vendor who locks your program into one way of operating, ask yourself these questions when considering any ERM Software.
Question 1: How does the ERM software support your ability to aggregate information to any cross functional topic across silos?
All Risk Manager know it's important to aggregate across silos, but what does that actually mean, and what does it look like?
As you collect risk, control, and monitoring data from across the business, that information requires context for when you meet with senior leadership. The real job of your program is supporting their goals, no matter how often they change or what they encompass.
An ERM software must have the ability to define and redefine the cross functional topics that make up the goals of your program, and it should have a way of aggregating any of the data you collect in the context of those goals.
Question 2: How does the ERM software integrate with various risk management functions, such as Vendor Management, IT Governance, or Business Continuity?
Vendor Management, IT Governance, and Business Continuity are examples of risk management silos. An Enterprise Risk Management Software that doesn't support these functions and their more unique needs is actually failing to apply to the entire enterprise.
If the goal of ERM is to standardize how risk management is done across the company, then the software you select must have the methodology necessary to apply that standardization to all governance functions.
Question 3: How does the Vendor structure its commitments to Customers?
If Questions 1 and 2 help organizations define the depth and scope a Risk Manager will require of their ERM solution, Question 3 is designed to focus on how quickly the vendor can deliver. How much does the provider expect to charge for professional services? What reporting is included or not included in the pricing? What kind of commitment does the vendor require for the initial contract term?
These questions should raise red flags about whether the vendor is as flexible as they've suggested over the course of your evaluation.
Interested in seeing how this approach differs from traditional governance? Watch our short video on Strategic Risk Management.