Print this article | Return to Article | Return to CFO.com
Once again, problematic ERP installations are making headlines. It's time to ask, How much of the problem is really the software?
Andrew Osterland, CFO Magazine
January 1, 2000
Last July was a hot month in Pennsylvania, but the IT managers at Hershey Foods Corp. headquarters, in Hershey, Pennsylvania, were feeling a different kind of heat. For the past three years, they and four different teams of consultants had been working on a massive enterprise resource planning (ERP) software system from SAP AG and two other software vendors that would put the company's operations on one integrated computing platform. The $115 million system would replace scores of legacy systems that were currently running everything from inventory to order processing to human resources. They were three months behind schedule, and itching to flip the switch on the project. It would all go live simultaneously across the enterprise with one big bang.
Big bang? Big flop. By mid-September, the company was still trying to fix glitches in its order-processing and shipping functions. During the busiest season of the year, big customers like WalMart and Kmart were loading up on extra Halloween candy from competitors like Mars and Nestlé, while Hershey warehouses piled up with undelivered Kisses, Twizzlers, and peanut-butter cups. The upshot: third-quarter sales dropped by a staggering 12.4 percent compared with last year, and earnings were off 18.6 percent.
A week after Hershey's disappointment, Whirlpool, a leading manufacturer of household appliances, announced similar though less severe problems with its SAP implementation. In fact, the two companies are just the latest additions to a long list of companies that includes Dow Chemical, Boeing, Dell Computer, Apple Computer, and Waste Management that have struggled in varying degrees with ERP projects.
What's going on here? Since 1992, when market leader SAP introduced R/3, the first client/server-based ERP system, thousands of companies worldwide have implemented the software. Many have been successful, but none has been without problems. Indeed, since at least 1996, SAP and the others have worked vigorously to respond to customer complaints about complexity and difficulty of implementation. But horror stories about SAP implementations (and, to a lesser extent, competing products like those from PeopleSoft, Oracle, Baan, and J.D. Edwards) persist.
Where Did Hershey Go Astray?
Like most companies with snarled ERP projects, Hershey hasn't offered many details. But outsiders point to two notable errors the company made. The first involves timing. When installing a famously complex product like SAP's R/3, the busiest season of the year is not the time to take the system live. Snags always arise, and it's far easier to iron them out during less busy periods of the year, says Kamalesh Dwivedi, chief information officer for telecom equipment maker ADC Telecommunications. Dwivedi and Minnetonka, Minnesota-based ADC managed to accomplish a rarity in the world of corporate computing: a big-bang R/3 implementation completed on time and under budget.
Dwivedi, who was involved in two other successful R/3 implementations, suggests that the best time to go live with an ERP system is at the end of the first month of a quarter. That way, the company is through its financial reporting from the previous quarter and still far enough from the next to provide time for troubleshooting with a new system. "It takes three to six weeks after going live to identify and fix problems," says Dwivedi. That may seem absurdly optimistic to IT managers who have spent years tinkering with SAP systems. But if Hershey had gone live in April, as originally planned (the company did not disclose reasons for the delay), at least it would have had more time to fix problems before the rush of transactions from the busy fall season.
Second, Hershey attempted to do too much at once. Installing SAP's R/3 software is complicated enough. Throw in a customer-relations management program from Siebel Systems and a logistics package from Manugistics, and the project becomes dangerously complex.
But not impossible. In another ambitious SAP installation, Amoco Corp. (now BP Amoco) successfully implemented R/3 in all 17 of its business groups. It kept legacy systems in several departments, such as production planning and human resources, that had to be integrated into the SAP platform.
Steve Grossmann, Amoco's SAP manager at the time, says the project was accomplished in five separate implementations. "These were big bangs," says Grossmann, whose department has since been outsourced to PricewaterhouseCoopers. "People walked out Friday, and when they came back Monday, their whole world was upside down."
Hershey can relate. But the differences between the two installations are significant. Amoco did not implement other software at the same time as R/3, avoiding the gnarly issues of integrating multiple new applications. And it took its time between the five major rollouts of the R/3 system, which began in March 1996 and finished last summer. Grossmann says Amoco had its problems, but nothing like the major business disruptions Hershey is experiencing. Hershey, unfortunately, did not have the luxury of time. With Y2K looming, it may have felt pressure to get all three software packages up and running before the end of the year. It is now left with a mess that will continue to hurt the company heading into next year. "There were three cooks in that kitchen," says Stephen Cole, research director of Forrester Research, in Cambridge, Massachusetts. "That's why there is so much finger-pointing going on."
The Internal Fix
Beyond the apparent mistakes at Hershey, there are plenty of other ways for ERP implementations to go awry. Advice from successful implementers suggests ways to avoid at least the biggest potholes.
Number one. Make sure an ERP system is right for your company, suggests ADC chief financial officer Robert Switz. That may sound obvious, but no off-the-shelf software package is a panacea for a corporation's computing needs. And neither vendors nor the consultants that install the systems have much incentive to discourage prospective buyers. SAP was designed for manufacturing companies with predictable, similar ways of doing business. It is not particularly adept at handling front-end, customer-related operations. Allied Waste, a provider of waste management services, decided to scrap a $150 million ERP system it inherited through its acquisition of Browning-Ferris last August, because it felt its business practices couldn't be squeezed into the SAP mold.
Some businesses, such as telecommunications-service providers, have such sophisticated billing operations that no standardized ERP package could replace customized software produced in-house. Other companies, including Hershey, have chosen to graft different customer-relationship management (CRM) applications onto their back-office R/3 platform. That increases the number of interfaces and touch points where problems can arise. Before embarking on an ERP project, senior managers should assess whether they can — and want — to standardize business processes around one common template.
Number two. Understand the implications of customizing the software. However tempting it may be to preserve specific business processes by altering the software code, customization almost always means trouble. "Modify the code as a last resort," suggests SAP America's CEO, Kevin McKay. "You don't want to go there, because it hurts performance" — particularly when companies seek to upgrade their systems. When ERP vendors add new functionalities to their product, they usually involve changes to the database and to the data-entry screens. Any new data or fields that have been added to the software code could be wiped out or altered by upgrades. The testing and retesting of customized elements can provide expensive headaches for years to come. "Don't change the code," says ADC's Switz. Change the business process instead.
Number three. Develop performance measures for the system. Many senior executives have been dismayed at the apparent lack of cost savings they achieve by implementing ERP systems. It takes work, says Dan Spaulding, the former director of management reporting at energy services company Halliburton, in Dallas.
"We thought the benefits [of the ERP system] would just naturally happen, but they don't," he says. Spaulding developed 28 key performance indicators (kpi), including inventory turns and accounts receivable days outstanding, as well as 100 secondary indicators, to help assess the effectiveness of the R/3 implementation at Halliburton. He and other members of a "value delivery group" — separate from the R/3 project team — monitored these indicators and focused on improving them.
Number four. Control your consultant. Everyone needs consulting help for an ERP implementation. It's a question of how much. Switz suggests that, before hearing the sales pitches of consultants, senior executives should be clear about what their own IT staff can do, and what they need from consultants. Then interview the staff proposed for the project and draft a contract that spells out which individual consultant will spend what percentage of his or her time on the project, and how any staff changes will be handled. Switz, for example, conducted reference checks to identify and book the top SAP consultant at CSC Consulting before signing a deal. He also negotiated a pay-for-performance scheme that would pay CSC from 85 percent to 115 percent of its compensation based on the meeting of specific milestones.
Switz ended up happily paying more than 100 percent of the fee. The alignment of consultants' interests with the client's is the best way to get the help needed and get the consultants out. "You've got to set a date for saying good-bye," says Switz.
Number Five. Control your internal politics. Consultants can't deal with the turmoil involved in ERP implementations by themselves. Department heads are sure to present excellent reasons why the new system won't work on their turf. Their resistance to change can stall projects cold. Switz argues that ERP implementations are every bit as complicated as new plant constructions, and should be managed as such, with as much buy-in from the top. CEOs and CFOs have to visibly support and monitor the progress of the project.
Most of these recommendations are not new. What's striking is that at this date, more companies don't follow them.
For most of this decade, enterprise computing has been a fee-generating gold mine for consultants. But payback time could be around the corner.
On November 2, 1999, W.L. Gore & Associates, the maker of GoreTex, filed a lawsuit against Deloitte Consulting, which Gore had hired to install a human-resources software package back in July 1997. The project did not go well. Gore is charging Deloitte with breach of contract, fraud, and negligence, and seeks recovery of the $3.5 million in fees it paid to Deloitte. For good measure, the Gore suit also names PeopleSoft, the maker of the software, for certifying an incompetent party.
Another company, SunLite Casual Furniture, accuses Deloitte of worse. Along with allegations of incompetence and overbilling, SunLite's suit, filed in Arkansas, charges the consultant with maliciously "indoctrinating in SunLite a total dependency on D&T that D&T hoped would result in lucrative fees for years to come."
And, of course, FoxMeyer Drugs blames a botched implementation of SAP's R/3 software for pushing it into bankruptcy back in 1996. The trustee for FoxMeyer's customers is suing Andersen Consulting and SAP for $500 million, despite the fact that the company spent only $30 million on the project.
There may be only a handful of such suits out there, but they could be a sign of things to come, says John Keitt, a lawyer in the technology practice of Dewey Ballantine LLP. "If Gore gets past the summary-judgment phase, it may open the door for a lot of similar suits," says Keitt. There are certainly enough ERP-addled corporate managers to suggest that.
Gore's basic complaint is that Deloitte promised expert staff and delivered incompetent trainees who learned the software at the company's expense. A Deloitte spokesman says that Gore never raised that objection during the engagement.
It's called the "bait-and-switch" maneuver, says Keitt. "The consultant rolls out the first team. They're talented and engaging and they pitch the deal. If you're sophisticated, you put in the contract that you want these guys on the job," explains Keitt. If you're not, you get stuck with whomever.
What's clear is that consultants, particularly the Big Five, who now have huge ERP practices, have at times been severely stretched for resources. In the mid-1990s, when most of the thousands of companies with ERP systems embarked on their projects, there was a major shortage of ERP-experienced staff. It's equally clear that consultants don't like turning business away. "They're like the airlines," says Kamalesh Dwivedi, the chief information officer of ADC Telecommunications, which turned the key on an R/3 system in 1997. "They overbook their people."
Is that fraud? If the Delaware or Arkansas court determines it is, the consultants may not be protected by contract caps that limit their liability on ERP projects. They could be on the hook for treble damages, not to mention punitive damages a jury might tack on. And given the number of firms that have struggled with ERP systems, and felt poorly served by their consultants, the price tag could be huge.