I had an opportunity to talk to an independent consultant who has worked for some time now with insurance companies in Japan. He specializes in new technologies involving calculation engines. His experiences give some insight into the reasons why these emerging technologies are being adopted relatively slowly, and may also give some insight as to the pace at which these technologies may generally be adopted throughout Asia.
The standard processesMost insurance companies’ administration and illustration systems rely on mathematical IT or actuarial resources to provide input for new products and product revisions, as well as IT staff to make appropriate system changes.
Generally these systems use a table-based approach to derive premiums and projected values. This approach requires significant disk storage, particularly for administrative systems that have to hold historical data dating back many decades.
The process of generating these tables is generally entrenched in the product development cycle, and in many cases involves a number of people using various skills and techniques to develop models in a wide range of tools such as Excel, Delphi, Foxpro, and other programming languages. The time to market depends on, among other factors, product complexity and number of systems. In some cases, the speed also depends on current staffing levels because some of this knowledge is lost in staff turnover and personal toolset preferences. In this process, there is a distinct division of responsibility: the mathematical resource for the tables and their accuracy, and IT for their deployment and ultimate usage.
New technologies In recent years a number of vendors have released technologies to support deployment of new products and product revisions to many systems without the need to generate large and complex tables. These technologies also allow for a single centralized repository of calculation and business rules using a single software source – thus capturing all the intellectual property in one place and reducing the complexity of having to support multiple skill sets. The skill set required for these technologies is potentially a combination of traditional skills and new skills.
Challenges The adoption of these technologies requires a mindset change, not only in actuarial departments (product development) but also within IT. The business benefits are not always apparent to the individuals using the tools, because their focus generally is on “build” activities.
The definition of product components is generally done in a GUI interface, which requires different skills than Excel or traditional actuarial programming languages. The result is far more visual, and testing and debugging are far more interactive. So there is a learning curve, but it is usually short.
On the mathematical side, the main problem in introduction of these technologies is related to business processes (and software) that have been entrenched for many years, as well as the reluctance to change, which is particularly common in organizations where responsibility for parts of the process is being shifted.
On the IT side, the main challenges revolve around the interfaces and the need to consider the impact and efficiency of replacing table look-ups with calls to a third party product, not only for simple calculations done in an “online” kind of scenario, but also for full policy projections and usage in a batch type of environment. The challenge here is to design interfaces that are more generic so as to reduce maintenance and enable cloning in the event of new requirements, not simply to use these technologies as a plug-in replacement for table look-ups, which could lead to inefficiencies and negate the value of the new technologies.
My thoughts There is no doubt that these new technologies will be adopted – however, implementation needs to go hand in hand with a number of business considerations. Consultants should be aware that standard implementation processes may need to be tailored in light of local business and cultural practices. In the same light, business value may have to be demonstrated in alternative ways.