How to accelerate the market introduction of new variants of insurance products?

Last update: 2021-09-15

The dynamics of business in the insurance market requires decisive, fast and secure changes in IT systems. The market is rapidly changing, often putting insurance companies ahead of a fait accompli. What is more, business growth is associated with the need to cooperate with other entities like subcontractors or insurance companies, which usually requires changes in IT systems.


The situation is so problematic that neither the Legislator nor the Subcontractor or the Insurance Company will adapt to our processes. There is no developed standard, format or information exchange process; it is specific for each of the entities, and we have to adapt to it. In the given situation, three scenarios are possible:

From the point of view of the system, the simplest solution is to impose certain requirements on external entities that will have to adapt to our standards. Unfortunately, usually (unless we have a very dominant position on the market), we cannot enforce such an approach. Internal regulations of Insurance Companies or subcontractors may effectively prevent any changes.

Process unification

Such an approach is used most often, which unfortunately does not mean that it is the best. It consists of the implementation of dedicated solutions for each company separately. It is very time-consuming, associated with unpredictable costs and, unfortunately, often has a negative impact on business that requires very fast time-to-market.


In one of our projects, this approach had a great impact on the dynamics of the business and often blocked the possibility of a faster start of cooperation or increasing the scale, which directly translated into the implementation of sales targets.


What's more, depending on a specific provider (the so-called vendor lock-in), a situation of a sudden increase in development costs may occur, which must be covered by the business. Otherwise, we will stop keeping up with the market.



Implementation specific to each company

Platform universalization

Since the previous two approaches do not optimally solve the problem, the question arises is there another way that will allow non-technical people to make changes to the system quickly (but also safely)?


We have implemented this type of solution for one of our clients operating in the claims handling industry. By building specific elements of the system that could later be reused by a non-technical person to build a workflow for a specific new subcontractor or Insurance Company.


For example, each of the Insurance Companies had a different way of exchanging policy data, therefore we built certain "blocks", e.g.

  • receive data from an FTP server,
  • receive data from an email attachment,
  • map columns to data,etc...

    that could be used, after configuration, by the System Operator. Thanks to this, the client was able to map the workflow of receiving policy data from the new insurance company, using the available elements, without programming support on our part.


    Consequently, we reduced the time-to-market for introducing a new entity to 3-5 days, from the original 3-4 weeks.


    Of course, this solution should not be treated as a holy grail because it also has its consequences (e.g. higher development costs or the need to train staff in the use of the system). However, with the right approach, where these more configurable system elements are clearly defined, the approach results in many added values, such as time-to-market counted in days, not weeks or months, and the predictable cost of introducing changes without the need of programmers support.

    Summary

    Is it possible to grow and react to the market without changing the system? To some extent, yes, but it often leads to the introduction of various workarounds, changes in processes or generates a lot of manual work. The IT system must be flexible, open to changes and resistant to errors. The most agile ones will survive.


    Check how much time and resources you can save by enabling non-technical people to make changes to the platform

    You might also be interested in other articles published in this series:

    Related articles
    Published by

    Technical Consultant

    Krzysztof Ryk
    Contact us

    Władysława Reymonta 13

    50-225 Wrocław