By Today’s blog is an OpEd about Risk Management Information Systems (RMIS) based on my experiences. I have spent the majority of my career within the Risk Management and Insurance space, with the last 20+ years working for two of the major RMIS providers. What I’ve figured out is insurance and risk drives so many aspects of our economy. The inability to obtain insurance, or obtain but at an unreasonable premium, can (and does) prevent company’s from entering markets. The tangible and intangible costs from losses can cause companies to pull out of markets/states/countries and even shut down operations entirely, which can have a ripple effect throughout the economy. From Insurance 101, we know our options when it comes to risk are:
- avoid
- accept
- transfer
- mitigate
While you can throw a dart at a dartboard marked with those options or pull slips of paper from a hat to decide how you want to address risks impacting your company, it makes more sense to consolidate data and make educated decisions. What tools are available to you to improve your experience with risk and insurance? Enter the RMIS (similar to “release the Kraken”)!
Having spent time with clients building out their use of a RMIS and experiencing successful (and unsuccessful) implementations, it is clear to me that:
- it is necessary to have some type of system to help with gathering your data and completing your analysis not only of your risks but also strategies that allow you to take calculated risks, mitigating the severity of damages should they occur.
- A big aspect to the successful rollout of a tool is engagement. I said help, because you can’t forget that it is a tool. My professor a long, long time ago in my senior year at SMU introduced this acronym (which looked like radio station call letters, but stuck with me over the years) – WIIFM – what’s in it for me. I can architect a beautiful system, but you, as the risk manager/safety manager/RMIS administrator, absolutely must have a plan for answering that WIIFM question, first to convince the executive board of the investment and second to the field/end users to ensure their engagement.
Your first question will likely be ‘What data?’ – the typical starting point is gathering claim data from your carriers and TPAs to see the financial impact of your losses. I prefer to start with the tasks tied to insurance renewal efforts: capturing # of employees, payroll, vehicle counts, turnover, etc. These elements are usually easier to get (and sometimes carriers can be stingy with the release of data). When deciding how granular you need that data, it is best to think about how you want to ultimately see your Cost of Risk…and back into your elements from there, which brings us to the lovely space of locations and location hierarchies.
The biggest driver of any implementation is location hierarchy, the ‘backbone’ of the system. I’ve seen many implementations go sideways on this deliverable. In my experience, I’ve gravitated to a much simpler approach. I would much rather see a flat structure and use of coded fields or even text fields for analysis than to be hung up on defining levels within your organization’s structure. And sure some RMIS allow for multiple hierarchies AND you can have location based security…but there is an administrative cost around the maintenance of more than one structure or a massive location hierarchy. I highly recommend you follow the KISS approach (keep it simple, stupid). Consider what your the end game is. For all it should be user engagement and ease of maintenance. I may architect differently if your goal is allocation of insurance premium to divisions. At the time of my engagement, I will spend more time on end goals and how success is defined so that the we build a solid foundation (and avoid the dreaded rework).
Your next question will be ‘why can’t I use excel’? Excel is always an option. But let’s be real with each other – that’s like using a push mower on a 20 acre field. It will work but it isn’t robust enough for the job. True story – When I was an Information Manager at Snelling, I used to extract data from a less than stellar RMIS system into excel to complete my allocation process. So I’m not necessarily opposed to excel. It’s just the issues surrounding around ‘most current’ or ‘most accurate’ version of the spreadsheet. I would send the spreadsheet via email to the actuary. He’d send it back with changes, but at that point, I’d already gotten different data from the field, so now I had two different spreadsheets. Then we’d have a call and make adjustments, but at that point there were two more because I had the file both locally and in two places on a shared network drive with different modified dates. You can see this can be a real nightmare. So having one source of truth (keeping all data within a RMIS) will make your life incredibly easier.
With a RMIS there is SO much more that you can do than with excel, once you understand the administrative side of the software. A RMIS is a relational database with tables that link to each other AND it allows your to automate boring/tedious tasks so you can concentrate on more important job responsibilities. 90% of the time, if a client asked, ‘Can your system do…?’ The answer was ‘YES!’…I typically followed up with ‘But should we?’ Don’t be afraid of that conversation! When I asked that, my goal was to ensure we stayed on track to what we were hoping to accomplish. It is easy to get distracted by all the things a RMIS can do, but those distractions will cause you to lose focus.
Your next questions are ‘Who?’, ‘How much?’ and ‘How long will this take?’ For the Who, please check out Red Hand Advisors RMIS report. Pat and Dave have vast industry knowledge and produce this report annually. Gartner also produces some nice documents.
‘How much’ and ‘How long’ is somewhat up to you. There are some sales person who are looking out for your interests, but remember they are compensated on what they sell. My recommendation is always start small, rather than a large multi-phase project (unless you’ve got some funding burning a hole in your pocket). What I’ve seen is that implementation teams at every RMIS are typically understaffed and over-allocated. That means large convoluted implementations can drag as the team is pulled into multiple directions. The easier/more contained your project is, the faster it can be implemented. Your best investment would be a strong system administrator on your team (either internal hire or using a consultant) who can drive the project on your side and push your RMIS’ project team. I’ll save the lecture on implementations for another day!
Thanks,
Mary