ERP: Selection and Configuration
Tuesday, May 07, 2013
Many organisations purchase their ERP package from a vendor and after the software has been delivered and installed go through a configuration process to align the software with their requirements.
Given that 60% or more of organisations carry out modifications to the software after it is delivered and one of the biggest complaints about ERP implementations, from customers, is that “The ERP software does not do what we thought it would do” you would think that the selection process is flawed. It is!
Purchasing ERP software and then going through a configuration process (which software houses include as part of their fees) is like building a house and after it is built, designing it and then modifying it.
Yes, the way organisations go about buying ERP software and then going through a configuration process post purchase to find that it requires modifications or doesn’t fit their requirements is absurd. ERP software vendors love it and have established and encouraged this method of selecting and post purchase configuring software as the normal way of doing things. It avoids exposing the ERP package to close scrutiny prior to buying the package and ensures increased revenue for the software house in carrying out modifications and provides an excellent out for accountability and missed deadlines in the implementation schedule.
The only way to avoid this is to do the work up-front by taking the gathered requirements data from the organisation and then producing a model as to how you want it to work. The model is in fact how you want the software configured and so it performs two purposes. Firstly you can test the software against the model to ensure it does what you want it to do and minimises the need to modify the software post purchase.
Are there any issues with this? Yes! The ERP software vendor will not want to put in the effort up-front as it will expose the weaknesses in the ERP product they are selling and it will reduce the scope for post purchase modification and configuration services they love to add-on.
ERP vendors will resist using the excuse that pre-sales configuration is too costly and not worth their effort. They would prefer you buy it based on their demonstration where they don’t actually simulate your business and expose the weaknesses of the software and where they can make all sorts of statements about flexibility and adaptability that they don’t commit to writing and that they claim later on you misunderstood what they said.
The model based on the requirements you have established in-house and the linking together all of the elements firstly shows you whether you have covered all of the areas in your business, provides the configuration map for the delivered software and this can form part of the ERP contract deliverables.
If you chose not to test the software through the model due to vendor guarantees that the ERP software will support the model then tie the model together with the defined individual requirements into the contract so that is what the ERP vendor has to deliver. That way the ERP vendor will have to carry out any modifications to their cost as they have to deliver in accordance with the model and defined requirements. In any event ensure the deliverables is performance against the model.
Choosing not to test against a model is a second best solution as you may find the integration and functionality post-purchase contractually correct but impractical for use in the business but in compliance with the contract. This will lead to the inevitable software modifications. It is preferable to construct your model with the detail and test prior to the purchase of the software. You will achieve a better outcome and can spend the time implementing the technology and not arguing about modifications and the impact on the ERP project.
This path of selecting ERP software deviates from what has evolved as a very unsatisfactory norm in the market place for selecting and configuring ERP software. It will provide you with a much better outcome, avoid the massive modification costs associated with ERP projects and provide the basis for holding the ERP vendor accountable for defined deliverables.
Where vendors refuse to co-operate then simply walk-away and find a vendor that will back their product and set it up in the way you want to see it. Often ERP vendors will resist due to the fact their product cannot do what you want it do, unless the package is modified. If the ERP vendor wants the sale make them work for it!
Where you are inclining towards a particular package and the vendor resists the modelling concept then offer them some compensation for the cost of putting the configuration together. You will save the money tenfold in not having to carry out modifications to the ERP package during the implementation process.