<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

The blueprint: hierarchy and reporting structures in risk management software

blueprint for risk management software“You've got to get organized. It may be something you say to yourself, even on a daily basis. Or it may be a gentle reminder” you mention to someone at home or at work. When you'’re talking about implementing a risk management information system (RMIS system), getting organized isn’'t optional, —it’'s mandatory. As a veteran of dozens of RMIS startups, I know firsthand the importance of designing and setting up organizational hierarchy and reporting structures.

As the blueprint for the entire RMIS, a workable hierarchy:

  • Maps the workflows
  • Establishes formats for loading data into the system and generating reports
  • Integrates the units, personnel and roles
  • Captures the distinct levels within the organization
  • Indicates down to the user level what the roles are and who should be included in accessing data and reporting

We find that most organizational hierarchies include:

  • The location's legal entity at the highest level
  • The disparate divisions, regions, accounting and operational status
  • Any other identifiers that come into play

Fourth in a SeriesRisk managers need to know that users of risk management software have the appropriate permissions to view the data they are tracking in the RMIS. From there, users can perform analytics on the information and make solid business decisions based on that information.

Having good organizational hierarchy and reporting structures in place is a critical part of ensuring that risk management software delivers business value and strong return on investment.

More Posts in This Series

  1. Introduction
  2. Manage the project collaboratively
  3. Define your success criteria clearly
  4. Capture your organizational hierarchy and reporting structures
  5. Focus on data mapping and data integrity
  6. Build it to scale
  7. Deploy in phases
  8. Encourage user acceptance
  9. Be flexible

So, how to start?

As my team launches an implementation, we often find the client has some type of hierarchy in place. They may have an existing RMIS. They may be receiving data from one or more third-party administrator, each of whom has its own format. The client may have an in-house system. Or there may be a combination of all of the above.

Even a loosely structured hierarchy is a starting point for discussing and mapping out a new structure. It can: 

  • Indicate sources of the client's data
  • Indicate frequency of submissions and updates
  • Indicate the form (Excel or manual, for example) in which the data will be submitted
  • Provide a view of the client's workflows

At this early stage we urge clients to understand how valuable it is to have all parties using the same structure. To that end, the RMIS structure should:

  • Work for third-party administrators handling the organization's claims
  • Align with the organizational structure from, for example, an SAP or an Oracle system
  • Enable the risk management team to produce reports in line with how top management wants to see its data

To steer clients in their hierarchy decisions, we often provide them with examples of structures that similar organizations have in place. We also prepare examples using the client's own data, represented in Excel, in a PDF or in a diagram. This helps them visualize what we'll be doing in the system and illustrate how we'll organize the information.

For new RMIS clients, it may take a few more renditions of prototyping and showing them how it's going to look before a new client is comfortable signing off on the hierarchy.

We want clients to be able to enter data easily into the RMIS and in a logical format. We want them to be able to set up security so users have access to data and reports based on their authorization level. And, they need reports in formats that make sense across the company.

Chance for a Fresh Start

Whether a client is implementing a RMIS software for the first time or moving from an existing system, the setup of the organizational hierarchy offers a good checkpoint. The setup process is an opportunity to:

  • Review existing workflows
  • Review levels of user security
  • Review types and formats of reports and access
  • Review processes and practices

Clients who have prior systems can look at what they have and confirm that it’s the structure they want going forward. This may be a juncture to improve on that structure so that they'’re able to create reports that are the same across the board.

They can consider introducing best practices at this point. They may want to modify business workflows to gain efficiencies, to improve reporting or to redefine levels of users that better reflect security needs.

With the guidance of the RMIS provider, clients can validate that this is still the best way to structure these elements to manage the risk management side of their business.

We remind our clients: You'’ve bought new risk management software for a reason. Take this opportunity to address the areas that were disjointed or weren't working well; then modify the system’s structures to remedy them.

The Management Question

Clients often want to know, once their organizational hierarchy is in place, what can they expect in terms of managing it going forward? Our answer is: It varies.

Ideally, the RMIS will have the tools that allow the client to manage and maintain their hierarchy through virtually any event, including:

  • A merger with a new company
  • Expansion and added locations.
  • Acquisitions and diversifications

All of the scenarios above require a hierarchy that is flexible enough to support the client throughout any modifications to organizational hierarchy and reporting structures. Such flexibility will provide:

  • Seamless integration from one set of data sources to the new hierarchy
  • Automatic data loads, with little or no manual intervention
  • Functionality that keeps all data in sync with whatever their systems may be.

Whether it'’s an easy drop and drag to move their structure around, adding new locations, or expiring locations that are no longer needed, the hierarchy must be designed to make these updates automatically for them.

The goal is to take the manual component out of their jobs. They can focus on making informed decisions based on reliable information to support decision making, without having to focus on vagaries of data or maintenance of the system.

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

RMIS Guide

Jun 17, 2013

 | Originally posted on 

Subscribe by Email