Supply-chain software vendors would love to keep on selling you product. But first there's a little matter of those systems that you purchased a few years ago, but never got around to implementing.

It's called shelfware, and, in the aftermath of the high-tech collapse, it's still a problem. In a recent report, former Accenture consultant David L. Anderson cites estimates that vendors sold more than $15bn in supply-chain software between 1999 and 2002. Yet much of that product sits gathering dust. Nerendra Mulani, an Accenture partner in Chicago, speculates that more than half the software sold between 1995 and 2002 is still shelfware.

The dilemma has multiple consequences. One is residual anger that some buyers feel about vendors who sold them more systems than they needed. Another is the possible impact on IT budgets for 2004, as new purchases are postponed in favor of activating unused programs. Most of all, the shelfware situation means many companies aren't reaping the benefits of some valuable tools, and could suffer competitively as a result.

The amount of shelfware depends on the type of application. A survey of 132 companies by AMR Research Inc., conducted earlier this year, found that only 1 percent of the buyers of supply-chain management suites had failed to implement the demand-planning module. That application requires less integration with other enterprise systems than other SCM components, explains AMR's Larry Lapide.

The number climbs to 15 percent, however, for manufacturing planning and scheduling modules, which had the highest rate of shelfware among surveyed buyers. The need to tie those systems to plant operations on a real-time basis is one reason why companies have put off their implementation, AMR says. Just 3 percent of the sampling had yet to implement supply planning, which offers such vital functions as order promising and multi-site inventory planning.

Nor were enterprise resource planning vendors immune, despite the rage for that type of system in the late 1990s. A recent study by Morgan Stanley found that 20 percent of ERP licenses weren't implemented, according to Sarinder Chhabra, senior vice president of customer support and services for Dallas-based i2 Technologies. The number is even higher for customer-relationship management software, where shelfware is said to account for more than 40 percent of recent purchases, Chhabra says.

Shelfware falls into two general categories, Lapide says. There are the systems that companies bought and never used. Others were only partially implemented, as part of a big suite of applications. Companies might not even know they have certain software, if they purchased an ERP suite with extra functions, Mulani says. But they're still paying license and maintenance fees for all of those products.

What's the Reason?
Why have companies failed to deploy software for which they've paid? They might have acquired systems intended for multiple locations, but only installed them at one place, Mulani says. Or the suite itself was so complex, incorporating such varied functions as planning, fulfillment and available-to-promise, that IT managers "ran out of steam." In some cases, the company's "super-user" might have departed, voluntarily or not, leaving the project in limbo.

The sluggish economy is another factor. Some shelfware consists of bypassed upgrade opportunities, says Lori Mitchell-Keller, senior vice president of market and technology strategy with Manugistics in Rockville, Md. Three or four years ago, companies were upgrading key systems annually. Now, strapped for resources, they're waiting 18 to 24 months. As a result, they could be missing out on new features that could greatly improve operations.

But the larger problem, experts say, can be traced to the high-tech euphoria of the 1990s. Hype over the promise of the internet caused many companies to pursue multi-channel sales and distribution strategies regardless of the consequences. Eager to reduce cycle times and configure goods to order, "they bought the lure that technology could help them to get there," Mulani says. "But you've got to have a cohesive operating model, defining how the new channel fits into your overall fulfillment strategy."

What companies forgot to do, says Lapide, is change their business processes in line with the software. Never mind that many applications require fresh approaches to sales and operations planning, constraint-based production scheduling, and centralized master planning. Desperate to meet the Y2K deadline for installing ERP and other systems, implementers simply slapped them on top of existing procedures. Not only did the products fail to perform as expected, certain modules that required deeper changes in order to function never got turned on at all.

Optimization packages are especially tough to implement without revamping the organization, Lapide says. They require several months to install, as companies come to trust the systems' conclusions over those of spreadsheets and human experts. Help from the original software vendor, as well as system integrators, is often needed. Unfortunately, as the economy slowed and budgets tightened, project managers found they had neither the money nor the people to do the job.

At least some of the blame rests with vendors, suggests Karen Peterson, vice president and research director with Gartner in Stamford, Conn. To pump up sales, they offered deals to entice companies to buy more than they needed at the moment. It wasn't unusual for a buyer to license a vendor's entire suite of applications, without even knowing what the modules were. And sellers could be vague about what their products were supposed to do in the first place. Everyone, it seemed, had an "end-to-end solution" for the supply chain.

As budgets dwindled, IT executives grew angry at the vendors who had promised huge benefits, and made correspondingly huge sales, Peterson says. Some stopped buying software altogether. "They didn't like anybody," she says. "It was almost a militant stance."

Lapide disagrees that vendors oversold their products to any great degree. If they were guilty of anything, he says, it was underestimating the time it takes to implement their systems. In the AMR survey of supply-chain planning software, 39 percent of respondents said implementation took more than 12 months, while another 21 percent reported a period of between nine and 12 months. Length of implementation was a major reason why 25 percent of users said their software vendors fell below expectations.

Buyers Exuberant, Too
Buyers were just as culpable for being overly optimistic about the benefits that technology could bring to their organizations. Says Lapide: "Users bought into some of the story and sold their own management on it."

At the height of the hype cycle, software purchases often were based on "defense and fear," says Tim Minahan, vice president of supply-chain research with the Aberdeen Group in Boston. Companies would spend money just because their competitors were doing the same thing. They were especially susceptible to the lure of the internet, jumping into online industry exchanges and net markets before those tools could be economically justified.

"We [supply-chain practitioners in general] got carried away with ourselves," says Jonathan Colehower, vice president of supply-chain management with Redwood Shores, Calif.-based Oracle Corp. "We lost sight of the basics." Vendors and buyers alike overreacted to the market for new and dazzling applications.

Vendors might sell half a dozen modules or more, only to see users put on the brakes when the first implementation blew the budget, Colehower says. Both sides would come to learn a hard, if retrospectively obvious, lesson: "A lot of the software we want to buy is limited by our ability to consume it."

To Christian Knoll, vice president of global supply-chain initiatives with SAP AG of Walldorf, Germany, shelfware is in the eyes of the beholder. He says many purchases of application suites are made with a long-term strategic plan in mind. Companies looking three to five years ahead don't expect to implement everything at once, he says. Modules planned for later use might appear to be shelfware, but they're really part of the larger scheme.

Knoll acknowledges a gap between what SAP has sold and what has been implemented. Yet customers are gradually going live with projects that take a substantial amount of time to complete, he says. At each phase, the goal is to maximize return on investment from any given piece of the puzzle.

Some shelfware might be the result of a shift in thinking about so-called best-of-breed software, versus acquiring multiple applications from the same provider. Mega-vendors such as SAP and Oracle Corp. have long argued that users can avoid integration headaches by adopting the latter approach.

Now, companies might be listening. Knoll says customers tend to favor the single-vendor strategy in tough economic times, because the total cost of ownership is lower. While others dispute that claim, IT managers must nevertheless be wondering whether their unused best-of-breed applications, purchased several years ago, are worth turning on. As integrated vendors add functionality, they increasingly argue that the extra features of a stand-alone package aren't worth the headaches of linking disparate systems.

Companies are walking away from best-of-breed strategies, claims Colehower, "but not as fast as I would like it to happen." (Oracle styles itself as an integrated provider that deploys in-house applications wherever possible.) While some are writing off what they view as obsolete systems, he says, others are determined to draw value from what's on hand - and paid for.

Mitchell-Keller, on the other hand, claims that it's often cheaper and more effective to install a stand-alone supply-chain planning module, such as that of Manugistics, rather than rely on the generic capabilities of a large ERP system.

In the end, the decision on whether to activate best-of-breed software, or banish it to a state of permanent shelfware, is an individual one. "Vendor consolidation is a strategy that some companies are deploying," says Minahan. "Unfortunately, it often requires that companies give up a little bit of functionality. Very few vendors are a mile wide and a mile deep."

Where to Start?
The obvious preference for companies with tight IT budgets - and that's virtually everyone these days - is to make use of existing applications. But getting started can be a daunting task.

Managers must determine what's still valuable, what to address first, how much time and money it will take, and what to discard. Minahan suggests deployment of an internal "SWOT" team. Coined by the military, the acronym stands for Strengths, Weaknesses, Opportunities and Threats. Its equivalent in the corporate world is a group of managers who conduct a high-level assessment of all the company's software licenses, whether implemented or not. The aim is to uncover the best opportunities for utilizing existing technology.

Systems should be ranked according to what they'll achieve and the speed of their return on investment, Minahan says. The original vendors should be called in for guidance, especially with respect to application upgrades that might have become available. Users should expect to pay for their help, but depending on the size of the customer and how much it has bought, there could be room for negotiations over license and maintenance expense. Chhabra suggests companies ask for a discount on their maintenance fees during the period of implementation.

Competitive Advantage
Peterson says companies should weigh competitive advantage in addition to strict ROI. Lower inventories could give the user an edge in markets with high supply-chain costs. And systems shouldn't be activated just for the sake of eliminating shelfware. "Figure out what your priorities are," Peterson says, "then match them to what you've got sitting on the shelf."

According to Mulani, most decisions today are made with two concerns in mind: improving customer relations, and reducing the overall cost of serving that customer. An unused system that delivers available-to-promise capability, for example, might take precedence because it achieves both goals.

SAP works closely with outside systems integrators to help customers realize value on dormant applications. While S.I.s end up doing 80 percent of the work, Knoll says, SAP can help customers locate their specific "pain points" and prioritize their needs.

Implementation costs might be high, Knoll adds, "but the value they can generate out of it makes the business case."

Oracle takes a similar approach. "We help customers in the same way you get any cycle moving," says Colehower. "First you define what the business problem is. Based on that, you can do an assessment of what the company already owns." Oracle then recommends the activation of suitable modules to achieve the user's main objectives.

Mitchell-Keller agrees that companies should look beyond cost savings in deciding which shelfware to activate. The real goal, she says, should be value from implementation. A forecasting module, for example, can help to balance the need for lower inventories with that of increased customer satisfaction. It might even conclude that higher stocks are needed in some places in order to beat the competition.

Similarly, she says, a company might strive to reduce its supply of work in progress while managing a just-in-time delivery pipeline. The result is a maximization of production time for the most critical items.

Chhabra says it's in the interest of both parties to get dormant applications up and running. "If our product sits on the shelf, we get a bad name with the customer." And, with more than 70 percent of a software vendor's business generated by existing accounts, customer goodwill is paramount. So i2 reps will personally visit customers that might have a problem with shelfware, and advise them on how to proceed.

The effort is part of i2's Business Optimization Services, whereby the vendor helps customers to realize continuous improvements from existing supply-chain applications. Errant systems can even be taken to India, where much of i2's support staff resides, for fine-tuning and integration with other applications.

Chhabra further recommends that companies consult with independent user groups, whose members often have experienced the same implementation issues. "It's amazing what you learn at these forums," he says.

There are signs that the shelfware problem is lessening. Peterson believes it peaked about a year and a half ago. Vendors are now tightening up their marketing messages, as users write off useless applications, reconsider the valuable ones, and renegotiate maintenance fees in order to take the sting out of delayed implementations.

Gone are the days of what Peterson terms "irrational exuberance and over-promising" on both sides of the fence. With budgets still limited and economic recovery uncertain, customers are taking a much less starry-eyed approach to technology. "They want to know about new software areas related to their core competencies," says Mitchell-Keller, "but they're no longer asking what's the next hot application area."

"There's very little aspirational talk these days," agrees Mulani. "As a vendor, you want to lay out a vision. But in the end, the purchase is being made according to very specific operating strategies and business scenarios that need to be addressed right now."

Lapide says companies are buying software on a pay-as-you-go basis, realizing the benefits of one application before moving on to the next. Vendors can no longer demand payment for an entire suite at the onset, then lay out a prolonged implementation schedule to which the customer might be unable to adhere.

Corporate memories are notoriously short, and economic cycles ensure that software sales will recover to some extent. Yet shelfware isn't likely to reach the level of the late 1990s anytime soon, experts believe. "In three to four years, people will forget," says Lapide. "But I don't think they're going to go on a buying binge."