- In the complaint brought by National Grid against Wipro, there were important details included regarding the negative impact of the SAP implementation on their business.
When Wipro was sued by National Grid for failure around a $1 billion set of SAP implementations, National Grid made some accusations around Wipro’s consultant quality.
The Claims by National Grid
“Specifically, inherent technical defects in the new SAP system rendered National Grid unable to operate its core functions relating to payroll, supply chain and procurement, accounts payable, and financial close and reporting. Wipro’s failures caused National Grid to suffer hundreds of millions of dollars in damages. The first series of payrolls processed after go-live were plagued by errors. As an initial matter, payroll programs that took a few hours to run on National Grid’s legacy payroll systems took weeks to run on the new SAP system (in part due to the flawed design of National Grid’s SAP in-house cash module).”
This would have been a surprise as the project would have likely promised improvements in this area.
“The payroll system itself was riddled with defects, as payroll amounts were wrong, causing harm to National Grid and its employees. National Grid was not able to pay its employees on time and in accurate amounts, as employees were underpaid, overpaid or not paid at all. National Grid’s union workforce was overpaid by approximately $8 million, a loss that National Grid ultimately had to absorb.”
This is quite basic functionality and considered essential for operations.
“Within weeks after go-live, the SAP system could not properly run National Grid’s business processes for paying vendors. By January 2013, the backlog of unpaid invoices exceeded 15,000, caused in part by data corruption that generated inaccurate vendor invoices. Unable to obtain the supplies it needed to service its customers and run its operations, National Grid had to prematurely pay vendors, in estimated amounts, to ensure that they would continue to supply National Grid with required materials. These pre-payments resulted in reconciliation problems when National Grid had to subsequently determine amounts that were advanced to vendors in excess of what was actually owed. In other instances, National Grid unknowingly paid vendors for the same invoice multiple times, which took extensive research and effort to uncover and correct.”
This describes a ridiculous situation which calls into question how much the system was tested before being cut over. This is not only the responsibility of the consulting firm, and questions around National Grid’s efforts in this area as well as the timeline that may have lead corners to be cut naturally arises.
“As a result, a cash reconciliation team had to be formed to contact banks to determine whether checks were actually cashed or not. This encashment problem forced National Grid to write-off approximately $3 million on approximately 40,000 checks that were cashed or voided in error.”
What a tremendous effort this must have been.
“Following go-live, National Grid experienced extreme delays in its financial close and reporting processes, which jeopardized its ability to carry out each of the functions discussed above. For months, neither National Grid nor its auditors could rely on the integrity of the data generated by its new SAP accounting management systems. National Grid was therefore forced to repeatedly delay issuing critical financial and regulatory reports (both state and federal) regarding its financial status, drawing penalties from its regulators and jeopardizing its relations with lenders.”
Obviously, with the previous items, there would have been no way to close the books.
“The financial close delays after go-live were stunning: whereas National Grid typically performed its monthly financial close in 4 working days, the first financial close after go-live took 43 working days. These delays were caused by (among other things): (i) the instability and defects in the SAP system; (ii) inaccurate data conversion and lack of data capacity; (iii) defective application interfaces; and (iv) the cascading effects of the payroll and supply chain issues described above.”
Again, the most basic things could not be done in the ERP system.
“Nor could National Grid take advantage of certain attributes of the SAP solution that are designed to enhance an organization’s financial close and reporting capabilities. The system’s flawed mapping and related design defects prevented National Grid from benefitting from the SAP FERC module, which addresses unique accounting requirements set by FERC for public utilities like National Grid. For more than a year after go-live, National Grid was unable to use the SAP FERC module to process the extensive financial reports it must regularly provide to FERC, and the company was forced to seek numerous extensions from its regulators. FERC also denied National Grid the ability to engage in short-term borrowing from banks due to the company’s inability to file FERC financial reports. The problems with the SAP FERC module should have been readily evident during testing, but Wipro never tested the module and none of the problems were discovered until after go-live.”
This lack of testing is very common at the SAP consulting firms. SAP has many problems with its applications and various modules. However, there is a strong tendency in SAP consulting firms to “take SAP’s word for it” that something works. This claim is made against Wipro, but actually SAP shares in the responsibility here for having such continual problems in so much of its software.
“By September 2013, the continuing efforts to stabilize the new SAP system cost approximately $30 million per month, totaling over $300 million. As of August 2013, there were still approximately 321 external resources contracted, and full SAP stabilization was not achieved until approximately September 2014.”
This is actually little discussed in the SAP and ERP industry. When a project does fail, what are the costs to remediating the situation? It is often thought that the loss is just the project cost, but when it negatively impacts the business, the business costs and the remediation must be added.
One has to be careful in taking accusations in legal cases at face value. There is no requirement in a US legal case that any stated be true. However, these issues are explained with specific detail by National Grid. If there were no lawsuit filed, we would never have heard of these claims as the implementation failure would have been suppressed. SAP consultants normally give a highly misleading representation of the benefits of SAP implementations.
This is what can happen when an SAP project goes south. Project problems and failures happen far more often that is generally discussed because they are suppressed. They are suppressed by the customers, by SAP, and by SAP consultants.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our SAP Project Management Content
Enterprise Software Risk Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model