Insurance is a unique industry. Many insurance operations involve complex actuarial algorithms and detailed workflows. This brings many challenges to the IT departments when transforming these functions to applications. Another big challenge is that these algorithms can change frequently, making it extremely difficult for IT departments to keep up with developments in a timely manner.

These challenges often force insurance companies to think about alternative approaches. If the process is internal and there are fewer users, they are usually developed in Excel by the business users themselves. They can update and maintain the applications without any IT support. While it appears to work in many situations, in time several issues arise that cause organizations a tremendous amount of time and effort.

Let’s talk about what makes these applications so difficult to develop and maintain for the IT departments:

User Interfaces with Hundreds of Input Controls

Many of these Excel tools have complex User Interfaces. It is common to have an insurance pricing tool with a user interface consisting of hundreds of input controls spread over dozens of pages. Creating an interface like this in Excel is not difficult for an experienced user. Excel’s grid layout and various formatting features make this a relatively simple process. Using various worksheet formulas and conditional formatting features to create dependencies between input controls is also simple.

But programming this user interface along with its rules for a web application is extremely difficult and time consuming. What an Excel user can develop in days will easily take months to code.

Calculation Algorithms Only Actuaries can Understand

Most of these Excel tools include complex actuarial calculations. Implementing and maintaining these algorithms in Excel is not hard for actuaries. Almost every actuarial department maintains such tools because there are no other technologies in the market with the capabilities Excel offers.

What is simple and flexible for actuaries quickly becomes a nightmare for IT departments. They have neither the experience in Excel nor the familiarity with actuarial concepts to review and understand algorithms built into those tools in order to rewrite them in a traditional programming language. This means that business analysts or consultants have to get involved and create detailed business requirements. Only then can programmers code these algorithms. In other words, we are talking about a process that takes many months, sometimes years, to complete.

Let’s say we went through this process and completely rewrote the algorithm in a platform like Java or .NET. Those who have worked in projects like this know very well that by the time the project is ready to deploy, actuaries will have changed parts of their calculation logic. It then becomes a vicious circle and many of these projects fail while business units revert to using their Excel-based tools.

Thinking Out of the Box

So what is the solution? How can we transform these tools into a more scalable and secure platform than Excel while still empowering actuaries to control their algorithms?

We have been involved in dozens of projects with insurance companies. From small to Fortune 100 level, all of the insurance companies we worked with share similar challenges. What we learned from these projects, we applied to developing and improving our software SpreadsheetWEB.

Develop Applications Without Coding

All of these Excel tools already have user interfaces designed for the end-user needs. They also work efficiently with the underlying calculation algorithm also implemented in the same Excel file. So, why not use it? That’s exactly what SpreadsheetWEB is designed to do. It allows a power user to select user interface (UI) portions of the workbook and automatically convert it to a web-based user interface. It also connects the underlying calculation logic to the UI. The final web application works just like the original Excel tool without the Excel look-and-feel (i.e. grid, menu, etc.). But the web application still looks and works like an application designed by software programmers.

This means the whole application can be developed without writing a single line of code.

Keep Calculations in Excel

The last thing you want to do is rewrite those actuarial algorithms unless they are extremely simple. Otherwise, it will be too expensive and time consuming to update them as the actuaries update their algorithms, which tends to happen often.

There are two approaches to handling this in SpreadsheetWEB. If you are developing an application with user interface, like explained in the section above, software will automatically integrate the calculation logic along with the user interface. Actuaries can update their calculations in Excel and simply upload it to the server. Updated calculation logic will automatically work with the rest of the application without any coding.

What if you already have an application developed in-house and you want to use the calculation logic built in the Excel tool? A common example of this scenario is insurance rating and quoting applications. Many companies use home-grown rating solutions. But the most challenging part of maintaining these applications is to handle changes in actuarial algorithms.

An Excel tool can be deployed and its calculation logic can be exposed as a web service in SpreadsheetWEB. A programmer can access individual cells in the Excel tool to set values and get formula results via generic web service calls. This essentially decouples the actuarial algorithms from the application completely. While the application is maintained by programmers and IT, the actuarial algorithms are maintained by the actuaries in Excel. Updating the algorithm is as easy as uploading a copy of the latest Excel tool to the SpreadsheetWEB server.

Database Integration

Many of the insurance applications are database-driven. In other words, user transactions (i.e. rating quotes, pricing scenarios) are stored in a database. Excel-based tools have a major drawback since there is no centralized database. If a user wants to save a quote, the data can only be saved in the Excel tool itself. This means having each user transaction stored in a separate Excel file, which is extremely inefficient. It also makes it practically impossible to develop reporting applications.

SpreadsheetWEB is also designed to handle this scenario. It automatically creates a database structure to store the transactional data. Unlike Excel, it only stores necessary fields identified by the power user. Otherwise, saving each and every cell in the Excel tool would be extremely inefficient from the database point of view. Hence, SpreadsheetWEB stores only the input fields and select calculated fields identified by the power user. Note that any formula cell in the Excel tool can be recalculated using the input fields stored in the database. This approach makes it efficient with database operations.

Bottom Line

Developing insurance applications is a time consuming and expensive process for IT departments, especially if those applications are based on actuarial Excel tools. In this article, I laid out the blueprint of an alternative approach to developing actuarial web applications quickly and cost-efficiently. I don’t recommend it for each and every insurance application, but there are many insurance applications that can benefit from this approach. The results can be very rewarding for the entire organization. Some of the largest insurance companies are already using this technology successfully.