ERP projects are among the most critical efforts IT ever undertakes, as they touch almost every part of essential business operations and are complex technically. Not surprisingly, some fail -- spectacularly. Although ERP has been an enterprise focus for a decade, many companies are still embarking on such efforts, and even more are dealing with ERP redos because of mergers and business changes. Here's what you can learn from the failures of others and put to use on your own ERP projects.
I focus on failed SAP deployments because the details are more commonly available, thanks to SAP's huge presence in large publicly owned enterprises and government, where documents surrounding litigation and major cancelled projects must be made public. But the lessons apply to Oracle and other ERP deployments as well.
What is an ERP project failure? Not mere cost overruns, but an event whose effects are so large that they force a company to restate its earnings or a government entity to cancel a project that is substantially funded.
John F. Kennedy once said, "Victory has a thousand fathers, but failure is an orphan." In the world of ERP projects, the reverse is almost always true: Failure has a thousand causes. These causes almost invariably arise, says Michael Krigsman, CEO of the consultancy Asuret and a well-known analyst of ERP failure, because of a lack of alignment between the three key parties in a project: the customer, the software vendor, and the system integrator.
A study by Judy Scott (then at the University of Texas School of Business) concludes that FoxMeyer was a failure of management. The use of inexperienced consultants by the lead integrator, Andersen Consulting, was a contributing factor, she reports, but the factor that sealed the project's fate was management's inability to regain control of the project and make the indicated decisions. Successful projects require responsive, thoughtful management.
System integrator failures
Because integrators do the actual implementation work, they are frequently an integral part of all project failures. Their chief offenses tend to consist of using consultants who are insufficiently trained in the packages they're installing -- sometimes even in ERP basics -- and they tend to be poor at regulating themselves. Both factors derive directly from how integrators charge: by the hour. (Few contracts are fixed bids.) As a result, the cheapest staff that can do the job result in the greatest profit, while taking on additional tasks produces a more profitable engagement.
The inherent conflict of interests between the integrator and the customer is a frequent source of contention, not only between those two parties, but with the software vendor as well. In 2009, for example, Léo Apotheker, the then-CEO of SAP (and now CEO of Hewlett-Packard), decried in remarkably blunt terms how the self-interest of integrators (here, Accenture and IBM) led to failed projects that reflected badly on the software, rather than on the integrators: "I don't give a shit if it's Accenture or IBM. ... I find it remarkable that people [from integrators] are walking around talking to customers and have no experience. [They] have no clue. It's annoying, but that's a fact."
The practice of integrators sending out inexperienced consultants is so pervasive that almost every lawsuit in ERP projects claims this as a cause of action. Greg Hatch, managing director at Alvarez & Marsal Business Consulting, a firm that offers advisory services to clients on large ERP projects, states that this problem derives in part from a mistaken perception of integrators: "You can view it as engaging a company, but you should really view it as hiring a team of people. You should interview the senior staff, such as the project manager and team leads, and study the résumés of the rest. Make sure they not only have relevant ERP experience, but ideally have done ERP projects in your particular industry."
As a customer, you must address the problem of slipped deadlines through strong project management. You should actively resist the temptation to push out the schedule because of unexpected problems or misprojections of time and resources. Each delay is a symptom of a larger problem, and the project management team, with the integrator, has to figure out what's wrong and get it fixed.
Krigsman agrees: "One of the things you're paying a company like SAP is for its knowledge of the business processes in your industry. Its software typically embodies best practices, so to the extent possible, avoid writing custom code, and instead, where possible, change your business processes to align with the ERP package."
ERP's complex triad: Getting it right
The alignment of the customer's need, the vendor's software, and the integrator's implementation is a remarkably complex triad, whose dynamic nature requires all parties -- the customer, especially -- to monitor activity carefully and respond immediately when problems occur.
But even managers who are well versed in ERP implementations can run into serious, unexpected problems. Consider Hewlett-Packard, a company that at the time of its internal SAP failure had a business unit that consulted on SAP projects. The botched implementation cost HP $400 million in third-quarter revenue. According to a Register.co.uk article, "HP staffers were standing inside 18-wheelers [trucks] hand-labeling shipments of million-dollar Superdome servers and the like. High-ranking executives were being forced to spend their time approving rush orders of $50 parts to key customers."
As several analysts point out, no matter how good you are, ERP projects are hard. Still, there's some advice that consultants and analysts agree on.