By Leo Corcoran, CEO
March 27th, 2019
Last week we discussed the roadblocks we have seen customers face when adopting a core software solution. To help you avoid repeating these mistakes, I have some practical advice for you and your team to consider before jumping into a claim transformation project.
Implementing a Core Software Solution
To avoid these pitfalls, I have outlined a checklist for you and your team to follow as you embark on this journey:
- Before going to market, review your existing business processes. Update them, change them without software, and get your internal teams used to change. Get them in the right frame of mind to think outside the box (that they have most likely lived in for a long time!).
- Do not develop requirements in a vacuum. Most requirements are built from the ‘outside in.’ We’ve seen businesses trying to redesign their existing system by customizing the core, without clearly understand the capability of the core product.
- Spend time reviewing some of the core products available in the market to get an idea of the capabilities you would like your system to possess. If you don’t, you risk being cornered by your preconceptions, without investigating the real capability of the software you are about to purchase.
- Do a Proof of Concept (POC) with your preferred vendor solution. Do not create an RFI/RFP before you do a POC. By investigating a range of capabilities that can better position your RFP/RFI to get a complete picture of the range of software available to you, you to avoid the vacuum.
- Understand the product you are about to implement from the ‘inside out.’ Do extensive training sessions, so that when you look at your current processes and reflect on how you want to change them, you can review them in relation to the core product. Can the core be configured to satisfy this need? If so, you can reduce the amount of custom code you will implement in the long run.
(At ClaimVantage, where there is a requirement that makes sense we try to include it in the core. We recently had a requirement from a customer to automate payment adjustments. We discussed this at a Customer Focus Group and collectively agreed that it made sense to implement. The big benefit for everyone is that it was implemented in the next product release and was then available to all customers – not a bad deal!)
By using this approach with our customers, we’ve successfully pushed back and led the customer to implement a claim management solution fit for the InsurTech revolution.
The Benefits of this Approach
In a recent implementation, we worked closely with a customer who wanted to implement the core product due to budget constraints. We successfully demonstrated that if they implemented the core product they would:
- Reduce their overall maintenance costs,
- Be able to take the latest upgrades with minimum effort, and
- Avoid any legacy software issues.
We started the project by delivering a POC, based on a sample of their lines of business. We trained their internal subject matter expert (SME), who was very open to learning the product and clearly understanding its capability. After some weeks this company was running claims through the system in parallel with their existing legacy system, allowing them to review and compare the outcomes. At this point, our team met with theirs to conduct a gap analysis, which resulted in some suggested core enhancements and business process changes to better align with the core product.
The next stage was to have one of our Business Analysts (BAs) on site to do discovery with the customer and their internal SME. On day one, the SME produced a list of thirty-two requirements that he felt could not be addressed with the core product. The discovery lasted three days, and at the end of that process, we had only six requirements left. Twenty-six requirements had been addressed through core configuration and some small changes to the business process.
The last six issues were addressed as follows:
- Three were met by small core enhancements.
- Two were met by integrations, which are typical of all implementations.
- The last one was met by extending the data model with some additional data elements to meet their specific reporting requirements.
Core software does require a level of compromise, but with a good vendor partnership and upfront communication, it is possible to work through the initial resistance to change.
In my experience, the key elements to software delivery based on many years of the good, the bad and the ugly are:
- Extensive training to learn the product from the ‘inside out’,
- Test run the core product using a well-defined proof of concept with clear goals and objectives that can be measured, and
- Don’t mess with the core product. Use it to the best of your ability before even considering a layer of custom code.
The benefits of going down this route, go beyond the actual software delivery. If done correctly you will have gotten your teams used to change and in a better place for the next project. You will save the company money by not having to reimplement and regression test all the custom code you built because you could not change your processes. And last but not least, you will not have any more legacy systems which is key to staying ahead of industry trends, keeping up with regulatory change, and delivering a better customer experience.