Let’s get right to it. This is the age of software. Almost every business is turning to software to improve quality, speed, and price. Software is the differentiator, and a bad system will beat good people…every time (shout out for another Demming quote). This is especially true in risk management, insurance and the claims space where I work and live. But, instead of people delighting in the new efficiencies and tools, many are flat out suffering as a result of a poor claims system implementation.
The 8 Ingredients for a Successful Claims System Implementation
As your company migrates to a new system, keep in mind these 8 ingredients to ensure your claims system implementation is a success.
#1 – Choose Correctly – Popular Vs. “Right For You”
The first place to start is with system selection. Choose software that is right for your organization’s needs. Every claims department has a unique profile. Consider factors such as:
- the kind of exposures handled
- the volume of pending and new claims
- the number of users
- intake and coverage review processes
- the degree of outside access
The interplay of these factors determines what is right for you. Specific questions should be answered in detail, such as:
- Are we a quick turnaround processing shop?
- Is each claim a complex project that involves sophisticated tools of investigation and analysis?
- Is speed our primary objective or is it critical that we get every aspect of coverage, investigation and legal analysis correct?
- Are we a self-insured organization about to purchase a commercial carrier claim system? If so, why are we doing that when there are systems that cater to the self-insured?”
These are important considerations. The choices of “off-the-shelf,” custom tailored or home-grown systems should be made carefully and depend largely on your organization. The smoothest implementation of the wrong system is just a giant step backward.
#2 – The Right Project Team with Sufficient Time
The challenge here is that many organizations with a need for a new system are hampered by a lack of time. And, the lack of time is often caused by a bad system. If your internal point-person and others responsible for working with developers are pressed for time because they are working a claim load at 120% of capacity, the project may fail. The project team needs sufficient time to think critically.
A new system offers great opportunities to put a superior process in place and support the process with tools and information to guide claims adjusters. A team pressed for time may simply make decisions to “get through it.” Or, they may not have adequately addressed the details needed for developers to design the best solution. Some companies hire outside parties to assist in this important area because they lack the white space to spare key people for prolonged projects.
Perhaps equally important is forming a team that has input from underwriting, marketing, accounting, and risk control. Creating a cross-functional team will ensure that the system’s inputs and outputs spread the advantages across the company.
#3 – Internal Staff With “Know-How”
In addition to the time resources needed, the internal team must have a near mastery of the company’s claims department. This is one of those cold and harsh truths. If the lead person does not fully understand how the claims system must operate efficiently to serve not only the claims department but also underwriting, accounting, subrogation, litigation management, and the agent network, the system is not going to live up to expectations.
An implementation is challenging for even the most experienced and knowledgeable claims professional. The sheer number of issues to be adequately addressed is daunting. The depth of detail of many of the issues is enough to make you wish you got into rocket science. A good project team must have the deep knowledge to see the project through to the point of universal success.
#4 – Internal Buy-In
Knowledge and time are necessary but not enough. The internal group responsible for the implementation must be fully committed and hungry to go through the process. The “buy-in” is necessary because perseverance can only happen when the person quarterbacking the implementation believes in it. System implementations fail when the lead person simply does not see the benefits of a new and improved solution. There is no faking your way through a project like this.
#5 – A Software Vendor That Understands Your Specific Business
It’s not just the internal challenges that can sink your implementation. The project manager on the vendor side must take painstaking steps to fully and completely understand the industry, the business, the people and processes that surround the contemplated new system. This requirement is not an easy task. Everything counts here. The vendor should perform a thorough review of the organization’s departments, processes, forms, and templates.
Conversely, the software buyer must be willing and able to educate the vendor by highlighting the fine grains of distinction that separates their business from the generic. The process takes time and should not be rushed to meet a deadline.
#6 – Project Momentum Management
Some projects are truly massive and take a long time to complete. But if a project lingers too long with little or no direction or progress, the chances for failure rise. Multi-year projects are not uncommon. If they involve the focused effort of 10 to 20 key people, staff turnover is a real risk.
System implementations can be like surgery where you don’t really know what you have until you open things up and look around. For that reason, initial planning and mapping can be helpful but will not necessarily prevent issues of scope-creep, indecision, miscalculations and delays.
#7 – Consider Recent or Future Business Changes and Direction
Was the goal of the new system to solve yesterday’s problems? Be sure the system being implemented has the capacity to move the company forward. Some implementations replace an old data storage system with a new data storage system that holds more data. A small step forward but not exactly the system of the future. Rethink the workflow and business processes that are currently in use.
Do this before you imagine your new system’s features and not after. Then, you will have the freedom to create and implement a high impact system for the business you want to become instead of the business you were 5 years ago.
#8 – Think Deeply About the Proper Scope and Limits of the New System
Should this system be all things to all people? Or, do we unbundle and create the perfect claims system that integrates with the policy system? Is it more or less problematic and secure to share this platform with external users?
There are many important scoping questions that should be thought out in light of what your business needs. Everyone talks about scope, but few truly know how to contain it properly. Limits of the project cannot be chosen arbitrarily. It’s not helpful to build just the front half of a car. If that one extra module in the system will complete a workflow loop so that there is a common location for related information, by all means, build that module into the system.
A good example here is the implementation of a coverage analysis module inside of the same claims system that holds information about the facts of the claim, the claim notice and the policy details. Inclusion of this module inside the claims system eliminates needless duplication.
Conclusion
System implementation is delicate. The project’s requirements should be defined clearly while also leaving room for flexibility. Most systems end up requiring far more customization in both number and degree. It is important to develop a strong relationship among the people involved. Your RFP may prove out who’s best at a beauty contest, but your company requires accurate function and elegance.
