In upgrading systems, it's important not to maintain the status quo, but to rethink processes and take advantage of best practices.
By Alec Miloslavsky in Risk & Insurance magazine, June 2013 - Download PDF
Depending on which analyst's report you read, approximately 80 percent of major system implementation or legacy replacement projects in the insurance industry are not completed on time or on budget.
That adds up to months or years of unplanned and unexpected delays with corresponding millions of dollars spent that were not forecast or budgeted. And that doesn't include the opportunity cost for business initiatives dependent on the new system that had to be delayed or scrapped entirely.
As one might expect, an implementation project gone awry can cut a promising CIO career tragically short. The question is, does it have to?
Insurance is an industry built on the business of evaluating and mitigating risk. Actuaries and risk managers have a wealth of historic data to draw upon from years, decades and perhaps even centuries of insurance transactions.
Typically, the various perils and risk items are well understood, as are how to price them and how to mitigate the risks. Many data points such as credit scores exist, which help evaluate the risks in personal lines underwriting, for example.
In contrast, no such historical data exists for system replacement projects. This means it's more than a case of the shoemaker's kids going without shoes; it's a matter of not having the tools and data to understand and mitigate common implementation risks.
Getting in the Same Page
In the case of a core system replacement, dozens of people must simultaneously agree on the requirements, a fact which increases risk considerably, especially if the decision-making criteria are unclear.
Inevitably, stakeholders from operations and IT will have their own perspectives on the issues, for example, and keeping them aligned is difficult. The challenge grows as the volume of requirements and specification documents and changes grow, because traditional tools are not designed to quickly highlight the reasons for certain requirements or changes and don't allow team members to effectively assess the real business impact.
Diligence is the key. Once a large and expensive IT project is approved and initiated, there is no plausible way back. This means the project owner truly has only two decisions to make once the project is started: Keep writing checks or stop. This is a primary reason insurers must approach core systems replacement projects with the same rigor they use to evaluate and price a risk.
Understanding the Risk
Core systems replacement affects almost every functional area of an insurance organization, and since most people who work in the trenches don't like change, this presents a major risk to any project. A goal for many, whether subconscious or intentional, is to maintain the status quo and may well be supported by phrases like "you don't understand, we're different" or "we've always done it this way."
The bottom line is that there's a cost for being different. Unless it provides a real competitive advantage that results in higher profits, there is no value in maintaining the status quo just for old-time's sake. Rarely is that the case.
The truth is that within a given line of business, most insurers have the same basic processes. The difference, as we all know, lies in the mix of products sold, the states or countries in which the company is licensed, and the lines of business written, not to mention the technology infrastructure underpinning it all.
Perhaps it goes without saying that new technology offers increased ability to streamline processes and improve operational efficiencies. Isn't that the point? That said, modifying a software package to maintain outdated customs and traditions is the equivalent of paving cow paths. After the asphalt dries, the new system could allow the company to perform the same outdated processes.
In addition, once a single line of code has been created, the software becomes a one-off version that has never run before, making scalability and performance a complete unknown.
In addition to delaying implementation, customization may result in added time and higher costs to upgrade to new versions and enhancements. Customization, whether in a commercial language like Java or, even worse, in some proprietary language, may ultimately result in rapid obsolescence, a lack of flexibility and a total cost of ownership (TCO) that quickly skyrockets.
For some companies, the best way to deal with core system replacement is to consider a system that includes pre-configured solutions to handle transactions within specific lines of business. This can mitigate concern about customization and stop the seemingly inevitable paving of the cow paths.
Typically, pre-configured solutions are based on the best practices of like companies within the industry that have been honed over time. They cover things like product design, business processes and even pre-built integrations with common third-party data sources. They have embedded subject matter expertise and take a lot of error-prone committee work out of the risk equation by pre-configuring the business requirements. They may also provide a valuable shortcut to system implementation and allow those responsible to focus on a small percentage of the total configuration effort rather than starting from scratch.
When a system package is 60 percent to 70 percent pre-configured, insurers start with a working system. The question is no longer, "How do we make the system work our way?" But instead, "Will the new pre-configured system work for us, and if not, why not, and how much will it cost to change?"
Of course, manufacturing a system that is capable of accommodating multiple lines of business, and allows sufficient flexibility to handle all the required complexity with minimum custom coding is difficult.
Software vendors take years to manufacture an integrated policy, billing and claims suite, and unless it is built correctly coming out of the box, a significant amount of customization will be necessary in every implementation.
A slick demo or an aesthetically pleasing color scheme on the UI is not a good indicator of the underlying system capability. So, what is? What are the various risks, which can be identified and mitigated, that will lead to a successful implementation?
There are obviously many obstacles to pulling off a successful implementation, customization being the biggest.
The question becomes whether a system is built so that it has the right balance of configuration versus customization. Does it configure those elements that change the most, or those that are the most difficult to maintain or upgrade? Are there other obstacles, such as proprietary language use, that will add to system maintenance cost? What percentage of custom code is spent on business rules, product configuration and workflows? If it is a high percentage, you may be creating a custom system.
Upgradability must also be considered. How long does it take to upgrade? If it's many months, the implications are obvious. Do multiple lines of business run on a single instance of the platform using the same master data? If not, you might again be implementing a core system per line of business.
Having automated tools that keep track of requirements, retain knowledge, and evaluate the impact of changes to the system before they are committed is a significant factor in achieving success.
Insurers need to seek out multi-line software solutions designed to support new products and new business, and break old cycles.
Alec Miloslavsky is executive chairman and CEO of Exigen Insurance Solutions. He can be reached at firstname.lastname@example.org.