Over the past 30 years, the world of automating policy administration in property/casualty insurance has changed a great deal: In the early days of computing, companies built their own; in the '80s, less than a handful of vendors became mainstream; and in the '90s, riding a wave of technology innovation, an assortment of technically astute medium-size and smaller shops decided to try their hand at insurance.
However, except for the truly early days, one thing has remained constant. Modernizing policy administration has lagged behind the insurance business innovation it was supposed to support. That gap has been growing steadily over the last 10 years, particularly among mid-tier insurers.
Although difficult to ascertain accurate statistics--old and even some newer policy processing systems have undergone so many changes even their creators would not recognize them--plenty of carriers still are processing policies on aged systems.
Are these old systems that good? Once upon a time they probably were. In this day and age, though, that's not likely. So why do we keep putting off replacing the "core" of core insurance business processing? Is reinvesting in the old systems really worth the effort and the cumulative cost, or is it time to cut our losses and move on? Let's look for some answers.
This is something we keep hearing time and again: "The system does its job, so why mess with it?" If that's true and the system really does live up to business expectations, then such a position is hard to argue against. But is it true?
To begin with, the insurance business has transformed slowly but irreversibly in the past 10 years. One could cite a number of socioeconomic or regulatory changes that have transpired, but the fundamental reason behind this metamorphosis is customers have changed. Whether "customers" mean agents or the insured or both, maintaining a customer-centric view of the world has become mandatory for any carrier--large, medium, or small. Unfortunately, the systems in question are not customer-centric. They are policy-centric and, therefore, by design, unresponsive to customer-centric strategies.
Next, these systems are monolithic, again by design. This means, except for breaking in to tweak lines of code only to recast the concrete, they cannot be disassembled easily into pieces that can be independently reengineered or replaced.
Finally, the typical platforms these systems run on are fast heading toward the Antiques Roadshow.
Add it all up and what you get are systems that essentially are broken. No amount of additional spending in the face of such built-in limitations can alter that fact. As a result, they're holding the business back. Yet so many companies spend tremendous amounts year after year to extend the "useful" life of these systems. Why?
Indeed! But the argument works both ways. It's the same argument the industry has used since its beginnings to motivate our own customers into action: "Minimize your risk by investing in protection." Unfortunately, where IT is concerned, we tend not to heed our own sound advice.
To "play it safe," companies have had to go out of their way to devise methods and techniques for extending the life of legacy code. The more complex methods include: reengineering, design recovery, functional discovery, wrapping, etc., all of which are drawn-out endeavors of very low certainty. Some carriers have discovered successful short-term bandage approaches to protect their original investment. Others have not been so lucky. In either case, the costs were not trivial. But the really bad news is compounding spending to hedge one's bets just multiplies the original problem by moving long-term solutions further from financial reach.
The excuses for avoiding a major system replacement are distinct for different companies, depending on the type, origin, and architecture of their systems. The most common three are:
o pain (system inadequacies) not acute enough
o risk and cost too high
o no viable vendor solutions available
The first point speaks for itself: No pain--no problem--no argument from us.
That leaves risk/cost and vendors. We talked about vendors in a prior "CIO Chronicles," so let's leave them for later. Let's first deal with risk and cost.
Whichever way you may choose to do it--buy, build, or outsource development--the cost of replacing a policy administration system inevitably will be high. But as we've seen, so is your annual spending on the system you're running now. For the sake of weighing replacement cost against perceived risk, tally the annual expenditure on your current system. If you know what your TCO (total cost of ownership) is, great, you're already ahead. If you don't, be sure to enter every detail, including the cost of maintaining historically knowledgeable staff, tools, hardware, and operating systems. Then add the cost of the lipstick, middleware glue, and other layers and wrappers you had to put in place just to get the system to work with, for example, the new CRM you bought, or to support mandatory external connectivity hubs and front ends. When you're done, extrapolate the calculated annual total at least 10 years into the future.
Since high cost is a given, let's look at risk. Volumes have been written about the risks of replacing heavy-lifting back-end systems--with good reason, too. The stats about the industry's track record on how many projects flat-out failed and how many overran time and budget are abysmal. But these stats just illustrate the success or failure of IT projects in isolation from the business. What they don't tell you is what these projects were. How many were in-house development or outsourced custom builds, and how many were vendor implementations? Another missing piece of valuable data is: What really happened? Who failed whom, or rather, "whodunit"?
As bad as these track records may be, it is unlikely a failed IT project will tank the business. Times have changed, and so has the meaning of IT-related risk. Today, the only risk worth examining is the risk outdated, rigid processing systems can pose to the viability of the business. Although not often the case in this industry (a hot topic for some other time), business and IT must be joined at the hip. If IT can't provide the agility not just to support but to help promote business innovation, the gap between the two will widen, and then the business can and will tank.
Where does that leave us? The everlasting four choices are: Do nothing, build, outsource building, or buy it from those that have staked their businesses on it.
Ah, those vendors! "If only there were one that didn't . . . [insert your grievance here]." True, nobody's perfect. But have you taken a closer look at vendors recently? We did. Earlier this year we were asked by a group of mid-tier carriers to examine policy administration system vendors in the North American market. We looked at 15 of the most relevant policy administration vendors of different size, maturity, and technology breed. Not just casually, I might add, but in considerable depth: from product feature/function (including underwriting, claims, and billing functionality where these were parts of an integrated system) to business and technical architecture, staffing, implementation methods, and delivery capability. Last but not least, we also looked at their financial viability and "staying power."
The results? Suffice to say we were nicely surprised.
It has been said "the best is the enemy of the good." Even though some of these vendors may not have all of the functionality we're looking for, quite a few of them have come a long way over the past few years. What they do have are functionally-, architecturally-, and technologically-advanced systems that--we have no trouble saying it--are good. Certainly they're good enough to earn the right to be on your TCO and ROI sheets.
If all the above reads like a case for the vendors, it is for good reason. First of all, there aren't any silver bullets or major breakthroughs out there just waiting to happen. Second, technological advancements are happening at such a pace that trying to keep up with home-grown code requires a king's ransom in annual expenditures. We've come across companies that internally have to juggle up to 30 different technology platforms! Third, throwing custom development "on spec" over the offshore fence certainly is much cheaper, but with hardly any exceptions, the returns appear to be suspect--your core business application is just not a pair of jeans.
Which brings us back to the vendors. If nothing else, they have invested heavily into their own competence of bringing new products to this market. And they're worth a look. While waiting for that silver bullet or a miracle market leader to appear, we're missing out on opportunities to move ahead. It's time we all started focusing more on our own core competence instead of competing against the competence of others.
Take a keener look at some of the vendors out there. Look for "good enough" functionality among those that offer modern, business-flexible platforms.
Finally, work out a few TCOs and ROIs. Bear in mind, however, vendors operate on a shared-cost model. By sharing the cost of a system and of its functional and technical improvements with others, you gradually will be reducing your future cost of ownership.
When you compare the numbers, the relation between your perceived and real risk may surprise you--perhaps sufficiently to bid a kind "thank you" and a firm farewell to that code of yesteryear.
