Business software firms sued over implementation

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

http://news.cnet.com/news/0-1008-200-1428800.html

Link

Business software firms sued over implementation By Kim Girard and Melanie Austria Farmer Staff Writers, CNET News.com November 3, 1999, 4:20 p.m. PT

update Although glitch-plagued software implementations are nothing new, the growing number of brand-name firms reporting big troubles with their multimillion-dollar projects is starting to look like a Who's Who of the Fortune 500.

The list, for starters, includes Hershey Foods, Whirlpool, Allied Waste Industries, and maker of Gore-Tex W.L. Gore & Associates. Other stories of troubled enterprise resource planning (ERP) software implementations are also leaking out from additional companies, colleges, and universities across the country.

Some companies are even turning to lawsuits, alleging the software doesn't work and pointing a finger at the ERP software makers and consultants who install the systems intended to automate their accounting, order entry, and manufacturing processes.

However, many analysts say when huge software projects go wrong it's often the buyer's fault, particularly when companies fail to understand the scope of the project or lend the time and money necessary to move from an old computer system to a new one.

Forrester Research analyst Bobby Cameron said firms that have recently spoken publicly about their software woes are only a fraction of large businesses over the past several years with troubled implementations, particularly users of German software giant SAP's tightly integrated software, he said.

"It's not a recent phenomenon," Cameron said, though he added: "People's willingness to talk about it builds momentum."

But when software projects go bad, he said, companies are more likely to be "scurrying like hell to cover it up," because they fear they are the only ones having troubles.

Why do software projects go bad? By some accounts, up to 30 percent of all SAP implementations fail to meet the buyer's expectations. Many fail because the companies fail to "kow tow to the ERP vendors" and understand that these software projects involve hard work, commitment, and a driving project manager who understands that a successful ERP project starts on a small scale with a firm intent to meet project and budget deadlines, Cameron said.

For many companies, analysts say, investing in an ERP system becomes a corporate religion driven by the head of the corporation or chief technology officer. SAP, for example, which has installed its software in about 20,000 locations worldwide and at about 5,000 U.S.-based companies, can take years to install throughout a complex corporation with many business units. The technology is tightly integrated and requires a commitment from all divisions and often a change in the way a company does business to make it work.

Many companies are not willing to make those changes, Cameron said. And other times, managers within manufacturing units aren't willing to sign on to a project if they're not convinced it's going to make them more productive.

"Some companies that went to chisel this in didn't have any idea of what was needed to force the fit," Cameron said. "They did a half-assed job. They skimmed and they ended up with a lot of problems."

But some companies say their woes have nothing to do with poor planning, but with incompetent companies that fouled up their projects.

Bringing out the lawsuits W.L. Gore, for one, is suing Pleasanton, California-based PeopleSoft and Deloitte & Touche, the consulting firm that installed its $2.5 million personnel and payroll software system in 1996 and 1997. The suit, filed in Delaware, alleges PeopleSoft sent in unqualified consultants to do the job, forcing Gore to rely on PeopleSoft's customer service hotline to set up the program after major problems occurred when the system went live.

"PeopleSoft was just a complete disaster," said Jay Eisenhofer, the lawyer who is representing Gore. "They said [Deloitte] could implement the software. That wasn't the case."

Though not addressing the Gore suit, Eric Stathers, vice president of customer service at PeopleSoft, said when a project doesn't work, the responsibility often lies with the user.

"The work environment is very complicated now," he said. "In many cases you have understaffed organizations. They don't have a clear idea of what they want. They haven't budgeted up front. A lot of these problems are budgeting and planning."

Stathers said he believes more companies are publicly criticizing ERP vendors because they are coming to the end of their two or three-year projects and finding that they are over budget, fighting internally over the project, worried about losing their jobs, or concerned about not moving over from a legacy computer system to a new one by the critical Year 2000 deadline.

A Deloitte & Touche spokesperson said the company had not seen the complaint from Gore and "assumed there were no issues [with the system]." The company said any issues would be "acted on as a high priority once we have the details."

Sometimes it's just the consultants who get slapped with a lawsuit.

Last year, the bankruptcy trustee for FoxMeyer, a former $5 billion drug distribution company, filed a $500 million lawsuit against Andersen Consulting, alleging the company's botched implementation of SAP's R/3 software helped send FoxMeyer into bankruptcy in 1996. At the time, Andersen called the claims "outlandish and totally at odds with facts."

Though not suing any vendor, both Hershey's and Whirlpool have reported troubles linked to their big software implementations. Hershey's partly blamed the software for fouling up its Halloween candy shipments, while Whirlpool tackled appliance shipping delays after it went live with an SAP implementation recently.

Jeff Zimmerman, SAP's senior vice president of customer support services, said problems at both companies have been fixed. He said SAP "gave Whirlpool the red light" two times before the company went live with 4,000 users on SAP's core R/3 system, telling the company that the supply chain system wasn't ready to go.

"They moved forward," he said. "We wanted them to go back and do some performance testing. They were on a time line."

Whirlpool did not comment on the matter.

Hershey's problems involved not only SAP, but software from Siebel Systems and Manugistics.

Zimmerman said the company wanted to do a 48-month global SAP rollout within 30 months. The project was on schedule when troubles occurred with a non-SAP system, he said. He said the three companies worked together to fix the problems.

"We missed the Halloween season," Zimmerman said, adding that Hershey's knew the switchover to the new systems would impact their business.

A Hershey's spokesman said the challenges Hershey's is having with its distribution and production systems are "not being blamed on any computer or software company."

Overall, the number of software problems that results in lawsuits is minimal, said Yankee Group analyst Harry Tse.

"It's definitely not a high percentage," he said. "Most of the implementation problems stem from not setting expectations up front."

Meta Group analyst Steve Bonadio said lawsuits and related problems come with the territory with any massive, complex software application installation.

"We're seeing it occur in pretty high profile cases," he said. "But these things tend to drag on and you never really hear the results. There's really nothing specific that goes wrong. It usually has to do with the implementation process and the initial deployment of the applications."

Paul Melchiorre, vice president of North American operations at Ariba and former senior vice president of global accounts at SAP, said problems will continue to occur within companies where ERP software is being sold as a system that can handle everything from production scheduling to e-commerce transactions to sales force automation.

"For finance and ledger, it's good stuff," he said. "It was oversold as one system to do everything forever and the flexibility just isn't there in the systems."



-- Homer Beanfang (Bats@inbellfry.com), November 08, 1999

Answers

http://www.msnbc.com/news/331767.asp?cp1=1#BODY

Software glitches could multiply as firms revamp to compete TECH WEEK By Jason Fry and Megan Doscher THE WALL STREET JOURNAL

Nov. 5  It hasnt been a good few weeks for makers of enterprise-resource planning software.

In hostile bid, Pfizer tries to buy Warner-Lambert (Nov. 5) Drug makers set $72 billion deal (Nov. 4) Pfizer bids $80 billion for Warner-Lambert (Nov. 4) Drug industry is ripe for megamergers (Nov. 4) More technology news from The Wall Street Journal.

Theres a gold mine out there for the likes of SAP and PeopleSoft and the consultants who knit systems together. Unfortunately, that means more software horror stories will be on the way, too.

THE RUMBLINGS BEGAN late last month, when details emerged about troubles with Hershey Foods Corp.s ordering-and-distribution system  troubles that stem, ultimately, from a $112 million computer project designed to automate and modernize that system. Hershey offered few details, but it was clear that something was very wrong: Distributors reported candy shortages and trouble getting orders filled, or even getting information about future orders, for the critical Halloween candy season. Hersheys project began in 1996 and was sparked by year-2000 worries and a desire to help retailers keep inventories down. From the beginning, it was clear that the new system would be complex, marrying software from a host of companies and a blizzard of network gear and computers. Originally set to go live in April, the system actually came online in July. Problems became apparent in September, and the company and its various tech vendors are reportedly still working them out. Meanwhile, Hersheys tech vendors werent exactly quick with the mea culpas: SAP AG, which makes the R/3 enterprise-resource planning system used by Hershey, said its system wasnt at fault. Siebel Systems Inc., whose software is part of the mix, said they were told they werent the weak link. International Business Machines Corp., hired to make the products from those two firms and Manugistics Group Inc. work together, talked about how complex the undertaking was. SAP then got an added dose of bad news this week, as Whirlpool Corp. said it had dealt with delays shipping appliances since starting to use a SAP system in September. While Whirlpool said it thought most of the problems had been fixed and things would be back to normal by December, it also said that it had suffered disruptions in the five other countries in which its used the systems. In other words, shipping woes are normal  a realistic perspective, perhaps, but not exactly a strong sales pitch for ERP software. SAP said it had warned Whirlpool that it had problems generating some data before the system went life, but Whirlpool went ahead anyway. At least SAP wasnt alone. The week also brought to light problems at W. L. Gore & Associates, the maker of Gore-Tex, which sued PeopleSoft Inc., Deloitte & Touche LLP and Deloitte Consulting for punitive damages and treble compensatory damages to be determined at trial, along with nearly $3.5 million in fees and charges. Deloitte was hired to install PeopleSoft software designed to tie together Gores personnel, payroll and benefits departments. But Gore charged that Deloitte used the project to train newbie consultants, leaving its HR department in chaos. Among the most acidly amusing charges was that an early team of consultants had tested the system by entering fictional employees into the database and then couldnt figure out how to remove them, leaving Gore cutting checks to the likes of Donald Duck. Such horror stories arent new: The roster of companies that has struggled with software installations gone awry includes UOP, a partnership between AlliedSignal Inc. and Union Carbide Corp., defunct drug distributor FoxMeyer Corp., Allied Waste Industries Inc. and Waste Management Inc. And, alas, that roster is only going to grow as more and more companies turn to complex software installations designed to knit together far-flung operations.

change

+0.438



-- Homer Beanfang (Bats@inbellfry.com), November 08, 1999.


The Snowball is gathering speed on its downhill roll, and Hell is about to freeze over.

-- Donald Duck (quack@quack.likethemoney), November 08, 1999.

>>Business software firms sued over implementation

That's the headline, but I only read about a single software company that a lawsuit was filed against. Some journalism!

-- Scarecrow (somewhere@over.rainbow), November 08, 1999.


It seems the implementation problems aren't gathering speed here, but the reporting is. This part is interesting:

"firms that have recently spoken publicly about their software woes are only a fraction of large businesses over the past several years with troubled implementations...It's not a recent phenomenon"

All of this is wonderful support for Hoffmeister's observation that y2k has already struck with considerable force. "Up to 30 percent of all SAP implementations fail to meet the buyer's expectations." "SAP...has installed its software in about 20,000 locations worldwide and at about 5,000 U.S.-based companies."

That's a big number just for SAP. And little companies don't use SAP. That's about 6,000 cases of "failed to meet expectations" there. Yet the vast majority were able to keep it pretty well covered up, even though implementation problems aren't like date bugs -- they affect all systems, can strike anywhere and be caused by anything (murder to debug), and "often [require] a change in the way a company does business to make it work."

Without doubt, we have been living through the most massive (and rushed) switch to new systems in all history. Incredibly risky, and thousands of big companies have been having big problems. One company (FoxMeyer) even claims the effort "helped send them into bankruptcy." It would seem those dominoes are pretty well nailed to the floor.

-- Flint (flintc@mindspring.com), November 08, 1999.


The problem with the assumption that problems have been minor so far has to do with a fundamental misunderstanding of production shops.

Very few production facilities are running Y2K compliant code today. Code that is "broken" vis a vis 2000 is 1999 perfect. Rather than risk a screwup a la Hershey, they merely run 1999 code until Dec. 31.

Expect to see more companies in January with problems as they roll out their production 2000 software.



-- K. Stevens (kstevens@ It's ALL going away in January.com), November 08, 1999.



Flint:

Aren't the problems of late fundamentally different since they can still fall back on old software while they debug the new? Doesn't the situation change discontinuously come January 1 where the safety net is pulled out? I don't think the dominoes are nailed down at all. Despite your obvious skills in IT, your analysis seems naive (or forced).

-- Dave (aaa@aaa.com), November 09, 1999.


Flint,

[All of this is wonderful support for Hoffmeister's observation that y2k has already struck with considerable force. "Up to 30 percent of all SAP implementations fail to meet the buyer's expectations." "SAP...has installed its software in about 20,000 locations worldwide and at about 5,000 U.S.-based companies."]

I disagree, at least in part. The fact that SAP (and PeopleSoft, and Oracle, and Baan and the other ERP systems) installations are often problematic and "fail to meet the buyer's expectations" has more to do with the way those products have been percieved and marketed than how they work. These things have been sold as cure-alls that are easily installed and fit smoothly into your existing business. Only in the last year or two has the world at large come to realize that these systems require long implementation times, vast amounts of work and/or major changes to the way that a company using them conducts it's day-to-day operations. These companies aren't having problems because they rushed something into place to get around Y2K, but becuase they had no real clue about the implications of what they were buying.

Furthermore, to tie some of these things to Y2K is not necessarily fair or accurate: The W. T. Gore/Peoplsoft issue is over a system that was installed in 1996, and I saw somewhere that the Whirlpool system that was being replaced had no serious Y2K issues but rather simply didn't have the functionality Whirlpool needed to conduct business the way it wanted to. And, without knowing why Hershey was upgrading it's system, it's a bit premature to assume that they were rushing it in before 1/1/2000 (although, to be honest, I wouldn't bet against it).

[That's a big number just for SAP. And little companies don't use SAP. That's about 6,000 cases of "failed to meet expectations" there. Yet the vast majority were able to keep it pretty well covered up, even though implementation problems aren't like date bugs -- they affect all systems, can strike anywhere and be caused by anything (murder to debug), and "often [require] a change in the way a company does business to make it work."]

I would take some issue with the phrase "keep it pretty well covered up." It implies visions of the sort of evil conspiracy you have so often complained about from others. Many times, the "failure to meet expectations" comes from having to change business practices to fit the software when buyers thought it was going to work the other way around. Those sorts of issues are, to be blunt, nobody's damn business so long as they do not seriously impact the earnings of a publicly held company or cause some harm outside the buyer's company. Not publicizing them isn't covering anything up, it's simply keeping internal company issues internal. While the Hershey's and Whirlpool problems falls into the latter category, the Gore problem falls into the former.

[Without doubt, we have been living through the most massive (and rushed) switch to new systems in all history. Incredibly risky, and thousands of big companies have been having big problems. One company (FoxMeyer) even claims the effort "helped send them into bankruptcy." It would seem those dominoes are pretty well nailed to the floor.]

I would dispute the FoxMeyer claim on at least one ground. Anyone who bets their business solely on what the consultants tell you and do for you without having someone internally to pass judgement and approval over what they do deserves bankruptcy. It's the capatalist version of natural selection, and it culled a stupid company out of the herd. To sit back and say "Ohh, those bad ol' consultants screwed up my company" is simply shirking the responsibility that the management had to manage what Anderson was doing and to replace Anderson with someone else when it became clear that they weren't living up to expectations. (Also, I wonder what the real financial status of FoxMeyer was *before* the SAP rollout. That could just have been the final straw, and if it hadn't been the SAP installation it would soon have been something else.)

However, I will grant you this: The number of systems installations during the past two years has skyrocketed, due largely to Y2K concerns. While I wonder if the percentage of new installations that are being rushed in before they are ready is really higher than it has been in the past, the sheer volume certainly makes it a broader and more pervasive issue than normal.

-- Paul Neuhardt (neuhardt@ultranet.com), November 09, 1999.


Paul:

I didn't mean "covered up" in the sense of a conspiracy. I wasn't clear, but I meant that the impacts of the problems didn't seriously affect the customers or the health of the business -- they were successfully kept internal.

Dave:

I'm not sure if we're disagreeing here or not. I'll try to clarify, and maybe we can find out.

The key issue, I believe, isn't whether a safety net existed during all these new implementations, but rather whether it was used. Even Cory Hamasaki has conceded that in most cases, dual systems were NOT used in actual production. The two systems (old and new) may have been run in parallel during testing, but the new system being tested wasn't real-time. Instead, output from sample datasets entered into the new system were compared with outputs from the old system to make sure they were functionally the same.

Once the cutover was made, though, it was sink-or-swim. The cost of falling back to the old system is recognized as FAR exceeding the cost of ironing out the wrinkles in the new system. Now, this recognition may have been incorrect in some cases (like Hershey and Whirlpool -- Cory has provided half a dozen more examples). But surely such companies would have reverted to the old systems if they could, since the cost in lost business exceeds the cost of the new implementation. But they did not do so. For most such switchovers, the notion of a safety net is at best an illusion. Despite horrible problems, reverting to the old system was not done. It should be clear that doing so was not considered a viable option.

Which gets us to the heart of the issue -- these problems *happened*. They *are* happening. Whether they *could* have been avoided had the projects been managed differently is a moot point. We actually *have* been suffering through a massive wave of troubled new implementations, without any significant dominoes.

Depending on the remediation strategy used, this can also apply to those who have returned remediated systems to production. If date expansion was used, this can mean major modification to the data itself, with corresponding changes to all the programs that access that data. Errors are showing up pretty regularly, and being handled. Even windowing has already unearthed some annoying problems. We're dealing with them. Most such errors were found and corrected in testing, of course.

So if there is a discontinuity starting at rollover, it will not be due to the loss of largely imaginary safety nets. Instead, it will be due to software encountering unremediated or incorrectly remediated date calculations. Yes, there will also be residual problems with new implementations that are not directly related to dates. As I said, many of these implementations were rushed. However, it's doubtful that too many organizations started switching recently. They may have started too late to do the job competently, keeping Homer Beanfang busy finding accounts of the inevitable result. And again, these problems are happening *right now*, without dominoes.

How virulent date problems will be, especially in the immediate vicinity of rollover (within the first week or two) I can't do more thank make a biased guess. My point was that the number of problems *already* experienced has been huge just as a result of trying to avoid problems later. For Really Bad Things to happen generally, the impacts of date bugs specifically must be at least an order of magnitude greater than we've experienced so far.

And my gut feeling (for whatever that's worth) is that date bugs are not in the same class as implementation problems. They are much easier to track down (you know what you're looking for), they don't involve redesign, they don't require you to change the way you do business. And presumably they won't strike the many companies that have suffered through the headaches of compliant new implementations, and be minimal for the even greater number of companies that have done decent testing of their remediated systems.

From where I set, expecting such a huge (and lasting) increase seems much more a matter of religious dogma than of careful analysis. We shall see.

-- Flint (flintc@mindspring.com), November 09, 1999.


Moderation questions? read the FAQ