- Corporate Security
- Governance, Risk & Compliance
- Information Security
A 2018 ERM Benchmarking Survey revealed that despite the wealth of tools promising efficient risk management, 63% of organizations continue to rely on basic office tools like MS Excel and PowerPoint for their Enterprise Risk Management program.
Technology can facilitate greater integration of risk management. Yet, few organizations have embraced the power of enterprise wide technology for ERM. In this webinar, providers and users of risk management software will discuss the benefits of using ERM technology, solutions on the market, best practices when evaluating a software vendor, determining if you’re ready for software and barriers to implementation.
In partnership with The Risk Management Society, Resolver hosted a webinar to answer a question many risk managers struggle with: “How will ERM software help me, and are we ready for it?”
We have also provided a full transcript of the webinar at the bottom of this resource.
Megan: Hello and welcome to today’s RMS webinar titled, “Stranded in Excel: Moving Beyond Basic Technology for ERM.” I’m Megan, and I’ll be the operator for the presentation today. A few notes before we begin. If you have a question for the presenter during today’s session, please submit them by writing in the question box. You can submit them at any time, but we will reserve time at the end of the presentation for Q&A.
Megan: If we do not have enough time to answer all your questions, we will answer them by email after the live session. A copy of the PowerPoint presentation is available under the handout tab. Now, I’d like to turn today’s presentation over to our speakers, Ollie de Boer, technology lead Satarla, Jamie Gahunia, strategic product manager, ERM resolver, and Brian Link, managing director, Mobius One.
Jamie Gahunia: Hi everyone and thank you for joining Resolvers webinar. Celeste Duke is actually also our fourth speaker. Welcome to today’s session which is “Stranded in Excel: Moving Beyond Basic Technology for ERM.” Today’s session is a panel discussion with three ERM technology leaders to discuss our love/hate relationship with spreadsheets. We can’t live with them but can we live without them?
Jamie Gahunia: I want to introduce myself as moderator for today’s session. I’m Jamie Gahunia, project manager at Resolver. I have been involved with many ERM program implementations in the past and also have an internal audit and risk background. I have had my fair share of being buried under spreadsheets. For those who haven’t heard of Resolver we are one of few recognized risk management software providers on the Gartner’s Magic Quadrant. This would include risk security, business continuity, internal audit compliance, and IT risk.
Jamie Gahunia: To start off I would like our panelists to introduce themselves and to tell the audience a bit about their career and experience with ERM tech. We’ll start with Brian, then Ollie, then Celeste.
Brian Link: Alright, thanks Jamie. Hello everyone. Yeah, I started my career as it pertains to risk management as a partner with Ernst and Young for a number of years in the risk advisory practice. The initial foray in the risk management technology was the… I’ll call the wonderful catalyst was Sarbanes-Oxley. That’s for the development of a lot of cloud based platforms for managing risk, albeit financial reporting risks.
Brian Link: Although a lot of companies were unhappy about the added costs associated with SOX compliance, I think what I saw at the time was board members and CFOs really enjoyed knowing that material. Financial reporting risks were identified, documented, and so forth. Now as CEO of Mobius One, I see that same appetite at non-profit and cooperative organizations. Particularly the board level for that simple yet powerful view of key risk, and most importantly, what’s being done response to those risk and risk in particular that are impacting business objectives.
Jamie Gahunia: Ollie?
Ollie de Boer: Oh. Hi. Thanks Brian. Thanks Jamie for the intro there. I’m Ollie de Boer and I work with Satarla. We’re a risk management consultancy firm and we specialize in training consultancy and research services. I’ve been working with Satarla for approximately about two and a half years. Currently I’m the technology lead so I’m leading all on all projects related to kind of software [inaudible] as far as risk management and other kind of technology related opportunities. We do work quite closely with Resolver as a company as well.
Ollie de Boer: Prior to that … prior to being at Satarla I was at G4S for about five years and I started there doing frontline risk management; so understanding what it is in the day to day operations of a business, what that means in terms of their risk landscape. I did project management for a year for a region there. Then I was the group risk manager there for several years. I was helping to basically run the enterprise risk management program across this massive organization. If you don’t know it, it’s the world’s biggest large… it’s the world’s largest private security company and it operates across about a hundred and fifty jurisdictions at the time when I was helping to run ERM.
Ollie de Boer: That also included a software project. We put in place a technology solutions manager, a risks self assessments, and internal audit. What I kind of bring is I understand the challenges of ERM technology and living in spreadsheets prior to that but from both side’s defense. Currently a consultant but I was an internal risks manager.
Jamie Gahunia: Celeste?
Celeste Duke: My name’s Celeste Duke. I’m a senior manager at EY. I actually lead our Canadian national JRC. I’ve been focused in this phase for a number of years. I tend to work with clients through helping them throughout their entire JRC journey, Whether it’s selecting the right tool to meet their needs to helping them get ready for a tool. What processes, framework, taxonomies do they need to have in place in order for tool implementation to be successful. As well as helping them through the actual implementation of a solution. I’ve seen clients of different sizes struggle through using manual process excel and various tools to try to solve their risk and trying to make the decision of when is it the right time to move to an actual software, when am I actually ready to do that.
Celeste Duke: I’m very happy to be part of today’s panel to discuss some of the experiences and struggles that I’ve seen through my career EY.
Jamie Gahunia: Thanks, Celeste. Just to help our speakers tailor their responses to the audience, we have a quick poll to confirm who we have on the line. Our first poll question is “What are you currently using to manage ERM program?”
Jamie Gahunia: [brief silence]
Jamie Gahunia: Excellent. I can see from the results that we have a high percentage of spreadsheets being the main tool of ERM. Before we discuss any tool [inaudible] spreadsheets, I’d like to ask our panelists about understanding and collecting risk data itself. Ollie, this question is for you. In your opinion, what kind of data is the most valuable to the ERM function?
Ollie de Boer: Thank, Jamie. Yeah, as the slide says there “data, data, data”. Where do we start? It’s a good question. I think before we really tackle this question we need to kind of dial it back and say “Okay, what is the [inaudible] the enterprise risk management function?” You know, there’s broadly like four main functions you could argue of an enterprise risk management function. You trying to rely on your risk, your strategy, and your performance. You’re ensuring there’s risk governance in place. You’re managing ERM process. You’re trying to kind of enhance and roll out a risk culture across and organization.
Ollie de Boer: Now a technology solution isn’t going to be the be all and end all of those things, right? It’s essentially about collecting data and managing that ERM process. If you think about what we’re trying to achieve wit technology and software, it’s really about efficiency in terms of identifying risks and getting them into the software in the first place. Assessing them, responding to them, prioritizing those ones that are most important for management and action.
Ollie de Boer: The main purpose is really… I mean you can put it into three broad camps. Let’s support the organization to achieve it’s goals and it’s objectives. Let’s work on that risk assessment process there; so what is it in terms of identification, prioritization, and management that we need to be thinking about? This covers all of out risks opportunities and threats. A lot of the times these solutions tend to… They can focus on the down side of risk management which is looking at threats predominantly. It’ important make sure when we’re collecting our data we are ringing through those opportunities as well.
Ollie de Boer: Action management as well, that’s a really important part of what we need to be doing. Then finally, sort of… reporting as well. We need to get data in but we also need to get data out. It’s very important that we have a reporting mechanism that supports effective decision making across the organization. Thinking about that kind of… that data in and data out process, and what kind of data would be most valuable…
Ollie de Boer: A lot of the times when people, especially if you’re embedded in spreadsheets, you get very focused on the actual process itself rather than… when you’re migrating to a technology solution, what you may find is quite different is you’re moving towards a solution where you’re getting… you have a much slicker front end for getting data in. You have a reporting engine on the back end for making better decision and getting data out essentially.
Ollie de Boer: Something you need to consider is, okay so we know we need to make better decisions. What’s the kind of data that we should be collecting in the first place to make those decisions? How’re we building these reports? How we’re going to collect it on the front end. Things to think about there in terms of picking up that valuable data is what does this front end look like? Is it slick? What is my reporting engine on the back end like? Have I got kind of a native in-built good reporting function or am I using a third party application as a specific skill set and I need to train myself up on that?
Ollie de Boer: Yeah, the database part in the middle, which is your spreadsheets at the moment, they’re almost like the least important part of the whole process there. That’s something that the ERM team will own in the center but thinking about data in and data out is really important. To give some kind of more specific examples about what we mean there, what do I mean by data that we’re collecting? The most obvious one is risks, right? That’s why we’re all here. We need to be collecting information on risks.
Ollie de Boer: Really importantly as well, we should be collecting information about the relationship between our risks and any software technology solution that you’re using, it should be able to map the relationship between risks. Because that’s really how risks work in the real world. We know their not isolated stacked events. They do interrelate. When one occurs it may lead to another one occurring. Or may be an indicator another one is about to occur.
Ollie de Boer: We should also collect information around our objectives because, as I just mentioned before around aligning risk strategy and objectives, if our risks aren’t tied to some sort of objective then they’re a bit abstract and they’re possibly not linking back to the the strategy of your organization. If we know have certainty around, or control around our risks, then we have more certainty that we’re going to achieve our objectives and therefore our strategy.
Ollie de Boer: We want to be collecting information around risk assessment in terms of how we’re prioritizing our risks for management. There’s various different ways that we can be doing that. If we think about a very common way of doing that is like [inaudible] vs impact on a matrix. We could change that up a bit. Quite a lot of good technology solutions will allow you to put impact or any kind of metric you like on that matrix so you could have impact vs control effectiveness, for example. Or velocity, things like that.
Ollie de Boer: We also want to collect information around out controls. How we’re managing our risks and again the relationship between our controls. What does that total control environment look like in your organization? Actions, this is a really important part. This is where spreadsheets really fall down because spreadsheets don’t do action management. There no way of sending out actions via spreadsheets. Indicators, anything that’s going to automate or monitoring of a risk being more likely to occur or not is a good thing to collect too.
Ollie de Boer: Let’s think about where we’re pulling all this information from across the organization. It’s going to come from different levels of the organization. We’ve got the front line, and this where you’re going to have your day to day risks, which are going to impact you quite quickly. It could be like a health and safety type of risk. All the way through to your projects and programs and your longer term risks, the strategic level of the organization.
Ollie de Boer: Yeah, it’s basically…
Jamie Gahunia: Okay.
Ollie de Boer: Thanks.
Jamie Gahunia: That’s good, Ollie. I’m just cautious of the poll questions that are coming up next. No, that’s excellent. That’s a good insight as to all the data that’s being collected, which leads on to poll number two. In addition to the valuable data, I’d like to briefly switch to the risk management adoption. Just to inform our panelists as to the top challenge of face your risk department. What is your biggest challenge in risk management right now? Brian, if I can get you yo comment on the result when it comes out.
Jamie Gahunia: [brief silence]
Brian Link: Okay. Well the biggest challenge here, over two thirds saying that the time spent on reporting-collecting, aggregating, analyzing… I think that’s very, very much in line with what we hear anecdotally and why we’ve got so many people on the call today. This speaks in particular to the data collection mechanism which tends to be excel. Even just the simple benefit of increased efficiency, if you say “Okay, well how are we doing this? How are we collecting and assessing data related to risks, controls, et cetera?”
Brian Link: Looking at the amount of time that’s invested in the quality of the outputs and the challenges around aggregating the data, making sure you’ve got aversion control all right, you’re cat herding trying to get the data together… That all speaks to the responses that we just saw there on the page that it’s… a lot of it is simply about the inefficiencies of using spreadsheets and other manual processes to get the information together.
Jamie Gahunia: Excellent! That’s Brian. Considering some of the challenges that have been identified by the audience, I… Celeste, this question is for you. How do we determine the point in which we are ready or mature enough for software? What are some of the questions to ask when determining this readiness, and can you share some examples from your E and Y experience?
Celeste Duke: A very good question and I’m often asked that in terms of when is it the right time for me to move from the heavily manual process to something a little bit more formal. I would say there’s three key areas that I would look at to help determine that one is around risk. Do I have a comprehensive risk frame or do I have effective reporting? How am I managing my risks? Do I have a process framework in place that can be automated into a solution where my cost an value benefits from? Am I spending too much time manually collecting, aggregating data, which is something that we’re hearing today, a lot of folks are struggling with.
Celeste Duke: It’s too the point where you’re spending more time on the manual tasks than actually managing those risks and understanding what those risks are and how to mitigate and potentially remediate them. Where you’re spending your time aggregating as opposed to really understanding, as opposed to getting that holistic view of risk across the enterprise and not having that ability to have access to real time view of where you are.
Celeste Duke: I would say those would be the areas to think about as you’re looking to move from very manual to a software. I’ve seen different clients struggle through deciding when’s the right time. I’ve had clients that have decided “I’m going to move to a software” but don’t have foundational components in order to be able to configure in a tool and take advantage of what a tool can offer. I’ve had clients significantly spend time on manual process, whether it’s aggregating, collecting, reporting, using excel, other tools technology; and it’s taking the bulk of their time as opposed to really understanding what that enterprise view of risk is.
Celeste Duke: Everyone will struggle to determine when the right time is but it’s when you’re spending too much time doing the things that you shouldn’t be doing as opposed to the value odds. Cost and value, do you have the funding, the budget in order to be able to support a move to a software or technology.
Jamie Gahunia: Excellent. Thanks, Celeste. Brian, can you comment in terms of can an organization implement a tool to early? What are some of the risks, if you can add to Celeste, of using software to administrate the ERM function.
Brian Link: Sure, sure. Understandably there’s a lot of excitement that comes along with implementing a new technology. Sometimes that excitement and, “Hey, I finally got the budget!”, and there’s a lot of emotion attached to it. Sometimes folks can tend to move a little bit too quickly. If you do that then you can run into some challenges as it pertains to what I would call change management. If a technology is improperly aligned to the needs of the organization, it’s processes, it’s reporting requirements and so forth, then you’ll likely get some pushback. To help ensure success, it’s important to include key stakeholders early in the process. Especially the light users of the system.
Brian Link: They’re the ones that will likely complain the most. If what they end up being asked to use isn’t familiar, isn’t usable and so forth. It’s getting all the right people involved, getting them excited as well, as to not only how much easier it’s going to be… We’ve talking ab awful lot about efficiency, and that’s very important, bu also the value of the data and the relevance of that data to them. Why should they care about this new software? It’s not really about the software, it’s about the great information they’re going to have to make better decisions around budgeting, around where are our assurance resources to be focused on the key risks and controls.
Brian Link: As Celeste mentioned, where might you want to put some remediation investment? If you can demonstrate that the software can do that for them that’s great. That’s one aspect of it. The other one is not so much pertaining to the timing or doing it so early but, it’s just a caveat around making sure that your process drives the technology. Don’t let the technology drive your process. That means first and foremost understanding your process and requirements and then assessing the various options, the various vendors and solutions relative to your process, your required outputs and being a little bit selfish around that. There’s a lot of great stuff out there but it’s not great if it doesn’t align to your specific process and requirements.
Jamie Gahunia: Excellent. Thanks, Brian. I guess now that we’ve determined we are software ready, the next biggest challenge that we hear facing risk teams is building a business case internally for software, getting the budget.
Jamie Gahunia: Before we go to our panelists we have a poll question for the audience. What is the most difficult part of creating a business case for software internally?
Jamie Gahunia: [brief silence]
Jamie Gahunia: Ollie, if I can get you to comment on the responses once it’s up.
Ollie de Boer: Thanks, Jamie.
Jamie Gahunia: Ollie, yeah, why do you think that it’s so difficult to prove ROI internally?
Ollie de Boer: Yeah, interesting poll results. I think, basically, this is very common. A lot of organizations are saying this. The vast majority is saying “proving the ROI” and “Securing the budget” as well. We had almost 80-90% of people there responding. If we think about risks and way that they work, we can think about the known risks and the unknown risks. An organization, when it comes to unknown risks, it’s very hard to quantify those events, those future uncertainties.
Ollie de Boer: With the current risk portfolio you can say “Okay, we have control around this. We know this is costing the organization so much money to do this.” You just, you don’t know unless you’re running a flawless process management program. There could be a future risk that could come up that is likely to turn into a crisis. Proving that ROI and securing budget as well, a way to get around that can be to build a business case to say “Let’s look at has our organization had a really costly crisis that has impacted us?” Or if it hasn’t “Is there a similar type of organization in your industry that has?”
Ollie de Boer: Let’s look at that and let’s dissect that. Let’s use some form of analysis to look at this incident, this crisis. What happened? How much did it cost that organization approximately? How much did that impact their strategy, their reputation and what they do? The think about the time horizon of that event when you’re trying to build that ROI or secure that budget. You can say that was a crisis that impact an organization and there was a material cost. If that had been controlled as an incident and responded to ore effectively then it would hae prevented escalation into a crisis.
Ollie de Boer: Even before becoming an incident, if that had been a risk and you prevented it from occurring in the first place, the you wouldn’t have had that move of the event from risk to incident That’s one was of looking to secure budget. Also proving ROI. Because you’re effectively doing peer review and benchmarking that. That’s one of my ways I would show it. It’s effectively “let’s use proactive risk management here to prevent a material crisis from hitting our organization.”
Ollie de Boer: Software is just a way, like we spoke about earlier, of automating and speeding up that decision making process. If you’re getting your data in and your data out faster, it will… it will help your organization to make those decision quicker and prevent the risks potentially from escalating into a crisis and that getting… Oh sorry, an incident and that getting worse and turning into a crisis.
Jamie Gahunia: Excellent. Thanks, Ollie. Brian, building upon Ollie’s comment, what are the two tips you can provide to teams looking to build a business case internally.
Brian Link: Yeah, I think the recurring theme I’m hearing this morning, or afternoon I’m sorry, is efficiency and impact. It shouldn’t be to come up with some cost justification that speaks to efficiency looking at the number of hours, full time equivalence, et cetera that are spent to support the process end to end. That’s actually the most straight forward component of this. I think the one that really makes a difference, and Ollie kind of just spoke to that, is that of impact. Then also thinking about “well who holds the purse strings” ultimately. Who are going to be your cheerleaders that folks are going to respond to in the organization.
Brian Link: In there I’ve often found it’s two people. It’s the audit committee chair or it tends to be the audit and risk committee chair. Also the CFO. As Ollie mentioned, it’s avoiding surprises that could impact your reputation. A little bit of fear is not a bad thing to bring up. The ability to reduce the chances of those and impact of those surprises. Then secondly is looking at… the organization is spending, depending on the size of the organization, often millions and millions of dollars on assurance. On regulatory compliance and on remediation and so forth.
Brian Link: If you’re able to take the outputs of this process and use it to better focus those scarce resources upon areas it will matter, I think that’s hugely impactful. I guess I’ll go with three instead of two. The third I think is… We’re talking a lot about ERM technology, but ERM technology is usually not something that sits there in isolation. ERM technology tends to be part of an integrated platform and an integrated approach to risk and performance management. Although you might be saying, “Hey I’d like X amount of dollars to implement some software to implement the ERM process”, that business case can often involve something much more compelling to say we’re starting with ERM and we’re going to have this great view of the key risks of the organization, how they’re being managed, what we should do about them. Those responsive actions.
Brian Link: Then, as an example of that, to say “well as subset of the risks that we’ve identified and assessed, we determined that we need some independent assurance around those. Let’s feed those naturally into the internal audit plan.” Well that internal audit activity can also be supported typically by that same technology. There tend to be internal audit applications there as well. Or you could say “We have risks that we’ve identified relative to regulatory compliance.”
Brian Link: Again, the platforms out there today tend to be holistic, integrated, efficient platforms. Cloud based. Lots of really compelling reasons from a risk governance perspective to bring all of this activities together and ERM is a great starting point. It tends to be a relatively low cost, very high impact way that your audit committee chair is going to love. If he or she looks at that report that says “Here are the key risks, here’s how they’ve been assessed, and here’s what we’re doing about them”, and they’re able to, within their board packet or their online interface to the technology, see how that connects to their internal audit plan and reports, and their regulatory compliance reporting, et cetera. It gives them a heck of a lot more comfort that all of this stuff is working in tandem. That you’ve broken down the silos and you’re doing it that much more efficiently, that’s hugely compelling.
Jamie Gahunia: Excellent. Thanks, Brian. Celeste, do you have anything to add to that on the clients that you’ve seen in the past? With respect to ROI successes?
Celeste Duke: Those were great comments that Brian brought forth. Completely agree in terms of being able to get the budget is you need to have that sponsorship, that buy in from executives. They typically need to understand what the value that you’re going to get out of a software or tool. Where that gets accelerated would be where there’s been an incident where something has occurred and there’s been no way to track it, there’s been no mechanism in place and that certainly helps.
Celeste Duke: To Brian’s point around pooling of teams and resources, where I’ve seen it successful in smaller organizations have been… I have my IT risks, my third party risks, internal audit all come together to say “you know what, we’re all struggling with different things around managing our risks. We’re highly manual. We need a tool to help us as opposed to just focusing on ERM.” We’ve seen where different stakeholders have come together to make that case much stronger and a lot easier and palatable for executives to understand.
Jamie Gahunia: Excellent. Thanks, Celeste. Which brings me to poll question four, which is where does the budget for risk management technology lie within the organization?
Jamie Gahunia: [brief silence]
Jamie Gahunia: Brian, if you could comment on the results once they are ready. It looks as though that we have a clear leader of the risk management team actually has a lot of the budget. The second response is “I don’t know”. If you could comment on those results that would be great. Thank you.
Brian Link: Sure, sure. It’s good to see that the risk management team… What I’m inferring from this is that the risk management team is getting the budget, which is fantastic. Which is often a big barrier that the risk management functions in many organizations, if they have a dedicated risk management function, tend to be relatively small as compared to other key support functions in the organization, second line, third line. I kind of take it back to what Celeste mentioned there as well is it’s great that the budget’s coming from the risk management function, but it can be a heck of a lot more compelling if you’ve got some friends next door in internal audit or internal control or regulatory compliance or vendor management or IT security. To get those folks together and say “hey, I’m looking to make an investment here to support what we need from a risk management perspective. Should we be looking at this collaboratively?”
Brian Link: If not, if they’re not ready, at least you can give them some early insight and allow them to be guests in the process so that when it comes time to potentially integrate across those silos, those folks are ready and are bringing with them the budgets to make it happen. Which is critically important! If you really want to build that sort of holy grail of integrated risk management across assurance, risk management compliance, and so forth, you’ve got to have everybody at the table. It’s another reason to involve those key stakeholders early in the process.
Jamie Gahunia: Excellent. Thanks, Brian. Celeste, can you comment on the typical time lines and also have you seen some ways in order to speed up the time lines in order to get budgets happening?
Celeste Duke: Time lines vary greatly based on organization. I won’t lie. I’ve definitely seen different things and as I mentioned earlier, things that will accelerate are having that executive sponsorship. Having had a lot of those internal discussions prior to saying we’re ready for a tool and selling that idea to say “we really need something”. I’ve seen situation where, again, there’s been incidents, there’s been risks that have occurred and no mechanism in place to really identify, assess them very quickly because either it was buried in a excel spreadsheet and someone didn’t get to see it when they should’ve seen it.
Celeste Duke: Certainly things like that, which I would not recommend the basis to do tool, you want to be ahead as opposed to being reactive. Again, I think that where you can pull resources and teams, I think that tends to accelerate bigger budget and bigger vision and ability to really leverage across the organization.
Celeste Duke: Time lines depends on where you are from a budget life cycle. It is really understanding “what value am I getting out of a software” and linking that back to your business case.
Jamie Gahunia: Excellent. Thanks, Celeste. Our next question goes to Ollie. Once a company has identified a need to move away from spreadsheets to ERM tech, what are the steps to identify and assess software vendors?
Ollie de Boer: Thanks, Jamie.
Jamie Gahunia: [inaudible] you Ollie.
Ollie de Boer: Cheers.
Jamie Gahunia: Yeah, thanks.
Ollie de Boer: As you’ll see listed on the screen there, there’s a range of resources listed there. Just a cautionary note on some of these. They are good resources so good place to start. They’ll give you a list of companies and what they can offering terms of their software, their use cases, et cetera. Some of them are paid resources. What you’re finding is some technologies pay to be on there whereas its not a true meritocracy. You may find that it’s almost like a partial data site. You’re not getting every vendor that could be a good fit for your requirements. That’s to really important part there.
Ollie de Boer: Before you eve start doing this, you need to make sure you understand what are our requirements? What are your use case that you’re trying to implement. Once you are… once you have a better idea of that, you can go out into the marketplace and have a look. There are these various resources here. I find that something like Gartner’s Magic Quadrant tends to cater to the larger type of vendor out there and larger type of organizations. That may be fair to say. Do get a second opinion before you commit to going down that path.
Ollie de Boer: There’s also review sites we’ve got up here: Capterra and Software Advice. They are internet databases essentially, which give you a high level description of different softwares out there. They link through to the vendor’s website. I find sometimes resources like this can be out of date. Or it can link to a legacy product sometimes. Just be careful there that you’ve got the most up to date information. Yeah, again it’s pretty important. You just need to make sure you understand “what are your needs and how are you making sure you’re assessing the marketplace correctly? Are you getting a good independent, impartial decision there?”
Ollie de Boer: Once you’ve identified some products, though, that you think would fit your organization, there’s a quite a rigid process that you can go through in terms of project management approach. If you think that you’re software ready, and you understand what your use cases are, you know what your requirements are, let’s think about “okay, which requirements here are the most important? What is it that I really, really, really have to have in my software functionality wise versus what is just nice to have?” Maybe “I absolutely have to have this type of report, like a bow tie analysis.” A nice to have could be a different type of report like a fish bone diagram or something like that.
Ollie de Boer: Understand what it is that you’re really trying to achieve. When you go out and you ask these vendors for information from them, matching them to your requirements, you understand, therefore, which ones are going to meet those requirements that you find essential. Going through a process of that asking questions to the vendors, down selecting. You could start with quite a long list. I’d recommend maybe ten potential solutions. Down select three to a few that you think would really, really meet your requirements there.
Ollie de Boer: Then you’re starting to get into the demonstration area. You’re asking the vendors to demonstrate the product to you. I find that what’s really important which the demos is you’ll probably want to see it, if you’re the project lead, you’ll probably want to see it first yourself to get a good idea of “is this going to work?” Try to get through the sales speak as well and really understand the functionality there.
Ollie de Boer: What’s key is proof of concept. You know what is going to work for your organization. You understand your requirements, you know what you need functionality wise. Now try to get your hands on the software in terms of demoing it, like proof of concept. You’re actually going in, you’re given a license, you’re going and you’re putting information in. Try to find those red flags. What is it that the software can’t do?
Ollie de Boer: If you have an essential requirement and the software can’t do it, you may not get that from a demonstration. If you start to get further down the line into contract negotiations and you’ve committed to a product that isn’t going to meet your requirements, then you may end up in potentially bad situation there. Proof of concept testing, very important.
Ollie de Boer: After you’ve kind of okayed it as the project manager or the product lead, have a tailored product demonstration for your key stakeholders. Really get them on side. We’ve mentioned stakeholders a few times. We know the importance of [inaudible] on investment. Get those key people onto a demonstration. Make it kind of a short one and tailored. Have a scenario that would fit your organization and get the vendor to demonstrate that scenario in their tool so you can have a risk that’s relevant to your industry. They’ll sort of show the life cycle of that risk in there. Or an incident, getting to play that out in the software as well.
Ollie de Boer: Have it very tailored. “How is it that we’re getting the information in? How are we going to be more efficient in terms of that?” Back to the reporting again, “how am I going to make better, quicker decisions off the back of that?” Don’t spend too long, especially for that tailored demo, on the database part of the application. The “how are we prioritizing our risks?” It’s really about making sure that you focus on the data in and the data out there. Also give a chance for Q and A for those key stake holders because they’ll really value that and that will make them buy into the whole process is well which is imortant for the sponsorship of this project.
Ollie de Boer: Thanks, Jamie.
Jamie Gahunia: Excellent. Thanks, Ollie. With that is our final poll. This is more of a perception question, but what is the biggest barrier when considering a software implementation? Brian, I’ll get you to comment on the result of the poll.
Jamie Gahunia: [brief silence]
Jamie Gahunia: Brian, I guess this ones for you. It looks like “unknown or hidden costs” are the top response for poll question number five. If you can provide some insight as to what that means or what are some of the unknown and hidden costs?
Brian Link: Sure, sure. I think this kind of speaks to making sure you get the right people involved early because the unknown or hidden costs often come up with or come up through change orders, change requests, the elements that could’ve been known initially but weren’t ferreted out. I think the reason that you’re seeing that response as well is that everyone’s heard the horror stories around IT implementations. It doesn’t matter if it’s risk management software or health and safety software or health and safety software, whatever it might be. Or an ERP system. The typical are overruns in terms of time and budget. That’s normal.
Brian Link: You have to figure out “Well how far within that normal range do we want to be? How much overtime and of our budget is palatable for us? What is our risk appetite?” To use a phrase as it pertains to those elements. I will say that I’ve been involved in implementations that go very, very well. We just implemented a credit union that was up and running in three weeks and everyone was delighted. There are other situations where if expectations aren’t properly set up front, people will be disappointed. It’s really, it speaks to investing the time upfront, to ensure that you have the right stakeholders involved. From a cost perspective, that you’re working closely with the vendor to not only come up with a specification and an associated budget.
Brian Link: Also, looking at the things that can impact your timeline, and therefore budget which is availability of resources internally to help support the implementation. Making sure that you really understand the change management process and that… What you’re buying is pretty well documented so that you’re avoiding those additional charges for things simply because they weren’t documented but were assumed to be in scope. That’s kind of a long commentary on that response.
Jamie Gahunia: Excellent. Celeste, do you have any additional comments to add to that?
Celeste Duke: I think Brian did a great job answering that question.
Jamie Gahunia: Okay, no problem. Okay…
Ollie de Boer: [overlap] Jamie?
Jamie Gahunia: Yes? Ollie, did you want to add something?
Ollie de Boer: Yeah
Jamie Gahunia: Sure. Go ahead.
Ollie de Boer: Thanks. Sorry for cutting in there. The other category there, where people are saying… there’s twenty-nine percent of people saying “it might take too much time from their job”. That is a really interesting point touching on there. I think it really comes back to this project, is it a risk project or is it an IT project? The answer is it’s both. The enterprise’s management team, they’re the subject matter experts, they have to be involved in this project, right? That’s a fact. Do you have a mature and developed IT function in your organization that wants to own this because it’s an IT change management project?
Ollie de Boer: There’s no perfect answer to this and it totally depends on your organization and the culture there. Ideally I would suggest having a dedicated project manager. Somebody who’s experienced and understands both from an ERM perspective and also an IT change perspective. That will significantly improve the quality of your project and reduce risks around cost overrun, time overrun. Yeah. Thank you.
Jamie Gahunia: Excellent. Thanks, Ollie. We have one final question for all the panelists. I’m going to start with Ollie. The question is, if I was knee deep in excel spreadsheets right now, what’s the one piece of advice you would give me? Starting with Ollie, then Brian, then Celeste.
Ollie de Boer: Thanks, Jamie. Yeah, we’ve all been there. We know that the vast majority of the audience on today’s call are still using spreadsheets. It’s hard. There’s a lot of manual roll up that goes on with spreadsheets. Let’s really think about where is the value? One thing we’ve really drawn out today from the conversation is around reporting and making sure that we’re showing that ERM is adding value to our organizations. Let’s make better decision based on our reports.
Ollie de Boer: My advice would be fewer reports. Draw fewer graphs. Excel is made to kind of draw lots of descriptive types of graphs. They’re not all very useful. Think about what are the insights and what am I really trying to ach… what insights can I draw out from my data once I’ve kind of put it together in excel? What is it that I’m trying to report to key decision makers? Link it back to your strategy and your objectives. Have hose reports focusing on that. If you need to, tailor the front end so that you’re drawing those… you can draw those insights out and get that information to key stakeholders and decision makers. Thanks.
Jamie Gahunia: Excellent. Brian.
Brian Link: I’ll pretty much parrot what Ollie just said and distill it down to get key stakeholders both rationally and emotionally involved. Those key stakeholders, I would say, are the audit committee chair, audit committee and risk chair, and the chief financial officer, and potentially other functional leads. When I say rationally and emotionally involved, the rational is “look at all the money we’re going to save, this could be this much faster, we’ll have this much more richness of data, et cetera.” Then the second piece of it is the emotional involvement.
Brian Link: I hate to say it but pretty charts and reports can make a big difference. People, we’re visual animals. As Ollie mentioned, fewer but high impact reports. If you can hand an audit committee and risk chair or a CFO a simple, powerful, one page report that says “Here are the key risks that we have, here’s how they’ve been assessed. Here’s what we’re doing responsive to those risks.” Because the only reason we’re doing ERM is to figure out “What do we do about it? What’s the responsive action?” You can make that simple, palatable, yet powerful and make it look good, that’s a great way to help get them emotionally involved as well.
Brian Link: Over to you Celeste.
Celeste Duke: I agree with both Ollie and Brian. As much as I want to say throw away those spreadsheets, I don’t like them. It’s tough to manage, prone to error, and especially when you’re aggregating, calculating, doing a lot of different things in your excel spreadsheets. Both Ollie and Brian’s points where you can simplify, where you can bring out the key messages, and make your lives easier. I know, a lot easier said than done on my side of things. As much as I want to say go get a tool to help make your lives easier, it’s not always something that’s feasible. If you do have to work with excel, think about how you can make it easier on yourselves, on your teams, where you can simplify and where you can really show some of that risk data in a consumable fashion. As Brian said, make your stakeholders, I guess bring that emotional side to your stakeholders as well.
Jamie Gahunia: Excellent. Thanks, Celeste. That concludes our panelist questions. We do have a few minutes for questions and answers.
Jamie Gahunia: [brief silence]
Jamie Gahunia: There’s a question, and I’m going to pose Ollie… to Ollie. What software allows you to tailor your risk practices and templates to your currant excel reporting requirements, so you can grow in complexity?
Ollie de Boer: What software… sorry, Jamie. The question was “What software allows you to grow…”
Jamie Gahunia: Allows you to… yeah, to tailor your practices and templates to your current reporting requirement, so you can grow in complexity as an organization?
Ollie de Boer: Yeah. Any good ERM technology solution should allow you to do that. They should be scalable in their approach so that when you’re configuring your requirements you can keep it very simple, so you can have a very simple risk process there. Or you can have something that’s like more aligned to an international standard like ISO 31,000. Whatever it is process wise you should be able to build that in easily. The reporting engine, we’ve mentioned this before, make sure that you understand the implications of the reporting engine. Is it a native reporting engine so the reports that you’re building and generating to send to decision makers, is that already in-built in the software? Is it easy to configure? What are the implications of that for an administrator? Or are you using a third party application? Something like Tableau or Power Bi, or Qlik, something like that. It’s a different skillset. It can sometimes come with additional licensing costs so look out for that.
Ollie de Boer: Then in terms of scalability. Yeah. Any solution that you put in place, you should be able to keep it simple but also build it up in terms of complexity when needed. As you mature as an organization and your use cases develop, any good software should be able to accommodate that. You shouldn’t be… No software should force you to change your process. That’s a key thing with one of these projects. You should be able to fit your process into the technology regardless. Thanks.
Jamie Gahunia: Excellent. Thanks, Ollie.
Brian Link: I was going to add something very quickly to that in terms of configurability and what can you do to make sure that it’s flexible and scalable, is to have the vendor show you the configurability of their workflow, the configurability of their forms, the configurability of their reports. Say “Show me. If I’m an administrator, how can I go in and make those adjustments as my complexity changes or I want to add an extra review process, whatever it might be.” Have them show you the ease with which workflow, forms, and reporting can be tailored to our changing requirements. Then the initial proof of that is giving them what I call a demo script. Say “Here’s our process. Can you represent, and we’ll give you some dummy data too. Show us how it’s going to align to our process.” I think that’s another really helpful way during the demos of your short list of vendors can help provide an apples to apples comparison of what would really matter to you, which is a lining to support your methodology.
Jamie Gahunia: Excellent. I do have some follow up questions with respect to vendors and whether or not most give trials and do they have any reporting templates that are sort of off the shelf?
Jamie Gahunia: Maybe, Brian. You want to expand on that?
Brian Link: Sure. Most vendors will give you a sandbox to play in. The caveat I would put in there is, again it’s important to invest the time up front, to say “if we want to asses your technology, we want to do so relative to our requirements.” The vendors tend to be really proud of certain features and functionality and they tend to lead with those. Really what should matter to you is “This is what we’re trying to achieve. This is our process.” Giving the vendor the opportunity, and also kind of demonstrate their commitment to say “Alright, we’re going to take the data that you’ve given us, the script that you’ve given us, and we’re going to invest a little bit of time to customize the software or configure the software for you, and perhaps even with you, and then give you some time in a sandbox environment to try it out.
Brian Link: Involve the vendor a lot in that process. Get them to help build it with and for you. Get them to show you how to use it. Don’t expect them to just say “Well here are the keys. Go for a drive. Have fun.” That could backfire. Again, yeah, I’d say get the customized sandbox but also do your part by giving them some very clear instruction on what’s the demo script. Give them some good data and let them know what you expect. Again, you can have a nice apples to apples comparison across vendors around what matters most.
Jamie Gahunia: Excellent. A final question is, what does the future of ERM technology hold? We’ve heard a lot on machine learning, analytics. Can the ERM team draw on that from a technology standpoint? Maybe, Celeste? You want to…
Celeste Duke: Absolutely.
Jamie Gahunia: Talk to us about that question?
Celeste Duke: For sure. This is definitely a great question and something that I’m conversations with a lot of my clients. Now that I have a nice integrated risk management tool, I have a lot of data in place in order to make better decisions and have access to really time data. How do I take advantage of that information? How do I add machine learning ai to better understand those risks, better understand my data, and definitely great tools? There’s a lot of advancement in machine learning today and in ai and the capabilities that you can do with data quality. Certainly helping understand what your data quality is. Helping understand where you can go from there.
Celeste Duke: It’s very interesting and I don’t see today, a lot of clients that are there with necessarily their risk data, but a lot of conversations around that space are certainly happening and I find it interesting. Throughout the presentation today, Brian has raised the point of how rich we are in our data and the better that we understand our data, the better quality that data is, the better we are able to make business decisions or use our risk knowledge to align to our goal. Definitely interesting to see how and where that will go. We’re getting there, which is cool.
Jamie Gahunia: Excellent. That’s Celeste. That concludes our webinar. We’d like to thank you, and thanks Ollie, Celeste, and Brian. The recording, the poll results as well as our previous year end benchmarking results will be shared by email right after the recording. Or after the session. Thanks so much.
Megan: Alright and with that, I’d like to thank our speakers for their time and expertise today. A copy of this webinar will be archived on the Opus Ed within a few days. Please join us next Thursday for RMS Webinar “Best Practices in Reviewing Contracts to Identify and Mitigate Contractual Risk.” Thank you so much and have a great day!
Megan: [Silence until the end]