Buy vs. build: the debate over insurance software never ends
Insurers planning for a new technology system have always been faced with one fundamental question: should they buy a packaged system from a vendor or build the system from scratch?
This applies to many types of systems: policy, billing, and claim systems; underwriting solutions; portals; CRM; you name it. In the early days of computing, it was an easier question. There just were not that many purpose-built solutions available for insurance.
Today, it is dramatically different; mature solutions are available for almost all parts of the insurance business. But this still does not make a “buy” decision a slam dunk. Consider the fact that there are now many hybrid approaches, where you purchase some components, then leverage them to build out a custom solution.
In the past, each insurance company believed they were unique, and that made it difficult to find a solution. It used to be that many insurers thought their combination of processes, products, channels, and other factors were so unique that they demanded a custom-built solution for most business areas. No vendor could possibly accommodate all the workflows, exceptions, and variations of their business.
Is it worth your time?
But times have changed. Most insurers are unwilling to spend the time, effort, and money to build systems from the ground up. The market is moving too fast.
And they realize that they may not be quite as unique as they thought, after all. In addition, many systems in the market now are highly configurable, designed with extensive APIs, and allow for implementations that are much faster than the build scenarios.
With that backdrop, here are a few considerations for making the buy versus build decision today:
- Solution availability
Although the market is flooded with solutions in some areas, there are some lines of business and business areas that experience a limited availability of good solutions. Underwriting systems for complex commercial or specialty lines come to mind. Solutions in general for Excess & Surplus or large commercial may also be limited.
In these situations, there may be no choice but to build. Fortunately, even when a build is required, there are likely to be business process management and/or low-code development platforms that can include rapid application development to accelerate the build.
- Integration required
The level of integration between possible new systems and existing systems is one of the primary considerations when evaluating buy versus build. In the past, a complex or unique set of existing systems would favor a build approach so you could build the custom integrations.
In today’s world, most modern solutions have extensive APIs and, in many cases, are already pre-integrated with other solutions in the marketplace.
- Unstructured data requirements
Automating an area of the insurance business is not just about transactions based on structured data. The unstructured digital data in the form of documents, e-mails, pictures, voice annotations, and others are just as important in the workflow.
These must be integrated with the transactions so that the business users can conduct their business in a natural manner. Packaged solutions do not always manage the unstructured data and workflows well, although some are pre-integrated with solutions designed for that purpose.
- Staff capabilities
Many applications are migrating to more “configuration aspects” which provide for a different set of capabilities to maintain the application. There will also be programmer skill gaps – companies need to decide what the best investment for the future is. They need to make decisions based not just on what skills staff needs today, but on what skills will be necessary in five years.
- Future technology investment
Insurers must consider the life expectancy of the solution. With a buy approach, you can receive upgrades from a collaborative group of users. The prebuilt solution gives you the benefit of upgrades and enhancements that come from a pool of users outside your organization. In contrast, using the build approach requires you to continue to modify the solution based on your specific needs.
There is also the fundamental infrastructure element in the case of a buy, and the software company is responsible for the technology platform upgrade (operating system, etc.). With a build, the company owns the responsibility of adapting to upgrades in the technology platform.
This is important, as innovative software developers are always evolving. If you can’t keep up, important integrations might not work, making information difficult or impossible to access.
To make the right decision, you must evaluate various financial implications. Development time, cost, and resource availability are all key factors in determining an approach.
An important question is whether you have a development shop with the capacity to build or if there is a partner you work with that you can rely on for a build. In some cases, the framework of a solution might be available that would provide the capability to build out the solution further.
The net is that the debate over buy versus build is likely to continue in the insurance industry. There is no “one-size-fits-all” answer. Either approach could be the best approach for a given insurer after considering the factors described above.
And for many, a hybrid buy AND build approach may turn out to be the best solution.