System Change v's Customisation v's Configuration v's Standard
One of the top costs of implementing a new ERP system can be the level of changes to base code required to implement the system according to requirements. Are these business processes necessary? Can better processes be deployed?
When vendors are performing a system demonstration, a question often gets asked, “Can the system do this?” The vendor will almost always answer Yes, indicating the system will do it.
For example, the vendor might be demonstrating an approval process, and they will get asked the question, “Can the system send to two or more approvers at once and approval by either one will be sufficient?” The answer could be “Yes” and then we can move on, and the potential customer has the impression it is standard and no cost to implement.
However, the question then should be, “Is that standard functionality or does it require a system change?” If it is standard it should be followed by, “Is it standard in the system proposed for delivery?” because it could be in a future release or in an add-on module.
If it is standard functionality and in the proposed version of the system, score 10 and move on to the next item.
If it is standard functionality and requires configuration – then there will likely be a transaction in the system where the approval workflow and constraints are entered, and then the system will run as required. Score 10 and move onto the next item.
If customisation or system changes are required, then it may be best to look at alternative business processes first, as good ERP systems will generally support best practices as standard, or with some customisation.
If customisation is required, then there will likely be a change using specialist user friendly customisation tools provided by the vendor. When the system is upgraded the new functionality will automatically upgrade with it. An estimate will be needed for the customisation and then a decision can be made whether it is worth doing. This is likely to be a very low risk solution with the decision decided by cost versus benefit.
If the functionality requires a system change, then the core “black box” of the system will need to be changed. This will need to be version controlled and is a risk. Every time the system is upgraded there will be an additional cost to the upgrade to allow for this additional functionality to be retrofitted and tested, as it may not be supported by the vendor.
It is important to be aware of every piece of functionality that is non-standard and requires system change. This introduces cost and risk to an implementation and upgrade, and increases the total cost of ownership.
If system changes are required, they should be managed to a minimum. As stated before, the workflow in vendor systems in general is built around best practices, and should cater for most organisations requirements as standard. The requirement is therefore likely to be non-standard, and the business process should be analysed, and alternatives explored using standard functionality. Additionally, the benefits around these non-standard practices should be analysed before concluding if a system change should be requested or not.
Lumenia has over 20 years’ experience of analysing companies requirements and translating these into asking the right questions of vendors in order to get a solution from the vendor that is correctly costed.
This blog was written by Jon Marshall, Principal Consultant at Lumenia. For further information on Lumenia or on System Change please send an email to Jon Marshall.