Use Software Accelerators to Fill That Elusive Twenty Percent

In the modern computer era of the last several decades, industries including auto, banking, and, of course, insurance have developed and re-developed their core processing systems many times over. That often leads to a tipping point when companies must decide whether to continue to invest in older systems or move in a different direction. That’s when replacement projects to upgrade or replace decades-old systems – now referred to by the more palatable moniker of “modernization projects” – are put into motion. The problem, however, is that these projects are not as-is replacements of outdated systems, rather they are efforts at building completely new software keeping in mind the new business strategy, workflow and processes of the insurer.

As insurers and other enterprises embark on these modernization projects, they begin with an inception phase where a high-level analysis is performed and the all-important decision of buying a solution or building a solution is generally made. These decisions are made based on an amalgam of factors, including overall cost, time to market, technical and business resources, and several other considerations. Whichever solution is chosen, it is more often than not based upon a high-level analysis that relies on the 80/20 rule, so that whatever build vs. buy decision is made is based on the presumption that eighty percent of the required functional requirements will be met.

In the next phase of the project, a deeper dive mid-level analysis, combined with the creation of many small teams, results in the identification of the necessary integration solutions and specific functionality solutions required to support certain features of the new software. Here again a decision is made on whether to buy a solution or build a solution for a specific functional feature. The schematic below is a very simple example of the this recurring decision-making process:

However, many insurers make the mistake of assuming that they need to completely fill that twenty percent gap in functional requirements that the larger platform won’t meet. They therefore assume that their decision process for a particular feature or function to address the twenty percent gap must be to buy a product that usually has more than they need, and that often leads to unintentional – but very real – damage to the overall project. There are many reasons for this, but the primary drivers usually are:

• A deep analysis is not done on products that address a specific solution
• The cost of the decision is often viewed as a non-factor as it is often a miniscule part of the overall modernization budget
• The product(s) chosen to address the required solution have more features than are needed
• The product features of most value still need to be tweaked to meet the functional requirement.

The following schematic is illustrative of the above points:

But there is another way. For specific functions and features, insurers should consider using “software accelerators.” Accelerators are created and maintained in-house, are typically more bareboned than a product, and may or may not be a complete solution in and of themselves. But they can provide insurers with an effective and less expensive way to fill the functional gap. And while cost may not be an issue at this stage of a modernization project, any accrued cost savings can be utilized in building a more full-functioning solution from the initial software accelerator when and if that becomes necessary. The benefit is that accelerator solutions are often more aligned to the insurer’s needs than general solutions in the marketplace and can be easily customized to provide a specific functional need without making a larger investment of time, money, and resources in an off the shelf solution that will never be fully utilized.

If there is a downside to software accelerators, it is that such an approach has the risk of turning into a maintenance problem. However, the money spent on any accelerator maintenance is often far less than the licensing and/or renewal cost of an off the shelf product. And even if the costs were somehow equalized, using software accelerators written in-house provides an insurer with a more precise functional solution than any generalized solution purchased from a provider possibly could.

By way of a specific example, it’s often the case that in the process of building analytical and reporting solutions, insurers tend to spend a lot of money and effort in acquiring and implementing an ETL tool that ends up being underutilized – often just for data ingestion and metadata. In a similar vein, most core systems modernization efforts in insurance, financial, heath care include purchasing full-function products that they use to just do specific tasks like master data management, auditing, and data quality. In any of these scenarios it would have been worthwhile to evaluate the pros and cons of creating in-house accelerators to provide these functions.

Using software accelerators is an idea that insurers may want to consider. Among other things, software accelerators have the potential to allow insurers flexibility and control over that elusive twenty percent of functional needs without over-spending and adding complexity to their technology environments. In the end it might be a better way for insurers to optimize and manage their software portfolio, while not settling for an overkill product solution where most of the functionality is never fully utilized. For insurers in a race to modernize to stay competitive, that’s not a bad deal.

Originally published in
Insurance-Canada
Read the original article here.