Automobile dealers anxiously refer to it as the "test drive." It's the ritual where prospective car buyers put a new or used auto through its paces to determine comfort, handling and performance.
Insurance software vendors affectionately refer to it as the "test drive." It's a two- to three-day validation process in which a vendor makes a compelling case for why their solution is more compatible to an insurer's business fortunes than another vendor's product.
Why do software vendors affectionately refer to it as a test drive? Because while some auto dealers would move a car off their lot in a heartbeat-and forego the test drive if possible-an increasing number of software suppliers not only encourage prospective clients to take a "spin," many make it mandatory-a contingency upon signing a contract.
With competition in the insurance industry percolating, vendors realize that there's a lot riding on the shoulders of insurer partnerships.
To vendors such as Chester, Pa.-based AdminServer, which develops policy administration solutions, a test drive--referred to in many circles as a proof of concept (POC)--serves as an unequivocal testament to their IT capabilities.
"We have declined to meet with insurance companies who want us to participate in a 'dog-and-pony show,'" explains Ric Young, chief marketing officer at Admin-Server, which develops Web-based policy administration solutions.
"That did not sit well with one large-size carrier that was shocked when we declined a meeting. My view is, carriers don't know what they don't know about technology. So you have to show them, and that's what our test drive accomplishes."
Indeed, many software suppliers welcome the opportunity to strut their stuff.
"We welcome it for many reasons, and we actually look a little oddly at insurers that don't drag us through one because, how could they be setting expectations without conducting a proof of concept?" explains David Holmes, executive vice president, sales and marketing, for Atlanta-based Jacada Inc. "There's a lot at stake because of all the deals we do, a large percentage of POCs-maybe 80% to 90%-consist of first-time customers who are not familiar with our platform."
Test drives have reaped great results for software vendors such as Jacada, a provider of Web-based systems integration software solutions, and AdminServer, which performed eight POCs during 2004 and landed three major contracts, including Merrill Lynch Insurance and Phoenix Life Insurance.
"We are collapsing six of Phoenix Life's policy administration systems that go back 40 years onto one system," Young notes. "Carriers might not understand the essence of our technology, but when they see that it works applied to their products and systems, they're convinced."
Seeing is believing
Undoubtedly, vendors are more than eager to engage insurers in an extensive POC process to allay doubt, but mainly to reinforce the efficacy of a product suite.
"We tell insurers, 'we want to prove it to you,'" says Wendy Corman, business development officer for Bolivar, Mo.-based Duck Creek Technologies Inc., which specializes in Web-enabled policy rating solutions. "Too many companies sign contracts based on a promise and later discover surprises. Sometimes, what we tell an insurer regarding the ROI and performance of our system seems too good to believe. So the POC validates it."
To be sure, vendors want to obliterate doubt and vigilant insurers want to see the proof. "A proof of concept is critical," says Debbie Foell, assistant vice president, application development for Springfield, Mo.-based ANPAC, a provider of auto and homeowners insurance lines.
"A proof of concept lets you see all the pieces that must work together in your environment. "When we embarked on automating our state rating manuscripts for auto, it was unknown territory for us. You have to determine that not only is the product a good one, but that it's a good fit in your environment," states Foell, whose company selected Duck Creek's Example Author to automate and integrate its rating systems.
Adds George Hanrahan, vice president and director of information systems for Spokane, Wash.-based Western United Life Assurance Co., a provider of life and annuity products: "Over the years, I've seen my share of so-called vaporware. That's why a POC is so valuable, because it enables us to convert vaporware into reality."
Selecting AdminServer's policy administration solution in May 2003 enabled Western United Life to effectively replace its legacy system to standardize on AdminServer's rules-based platform.
The insurer consolidated its life and annuity systems on a single platform and in July went live with the new system for all 16 of its annuity products.
Quick to learn
"We took their test drive and went through a rapid pace in a week or less," Hanrahan explains. "We had our business people using their system-it was very quick to learn. Moreover, we have easily experienced a 50% increase in productivity of our customer service representatives for those products now being administered on the Admin-Server system."
More carriers such as Western United Life need to know that a POC is a thorough but fluid process. "What we do is get everyone from an insurer's operation in the room at the same time, with the exception of their IT people, who enter the picture during day two of the test drive," Young says.
Taking a day and a half, Admin-Server rounds up department heads of operations, actuarial, new product development, finance, and even agents. "We put their products on our system. In one day, we address many of the pain points of the business users," he explains. "Then, we drain the swamp, so to speak, and sit down with the IT department.
"We've been able to take the most pessimistic IT people and make them believers. The IT guys all want to get inside the rules engine, which is regarded as our 'secret sauce.' Many think it's smoke and mirrors, quite frankly," Young adds.
Paralysis by analysis
One of the dilemmas that confronts insurers is that they overanalyze the POC process, all in the name of due diligence. But concurrently they often lose sight of what they're trying to accomplish.
That's why industry experts say insurers should do their homework upfront-prior to actual proof of concept demonstration. "An easy way to boil it down is this: Insurers are either comparing (software) products or confirming a decision," says Jacada's Holmes.
For example, a carrier might perform a test with agents to determine whether they would use a certain system and confirm that the system was understandable. "In this case we know we have to design the POC to convince the agent; they have to see it and know this is going to change their lives," Holmes asserts.
In the past, when AdminServer would scout for new business, insurers would compare one vendor's product against other vendors' offerings. Now, most insurers it engages want to confirm what they have learned through their research.
"Nationwide (Financial Services Co.) conducted a formal test plan with another vendor and was all set to select that solution to upgrade their life and annuity policy administration system," AdminServer's Young explains. "They basically brought us in as an afterthought. We outperformed that vendor and won the contract, which was finalized in 60 days."
When insurers do compare vendor offerings, "I think it's smart to get down to a two-vendor selection process," Holmes says. "We see companies do POCs with four or five vendors. The more vendors to compare, the harder to really measure variance."
Clearly, the entire process can leave insurers with "paralysis by analysis," states Bob Talbot, vice president of supply management, for Fireman's Fund Insurance Co., Novato, Calif.
"We can study a potential vendor to death but we'll stop as soon as we reach the point of diminishing return," Talbot states.
The role of Talbot's supply management unit is to "make sure there is clarity between the business needs, the IT architecture and the commercial capabilities (of the vendor).
"My group is charged with making sure we accomplish three things: Avoid or reduce costs, manage risk and enable efficiency," he adds.
Supplier pre-qualification
To start the ball rolling, Fireman's Fund conducts a "supplier pre-qualification" based on two factors: the project's projected cost and the importance of a vendor's product to a particular Fireman's business unit. Smaller IT projects are approached differently than more ambitious ones, he adds.
"If we're spending $20,000 on an IT project, then we'll perform a much quicker due diligence than if we're spending $10 million," Talbot says. "For larger projects, we would perform a much broader analysis, including site visits (to a vendor's operation) and reference checking. We work jointly with corporate credit groups and obtain standard financial ratios. We want to know about a company's financial health as well as how they perform operationally."
Once supply management identifies the appropriate vendor candidates, IT and Fireman's Fund's business units push selection to the final stage. "As always, we want to establish some type of institutional memory of the vendor's performance," says Talbot.
The supply management strategy has shown impressive results: Over the past 2-1/2 years, Talbot estimates Fireman's Fund has saved $70 million and plans to save an extra $100 million in 2005 alone due to its effective vendor selection methodology.
On the front end of those savings, insurers have POC costs to consider.
Indeed, a proof of concept can get expensive, especially if an insurer is accessing multiple vendors. "If a carrier participates in our POC to confirm a decision, we might be more flexible (with POC pricing) than if it's occurring within a comparison shopping situation," says Duck Creek's Corman. "We will tell insurers to take as much time as they need and get it right. If they move forward with us, then we might apply those dollars to the final contract-it becomes reusable."
The vendor evaluation process is somewhat different for insurers such as ANPAC that are more apt to develop its own software.
"We write our own software for the most part, so we don't have a formalized team-in-waiting," says Foell. "But when we have a need for a vendor product, we select the people who we believe can best drive the POC process."
Vast improvement
When it was examining Duck Creek's Example Author solution-a project that would Web-enable and consolidate three disparate rating platforms-ANPAC's actuaries and IT group were involved in the testing and decision-making processes. Actuaries, after all, establish rating manuscripts at insurance companies and would need to see how the conversion to a new platform would work for their purposes.
"We benchmarked against our own batch rating and did paralleling to establish verification," Foell explains. "We performed a side-by-side comparison of our environment to theirs to determine if there would be anything lost in the conversion. We were happy to find that it was a vast improvement."
Industry observers agree that the proof of concept gives carriers an important perspective when evaluating technology.
"You could probably put it in perspective this way," concludes Jacada's Holmes. "If you go out and buy a car and test drive it, you can instantly compare how it feels in relation to other vehicles. But if you go out and drive a fire truck for the first time, that's something you've never done before.
"Maybe an insurer has never Web-enabled their agents before, or performed a legacy system overhaul," he says. "That's the mentality that insurers should take when they approach a proof of concept."
Cutting Through The Smoke And Mirrors
To ensure that the solutions being showcased are legitimate-not smoke and mirrors-many insurers have embarked upon proof of concept (POC) strategies that are more encompassing and systematic than in the past.
Although it's the responsibility of software vendors to establish the proving ground, it's incumbent on insurers to be equipped to absorb and measure what a vendor is delivering.
Some insurers are still fuzzy about how to approach proof of concept strategies. "Overall, I would say that insurers that have never acquired a piece of software are the ones that lack the performance-based metrics to internally measure and assess a POC," says Wendy Corman, business development officer for Bolivar, Mo.-based Duck Creek Technologies Inc.
Western United Life once relied heavily on request for information (RFI) and request for proposals (RFP) to make vendor selection decisions. Although it is still a tried and true methodology, it's now augmented by a deeper dive.
"I have three of my IT staff involved and five people from the business units, including marketing, operations, finance and new products," declares George Hanrahan, vice president and director of information systems for the Spokane, Wash.-based carrier. "We use a matrix/scorecard to weigh vendor POCs. It's human nature to select the last POC you see, so you need a numerical methodology to factor in a third realm."
When comparing vendors' products, Western United Life typically evaluates no more than four vendors and occasionally will perform a Web presentation with a vendor first before bringing them to its headquarters. "We also always leave a day or two between each POC," Hanrahan says. "We then establish a time frame to sign a contract. We try to go no longer than four to six weeks from the POC to when a contract is ultimately signed."
Industry experts agree that insurers have to be active participants in the process and must come with an open mind and demonstrate flexibility. Otherwise, a POC is performed in vain."We get nervous when a customer doesn't know what they want," says David Holmes, executive vice president, sales and marketing, for Atlanta-based Jacada Inc. "We need access to applications and networks. We need to set up a so-called laboratory, but it's up to the carrier to assemble the right resources."
Holmes says that his company will "walk away from a partnership if we believe that the customer might fail. We might say, 'You're going to need to acquire three or four more servers if you want to accomplish this.' " The POC can't always take into account the scale of a particular project and the internal systems architecture necessary to do it."
Deb Smallwood, insurance vice president for Needham, Mass.-based research and consulting firm TowerGroup, agrees that the onus is on insurers to meet vendors half way to optimize proof of concept strategies. "There are very few bad technology solutions out there-when there's failure it's usually a lack of executive sponsorship at the carrier level," explains Smallwood.
"I've been blown away by the rationale of some vendor selections. Carriers will sit through fabulous product demonstrations but then select an inferior product," Smallwood continues. "When that occurs, it's often dictated by corporate politics. Or, it's because a vendor with an inferior product might have come across as being able to understand a carrier's business better, understand their pain points-yet the product is still inferior," she notes.
Vendors Work Behind Scenes To Perfect Proof Of Concept
Vendors that support insurance companies have a lot riding on new business opportunities, both from a reputation and an economic standpoint. So it's no surprise that many vendors work diligently to craft the most thorough, fluid and customized proof of concept strategies that they can.
"We begin by getting an insurer's rating manual and rules engines and basically immerse ourselves in a company's processes," says Wendy Corman, business development officer for Bolivar, Mo.-based Duck Creek Technologies Inc. "We set up side-by-side screens to exhibit what our tool set can accomplish for insurers."
David Holmes, executive vice president, sales and marketing, for Atlanta-based Jacada Inc., relates that when his company's team arrives at an insurer's office, the way a POC proceeds can vary. "For instance, is the carrier wanting to evaluate ease of use of our solution set? If so, they are literally sitting over your shoulder at the desktop watching everything a programmer is doing," Holmes says.
"But if it's a project that doesn't require learning a new system directly, then the insurer might let our skilled people go off and do their thing for a few days. Then, the insurer's people might be brought back in to verify the system's performance. They might say, 'get it done and then I want to see that it's coming up okay in my environment.' "
Prior to a formalized POC, "an insurer will present a plan to us ahead of time, give us a chance to ask questions about it and then we will come on board to launch it," Holmes says. "By the time we get on site, we know what's asked of us and what skill sets to bring to the table. We have tech folks that are part of our sales team. These are people who can demonstrate what the difference is between our product and others. We also have designers who enter the picture. Each component serves a distinct role." At Chester, Pa.-based AdminServer Inc., the cycle starts with insurers furnishing AdminServer with product specifications about what it wants to embark upon, explains Ric Young, AdminServer's chief marketing officer.
Before the "test drive," AdminServer devotes 50 to 60 hours to preparation before coming on site to an insurer's office. AdminServer usually assigns three people to conduct its test drive, including what Young calls two "high performers" and one trainee.
AdminServer typically works with an insurer's actuarial team. "We design a test drive from the actuarial perspective," Young relates.
"We get a hold of the tables for the various product lines that are in spreadsheet format and import them to our platform. A life or annuity policy administration system is mind numbing-it's very complex. I ask actuaries for the most complex product they have, such as a fixed annuity, to design on our system. When they see their most complex product migrated to our platform, it provides the most compelling case of what we're able to accomplish."
