ERP Contracts
I’ve recently been involved at the contract negotiation stage on a number of ERP projects, and I’ve noticed radically different views from both system vendors and their clients regarding what’s necessary and appropriate in terms of contract details. I’ve also seen a number of situations where a failure to execute an effective contract has led to material difficulties during ERP implementation projects. So what are the key elements in any business system contract?
If an ERP project goes well then you’ll rarely need to look at the contracts again (except maybe to check commercial agreements). If difficulties are experienced your first port of call will be to check the contract to see what was agreed. A properly constructed contract defines the rights, responsibilities and obligations of both parties, so it is an essential part of setting expectations and protecting the interests of both parties.
Sean Jackson has written previously about how important it is to focus on documenting the statement of work (SoW) that the vendor is being contracted to deliver in his blog Contract Negotiation in ERP Projects. However the statement of work is just one part of a set of contract documentation that can seem bewildering to the uninitiated.
The primary document (or ‘master contract’) in a contract documentation set should be a “Master System and Related Services Supply Agreement” (or similar wording). This contract applies for the full duration of the relationship between the customer and the supplier and defines the relationship between the parties at a high level. It will usually contain sections on topics such as Software Acceptance, Intellectual Property Rights, Confidentiality, Liability, Insurance, Warranties and Dispute Resolution. It’s important to point out that the parties can agree that the contract state a requirement to have subsidiary agreements in place in relation to issues such as Dispute Resolution or Software Acceptance, but the specifics of those agreements can be detailed in separate appendices or annexes referred out to from the master contract. Such contracts are usually written in legalese, so Lumenia always encourages clients to seek legal advice on the content.
All other documentation (such as statements of work, software, consultancy, and support agreements) should be linked to the master contract. The idea is that the master contract remains in place and multiple SoWs with associated commercials can be executed as and when they’re required. So, for example, there may be an SoW for Phase 1 of your ERP implementation, a second separate SoW for Phase 2 and a third SoW for a system upgrade two years later.
Amazingly, I’ve seen instances where businesses have simply take the standard contract as provided by the vendor and signed it, assuming (incorrectly) that it’s a standard document that everyone accepts and which can’t be changed. I’ve also seen cases where the vendor doesn’t insist on a contract being put in place for services – they’re just happy to sell the software licences. If everything runs 100% smoothly then this never becomes an issue, but clearly your interests as a customer are woefully under-protected if something should go wrong. Make sure you don’t make this mistake!
Check out our latest blog on Solid contracts are a foundation of successful ERP projects.
This blog was written by John Donagher, Principal Consultant at Lumenia. If you would like further information on ERP contracts please send an e-mail to John Donagher.
