The Benefits of Making 'Partner' Deals with VendorsBy Rob Garretson | Posted 10-10-2005
The Benefits of Making 'Partner' Deals with Vendors
"We serve the sickest of the sick," says Doug Bach, CIO of Colorado access, a Medicaid and Medicare HMO based in Denver. And of its 120,000 members, a mere 3 percent account for nearly half of Colorado Access's costs. This means that the sooner the HMO identifies its neediest patients, and steers them into its intensive care management programs, the more it cuts treatment costs down the road.
Thus the partnership Colorado Access forged last year with Thomson Medstat, which provides custom medical-decision-support applications to help integrate pharmacy and lab dataresults from patient cholesterol screenings, blood tests, etc.into the Medstat data warehouse of claims and treatment information.
Now Colorado Access is successfully using that clinical data to find early indicators of diabetes among its members, and it's getting those patients into early-treatment programs.
There's plenty of evidence that its intensive-care management programs are working: Tracking a specific group of high-risk members receiving the services last year, Colorado Access found they are saving more than $400 per member per month.
The best part is that Colorado Access paid nothing for the custom-developed software.
Aside from participating in weekly meetings with Medstat developers, the HMO's primary contribution was working with its third-party labs to get the data into consistent and usable formats, something it would have had to do anyway.
This was the second project the nonprofit has worked on with Ann Arbor, Mich.-based Medstat to help develop a custom application, making Bach a two-time member of a quietly growing club: CIOs forging partnerships with their software vendors to help cut the cost of, or speed access to, custom software.
Though such partnerships may not show up in IT industry research, analysts and anecdotal observations suggest they are on the rise.
They are particularly prevalent in certain vertical marketsfinancial services, healthcare and lawwhere CIOs can parlay their company's industry expertise and reputation into big savings, more influence and support and, in some cases, royalty revenue when the vendor resells the application.
The vendor, in turn, gets to go to school on the customer, developing experience and a marketing portfolio for use in future sales efforts.
|Customer Name||Colorado Access|
|Software Vendor||Thomson Medstat|
|Deal||Joint development of an application that integrates lab dataresults from blood tests, etc.into the Medstat data warehouse to help identify health plan members who are candidates for diabetes treatment.|
|Vendor Benefit||Access to live clinical data, gathered and rationalized by Colorado Access, gives Medstat a powerful new feature that is a selling point for other customers including healthcare providers, insurance plans, large employers and government agencies.|
But the driving force behind these vendor partnerships goes beyond mutual benefits. It is also born of necessity.
"One of the reasons we've seen this become more popular than it has been in the past is that companies are more and more dependent on the big enterprise application vendors," said Jim Shepherd, vice president of research at AMR Research, in Boston.
The more a company's operations rely on prepackaged software from firms such as Oracle Corp., SAP AG or Siebel Systems Inc., the more CIOs are turning to those vendors for custom development, rather than to potentially cheaper alternatives offered by third-party integrators or in-house development, added Shepard.
"If I have SAP as my application backbone, I may be using SAP's applications for 70 percent to 80 percent of all of my application functionality," said Shepherd.
"And if I'm going to build to extend that, it's more important than ever that whatever gets written is completely compatible with that SAP environment."
But like any deal, partnering with a vendor can be a tricky bit of business. Some of these deals can be the ruin of either customer or vendor. Understanding the contracts and who owns the intellectual property, and anticipating hidden costs, is imperative.
The return on intellectual
Vendor partnerships are predicated on the belief that a software vendor will emerge from the deal with something of valuebesides your money.
SAP routinely engages in what it calls "strategic development projects" with customers, typically in exchange for a 50 percent reduction in the custom development costs, according to Harald Stuckert, senior vice president and general manager of Custom Development Worldwide at SAP.
In early 2004, SAP and Coca-Cola Enterprises Inc. announced a deal to co-develop an elaborate mobile system for moving bottles and cans of soda from factories to vending machines and retail stores, with less reliance on distributors.
Atlanta-based CCE, at $18 billion in revenue, is the world's largest bottler of Coke (it's 36 percent owned by the Coca-Cola Co.), and the company is contributing its expertise in beverage marketing to help SAP improve the mobile capabilities of its mySAP Business Suite for a wide range of food and beverage industries that use a process known as direct-store delivery, or DSD.
(Executives at both CCE and SAP declined to comment on the specific financial arrangements or the progress of the development project, which is targeted for rollout in 2006.)
SAP's typical 50 percent discount pales in comparison to Colorado Access's freebie, or the occasional deal in which the vendor pays a royalty on future sales to the customer that helped develop the application.
America's Growth Capital, a boutique brokerage and investment bank based in Boston, is negotiating with its CRM software vendor to earn a royalty stream on software it co-developed that integrates the CRM application with its Cisco Systems-based VOIP (voice over IP) system.
"I think this is something they could up-sell across their entire customer base," maintains Bob Lamoureux, the bank's chief technology officer.
For incoming calls, the custom application recognizes a client on the line, extracts key account information from the off-site CRM system, and delivers it to the screen of one of the 50 bankers who will take the call, even before he or she lifts the handset.
"In five years voice over IP will be the dominant enterprise-class communications system," Lamoureux predicts. "Why wouldn't people want to have [their phone and CRM systems] integrated more tightly?"
Even without revenue from the vendor, customers can realize cash flow from a well-executed vendor partnership.
Colorado Access is a nonprofit that relies on government and private grants to defray the costs of assisting the state's most needy residents.
Its work with Thomson Medstat (part of Thomson Corp.) provides a different kind of payback.
"We don't see it as a revenue source from a royalty standpoint," said CIO Bach. "I get a product that I need, I get recognized for what we added to it, and then I'm able to use that recognition to go out and get grant funds. That's my revenue source."
Yet cost savings and bottom-line boosts aren't the only benefits, and in many cases not even the primary reasons CIOs are partnering with their software vendors.
Early access to the new application, influence over its feature set and entrance to upper-echelon support are all common dividends customers earn on their intellectual capital.
|Customer Name||De Lage Landen|
|Deal||Joint development of a risk management framework that integrates budgeting, planning, reporting and consolidation.|
|Vendor Benefit||Live data and customer expertise in financial services to help build a powerful selling point across the financial services industries.|
"We're not doing it because it's a great price," says Frank Gillman, director of technology at Allen Matkins Leck Gamble & Mallory LLP., a Los Angeles-based law firm.
"We're doing it because we think it's a great tool for the type of work we do, and therefore it's a tremendous advantage to have some say in how software we need is developed, designed and upgraded over time."
The 220-lawyer firm, with offices in five California cities, has helped a number of vendors build products aimed at the estimated 3,500 midsize (those with between 50 and 250 lawyers) law firms nationwide.
The list of products Allen Matkins has adopted early and helped tailor for other law firms includes FrontBridge Technologies Inc. anti-spam and e-mail management software, WAN appliances from Riverbed Technology Inc., Softlink's Liberty3 library automation software, LexisNexis' InterAction CRM software and Thomson Corp.'s Hubbard One suite of law firm management applications, called FirmConnect.
"The practice of law is all about making a deal, so it's tempting to maximize the value of the projects we do," Gillman notes.
"We are getting the benefit of effectively having our solution delivered to us, without us having to develop it ourselves," says Brian Arculus, CIO of De Lage Landen, a Dutch provider of leasing and vendor-financing services.
Earlier this year, DLL entered into a partnership with Hyperion in order to integrate modules of performance-management software and create a risk-management framework for the financial services industry.
"If Hyperion is successful in selling exactly the same concept elsewhere, we don't get a penny of it, but we're getting enough benefit out of it because we're getting it first and getting it our way," adds Arculus.
Development partners also gain access to their vendors' top technical resources and decision makers, not only during, but often long after the custom software development is done, CIOs note.
The more vital the custom software is to the organization's business, the more valuable this bonus is.
"If it's a vendor we've worked with for years, helping them out also means that when Allen Matkins has a problem, we know that we'll be right at the top of the food chain in terms of support," Gillman added.
"To me that's the most critical [advantage]. I love the fact that when I have a problem with any of the products we use, I can pretty much call right to the top. It makes usITlook like we have access to a much broader network of resources than we do."
Arming the Enemy
CIOs who have partnered with vendors dismiss the common fear that they give away competitive advantage by allowing their intellectual capital to be built into products that are ultimately marketed to competitors.
Most have some critical internal or customer-facing applications that would never be shared through a vendor partnership, for fear of giving away competitive advantage.
But for back-office and other applications, the lead time they enjoy by being the first to deploy the software provides sufficient advantage.
Also, subsequent improvements in the software, gained from its wider use throughout their industry, provide a long-term benefit.
"There's a lot of talk about competitive edge in specific elements of software, but I actually don't buy into it," DLL's Arculus said. "Because it's what an organization does with the software that's importanthow they use it, not the actual core software.
"We're not really giving anything away to the competition. If a direct competitor picks up exactly the same product, it tends to improve the product to our benefit, as well. The subject is regularly brought up, but it's one that I personally don't have much concern about."
"The more successful the company and the product, the more enriched the product is going to become over time for you," adds John Sroka, CIO of Duane Morris LLP, a 550-lawyer firm based in Philadelphia that has helped a pair of vendors build software that integrates digital dictation and imaging with document management systems tailored to law firms.
But other concerns are bedeviling this growing practice.
Balancing company-specific requirements against the vendor's need to build capabilities that will have broader appeal across an entire industry can be tricky.
So can integrating new custom software with critical existing corporate applications. And serving as both development partner and beta tester typically places more of the quality-control burden on the customer.
"Clearly there's an expanded time of testing that we have to do, versus with an application that's in wider use," acknowledged Gilman of Allen Matkins.
"There's the potential that another product that we use, and that, ideally, we would love to have integrate with the new product, doesn't, because the new product is simply too new.
"There have been times when we've been offered a deal that we'd love to do, and some of our other key products just can't support it, so we can't."
And for every success story a CIO is proud to share, there are likely one or more failed partnerships that no one is talking about.
Particularly troublesome have been partnerships in which customer and vendor have shared ownership of the resulting intellectual property, creating legal and competitive complexities that eventually doomed the deal.
"Over an extended period of time, I can't think of a single one that hasn't been a disaster," says AMR Research's Shepherd. "And it's almost always an overreaching CIO who decides that the software business is more interesting than his business. It's an ego thing. When you look at the business proposition, the money or rights or capabilities that would be available to you, it's not worth the legal fees to negotiate the contract."
Though consultants and lawyers won't identify current clients who've been burned in a vendor partnership, David Whitinger, director of consulting for ICN (International Computer Negotiations Inc.), a Winter Park, Fla., consultancy that advises clients on how to negotiate better deals with vendors, tells of one large, well-known company that paid to have a back-office logistics application custom developed, but failed to negotiate ownership of the software.
The vendor ultimately "productized it," licensing the narrowly focused vertical application to direct competitors of the original customer.
But worse than any competitive advantage lost by sharing the software was the fact that the company ended up having to license the application again when it came time to upgrade.
"They just got into this quagmire of issues because they didn't own the software," Whitinger laments.
"We always recommend that if you pay for it, you own it. If you're going to have custom development, then you should own the rights to that software. You shouldn't accept a license."
Another unnamed ICN client, also a large, household name ("one of the ten most recognized names on the planet," Whitinger says), suffered an opposite but equally unfortunate fate.
Working with a major software developer to help design a complex new application, the corporation put people, time and money into the development, but for whatever reason, the product never came to market.
Not only was it a major waste of resources, it also exposed the customer to potential liability. Cautions Whitinger: "If someone buys the software based on, in part, you participating [in its development] and you recommending it, and it doesn't work or it never goes to market, they can sue you."
Bye, Bye Baan
When things go wrong in a vendor partnership, it's not always the customer who suffers most.
One example is the union of Boeing Co. and Dutch ERP software developer, Baanan unbalanced partnership that many observers cite as a prime contributor to the software company's financial collapse.
In the 1990s, Baan emerged as a solid, mid-market ERP vendor, popular with companies that manufactured large, complex systems.
It had some experience selling to the aircraft industry, but only to smaller companies dwarfed by Boeing's commercial aircraft division.
When Boeing Commercial Airplanes decided it would forsake its tradition of building all its software in-house and find an ERP package, it discovered that none of the commercial packages worked exactly the way it wanted them to.
It chose Baan under the condition that Baan develop a custom version of its software suite for Boeing.
"Boeing was going to help Baan become a power in the aerospace and defense industries. They didn't," Shepherd said.
"Boeing got a bunch of custom code. Baan was never able to sell it to anybody else [and] was financially crippled by the experience. It helped to precipitate their decline."
That type of partnershipbetween a large corporation with all the clout and a much smaller or unhealthy software house desperate for credibility, or even just the businessis often doomed to failure, Shepherd said.
"What happens is that the large company ends up specifying a set of requirements that are a perfect fit for them, but don't make any sense for the software company's business."
|Customer Name||Coca-Cola Enterprises|
|Deal||Co-development of an elaborate mobile system for linking field sales reps, delivery drivers and vending machine service staff to bottlers' back-end IT systems.|
|Vendor Benefit||CCE's expertise to broaden the DSD capabilities of mySAP suite, making it more attractive throughout the beverage and other consumer products industries.|
In such cases, not only has the customer jeopardized a vendor that it must also rely on for enhancements and support, it also ends up with "an application that hasn't been validated by anyone else in the market, so it doesn't necessarily represent best practices. It represents the way the company does things or the way they'd like to do them," Shepherd says.
CIOs who've forged successful partnerships with their software vendors agree on the keys to success, the most important being a balanced relationship in which both sides contribute and benefit about equally.
Typical customer-vendor relationshipsvendors attempting to maximize profit and minimize risk combined with customers trying to negotiate a rock-bottom pricedon't make for smooth partnerships, proponents say.
"Partnerships work when there's an equal contribution. And that doesn't mean equal share, or that you've got to have a joint venture with 50-50 equity," said Arculus of De Lage Landen.
"It means that the contributions to the relationship have to have equivalence. If you don't have that balance, it's a one-sided relationship, not a partnership."
ROB GARRETSON has more than 20 years' experience as a business and technology journalist, most recently as a reporter and an editor on the financial desk of The Washington Post.