ERP Software Selection Traps
Tuesday, February 25, 2014
With daily reports emanating around the world of high profile ERP disasters it is worth examining the different perspectives of the buyers of the technology and the sellers and integrators: The buyer, who needs the technology to support his business, goes through a process of identifying his requirements via some form of internal investigation. These requirements are
translated into a specification which is passed to prospective vendors and a series of demonstrations takes place to determine the best fit for the organisation. This may sound logical but the manner in which this is conducted, more often than not, leads to downstream problems of excessive, costly modifications or additional software being purchased to obtain the functionality required.
The problems are a list of requirements that are ad-hoc demonstrated, and not simulated in a fully integrated way, leads to a mismatch of needs versus capability. The devil here is in the detail on how the software handles the requirements. Rarely does the initial specification detail how the software functionality needs to work in detail. The software vendor may tick the box for yes the software can do something but does it do it in the way
that suits the buyer’s needs. An example of this in the forecasting area. The requirement may have been for multi-site forecasting capability. The software may be capable of handling forecasting from multiple sites however, the detail behind the requirement may have been the aggregation of products into product family by sales, by region. It is the detail on what is required that goes beyond the simple requirement of multi-site forecasting.
An examination of ERP projects that have massive customisation or additional software costs time and time again demonstrate the shortcomings in the detail on how the software functionality was identified up-front.
The ERP software vendors are not going to willingly point out the limitations of the software during the sales cycle for fear of losing the sale. Behind the smooth talking PR friendly sales team lurks the dilemma of telling all the story or risk not making the sale. The implementation problems are not the issue of the sales team, they have done their job and secured the sale. It is someone else’s job to integrate the technology.
To avoid this problem more work needs to put in by the buyer up-front to produce a detailed model identifying the specific way in which they want the software to work and then using this model and detail to get the software seller to simulate the running of the company through his software. Software houses do not want to do this as it exposes their software to shortcomings and risk losing the sale.
The dilemma for the software seller is that they have to sell into a market that is very competitive and they compete with other ERP vendors that tell the customer what he wants to hear knowing that they are not being totally honest with the customer. The only solution to these problems is for the buying customer to spend more time up-front in specifying exactly what the requirements are, producing a model and having the software simulated through the model. It is worth paying for the vendor do this as the cost will be
minimal compared to the cost of modifications, customisation and additional software costs identified during implementation.
Experience Worth Listening to!