Monday, September 08, 2014
(advice from an expert witness in ERP disputes)
The process of selecting an ERP project goes through a number of steps. Firstly a requirements document is prepared by the buying client representing their view of their specific needs. These documents are typically couched in layman’s terms and are forwarded to prospective ERP vendors.
After sorting through the various responses from the prospective vendors a shortlist of potential suppliers is settled on and arrangements are made to organise demonstrations of the various ERP products. These demonstrations use a sample organisation as the basis for the demonstrations but the concepts are kept simple which do not necessarily reflect the complexity of the buying company.
During these demonstrations a number of issues arise whereby the ERP vendors respond with answers that are rarely documented but the client feels comfortable with the responses from the supplier.
It must be remembered the job of the software sales people is to sell the product and flexibility with the truth is part of the sales approach.
From the demonstrations and discussions a preferred package is identified and a more detailed proposal is requested from the vendor. These proposals often do not reflect the discussions that have taken place and tend to be somewhat vague in detail of what is being provided.
Along with the proposal software ERP vendors also want to sell their implementation services which are usually accompanied by their own brand of proven implementation methodologies. These methodologies come in various names but revolve around the words “Proven” or “Best Practice” To overcome the vagueness in the contract itself these methodologies contain a series of steps which typically contains a step or steps relating to “Clear Statements of Requirements” as being fundamental to successful implementation.
All of this serves to give the buying client confidence that their needs will met as a result of the software demonstration, the assurances given during the demonstration and the proven path methodologies that will be employed to meet their needs.
It is during the implementation stage when the software does not meet the expectations of the client and reference is made back to the assurances given by the sales people but is not reflected in the actual contract documents and the steps in the proven path have not been taken to ensure what is being delivered meets the clients expectations.
The differences between what the client believes he is being delivered and what is actually being delivered manifests during the implementation stage when customisation costs soar and budget overruns start to bite.
Discussions with the ERP vendor are met with “we didn’t agree to that” and reference is made back to the contract, which was vague, pointing out what is being delivered.
At this stage the relationship turns toxic as the client believes he has been misled and the realisation that the cost blow-outs are well beyond the budget and in many cases what the company can afford.
The vagueness of the contract puts the buying client at a great disadvantage in the event of a dispute. Assurances given at the time of the demonstration and subsequent discussions are denied or put down to misunderstanding all of which leaves the buying client with huge cost blow-outs and or a sub-standard system.
With the massive complaints coming from the organisations buying and implementing ERP systems it is in the interest of buyers to ensure they document exactly what they require with performance indicators against critical areas. It may take more time and effort to nail down the detail but in the end you get what you wanted or have the grounds to hold the vendor accountable.
Experience Worth Listening to!