Hardly a week goes by in which we don't learn of one insurance technology vendor forming an alliance with another vendor. Many of these alliances prove to be beneficial for both vendors involved and the insurance carriers that have purchased their products, but what if it is the insurance carrier bringing disparate vendors together?
"Some vendors are more disposed to working with other vendors for the good of the common carrier client regardless of whether the [vendors] have a relationship outside of that particular carrier," says George Grieve, president of CastleBay Consulting. "Some vendors are protective of their intellectual capital and are fairly standoffish in working with others and sharing information. Some vendors may have partnerships, and some may not. There are two or three different variables there."
Trae Jones, vice president of ATSC (formerly Appix), compares vendor relationships to personal relationships in that they can blossom and prove to be strong, long-term bonds, or they can fail for a variety of reasons.
When looking at what enables a relationship to succeed, Jones believes there are four major factors:
o It has to be mutually beneficial.
o Open communication is needed.
o There have to be effective incentives for both parties.
o The offerings of both parties have to be truly complementary.
"If there's a lack of any one of these factors, it can cause the relationship to self-destruct," Jones says. "If [all aspects] are there, the vendors can develop relationships that can bring financial and market-share gains for both parties."
Carriers can get by without all four, but Jones believes those cases are mere happenstance. "There would need to be some luck involved," he says. "In terms of long-term [situations] where the vendors' relationship will prove to be mutually beneficial, all four factors must be there because your luck just can't last that long."
The important question to consider, according to Grieve, is not whether a vendor works well with other vendors but rather how well carriers manage vendors. In his view, "not well at all, in general," he maintains. The kinds of things one might expect carriers to do, such as having common meetings, conference calls, or updates with vendors, where they discuss their plans and how that will affect the relationships, are rare, observes Grieve. "Those are things you almost never come across and are things that should be done," he says.
Stuart Bailey, vice president, claims, for Unitrin Business Insurance, believes some vendors become concerned about sharing ideas with other vendors, but it is the carrier's responsibility to make multivendor projects work. "What the purchaser of the service has to do is make it known upfront [the vendors] have to work as a team no matter what the project is," he says.
The state of a carrier's relationship with its vendors has two variables, explains Grieve. The first relates to the position of the carrier in terms of the life cycle of software implementation that is undertaken. "If the carrier is in a steady state where it has implemented what it wants to implement and that has been integrated and is doing what the carrier wants it to be doing, then promoting relationships with the vendor is not very important," he says.
The second variable, continues Grieve, involves the maturation cycle of one or more of the vendors and the purchased products. The carrier may have achieved a steady state where all its systems speak with one another, but if one vendor puts out a major release of software the carrier must adopt even though it will affect how the systems communicate with each other, then the carrier has an issue that wasn't caused internally but rather by one of the vendors. "If you have mature vendor software and a stable, mature environment in your shop, the extent to which those vendors work together doesn't matter much," says Grieve. "If you have a change either in the vendor community or in your internal application architecture, having those vendors know what's going on and coordinating are very important."
A best-of-breed approach is more likely to be implemented at a midsize or large carrier, Jones suggests, because small carriers can't afford the additional costs involved of having vendors perform extra integration. Also, he believes the risk is higher with a best-of-breed approach vs. a single vendor solution, and a small carrier is not going to have the IT shop needed to perform that additional integration support.
Several issues must be addressed when starting a replacement project. An important one is the architecture. "There is no question systems that have a service-oriented architecture are going to allow for easier integration with other potential vendors down the line," says Jones.
A second issue the carrier needs to explore is if and how the system has been integrated with other third-party solutions. "You want to press the vendor during the evaluation process to see whether [its product] has been integrated successfully with other third-party solutions," advises Jones.
Grieve recommends carriers ask the following four questions when interviewing potential vendors:
o With what environment is the software compatible?
o How often is the software updated?
o For a given release profile, as a carrier, what do I have to do to accept that release, and what do I have to watch out for to integrate with other vendors?
o What established partnerships does the vendor have with other software vendors?
"Those four questions give you a pretty good sense of whom you are dealing with," asserts Grieve.
At Great American Insurance Co., CIO Piyush Singh has organized a vendor summit each of the last three years, bringing together nearly all the carrier's vendors–software and hardware–at Great American's Cincinnati, Ohio, headquarters.
"What I aim to achieve is to ensure we can explain to all of our vendors what our strategy is, where we are headed, and what is being felt in our business environment," says Singh. The summit benefits Great American in that it allows the vendors to present where they are with their products being utilized in GAIC and be in the same room with every other vendor so they can realize they are part of what Singh calls "a larger ecosystem within the carrier.
"[Vendors] don't exist by themselves," says Singh. "To make things work, especially in our service-oriented world, we have to ensure the solutions work with each other and not have me calling five different vendors and have them each pointing fingers at what the other guys have done.
"[The vendors] make contacts and learn what the challenges are," relates Singh. "After the presentations, we have an hour of open discussion among all the vendors and phrase the issues we face." The sessions are informal, and Great American likes to mix things up socially, including an evening trip to a Cincinnati Reds baseball game at Great American Ball Park.
Among the topics tackled are the challenges the carrier has with its vendor community, according to Singh. The vendors also address their challenges working with the carrier world. "They talk about the situations they face, how they could help us, and what things could work or not work based on best practices," he says. "It is a very useful discussion for everyone."
Holding a vendor summit similar to Great American's is uncommon, notes Grieve. Smaller carriers rely more heavily on vendors for their software needs, he adds, whereas larger companies still tend to build their software. "However, it's the large companies that have established governance and vendor management practices," he says. "Smaller companies don't have the budget and the number of staff available to do those things."
Small and medium-size companies need to do more vendor management, though, contends Grieve. He describes Great American as a "big medium-size company that buys a lot of software, so it probably is as well placed as you can get to afford to formally manage and coordinate vendors. It has the money and the talent to do that, but it is not that big to go out and build all its software."
Grieve finds most carriers do vendor management on a situational basis, but he feels it should be part of their ongoing management. "What they do is manage point to point," he says. "They manage vendor A and vendor B like a set of spokes with [the carrier] at the hub. What they need to do is introduce these vendors to each other. I think what Piyush [Singh] is doing is unusual, and I think it's healthy."
When Singh first proposed the summit after joining Great American in 2006, the vendors were concerned about the benefits they would receive and had doubts about making presentations in front of a room full of other vendors. "But at the end of the day, they all realized everyone had a much better perspective of what was going on in the larger world," Singh says.
When he joined the carrier, Singh felt this would be a good way to bring all of the carrier's partners together. "The first year everyone freaked out and said, 'How can I present in 10 minutes?' We told them that's all you get and to think of it as an elevator speech," he recalls.
The summit also enables Singh and his staff to meet all the vendors in one day, rather than having a steady stream of them come through the carrier's offices throughout the year. "I don't have time to meet with every vendor and explain our strategy," he says. "If they can learn a little more about our environment [in this manner], everyone becomes better off."
When Bailey joined Unitrin, it had older technology in place for managing the claims system. "It was a good system, but it was green-screen technology," he says. "There were a lot of things still being done manually."
Bailey found himself with as many as six different vendors/software products. One of the issues he examined was productivity. With multiple systems came multiple log-on procedures and different rules. Another problem involved the difficulty in managing the final work product of those on the staff. Specifically, when data was entered into one package and the same data was entered into a different package, the people hired, trained, and paid to do high-level professional tasks were relegated to some degree to more of a data-entry-level person.
"I challenged CSC to help us with some of this," says Bailey. "We asked what we could do to bring this into one common-looking database. Because of the different vendors, we knew we weren't going to have one database to work from. But from an end-user perspective, I wanted it to look like one software package."
CSC created what it calls the Claims Desktop, taking a software package and parking it on all of the different products Unitrin had. "Not only did CSC create a single log-on, it carried that log-on to all the different vendors I had attached to that. It then allowed us to enter the data one time into that software package and pushed data to the other software packages, so you enter it only once."
Most of the vendors were very eager to interface with Claims Desktop, Bailey explains, because the interfaces didn't require the vendors to convey secret information or a programming language that was proprietary. "The ability to get the different vendors to cooperate and work together was to their benefit," points out Bailey. "When a company goes out and markets itself, it can say it already interfaces. It's a semi-marketing tool, but more importantly, it provides the service the customer needs."
A change in the software environment affects the way carriers manage vendors, as well. Grieve believes many newer vendors have decided the footprint of their software is smaller than that of the legacy vendors. "If you look at [newer] policy admin vendors, they are not writing rating engines, print engines, underwriting rules engines," he says. "What they are writing is what is peculiar to a policy admin system and nothing else."
Those newer vendors need to have strategic alliances to fill in the components they don't offer. "So, it's common for a policy admin vendor to have an established partner that is, say, a rating-engine vendor," says Grieve. "Those relationships are fundamentally good so long as they are real–they have to have done an implementation together in order for it to mean anything. It can't just be a marketing ploy."
Carriers need to do their research when they are evaluating a multivendor solution approach. "The risk-vs.-reward analysis is critical," says Jones. The benefit to using one vendor's partner to fill a functionality gap holds true only if the solutions have been integrated successfully, he cautions. "My advice to carriers is they need to be very careful if they are looking to bring vendor partners to the table that this partnership is not in name only," adds Jones. "The carrier needs to understand exactly how the vendors have tested the integration of their products and what their story is in terms of having a continuing, long-term relationship."
Carriers always need to be concerned with vendor updates, points out Grieve. New releases normally fall into two categories–fixing bugs and major upgrades. Fixing bugs in a system usually doesn't affect the carrier's integration of systems, but major releases can have implications for other systems in the suite.
"Nobody wishes us back to the days of the mainframe, but one of the good things about the mainframe was there basically was one vendor that had control over virtually everything in your shop," says Grieve. "Nowadays, there are myriad vendors, and the vendor management issue is more complex than it has ever been."
Once vendors understand the concept the carrier is working on, Bailey indicates, most of them are anxious to enter into a collaborative relationship. "They recognize the potential opportunities that are available for them and how much their product can be enhanced by interfacing with other vendors," he says. "Sam Walton once said to steal shamelessly from your competitors. His concept was to take their ideas and be open to what others had to say and how that could marry into your product. When you are collaborating with other people, the creative juices start to flow."
© Arc, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.