When insurance companies are in the process of modernising and renewing their business processes due to customer expectations, they often focus on the business requirements needed to keep up with developments regarding automation, efficiency, pricing, transparency, etc. To achieve this, systems must support quick and agile development and it should be possible for anyone to configure any solutions.
However, development in the insurance industry is not only governed by customer needs or the requirements of business and management. The insurance market is tightly regulated and a lot of requirements from different authorities should be considered as well, while country specific adaptations must also be taken into account in the systems.
You can often choose between two different options when considering whether to modernise or renew your business processes: further development of the legacy systems or a comprehensive renewal of the system environment.
A business case for choosing the first option is relatively easy to set up. You know what the maintenance of the legacy systems costs annually and you can estimate what it would cost to tear up workable solutions and build a lot of new functionality in or next to the legacy systems. It often becomes clear however that it has not quite turned out as planned and as a result you have at least the same costs as before plus a little more, along with extra complexity and vulnerability in the systems.
The more attractive alternative, and perhaps the easier one to present to decision makers, is to look at a completely new system environment / platform from scratch. How difficult can it be? Forget all the legacy and start with something completely new. The price tag for the new system environment is obtained relatively quickly, you get a plan for the whole project based on "experience", and then you can relatively quickly decide what is most profitable according to the "business case". But only if you stick to the system standard solutions.
What you often forget to bring up when presenting the solution to decision makers at this stage are "the small difficult things" and "the details":
- co-existence, the same functionality needs to work in both legacy and the new system for years,
- the extent of data and process migrations are usually not planned at this stage,
- what to do with the historical data from the legacy systems (hopefully the legacy systems will also be closed at some point),
- the regulatory requirements and the specific country adaptation needs.
Although these things above and many others are important to keep in mind, I will go into a little more detail on the so-called country adaptations, which I am personally well acquainted with both from a process and technical point of view, and which are often only considered at too late a stage during the renewal of projects.
It's generally said that when starting a comprehensive renewal, one should not see how the legacy systems work (even if country adaptions work in the legacy systems). You should also not go into details when planning how insurance processes should be developed or which systems would be most complete. Instead, you should focus on whether the system supports the main requirements for customer experience and has standard functionality for insurance and claims management (why should it not, otherwise it would not be called an insurance system...).
It is true that the decision-making process would be much more complicated if everything had to be taken into account, but many problems can be avoided at a later stage of the implementation process if you have an overall picture of what the system should support, all the mandatory requirements, and the small details of insurance, country adaptations and industry-specific processes and integrations in the system environment, as well as which laws, regulations and directives should be complied with and of course how the insurance industry in Finland and Europe will develop in the near future.
By country adaptations of the insurance industry, I mean not only integrations to the population register, the banks and a lot of other simple integrations, but also those that differ from the functionality in other countries, which in some cases may seem to be only small deviations from standard functionality but later show themselves to be relatively complicated solutions. Such complicated adaptations include the handling of traffic and occupational injury insurance, personal injury management, certain reporting and to some extent invoicing and accounts receivable.
These more complicated solutions and processes, those you do not think about when envisioning the company's future or planning your customer experience processes and which vendors have convinced you both that "it's just configuration" as well as on what information management makes decisions, can in the worst case scenario be impossible to get to work in the system, at least without making bad, unsustainable solutions with a huge amount of money.
Actually, these country adaptations are not that complicated, as all companies have working solutions in the legacy systems. Sadly, everyone has solved them in their own way and since they were not made with the future in mind when developed, they have often led to very complicated and expensive, but somehow workable, solutions.
The insurance systems on the market today are mostly large, standardized systems with lots of functionality common to the insurance market in Europe and even the whole world. This is a good feature when you start your project, as it provides ready-made and simple solutions with lots of out of the box functionality, but they often come with problems as well.
Country adaptations can seldom be configured completely and perhaps to some extent it is a matter of functionality, calculations and integrations, but in many cases, the whole process is affected, and you must bring in many changes in the standardized system core without dividing the whole. Another issue is that you can´t choose whether you should implement the country adaptation or not, at least in the same way you can with your own adaptations.
This means that this system environment, without knowing and planning it from the beginning, becomes a very complicated whole. We can say that the country adaptations not only scrape the system surface, but for the most part, they go deep into the basic functionality and thus affect both the system core as well as the surrounding systems and integrations.
Whether it be country adaptations, country layers, or country specific functionality, I think all insurance companies at some stage of their development process regret that they did not dive deeper into these processes or take them seriously at an earlier stage.
All insurance companies have the same challenges. They all develop and pay huge sums for their own customer and country specific solutions (in fact, it is the owner or customer who pays). Some system vendors, who also invest in these adaptations, have in certain cases realized that the country adaptations/country-specific functionalities are expensive investments and not profitable for the system provider if it´s developed for only one insurance company.
But is this really that complicated? Probably not, yet despite that, the insurance companies again and again choose large, complex standard systems to develop their own complex solutions even when there could be alternative methods and solutions that could more easily and cost-effectively be put in place.
To avoid these mistakes, you should have a very deep but at the same time a very broad knowledge of all parts of the project and phases, not take anything for granted, and especially consider from the beginning the mandatory country adaptations and legal requirements that do NOT exist as fully developed components of a standardized system.
In today's fast-paced world, most companies undergo one or more major transformations each year, driven by increasing globalisation, competition, and ...
Read moreHealthcare is in crisis in many countries, and Finland is no exception. When resources are limited, and the demand keeps ...
Read moreFor business and IT leaders, preparing for a business cycle shift means ensuring the right strategic target state and ambition-level ...
Read more