02:57 PM

When It Comes To Enterprise Software, It's The Contract, Stupid

Customers crying foul over big deployments gone awry often ignore the very language that defines the scope of the software offering or implementation. Here's how to smarten up.

Mention the term "enterprise software" or "ERP" to any executive or business owner with any experience with such complex deployments, and you'll probably witness symptoms of post-traumatic stress disorder.

No question, SAP, Oracle, Epicor, Sage, and scores of other enterprise software vendors have produced innovative products to improve almost any business process: manufacturing, supply chains, sales force management, financial accounting, hospitality, human resources--you name it. However, having litigated hundreds of failed enterprise software engagements for many vendors and some customers over the past 15 years, I have witnessed a common theme that reveals itself faster than a pop-up ad on a gossip-news site:

Customers don't pay enough attention to the contracts they're signing, and in many cases they ignore the very language that defines the scope of the software offering or implementation.

All licensing agreements for enterprise software have similar language. In legal parlance, these disclaimers, warranty and remedies limitations, venue provisions, and integration clauses operate to the advantage of the vendor, not to the licensee. They limit the offering to that which is documented in the vendor's user manuals, use notes, release notes, and other pre-defined criteria. Off-the-shelf software works the way the software was designed to work (most of the time). But customers will try to superimpose their business onto the software during the sales process, rather than vet the software in such a way that will allow them to understand how the software actually works.

What ensues is a train wreck. Here's why:

  • Most customers don't define the functionality they want from the software.
  • Salespeople speak in general terms because they don't know (or care to know) the nuances of the customer's business. "Yes, the software can handle a size-grid for order entry..." But what does that really mean?
  • The complexity of the software and the potential business application stifles customer inquiries.
  • Customer execs and owners assume that software is some sort of magic potion that will let them slash their labor costs, without understanding the dynamics of how the software will operate to get them to that point.

With apologies to Paul Simon, "Still, a man hears what he wants to hear. And disregards the rest...nah, nah, nah."

So what's a customer to do? Take several steps to close the "expectation gap" during the sales process:

  • Understand that vendor salespeople don't know your business, its processes, and its nuances--no matter how much you educate them. Vendors are there to sell software features.
  • Before you ever speak to a software vendor, make sure your specific criteria regarding your business processes are clearly and specifically defined (more on that point later). It's not the job of the software vendor to define those for you.
  • Understand that the only warranty that exists in the license agreement you will sign is that the software will function as the publisher's documentation states--not to meet the particular needs or purpose of your business. The more specialized the application, the more this point applies.
  • Don't sign any license agreement until you have objectively and definitively determined that the data flow and product of the software "doing its thing" will work for you, in the manufacturing process, for instance, from "quote to cash."
  • Understand that your processes will change and there will be internal resistance to that change. That's the whole point of acquiring enterprise software, isn't it? You can't impose your business on the software; don't even try.

So how does this all relate back to the contract? As mentioned above, the contract defines the relationship between the parties. In 15 years of handling almost 300 failed implementations for several public and private software vendors, I've yet to have an opposing counsel call me and say, "Hey, Ken, my client is entitled to terminate the agreement and get its money back because the software doesn't function in the way your client describes it on Page 32 of the user manual." That never happens. When conflict and litigation ensue, customers invariably run as far from the contract as they can.

Customers that don't have the foresight to protect themselves invariably want to talk about everything but the contract. ("The salesman told me blah, blah, blah.") My response is always that the opposing lawyer's client received everything it was entitled to receive as defined by the contract it signed. The client never saw something in the demonstration that it didn't get, and my client isn't going to consider expanding the scope of the signed contract. These "misrepresentation claims" routinely get thrown out quickly.

Enterprise software can, if properly vetted before contract, do wonderful things for a business. But caveat emptor. Making sure that the enterprise software contracts you sign state exactly what you expect from the product will drastically reduce the cost, stress, time, and effort to streamline your business.

Kenneth J. Richard is an attorney and consultant who represents several software and other technology companies. For more information, go to

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Email This  | 
Print  | 
More Insights
Copyright © 2021 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service