<img src="https://ws.zoominfo.com/pixel/kZxG1sNctrruFoZSPoVD" width="1" height="1" style="display: none;">
Contact Us
Book A Demo
Menu
Book A Demo
Contact Us

Risk pools and the status quo of their risk management information software

change_or_status_quo_for_risk_poolsAs the member of the Aon eSolutions Product Management team charged with development of our offering to risk pools, I listened with interest to the on-demand webinar that we released last month featuring Craig Bowlus, managing director of the Aon Risk Solutions Risk Pooling practice, and Michael Theut, senior solutions consultant with Aon eSolutions. 

The webinar that Craig and Mike led, as well as the blog post that Craig penned at the time, focused on the “going forward” aspect of risk management software and how risk pools are adopting new and emerging technology trends. I think looking ahead was the right focus for the webinar; however, the session got me thinking about where risk pools were and are coming from with their risk management information software and processes. 

My experience suggests to me that many risk pools still use some kind of homegrown risk management software solution that combines manual, spreadsheet-based processes with custom databases (Access or something similar) that have been built and maintained in house. In their webinar, Craig and Mike make a strong case for pools revisiting their approach to risk-management technology. It can be difficult, however, for a risk manager at any organization (risk pool or otherwise) to make decisions about the future of their enterprise risk software without first grasping the pros and cons of their current situation. 

The risk technology status quo and how it benefits risk pools

If a risk pool has not implemented third-party risk management information software like the Aon RiskConsle RMIS, my experience teaches me that the pool will most likely have a hybrid setup made up of spreadsheet-based processes and databases. 

When it comes to homegrown databases, there are different levels of sophistication: Some pools use only simple tables in their database; pools with internal IT assistance may be more likely to have a front-end, application-style look and feel to their database. The top benefit of homegrown databases is the ultimate, the-buck-stops-here control that pool administrators have over their particular database. Pool administrators control the direction of that system and have strong internal accountability over the IT team that develops and maintains it.

When it comes to spreadsheets, many pools manage a wide variety of data manually through Excel documents, including member rosters and exposure values. I think risk managers are comfortable with spreadsheets because they’re fast; almost everyone can use spreadsheets; they can be very powerful; and they enable users to do a lot of manipulation of the data.  

Where the risk technology status quo can disappoint

Pool administrators are likely to be as familiar with the potential drawbacks in a homegrown risk technology setup as they are with its advantages. In fact, the drawbacks are in many respects simply the other side of the coin: 

  • Whereas a database built in house is designed precisely for the risk pool’s needs, it can be difficult to adapt and expand the system unless dedicated IT resources are always available and focused on building out the system. 
  • A homegrown database can be built for the risk pool at its current size, but these kinds of systems can be difficult to scale up or down when necessary. 
  • Homegrown systems tend not to be capable of mobile use, which could make it difficult for the employee of a pool member, for example, to add notes to a claim file in the field or take and upload photos to the file. 
When it comes to spreadsheets, the potential drawbacks come back to the risk manager’s general imperative of developing and implementing processes that are sustainable, repeatable and auditable. Spreadsheets are effective for one-time analyses, and probably always will be; however, for ongoing procedures like monthly and quarterly presentations to the pool’s board of directors, the risk is that undetected errors in a spreadsheet will throw off the numbers across the reporting.  

Difficulties in “connecting the dots” can also be challenges for the homegrown, spreadsheet-and-database system. Imagine, for example, the challenges in telling a coherent risk-profile story when a risk pool has its member roster in a spreadsheet; its claims data coming from a TPA system; and exposure-data tracking in a database. Pulling all that information together for a comprehensive, accurate view is time-consuming and fraught with the possibility of inadvertent error. 

It all comes back to core competencies

I think most risk pools would agree that their core competency (and area of expertise) is providing its members with a risk financing/risk transfer mechanism. Responsibilities related to that core competency include, for example, managing certificates of insurance. It’s common for pools to keep all of the certificates they collect from members as well as those they distribute to members in binders. Pool administrators are dedicated professionals, so they’re scrupulous about updating their spreadsheets with certificate data; however, because it’s a manual process, pools run the risk of overlooking data points like expiration dates. If an expiration date then impacts a lawsuit, the cost to the pool and its members can be substantial. 

The point here is that just because a risk pool can develop and build out its own enterprise risk management software, that’s not necessarily the best choice. The question is, why should a pool distract itself from what it’s good at (risk financing and transfer, member service, etc.) when there are other options out there?

We at Aon eSolutions went through a similar exercise several years ago, and we are continuously revisiting the areas on which we focus our software development resources. For example, in 2009, after a number of years of using our own, in-house reporting tools, we decided to make use of market-leading third-party business intelligence tools that did the job better and more cost-efficiently than we could. By making this choice, we were able to refocus our resources on our core competencies: building technology solutions for the risk, insurance and safety markets. 

By assessing the risk-technology status quo at risk pools, I hope this blog post helps pool administrators get a better sense of whether they need to reevaluate their own setups. 

Karen O’Rourke is a senior product analyst on the Aon eSolutions Product Management team, based in the Chicago Aon office. Email Karen at karen.orourke@aon.com.

Technology trends for risk pools

 

Dec 20, 2013

 | Originally posted on 

Subscribe by Email