As the blueprint for the entire RMIS, a workable hierarchy:
We find that most organizational hierarchies include:
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 |
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:
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:
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.
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:
Clients who have prior systems can look at what they have and confirm that its 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 systems structures to remedy them.
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:
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:
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.