Three ERP failure case studies and what you can learn from them
ERP failures always make the headlines, with the number of disasters for any platform likely being in proportion to their market share. Yet how do you turn these huge - and often financially devastating - setbacks around and carry on? We look at three real-world examples.
1. Woolworth’s Australia
In 2015, Woolworth’s moved from a thirty-year-old in-house ERP to SAP. Then after a six-year $200 million rollout suppliers had to wait up to 18 months for payment and store managers lost their profit and loss reports that were tailored for individual stores. High profile supply disruptions caused by this contributed to a 2016 write down of $766 million and the layoff of hundreds of employees.
Nevertheless, after making fixing IT issues a priority. Woolworth’s successfully completed a subsequent roll-out of SAP’s Success Factors HCM software in August 2016. Potentially the biggest payroll system implementation ever in Australia, CEO Brad Banducci described it as going “far less painfully than our ERP systems.”
Something to take away: figure out if your issue is fixable before abandoning the project completely. Sometimes soldiering through is your best bet.
2. Indiana University
A $52 million installation of PeopleSoft at Indiana University left thousands of students without access to promised financial aid. The school began work in 1998 to replace in-house systems that were twenty years old. It turned out that the new software was more sensitive than the old. If there was a discrepancy between what a lending institution had shown and what the university’s own systems calculated, the system simply blocked transactions.
On further examination, the university realized key processes didn’t fit well with the structure of the ERP, which was designed for a wide range of organizations. Despite initial teething issues, therefore, Indiana University stuck with PeopleSoft and eliminated these issues by revising and streamlining key processes.
Something to take away: it’s not you, it’s me! Before blaming poor quality software, see if there’s anything you can do to make your ERP a better match
ScanSource is one of the largest providers of bar code scanners for the retail industry. They are based in South Carolina. In 2009, ScanSource reached an agreement with Avanade to implement Microsoft Dynamics AX ERP system. Then in 2013, ScanSource filed a suit against Avanade, alleging a ‘bait and switch’. The cost of the project had grown by four times the original amount, and the timeframe of the project was now triple the original scope. So, what happened?
Vistex Solutions for SAP now has implemented SAP ERP at ScanSource. On February 2, 2015, ScanSource began using the SAP ERP application in Europe to support its growing business, as the ERP system allows for the enhancement of business processes and creation of efficiencies to meet the needs of its operations globally. With a new stable platform, ScanSource now runs more efficiently and effectively, making the company ready for future growth.
Something to take away: know when enough is enough. And know when your vendor is breaking contractual obligations with regard to project cost and time inflation.
Overall, good project management skills are critical in turning around ERP failure. ERP projects are expensive and take years to complete. Requirements will evolve and time and expenses must be managed carefully. When there is a mismatch, the project manager must quickly determine if the project will self-correct (one extreme) or should be abandoned (another extreme).
Featured white papers
Manufacturing ERP Failure: 6 Common Causes
Get your comprehensive guide to the causes of manufacturing ERP failureDownload
Futureproofing your ERP - a complete guide
Not futureproofing your ERP is a significant cause of project failure. These tips will help
Why your ERP budget went wrong
Have your ERP budget predictions fallen woefully short, despite your best efforts? Here’s what’s ...
The dangers of poor ERP requirements gathering: a case study
What not to do during your ERP requirements gathering phase