IT PAYS TO IMPLEMENT TECHNOLOGIES THAT ARE VERSATILE ENOUGH TO PLUG IN TO OTHER SYSTEMS. THE INSURANCE MARKET IS BEGINNING TO SEE THIS AND MOVE AWAY FROM A DEPENDENCY ON LARGE PROPRIETARY PLATFORMS. BUT WHAT SHOULD YOU LOOK OUT FOR WHEN CHOOSING A NEW VENDOR FOR PART OF YOUR ACTUARIAL SYSTEM?
‘One-size-fits-all’ software solutions are increasingly being avoided by insurance companies, who are keen to offer their teams flexibility: to work in the manner they deem as fit and cost-effective. Coupled with well-defined reporting protocols, this results in more powerful management information and efficiency.
We believe there are three important basics to get right at the start of the implementation process, which will help everything else fall into place.
Don’t tie yourself into supplier-led updates
If a software supplier, or Software as a Service provider, has a system that works well, then ideally anyone should be able to update it. In many cases it may well be best to get your trusted provider to make changes, but if it feels like the provider are the only ones who can carry out updates, I would question whether this system is really working for your business.
From a cost-analysis perspective, this is probably the single most important requirement for current system implementation. Your system should be run by you. However, as the old business model has previously worked well in the professional software services arena, you are unlikely to get this advice from any system suppliers.
Specify the data requests, but not the working methods
Traditional information transport in insurance companies often includes rigid structures (such as locked-down Excel templates) that must be filled out and sent on. Where this structure is inadequate for the completing actuary, a “sandbox calculation” area might be strapped on to the side. Sound familiar?
Often this highly prescriptive approach doesn’t fit any one team perfectly. Adjustments are made across the company, resulting in a complex web of methods and exceptions that is almost impossible to track.
Requesting set data, and allowing calculations to be performed as the user sees fit, results in much cleaner working flows.
For instance, Application Programming Interfaces (APIs) offer a better route to request standardised data, but leaves methods up to each user. This doesn’t remove the exceptions and method differences, but it does produce clear boundaries of ownership.
Where a system is requesting values that can be arrived at via any platform, the result is cleaner data flow.
Prepare for the winds of regulatory change
The world of regulatory reporting and, in large organisations, group reporting, can often change. How your technology systems deal with this is largely down to the adaptability you have designed into the system at the outset.
Taking a fluid view of regulations, and how they may change in the coming months, years and decades, pays dividends. It can almost be free if implemented correctly at the beginning. Don’t let yourself be caught flat-footed when it comes to reporting requirements.
For instance, when thinking about a new tool and when it’s going to be implemented, consider questions such as:
- what happens if we need an extra data field?
- what happens if we change an external supplier? (e.g. cat models)
- can we update legacy data and will that flow through?
If flexibility is added in these three areas the result is a much more dynamic and cost effective system, which can be a powerful ally in a competitive marketplace.
0 Comments