Should a technology solution be custom built or externally sourced with a commercial, off-the-shelf option? This is a fundamental question across every business, but is currently especially pertinent for the insurance industry, given the focus on new providers of insurtech. For those heading up technology, the objective is to provide systems that bring value to the business. This could mean buying in software written by third parties, building a system from scratch, or a mixture of both.
In a recent Insurance Nexus webinar entitled Raising Insurance Customer Engagement, Monika Schulze, Global Head of Customer & Digital for Zurich Insurance admitted that traditionally insurers have developed everything themselves. She recognises the approach is now changing: insurers are much more open to explore third-party solutions. In her view, many insurers no longer have the expertise or technical resource to meet all the changing needs of their customers.
How do you decide?
So, there is definitely more acceptance in the insurance industry that ‘build’ is not always the default position. As a software vendor, we are acutely aware that there is no single answer. What is important is that the question is given the attention it deserves. So where do you start?
Identify core business requirements
First and foremost decide on business requirements. Validating that a business need exists and providing an estimated return on investment or proof of essential added value for customers is the first imperative.
Validate the need for technology
The decision should never be about the technology, it should always be about the business need. Too many organisations choose an enabling technology before identifying a legitimate business objective. Having identified the core business requirement initially, the next step is to honestly examine the existing technology and agree whether change is needed.
Identify technical architectural requirements
The business objective should inform the choice of solution. There are many considerations that will help decide the most appropriate technology. These include the Information Security (IS) strategy needed, the operating system in use, and the preferred architectural framework such as J2EE or .NET. Alongside these, there is the question of flexibility. Will there be a requirement to re-use the business functionality across multiple products or for cross-channel accessibility? Is there a requirement to frequently flex product design, pricing, or business rules? Will there be multiple third party or internal interface requirements?
Examine existing solutions
At this point, the need has been validated, a commercial business case has been agreed, and both core business and architectural restrictions have been identified. Leaders should now take a good look at existing systems. Is the answer already in place elsewhere in the business? Thinking in silos has long been a weakness in the insurance market and it is not uncommon that different parts of an organisation are not aware of what systems exist elsewhere.
Review in-house skills
Is one of your business areas is product development? If not, there is an extremely high probability that your operations and maintenance technology resources do not include all of the skill sets necessary to design, develop and implement a successful solution from scratch.
Does a third party solution fit your needs?
Ultimately, it comes down to a straight comparison between the in-house capability and the most appropriate third-party solution. The very comparison itself is painful and time-consuming but, without putting in the hours, the correct decision cannot be made. Even if there is a strong in-house team, it is still worth measuring internal capabilities with what is available externally.
However, despite the steps above, or sometimes even missing many of them out, decision makers often focus on the significant short-term cost differences between a custom in-house solution and an external solution … and they decide to build their own to ‘save money’. Decisions affecting the future viability of a business should never be made on short term cost savings alone.
Financial considerations of ‘build’
Leaders who decide to build their own solution often overlook the following expenses:
Delivery of an in-house solution is often subject to long unexpected delays: building proprietary software takes a great deal of time, frequently involving re-inventing the wheel. A specialist technology company typically has an off-the-shelf solution, developed over years, ready to deliver immediately.
Although the business leaders may feel they already have appropriate in-house skills, they often underestimate a) the cost in time and resource of building proprietary software, and b) the opportunities lost while the resource is heavily tied up on one project. They also tend to underestimate the long-term challenge of maintaining the in-house skill levels needed to maintain the system when it’s built.
Lack of technical proficiency
If you do not have a strong enough software team with the necessary skills, it would be wise to pass on the opportunity until you do have such a team in place. Third parties that are dedicated to providing one piece of software are more focused. They have thought of things that you won’t because they have more resources to spend on thinking of those things.
Building custom software in-house can ultimately deliver a significant return on investment. By developing your own software you get exactly what you need: off-the-shelf software is designed with different types of user in mind, your software only needs to be built with you in mind. And if you discover later that you need something, you can choose to add it yourself instead of waiting for a third party to do so. But you need to invest significant money and time to ensure that you have the right resource in place both now and well into the future.
Key considerations of ‘buy’
When assessing external solutions, these are probably the three most important considerations. I have not put price on this list as cost should only be considered AFTER you have decided the system can deliver. My top three considerations are as follows:
How flexible is the solution?
Many of the new generation solutions offer both flexibility and self-sufficiency. They allow you to modify or grow quickly and easily; they offer the functionality for you to become self-sufficient. Without this flexibility, you could potentially be held to ransom by the software vendor if the vendor’s willingness and ability to deliver the enhancements you need ends up dictating the speed and cost of business change.
How close is the business fit?
Third-party technology generally addresses many of the requirements but very rarely every one. The question is: how long and how expensive will it be to plug the gaps?
How does it fit with your overall technology landscape?
Most companies need the ability to integrate new software and processes with pre-existing internal systems and with a wider set of APIs from other software providers and business partners. A third-party solution that does not offer this effectively will hinder your efficiency.
Always consider both
At the risk of stating the obvious – you should always consider both options.
Buying when you should have built incurs the cost of learning how to use the third-party system, and only later discovering that you made the wrong choice.
Building when you should have bought risks the cost of countless hours of development time wasted on something that ultimately fails to deliver the desired results.
As stated at the outset, there is no quick and easy answer. The only definitive conclusion is that both build and buy have to be considered in equal measure. Only then can you make the right decision for your business.