Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
May 24, 2018
7 Min Read
The desired destination for enterprise resource planning software is the promised land of business processes that are automated, more efficient and sometimes innovative across a range of company operations. Yet, in the absence of basic planning and exquisite attention to contractual obligations, companies embarking on ERP deployment can end up in a much darker place: the courtroom.
Although hard data on the percentage of all ERP implementations that end up in litigation with one, two, and three tier vendors isn’t definitive, anecdotal evidence demonstrates that those shopping for an ERP package now should be taking notice. Although a courtroom showdown is not the most common outcome, the fact that any implementation ends up there at all suggests that things can go horribly awry. And these failures seem to be an equal opportunity curse.
“Large companies are just as susceptible to having a huge ERP implementation failure that causes massive business disruption as are mid to small size companies,’ says Marcus Harris, an attorney who specializes in ERP litigation for Chicago-based Taft, Stettinius and Hollister. “It’s shocking that in 2018 we’re still dealing with the same ERP implementation issues from 15 and 20 years ago.”
Shocking indeed. Consider the accumulated wisdom available to business and IT leaders: roughly 25 years after ERP made it into three-tier client-server environments, after 10 iterations of Windows, after the emergence of web-based apps and cloud computing, after the mountains of analyst reports, textbooks and certification programs we’re at a place in which companies still overlook the most basic planning and due diligence in deliberating the viability of this most foundational software. The good news is that with some sharp planning and a careful analysis of contractual obligations to both parties, the nightmare of litigation can be avoided.
The devil is in the details
There’s an old saying: success has many fathers but failure is an orphan. In fact, ERP failure from a legal perspective has many fathers too. Harris says many legal disputes arise out of the scope of the licensing agreement. Vendors typically want to limit the scope, while users want as broad a scope of license possible. He cites the visible example of Diageo, the behemoth liquor manufacturer, versus SAP, decided last year in Europe – which Harris did not litigate. Diageo discovered that it needed additional workers to access native SAP data from other applications – a common need after an ERP deployment. Licensing terms obligated Diageo to pay additional fees for “indirect access” to the core ERP software. Diageo said this would amount to an additional 50 million euros of license fees and went to court. The court ruled for SAP.
A key problem was that “user”, “indirect user” and “access” were not defined in the licensing agreement. Had Diageo understood that significant additional licensing fees would emerge when additional applications and users accessed the SAP platform, it would at least know what the financial ramifications were. Diageo would have been in a position to at least attempt less onerous terms.
It shouldn’t be lost on business and IT executives that a multinational liquor producer overlooked the most basic details of a standard term in an enterprise software licensing agreement. This wasn’t Aunt Ida’s Tropical Bird Store on Main Street.
“End users have to get down to brass tacks: what can I do with this software? Is what I think I’m licensing as a business, is that actually described in the schedule to the contract?” says Harris.
Another common source of conflict that sends ERP buyers into litigation revolves around legal claims of fraudulent inducement and negligent misrepresentation – two formal legal concepts. Harris is litigating a case right now between a metal products manufacturer and a well-known ERP vendor over the functionality of the application.
Among the products the metals company makes are wire spools, which typically are sold as one big unit and broken up into smaller spools through its distribution channel for final sale to multiple customers. The metals company was assured by the vendor that each spool could be tracked by product number through every stage of its journey to the end user buyer in case a recall was required. The needed functionality never materialized and the company filed suit.
In a similar situation, Harris is representing a service provider to sports venues. Accounting is key functionality in ERP packages. This service company needed to allocate costs to various jobs that it asserts the ERP vendor assured the company the software could accomplish. The software was so ill-suited to its needs the company abandoned it. Unfortunately it hasn’t been able to abandon the costly payments to the ERP vendor. This is at the root of the litigation. The customer seeks to stop the regular payments spelled out in the contract because the software is unusable for its purpose.
In another example where the customer and vendor aren't in sync concerning needed functionality, an electronics retailer expected its ERP package to handle X number of ecommerce transactions per day. The vendor assured it this was achievable. The problem arose from the definition of a "day". The vendor assumed transactions would be spread out fairly evenly over 24 hours when, in fact, the retailer might see half its daily business done in a four-hour time frame after people were home from work. People abandoned orders because the software could not handle massive spikes in transaction volume at peak times.
“The software simply wasn’t suited to do that kind of volume in the time frame the customer envisioned,” says William L Baumann Director of Expert Services at Denver-based Panorama Consulting Solutions, who has arranged expert witnesses for both plaintiffs and defendants in ERP litigation. Baumann said that in this instance the issue was more a misunderstanding between customer and vendor rather than blatant misrepresentation. But the outcome was just as bad as if it had been – a trip down the aisle to see a judge.
Exorcising the demons
So, what is there to learn from this? In the case of the sports arena services company two huge issues emerge. Vetting in exquisite detail that the functionality of the software aligns with what the vendor is pitching. This requires detailed, clearly thought out business requirements and use cases so the company can say to salespeople: Here is what we need. Here is a list of scenarios in which we would like to use your software. Can you deliver this specific functionality? Baumann cautions that vendors will often demo a version of the software that is not yet live and might not be for six months.
“The electronics retailer was demoed a version of the software that wasn’t released yet. You’d like to think this is a remote case but it’s not. Vendors are going to show the best sizzle they've got.” Baumann said that not all ERP vendors engage in this behavior but end users must exercise the same due diligence they would when buying a house. This case was settled before going to court so terms are confidential.
The second issue revolves around the termination clause in the contract. If companies conducted up-front due diligence – documenting business requirements, use cases, examining the help documentation for the software - which serves as a reference for the warranty – the need to terminate would never occur. But if everything goes south after the implementation anyway, the cruelest fate is facing costly vendor payments when no one is using the software. “I see many times that customers enter into contracts with one-sided termination provisions that don’t allow them to terminate the contract and I think that is just ridiculous,” says Harris. The sports arena services company is facing five years of payments to the ERP vendor for an application no one uses.
Include legal documents in ERP planning
It seems counterintuitive but there is an argument to be made that one of the first steps a company contemplating ERP software investment can undertake is a complete understanding of the legally binding documents that typically surface at the end of the vendor search, when a final commitment to move ahead with the ERP purchase has been reached. Scrutinize the licensing agreement and consulting contract boilerplate closely at the beginning of the selection and planning process. What are the limitations to the license? What are the costs to extending the license? Is the statement of work folded into the consulting agreement at the time of implementation detailed and comprehensive?
“It’s easy to look at a contract and analyze what is before you but you need to ask what is not here? What am I not getting and what do I need that’s not presented in this contract,” says Harris. Exploring simple questions like this might avert complex legal issues later.
John Berry is an author and information technology analyst based in Bend Oregon. He can be reached at [email protected]
About the Author(s)
The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT professionals in a meaningful way. We publish Guest Commentaries from IT practitioners, industry analysts, technology evangelists, and researchers in the field. We are focusing on four main topics: cloud computing; DevOps; data and analytics; and IT leadership and career development. We aim to offer objective, practical advice to our audience on those topics from people who have deep experience in these topics and know the ropes. Guest Commentaries must be vendor neutral. We don't publish articles that promote the writer's company or product.
You May Also Like