What should be included in your ERP contract?

We regularly hear of failed ERP implementations but we rarely hear of companies taking legal action against their system suppliers or system integrators. Is that because those people are actually not responsible even though their fees run to millions, tens of millions or even hundreds of millions of dollars, or is there something else to consider? Perhaps a factor is that it is actually very difficult for dissatisfied customers to successfully sue companies that have underperformed so that only the mega-failures (like Lidl, National Grid and Waste Management) make it to court.

It's true that many ERP projects are so big and so complex that, when they fail, usually no-one is completely blameless. For every customer who complains about the advice they were given, there is a consultant who complains that his or her advice was cherry-picked or ignored completely. For every customer who complains about the training they received, there is a software trainer who complains of customer staff showing up for training, bringing their cell phones and tapping away relentlessly through the entire session. But perhaps the biggest reason is the failure of the contracts that govern the project to fulfill their function.

A good contract ensures that there are no surprises during the project. It states, clearly and unambiguously, what is to be done, who is responsible for doing it, when it should be done by and what redress there should be if things go wrong. But such contracts are almost always drawn up by the supplier, who almost always has a bigger legal department than that of the customer. Moreover; it is a legal department that specializes in ERP contracts so, if things go to court, the customer is on a playing field of the supplier's choice and is playing by the supplier's rules.

So how can companies buying ERP systems ensure that, when things go wrong, the odds aren't stacked against them? In the 1980s, the acronym SMART was popular for qualifying business objectives: they had to be Smart, Measurable, Achievable, Realistic and Time-related. These criteria are not a bad start for defining what a good contract (for all parties) should be.

Specific

For the protection of both customer and supplier, a contract should state very clearly what is to be provided. Phrases such as, “Supply and implementation of (named) ERP system” are far too imprecise – what does 'implementation' mean? Does it mean that the system has to work, has to deliver agreed functionality, and has to pass agreed acceptance tests? It should, but it doesn't. And even saying things like, “a working system”, or “a system that satisfies the company's requirements” doesn't help unless those phrases are clearly and explicitly defined.

Additionally, during the presale period and during demonstrations, claims and promises about system capability and functionality will have been made (frequently verbally) but these statements mean nothing if they are not written into the contract.

Measurable

Closely linked to the previous section, this problem is most easily identified in a contract when the word 'improve' is used. For example; “The system is required to (or will) improve inventory management”; or “The system is required to (or will) improve customer service”. If a company is dissatisfied with the delivered system and the dispute goes to arbitration or to court, how easy would it be to prove, or disprove, that something had not been 'improved'? It might be argued that an improvement in inventory management should result in a decrease in stock levels but, equally, it might mean an increase in service levels and those two measures can, in fact, often be in conflict. (These phrases probably fail the 'specific' test also.)

Check out our free 5 steps ERP selection checklist to ensure you cover all your bases when selecting ERP

Achievable

Recognizing some of the above problems, some companies try to get around problems by writing their own contracts or at least having clauses that they, or their attorneys, have written inserted into the supplier's contract. But, if they enter statements such as, “the system must reduce stock levels by X%”, or, “the system must reduce delivery lead times by Y%”, then no sensible system provider is going to sign that contract because these are not things that even a good system can guarantee. They rely to a great extent on both customer staff acceptance of the system and on factors beyond the supplier's control. For example; if the company grows in size or decides to open new distribution centers, stock levels could very easily increase regardless of how well the system performs; indeed, in these circumstances, it may be a deliberate act.

Realistic

Again closely related to the previous section; unprofessional sales people can be tempted to promise (although perhaps not in writing!) benefits that, in real life, will not be achievable. But they will attach caveats such as, “Many customers have achieved.....”, or, “Used properly, the system can ….”. These statements may sound impressive but if things go sour, in a court of law they are next to meaningless.

Time-related

When companies launch an ERP project, they will have, at least in their own minds, a target go-live date. This date can be just a nominal date to focus attention but can also represent a critical requirement if, for example, support for their legacy system is being discontinued or if planned business developments mean that new functionality is essential. When the go-live date is important, it simply must be written into the contract but doing so effectively is not always easy. The problem is that the supplier can only commit to completing the work that is specified in the contract, and it is not unusual after the contract is signed for new tasks or requirements to be identified as being needed for a successful conclusion. If the scope of work changes, it may be unrealistic to expect to hold the supplier to the original promise.

So the project needs a formal change control procedure and how this operates, and how it impacts upon delivery promises, needs to be explicitly stated. Is there to be an agreed time contingency? Is there to be an agreed formula to define allowable project slippage? Is the supplier required to provide additional resources (at an agreed cost) to ensure that the go-live date is not affected?

A second problem with target go-live dates that has to be considered is that often it is not in the supplier's or system integrator's best interests to meet those dates. They will have large numbers of consultants (in the case of a Tier 1 system, regularly dozens or hundreds) earning lucrative rates and will not want that to end; especially if they have no other immediate contracts to absorb those resources.

Turning that around: there are times when customers are able to strike a hard bargain with suppliers but, when more lucrative works turns up for them, they will be tempted to pull their people out as soon as they can. Sometimes that may only mean pulling out their best people and replacing them with the B team. That, in itself, is bad enough but these people will need time to come up to speed on the project, just like the initial team did. The customer paid for the original consultants to progress along the learning curve: does the contract say who should pay for the replacements to go through that process again?

Another time-related thought is that, within the lifetime of an ERP system, the company running it will change. It may get bigger and it may get smaller, and that will mean a changing number of users on the system. And, if running a cloud-based system, the amount of storage required as files get bigger and bigger will also change. The contract must spell out in clear terms how these changes will be reflected in monthly and yearly charges. And, given that the system is likely to be in use for at least ten years, it must also specify what increases in charges over that time would be considered reasonable and how they will be calculated. Some Tier 1 customers have recently had massive shocks when their supplier changed from charges based on the number of users to transaction-based charging.

Companies also need to be aware that, for a number of reasons, some ERP implementations disappoint or even fail entirely. They need to know, if this happens, how they can (indeed, if they can) extract themselves from the contract so that they are not left paying fees and charges long after such systems have been abandoned.

One final thought is that there is a lot of good advice out there on ensuring that projects go well. In taking advantage of that information, companies should always remember that, until they sign a contract, they are the ones with the power. They should never sign a bad contract, even if that means spending a fraction of the total project budget on good, independent advice.