Not too good to be true: 7 considerations to successfully implement a new tech platform
Klaas Dijkstra - Chief Information Officer, QBE Asia
New technology alone won’t magically solve anything. Non-technology issues and challenges, like how companies are organised and their openness to change, are equally as important to successfully implementing any new technology
Recently, I was pitched a solution to a specific problem by an up-and-coming insurtech. The salesperson, along with their solution architect, asserted their proposition would solve a bottleneck we had been challenged with for years, costing a mere few thousand dollars, and taking just two weeks or so to implement. That’s impressive, I thought.
Except the solution didn’t fulfil its goal. It only solved a minor part of a much bigger issue, and worked in silo from the rest of our core system — the product we were trying to improve was high in volume yet low in gross written premium (GWP), hence it remained quicker and cheaper to manage manually. What we needed, the salesperson added, was a far more sophisticated end-to-end solution, which would cost QBE several hundred thousand dollars more to implement over several months. The original pitch was simply too good to be true.
This isn’t the first time I’ve experienced such a scenario. Nor will it be the last. That’s not to say that all insurtechs behave in such a way. On the contrary, many are highly skilled, collaborative, and offer genuine value to businesses like ours. As the CIO of a large insurer in Asia, I frequently entertain such conversations. An important part of my role is to continuously seek out new solutions, talk to insurtechs about what’s currently available, and unearth what might soon emerge.
The experience also contradicted the findings of a system comparison exercise QBE conducted in 2022. The venture drew a handful of conclusions. Namely, replacing a legacy system with a brand-new one isn’t magically going to resolve the issues associated with the older platform. Most of the time, these aren’t solely technological problems, and typically stem from process and product complexity.
As an insurance company, our role is to assess risks and come up with an appropriate price for these. We should therefore invest in ‘systems of intelligence’, which can assist the insurer in more accurately and more quickly assessing these risks, and price them accordingly. When implementing new technology, there are also a number of practical considerations — many of which aren’t technology related. With these core findings in mind, here are seven learnings CIOs and other insurance senior executives should consider when contemplating a new system.
1. Establish the problem you’re trying to solve
Before implementing any new technology, you must be crystal clear on why you’re embarking on such a venture. Specifically, you must define the business outcomes you want to achieve; the business strategy you will execute to achieve these outcomes; and any existing problems and constraints that need to be removed in order for them to successfully achieve their goals. Based on your answers to these, you can decide whether a new system is required.
For instance, at QBE our goal might be to grow our GWP in the SME space. The strategy to achieve this could involve new products and packaged risk solutions for digitally native partners and customers. However, to realise this strategy, we will need to ensure the right capabilities and skills are in place.
2. Simplify the product blueprint
For legacy insurers, adapting and amending processes and products to meet the evolving needs of customers is typically highly challenging. That’s because when we try to amend something, change must usually happen in multiple places, and the whole exercise becomes highly time consuming. If we don’t address this complexity, the likelihood of new technology succeeding is minimal.
Fixing this issue could involve structuring products in a modular manner. By this, I mean have a suite of risk coverages in a specific risk area, with each coverage having its own wording and pricing, rather than have just one or a mere handful of policies in this field. This way, policy holders can remove or add coverage to meet their needs and price points, an approach legacy insurers aren’t currently set up to facilitate. Not only would such products meet the specific needs of customers; they could be compiled more quickly due to their modular nature.
3. Create a country-agnostic repository
Another challenge hindering the speed and delivery of new products is how different markets operate in silos. This is typically due to multiple factors, including regulatory requirements and market conditions. The preferences of distributors and customers often leads to in-market product differences as well.
Creating a repository of coverage modules, which are country agnostic but with the option to add nuances in terms of wording and coverage, will enable insurers to roll out polices across an entire region, quickly and at scale. It will also make these products more cost-efficient for insurers as well.
4. Work to a realistic schedule
There are several other foundational design questions that need to be answered
before we start any technology implementation work. The reality is that in the vast majority of cases you’re not building a new insurer from scratch, and therefore the complexity of your existing business needs to be planned for and designed for carefully. This usually involves defining scope and a delivery plan, creating a product blueprint (as mentioned above), and devising a tech operating model. It also involves establishing the solution architecture, as well as drawing up a product migration strategy. Planning and designing can take months to execute when operating across different countries, channels, and customer segments.
The next stage is the development of the minimum viable product (MVP). Here, we create a base platform, set up QBE, partner and user accounts; configure the product, test, and prepare to go live. Simultaneously, the business conducts change management activities to prepare for the new product. This phase typically can take about six to eight months to complete for larger, more complex technology initiatives.
5. Simultaneously run the old and new platforms
There will be an interim period during migration where you will need to maintain both your old legacy system, and your new system. As a result, IT Run costs will very likely go up (you will need to pay for the old system and the new system during this interim period). Furthermore, the IT Run cost for the new system will likely be higher as well, as new technology licenses are usually priced as a percentage of GWP, whereas the license costs for “legacy” technology tends to be a fixed amount. In addition, the skills required to develop and maintain new technology also tend to be more expensive.
To justify the cost of a new system, insurers need a GWP-driven business case to fund set up and implementation costs. New GWP can be driven by new channels, products, and technology — customers tend to buy additional policies that are driven by these — vis-à-vis current GWP, which is supported using existing capabilities.
6. Consider multiple platforms and vendors
Tech platforms need to support a multitude of capabilities, use cases, and scenarios — despite the industry’s best efforts to simplify these. Newer platforms, provided by tier 2 vendors, tend to be optimised for specific business lines or channels, and usually aren’t able to provide all the capabilities that a larger regional insurer like QBE Asia requires. Tier 1 vendors generally offer a wider range of capabilities, but at a much higher price point.
In light of these inflated costs, you could switch from building a single, all-encompassing platform, and instead run a few fit-for-purpose platforms that are optimised for specific products, channels or market segments. Doing so could greatly reduce IT spend. For example, you could run your Consumer and SME lines on a new tech platform with a ringfenced team and lower expense ratio overall; while simultaneously keeping your higher GWP value corporate and speciality lines, which require higher levels of human touch on existing core systems.
7. Embrace change
Perhaps the most significant changes needed to successfully implement a new platform relate to the way companies are structured, as well as the culture exerted by its staff and leadership. Typically, teams loose speed and agility if they are not empowered to make decisions, and decision making needs to go both up and down the chain. Notably, the inability to change ways of working can significantly hamper the capabilities of any new technology. The key business outcomes that new systems aspire to achieve — including improved speed-to-market and lower cost of change — requires better, more seamless collaboration, and more nimble ways of working. These are arguably more related to how companies and their teams organise themselves than any piece of technology.
To capitalise on the opportunities brought about by new technology, teams must be open to new ways of working, and accept that implementing a new system is a long-term venture involving much change. Ultimately, the rolling out of new technology isn’t going to magically solve anything on its own — non-technology matters are equally if not more important to successfully implementing any new tech platform.