Why You Need More Than One Software Vendor
Lining up a single vendor to supply most of your software seems easy but isn't always smart, says an IT management expert. With fewer vendors to choose from these days, it's best to hedge your bets.
Thu, January 10, 2008
CIO — The conventional wisdom is that it's always better to have fewer software vendors—or even a single vendor—to manage than it is to use multiple vendors. Now that, according to a recent Forrester Research report, there are only 17 large independent software vendors left, it's a good time to reevaluate this closely held belief.
CIOs who subscribe to the "one-throat-to-choke" approach to vendor management typically think about it in one of two ways: Either they want to get the various company departments that run different tools to agree to a single provider or they want to forestall deployment of new tools until their big enterprise vendor supplies them. The goal is to, one way or the other, achieve a standard platform and make running IT easier.
But reliance on a handful of vendors may not be in your best interest. This is especially true now, when the software market is consolidating. Take the recent acquisitions of business intelligence vendors Cognos (by IBM), Hyperion (by Oracle) and Business Objects (by SAP). IT customers are waiting anxiously to see what the big guys are going to do with their newly acquired products. In the meantime, IT departments should hedge their bets.
Why Vendor Standardization Is Wrong-Headed
At the core of the desire for standardization has always been the desire to optimize IT at the expense of business constituents who prefer (or believe they need) a variety of different tools to do their jobs. By reducing the number of software products to support, limiting the number of vendors to call with a problem and minimizing potential behind-the-scenes data complexity, the IT job will be easier and overall support costs will be reduced. This optimization may, however, engender substantial employee frustration during a switch to IT's preferred tool.
Another questionable justification for standardization has been that integrating products from multiple vendors along with the data from multiple systems costs much more than standardizing on fewer vendors. Unfortunately, few IT departments compare the potential costs of integration with the costs of dependency on one vendor's product. With fewer vendors in the IT portfolio, CIOs limit their negotiating leverage; vendors won't budge on terms if they don't think they have competition.
Meanwhile, standardization produces unfortunate side effects. Business constituents wait endlessly for that elusive next version or conversion. Resentment of the IT department bubbles and boils as end users' favorite tools are retired or new tools lack functionality that users want.
