Fantasy: convinced by your technology vendor that its bleeding-edge policy administration system will seamlessly integrate with your existing network and infrastructure, slide like butter down your users' palates and establish record turnaround time for processing efficiencies, you sign on the dotted line. You even astutely craft your acceptance speech for your company's upcoming "Highest ROI" award. Everyone loves you—even your agents.Reality: Two years later, implementation continues to slog at a snail's pace, the systems won't talk, your team is overworked, the vendor has been bought by a behemoth that has lost you in the shuffle, and your boss, users and other stakeholders are screaming. You are stuck.
Best intentions by vendors or carriers often become the source of the greatest heartaches. But for many carriers, building successful relationships with suppliers is a matter of following a systematic approach-from strategic to tactical-and one that demands due diligence.
"Even determining your basic requirements takes a disciplined approach," says George Grieve, president of CastleBay Consulting, Austin, Texas. Grieve tells his insurance clients to establish cross-functional teams that can share the "buy-in" to feature/functionality requirements.
Using a policy administration replacement project as the example, Grieve recommends combining personnel from technology, product development, policy services, underwriting, and others with a vested interest in the project, such as the business side. "The first thing to do is have everyone have an honest conversation," Grieve says.
START INTERNALLY
Indeed, long before discussions begin with the technology provider, many insurers make the establishment of good partnerships with internal clients the priority.
"We start with informal conversations and, from that, articulate requirements into a project statement," notes Bill Garvey, an IT director for The Main Street America Group, Jacksonville, Fla. Garvey's team takes the project statement and builds in higher-level requirements, which specify why the technology is needed and how it will potentially benefit any one particular area. Once the project is approved, the team goes into fuller planning mode.
Garvey typically establishes a task force that includes representatives from the business side, IT project management, systems engineering, quality assurance and oftentimes security.
"We talk to everyone involved and ask all the questions: 'What exactly do we need?' 'How long will programming take?' 'What is the labor allocation?' They all have input to the scope and timeline. Then we take it to a more task-oriented vendor selection approach."
International Catastrophe Insurance Managers LLC (ICAT), a North American catastrophe insurance brokerage based in Boulder, Colo., investigates technology suppliers only when a specific business requirement has been identified. The growing, $140-million company, which provides catastrophe insurance to more than 60,000 buildings in 36 states, has identified several business requirements over the past couple of years, chief among them the need to replace its existing third-party claims administrator (TPA) with its own TPA, Boulder Claims. ICAT and Boulder set its sights on San Mateo, Calif.-based Guidewire Software's ClaimCenter. The three-month project included integration to ICAT's policy administration system and to Oracle Financials.
VERIFY BUSINESS REQUIREMENTS
"The business requirements can come from a business unit or from IT," says Joan Zerkovich, ICAT senior vice president, information technology. "As part of the budget process, we present the proposal to investigate the technology to our strategic leadership team, and from there create a set of functional and technical requirements for evaluation."
The technical team assesses the alignment of the application with ICAT's architectural framework, data warehouse and document management environments. The business team assesses functionality. The workgroups are then given a short timeline to narrow down the field to two to three supplier options through online materials, telephone conferences and online meetings with the vendors. Vendors that delay in providing information or demonstrating functionality are eliminated because they don't meet ICAT's responsiveness and partnership criteria.
Timelines-from identification of a vendor through proof of concept-typically require two to three months. Like Main Street America Group, once both business requirements and vendor selection is identified, ICAT believes in working closely with its internal teams to help the vendor "get it done."
Most recently, ICAT tested its process with the U.K.-based Thunderhead Ltd. ICAT will use Thunderhead's platform to power multi-channel generation of its insurance policies, policy endorsements and cancellation notices. ICAT will initially deploy Thunderhead's document generation platform to scale its insurance operations to enable high-volume production and delivery of its business communications across multiple channels, including print, Web and PDF.
ICAT found Thunderhead by conducting a market scan of the document issuance application space. "We did not limit our search to those vendors targeting the insurance industry," Zerkovich says. "We were looking for an infrastructure service rather than a strict insurance documents printing solution."
By looking for vendors that are aligned with ICAT's architectural framework, the company hopes to eliminate up front any wasted time and technical difficulties that could potentially interfere with a successful relationship, says Zerkovich.
"It also tends to lead us to partner with progressive companies that are providing leading-not bleeding-edge solutions that focus on integration via Web services," Zerkovich says.
ICAT's demand for alignment with its architectural framework, along with early definition of functional requirements by a small group of technical and business leaders, typically narrows the vendor field quickly. Neal Keene, Thunderhead's vice president of industry solutions, notes that, working with ICAT's team in a sales cycle of less than two months, "ICAT is clearly committed to doing it right the first time."
Part of that commitment is an understanding of the importance of vendor selection. "We don't ask [the vendor] to do it all for us," Zerkovich adds. "We ask them to do what they do best, then integrate that service with other applications that do what they do best."
LESSONS LEARNED
With more than $800 million in annual written premiums, the stakes are also high for The Main Street America Group's IT success. The property and casualty insurance provider services more than 500,000 policyholders through 1,300 independent agents in 16 states.
And even though the stakes are high, Garvey admits that his company has learned a few important lessons along the way.
"We've tried replacing core systems in the past and didn't always achieve the results we had anticipated," he says.
Garvey blames the rush to technology following Y2K vendors to move to the Internet quickly, but not with technology that delivered the features and functionality necessary for an insurance business to operate efficiently.
"If you think about how long it takes to develop robust core systems, it can take years," he says.
Some vendors said they were ready to deliver on that functionality but Garvey and Main Street America found out the hard way that some technology providers promised more than they could deliver.
"We purchased some technology that didn't fulfill our requirements," he admits. "When you are part way into that effort and find a gap between what you need and what you are really getting, it's very difficult to resolve."
For some carriers, the technology is there, but the vendor's track record isn't.
"It was the typical Catch-22," says Aidan McManus, senior vice president, CIO at Tokio Marine Management, New York.
"We looked at our business requirements, which are pretty complex, and knew we had to put some real effort into building relationships with vendors that offered the right technology for our platform," he says. "But getting to that point was a challenge."
With annual revenues of more than U.S. 16 billion and representation in 38 countries, Tokio Marine Management manages the operations of Tokio Marine Nichido Fire Insurance Co. Ltd., as well as four U.S. subsidiaries and a wholly owned claims service operation.
When the provider of commercial property, workers' compensation and ocean marine products decided in late 2003 to replace its core systems, the insurer came across Castek, a Toronto firm that scored on three counts: its enterprise-scale Insure3 software, its configurable components and its flexibility.
"The only problem was, at the time, Castek was less than a 10-man shop, and they only had one previous client," recalls McManus. "We told them we wanted to do business, but circumstances at that time just weren't right."
SAFETY IN NUMBERS
During Tokio Marine's evaluation process, however, India-based integrator i-flex Solutions acquired a majority stake in Castek, bringing to the table a cache of financial services customers, as well as a project and risk management framework based on a host of universal standards and best practices, including SEI CMMI Level 5 processes. During the same period, Oracle entered the picture with a 41% bid for i-flex.
"Our team understood the value of i-flex, which had a huge track record in the banking industry," says McManus. "We also knew that, based on the enormity of the project, mitigating risk was crucial, so we'd probably need to create the right mix of vendors to get the job done."
So the Tokio Marine team regrouped with Castek, working with the vendor's team to draw up a proof of concept that would verify that Castek, i-flex and the other partner pieces the insurer required would fit together.
The result was a six-member vendor unit that will help the insurer manage through its 18-month legacy systems replacement project.
That six-member team will also support Tokio Marine's long-term strategy: finding and working with vendors that can support the company's vision of corporate business agility via service- oriented architectures, component-based design, best of breed products and integration specialists.
ICAT's vision is similar. "[The vendor] brings a set of values to the relationship," Zerkovich says, "and that set of values is about providing the solution we are specifying that integrates their technology into our framework."
Values may be harmonious, but that doesn't guarantee the marriage will last.
"Accountability is so important," says CastleBay's Grieve. "Be clear about delivery, expectations and quality, but be aware that it cuts both ways. If you tell the vendor that you'll pay for delivery once you've agreed on all the criteria, you're on the hook for paying them. If that criteria turns out to be inadequate, shame on you."
Tokio Marine's McManus is quick to point to another "accountability" challenge: working with a multi-vendor team. Tokio Marine's teams are focused on coordination and enforcement of multi-level contracts and service-level agreements, schedules, day-to-day communication and interdependency management-all occurring through multi-locations (three time zones).
"The company negotiated a fixed price on the i-flex contract," he says. "Fixing the project price initially would give the appropriate incentives and service levels, but we knew we wouldn't see everything possible in the future, so we created a formal and reliable change management process that would allow us to identify additional work as it comes up and price it accordingly."
ENFORCING CONTRACTS
Grieve believes contracts are critical, but if you need to rely on them, it may be too late. "In our experience, the last place you want to face serious problems is in the contract, because it means all other aspects of the process have failed."
However, there is still inherent benefit in defining service level agreements in a contract, adds Grieve, because both parties know it's there and understand that the insurer doesn't want to invoke that part of the contract. That message enforces that both parties would like to avoid problems, but if an insurer must take action against a vendor not upholding contractual obligations, all the contract can do is rescue some money.
"These are seven- and eight-figure projects, so that's a lot of money," says Grieve. "But that's not the worst of it. If you are dealing with a core insurance process system, you are dealing with your ability to function. Having serious problems with a vendor that can't be resolved impairs the ability of the insurer to do business. In this instance, the earlier the failure, the better for the carrier."
The best defense may be a good offense, at least for ICAT.
"If a vendor drops the ball, they know we are going to go with a different solution," says Zerkovich. "Once we implement a solution, we operate in a way that assumes the vendor may not perform as expected. We ensure that the expertise required to operate the solution resides in-house, not with the vendor."
Other protection comes by way of making expectations clear from the beginning, addressing those in its contracts and demonstrating that the technology works through a proof of concept.
"This all happens before ever moving forward with full implementation," says Zerkovich.
Main Street America also requires its vendors to conduct various on-site exercises designed to prove the technology will work on the insurer's system, and uses a combination of boilerplate and custom-designed contracts and service level agreements to enforce service and support accountability.
"The important thing is that our teams are diligent about what needs to happen to ensure our business requirements are met," says Garvey.
Although Zerkovich believes in keeping a positive view of ICAT's ongoing vendor relationships, being realistic about the "marriage" with their vendor community is key to their mutually successful relationships.
"Each vendor offers some feature that we aren't crazy about and would do differently if it were up to us," she says. "But, we accept those differences and work with it or around it. This is our job as a customer that expects integration and a commitment to co-development of sorts. Our satisfaction is related to it as well."
"Companies that understand this model understand the position of their product in your environment," she adds. "It means true customer/vendor partnerships, adherence to similar standards and the ability to work together in a co-development environment."
