Moving to a new RMIS? Consider one that can grow with you

When an organization moves to a new risk management information system (RMIS system), it is usually making the change for a specific reason or reasons. Perhaps the organization requires more flexibility in tracking and reporting data. Maybe it wants the more powerful functionality that technology can provide. It may want to handle its risk management operations more efficiently across multiple departments, from field user up to the C-suite level.

Regardless of motivation, one question our implementation team likes to look at with a new client is how the RMIS we're developing today will be ready to support the client's needs in the future.

While the implementation process itself can command the full attention of both the provider and the client's teams, we still advise taking the time to consider how the solution will grow to meet the client's needs as the organization evolves.

The power of collaborative brainstorming

The step can be as simple as a collaborative brainstorming session. For example, we can pose the scenario: “We'’re tracking these five claim types in the system today. But we also have claims for areas X, Y and Z. How can we make sure the RMIS can accommodate this change? Can we build a system now that will track those additional claim types effectively, as well?”

The answer doesn'’t have to be definite, as in, “These are the exact reports we’ll need,” or, “This is the exact data we’re going to capture.” It'’s more a case of, “This is our policy information now, and in the future it would help to understand how our claims are impacting our policies and insurers.”

This kind of information helps ensure that we are aware of future needs and are making decisions today that will allow the client to grow into this setup.

FOR EXAMPLE: We have seen instances in which clients start small, basically capturing their policy information and claims information into the RMIS. But at some point they decide they want to be able to appropriate out the financials on a claim to the various insurers that are part of those policies. They are going one step further. Not only do they want to know what policies a claim is being linked to, but how it’'s impacting the various insurers on those polices.

Understanding workflows

We often find it works well to understand the organization’s current workflows. We focus on what their pain points are today, and then look at what’s not working.

Once we have a good understanding of the workflows, we discuss where they see the RMIS in the next two years, three years, —even five years. Are there other modules or capabilities they’ll need, or other critical data they’d like to capture? Have they witnessed how a RMIS works for another company in their industry in a way that could be helpful to them?

We realize that these are longer term, even visionary questions, particularly for a first-time RMIS client. But I have found that having even a basic wish list of how the RMIS could support them gives us a jump start on deploying the new system.

Beyond manual spreadsheets

Let’s look at another example. Many times, we see first-time clients who are migrating to a RMIS from using an Excel spreadsheet method of data capture. The risk manager is looking for a RMIS to bring in spreadsheets submitted from the field, updating property values, and producing a statement of values on an annual basis.

Their initial implementation meets the goal: it enables them to pull in basic data quickly and provide some basic reporting. But frequently the next step is to have the field-level staff logging on to the RMIS, updating their information in the system and allowing the risk manager to review and make sure the numbers make sense.

The client is here moving away from a very labor-intensive process of pulling together multiple spreadsheets or statement of values and consolidating them into one that can produce actionable reports.

By taking a forward-looking approach, we can deploy the implementation by understanding what fields users will update regularly, and what approval process needs to be put in place.

Keep it within a manageable scale—then expand

I think the main thing is to not make an initial implementation too large. It’'s best for the client to start with an implementation—and the scope of the RMIS software, —within a scale they'’re comfortable working with. I let clients know there'’s nothing wrong with doing some sort of a phased implementation. This involves the practicality of getting something in place, especially for a client who is implementing a RMIS for the first time. The ideal scenario is to roll it out to a scale they can support.

But we also don’t want them hampered by a system that can’t go beyond the deliverables in the initial implementation. I definitely encourage them to be thinking a couple of years out, to where they want to go next with the system.

Clients definitely want to be thinking a year down the road, two years down the road, five years down the road about what they’re expecting their RMIS system to provide—and how that will impact the effectiveness of their risk management operations.

Steve Rodell is manager, business analysis, on the Professional Services team with Aon eSolutions. Please email Steve at steve.rodell@aon.com.