press
Portfolio



24.01.2008
  Oneshield: Legacy Systeme weichen modernen Technologien (Text in englisch)
 

For Aidan McManus, SVP and CIO of New York-based Tokio Marine Management (TMM), the decision was reasonably straightforward. "We had a legacy mainframe system that we were leasing from a vendor, and that system was proving over the years to be increasingly inflexible," he relates. "It took too long and cost too much to try to keep that legacy mainframe-based system in sync with our evolving business needs."

Those limitations drove TMM ($442 million in gross written premium) to seek a nonmainframe, Web-based application that offered the desired flexibility and gave the carrier more control. "We were looking for a system that we could have initially customized by the vendor but that allowed us to maintain some level of configuration going forward, so that we didn't need to go back to the vendor each time we needed some change made to products," McManus explains.

Toward the end of 2004, TMM simultaneously began developing requirements in conjunction with its end users and surveying the marketplace for solutions. As the requirements became more refined, the pool of vendor candidates shrank from more than 100 to about a dozen finalists, according to McManus. "The Castek product Insure3 suite impressed us as being probably the most configurable product out there in the market right now," he recalls. "Castek's affiliation with i-flex solutions [which acquired Castek in 2005] gave them the implementation capacity and gave us the confidence to realize that this was a company and a product that could get the job done for us."

Considering the legacy replacement effort a "once-in-a-decade" occasion, TMM took advantage of the opportunity by embarking on a multiphased initiative that includes the Castek (Toronto) implementation, creation of an enterprise data warehouse and the implementation of an enterprisewide messaging infrastructure based on IBM (Armonk, N.Y.) MQ. "It's all going very well and on schedule," McManus reports. "We start user-acceptance testing in August. Our first use of the system will happen in November, and I'm pretty excited about our prospects."

Reflecting on his decision to move forward with newer technology, McManus acknowledges that the older mainframe-oriented systems still have their place, as they bring a certain economy of scale and reliability. "If you're running very traditional lines of business without a lot of product innovation, some of the older technology systems can serve you well," he comments. "If you're not looking for fast turnaround times and you're not concerned with the investment that might be required to bring those systems in line with a fairly complex set of business requirements, then you're better off with one of the traditional platforms."

However, McManus continues, "If your business requires you to be more nimble and you need to bring more innovative or complex products to market quickly, then it behooves you to consider bringing some configurability in-house."

Clear Future

The amount of configurability a carrier brings in-house -- and how -- may depend on several factors, not the least of which is the size of the company. But the state of policy administration technology is such that the way of the future is clear, in many observers' view.

"There are still carriers interested in systems bought on old technology and then wrappered, but those are growing fewer and further between," says Chad Hersh, an Austin, Texas-based senior analyst with Celent. "The longer that the modern systems continue to sell at a brisk pace, stick around and prove themselves, the more that vendors of older systems are going to have to confront that."

According to Hersh, that process is already under way. "A great example is CSC's [El Segundo, Calif.] Wealth Management Accelerator," he argues. "If it is truly not an issue to have older code bases, then why is the new Wealth Management Accelerator going to be COBOL-free within three years? Why invest all that money in getting off COBOL if COBOL is not dead?"

Hersh allows that the issue isn't so much the language as application design. Still, he insists that COBOL presents staffing and other challenges. "If you can't find people to maintain your system and it takes three times as long to build out new functionality as it does with a newer system, what good does it do you?" he poses.

And the problem isn't the mainframe, either, Hersh adds, since new systems can be run on the old hardware platforms. "The real issue is systems that are flexible, easily maintainable at a reasonable cost and that grow with the carrier without having to rely as much on the vendor," he says.

Carriers without significant IT resources may need to rely on vendor partners, so there is a place for that kind of arrangement, Hersh allows. However, he says, systems that operate on this model are also candidates to be displaced by business process outsourcing (BPO) based on modern systems.

Proven scalability on the part of newer systems is still a concern, Hersh concedes. But he notes that more and more carriers are willing to take a chance. "There are all kinds of ways to mitigate the risk, such as via lab testing and putting one line [live] and ramping up others later," Hersh submits. When all is said and done, he adds, "The road is running out for a lot of the arguments that have been made for why the older systems are still OK."

Clearly, however, many carriers, for better or worse, find some of those arguments compelling. Innate conservatism plays a role in making some insurers perhaps irrationally cautious, in the view of Joel Conrad, former National Life (Montpelier, Vt.; $1.3 billion in annual revenue) CIO and currently a Minnesota-based independent consultant. "There is a widespread sense that the cost of moving to a new policy administration system is too high," he says. "I don't think many companies make a strong effort to understand what the newer platforms will do and what the value proposition really is."

The kind of bovine reliability that older systems can afford also encourages a certain "if it ain't broke, don't fix it" mentality on the part of many insurers, according to Conrad. The same carriers are likely to be worried about whether or not they have the professional skills to move onto new platforms, including project management experience and the tools and techniques needed to convert existing business, he adds.

Further, the new-systems vendors themselves have yet to master making their own case, Conrad believes. Carriers' concerns about scalability and large volume batch processing are eminently reasonable. The vendors need to come up with true benchmarking statistics and stress performance testing on such tasks as large volume nightly policy runs, Conrad recommends. "I know the vendors can handle those volumes, but they haven't done a good job of demonstrating that they can," he says.

Unrealistic Expectations

Newer system vendors have also been guilty of encouraging unrealistic expectations, according to Brian Desmond, VP of marketing for Guidewire Software (San Mateo, Calif.). Modern systems have been hyped as permitting implementation in weeks, for example. But the reality is that implementation takes upwards of a year or two to bring complex policy administration systems live, Desmond contends. There are some essential integrations that cannot be skipped -- those to the claims and billing systems, a rating engine, the enterprise back-end systems, plus any number of external services, he explains. There are also issues surrounding data import, such as data cleansing and validation prior to import. "Consider a vendor claim to implement in a very short time more of a red flag warning that the vendor has no idea of how their software will fit into the customers' infrastructure," Desmond advises.

Another false claim, according to Desmond, is that systems are designed for configuration by business analysts and don't require skilled programmers. "The reality is that one must be fully conversant with not just the business process, but also the complexities of the workflow down each and every logical path in multiple branches of a business process," Desmond asserts. The skills needed, while business-focused, are very much like those required for the programming method, with the exception of actually writing in a specific language, he elaborates. "While the analyst can explain the business process, it requires specific capabilities to interpret the business intent, systematically work through the logical branches, decision points, loops and notifications, in order to develop a workflow process that performs as intended," he concludes. "Some analysts might be able to pull it off, but it's not for everyone."

The sort of disingenuousness cited by Desmond combines with questionable practices of more traditional vendors to reinforce insurers' conservatism and skepticism, according to Ric Young, SVP of sales and marketing for Glastonbury, Conn.-based SEG Software. "Most vendors' business models are strongly based on professional services, which is a built-in incentive to camp out at the carrier site for as long as possible, implementing never-ending changes [to legacy systems]," he says. "Many insurers have been lulled into this scope creep before they ever knew what hit them."

Carriers have understandably taken a wait-and-see approach toward new technology, as a result. "But when the carrier has waited too long and the old system has become too painful to work with, the BPO providers will swoop in with yet another set of promises," Young predicts.

A way for carriers to ease the transition to newer technologies is to insist that vendors share the risk, Young argues. Any vendor under consideration should be required to build a product and show it running on the system before the carrier makes a buying decision, he insists. "Any vendor not willing to invest the time and effort can step aside and make way for the next vendor in line," Young remarks. "Carriers have grown to expect so little from vendors; it's time to raise the bar and start making some real demands so that carriers can make an informed decision."

Transition Plan

Joel Conrad's prescription for policy admin transformation is to gain a foothold in the new world. "If you were starting a company, you would put the newer platforms in place, so why not set up the office of the future? Start with new products and create a small team that manages the new products, the new business, the customer service and the whole policy management side in the new environment," he counsels. "Then lay out a transition plan to convert business over to the new environment -- bring in people who know how to do this and build your company of the future."

Many companies have brought the newer systems in for the launch of new products, Conrad clarifies. But generally they have simply added complexity to their environment, he says. "The guys running the operations haven't really laid out the future on the new platform -- basically it's just another system to handle newer blocks of business," Conrad laments. "They haven't laid out the road map for the future."

Laying out a transition plan complete with road map is precisely what CSC has in mind, asserts Darren Klauser, VP in the vendor's life and annuities group. "Companies should transform over time with a strategy that involves a reference architecture and decoupling components and externalizing business rules," he comments. "When they have eventually matured to a place where they have decoupled enough of that strategic [legacy] investment, then they can plug in a new engine that is smaller in scope."

Insurers seeking to evolve their policy admin environments can build their own reference architecture and flesh out their environment with best-of-breed components, or they can adopt something like CSC's reference architecture, which provides a standards-based approach within a proven partnership, according to Klauser. "The upside of doing a reference architecture on your own would be that you may get a best-in-class solution that's a more custom fit for your specific organization. But then you have to reconcile the integration as things change over time," he argues. "What you get from adopting a vendor architecture is assurances that, as vendor products evolve, the vendor will bear more of the integration costs to that reference architecture."

Springfield, Mass.-based MassMutual ($456 billion in assets under management) believes CSC has a good strategy for transitioning the carrier's architecture, according to Bob Casale, MassMutual's CTO and VP, enterprise services group. The insurer has standardized across its life and annuity lines of business on CSC's VANTAGE-ONE platform. It standardized on a third-party-administrator (TPA) version of the platform for annuity business and on an installed instance of the product for nontraditional, variable product lines. At press time, MassMutual was due to go live in July on traditional lines of business, featuring whole life.

While CSC's transition plans are indispensable, the fundamental objective for MassMutual was to work with a proven partner, Casale relates. "We've certainly looked at contemporary product offerings from various vendors," he relates. "They are terrific, cutting-edge technologies. But they're not proven."

True Strategic Partnership

"We start the journey from a good business decision, which is, 'Will these people be here in the long run? Are they willing to be strategic partners with us, and are we going to have an opportunity to influence the direction they're going in?'" Casale continues. "We're very willing to give up some functionality for long-term viability and true strategic partnership."

Experience has proven the value of the CSC partnership, but that isn't the only reason the carrier is standardizing on VANTAGE-ONE, Casale insists. "We're spending a significant amount of money to standardize on these platforms, and we believe they will give us extreme flexibility and significant business advantage," he explains. "It's speed to market, it's simplified servicing, customer self-service -- it's the ability to do all those wonderful things."

Worcester, Mass-based The Hanover Insurance Group ($2.6 billion in annual revenue) has pursued a similar path as a CSC customer, but also went into production on a OneShield (Westborough, Mass.) policy admin system about a year and a half ago. "There were some big business drivers that pushed us to look for an alternative platform that we considered more flexible," says Mike Clifton, CTO, Hanover Group. "OneShield was about being able to configure, provide flexibility and have greater change management around agents' requirements."

The carrier's investments in a service-oriented architecture have made distributors' interactions with The Hanover transparent regarding with which platform they happen to be engaging, whether OneShield or CSC's Series 2 platform, whose value has thus been extended. Such a gradual and architecturally comprehensive strategy is the best bet for large carriers, Clifton suggests.

"I don't think there are many carriers who will make wholesale, full line-of-business policy administration swaps -- for most of us, that's not possible," Clifton says. "What we're all after is how to take and extend what we have, maybe take a strategic line of business and maybe replace that system and move forward with that -- that's what we've done with OneShield and our commercial package business."

Specialty P&C carrier Darwin Professional Underwriters ($244 million in gross written premium) was able to commit to OneShield exclusively without any swapping out. The four-year-old Farmington, Conn.-based company started from the ground up, choosing the new-technology platform based on CIO Bob Asensio's prior experience with Duck Creek's (Bolivar, Mo.) configurable rating engine. "Our going-in position was that it was possible to use a configurable product," he comments.

The nature of the company was a factor in its decision, Asensio acknowledges. As the brand name suggests, Darwin aspired to represent a step forward in the evolution of the insurance enterprise, as exemplified by a capacity for change in response to market opportunities and the ability to deliver a wide variety of product quickly, he says, noting that company leadership understood that it would rely heavily on newer technology to do so. Given a narrow window of both time and financial resources to get the company's technology component up and running, Asensio says, he was willing to "roll the dice" on the new technology solution.

Focusing on Business, Not Technology

Among the advantages of the OneShield solution was being freed from worrying about technical issues because of its open architecture, Asensio notes. "When someone comes up with an idea and says, 'Can you do this?' we're able to make it happen," he relates. "We haven't run into dead ends, and we've been able to keep our focus on business problems rather than technical issues."

The solution also enables Darwin to work independently of the vendor in the long run. "We were turned off by vendors who said, 'We have 300 people offshore and they will make changes,'" Asensio adds.

Asensio also sees OneShield as allowing the company to take a kind of evolutionary step up systemswise. "Historically, many systems were what might be called glorified filing cabinets," he remarks. "With a system like this, we're able to take another big step up the value chain where we have a system that, in our case, automatically underwrites [and] automatically knows when it needs to ask follow-up questions or not."

Darwin made the decision to buy the OneShield product in September 2003 and by May 2004 was in production with about a dozen products, according to Asensio. He says that Darwin spent about $1 million on consulting fees in the first year, and half that in subsequent years. But he declines to discuss licensing fees. The system first went live on what Asensio calls "craft business," which is less rules-intensive. "Following that, we began to attack our core," he continues, which includes small business, small D&O and E&O policies.

Focusing on that area since 2004, Darwin developed what it calls i-bind, a tool that enables brokers to get a bindable quote in a single session. "If they want to, and if it fits the box, in 10 minutes they can go from entering the information to actually having a policy," Asensio explains. "That's unique in our professional liability world."

   


 
Top