Why You Should Minimize Customization in ERP Projects
When I first joined the ERP (Enterprise Resource Planning) industry, my seniors often discouraged their customers from customizations in their ERP projects. Customizations used to be a bad thing in ERP projects in those days.
But time has changed. These days, there are more customizations done in ERP projects. Some ERP vendors and consultants are very proud of the customizations that they have done.
I spoke in many ERP seminars. When I told the audiences that they should minimize customization in their ERP projects, I can immediately see two distinct reactions.
One group will agree with me, and there will be another group who is puzzled about my recommendation.
Very often, the group who concurred with me were people who had experience in ERP implementation. And the puzzled group were often people who had no experience. The puzzled group could not understand why they should not make the ERP works the same way that they are working now with customizations.
I worked with seven different ERPs and hundreds of implementations over the years. I noticed that heavy customization was often one of the key reasons for ERP project failure. This article explains why you should minimize customization in your ERP Project.
Why Some ERP Projects have Heavy Customizations
ERPs are getting more comprehensive and advanced. Surprisingly, the amount of customizations during the implementation has increased when it should be reduced.
There are various reasons for this situation, and most of them are not to the advantage of the customer in the long term:
- Technology advancement has made customizations easier. But no matter how easy it is to customize, the consequences often outweigh the benefits.
- Your company may be in a unique business that no standard ERP process can handle your business processes well. Alternatively, you may have selected the wrong ERP.
- More ERP functional consultants nowadays come from IT background instead of operations and finance background. It is more natural for them to suggest customizations as part of their solution. You may like to read my previous article “How are the Changes in the ERP Market Affect Companies in Singapore” on how this results in more customizations.
- It is easier for the ERP vendors to quote low implementation effort initially to win the project. As the implementation effort quoted was low, the consultants will not have sufficient time to research and test out standard functionalities to meet the user requirement. Sometimes, they intentionally create more customizations to recover the lost services revenue. Such a strategy was often adopted, especially when the vendors found that they underquoted in their initial proposal.
- Some vendors do not provide the source code of their customizations to their customers. Keeping the source code from their customers allows them to lock-down the customer. It will make it difficult for another vendor to take over.
- More customization will result in more support services. And as the customers are locked-down, the vendors can charge a higher fee for support services.
Consequences of Customization in ERP
So, what are the consequences of customization in your ERP project? What are the reasons that you should minimize customization in ERP projects?
Customizations that are developed for a specific customer will be much more expensive for the same functionalities in a standard ERP that are developed for hundreds or thousands of customers.
In some projects that I came across, customization cost was more than two times the initial implementation services.
For best practice in ERP project management, companies should try to control the additional customization cost within 30% of the total ERP project costs.
Lock-down (Source Code)
You will be locked-down by your ERP vendor and challenging to change to another vendor. Some vendor keeps the source codes of their customizations without sharing with the customers.
Quality and bugs
Customizations are often done under a tight timeline. As vendors usually try to save the cost of the development, quality control in customizations is difficult. Due to the limitation of time, programmers tend not to consider future maintenance and configuration when they create the customizations. This often leads to more future customizations.
Quality control on the development of standard ERP product is much more systematics and detail than customizations.
In an ERP project, the programmers need to understand the standard processes in the ERP when they create customizations. Without understanding the standard ERP process, the customizations may result in unexpected problems.
99% of bugs in ERP projects come from customizations and not bugs from the standard software.
Support Response Time and Cost
When the user faces a problem with a standard ERP software process, it will be easy for the support consultant to guess the probable root causes.
If the problem involves customization, the support consultant will have to study the code of the customization before they can identify the issues. Supporting customization issue will incur more consulting resource than support standard ERP processes.
As most of the bugs usually come from customizations, the cost of supporting the projects with heavy customization will be higher than those with fewer customizations.
Prolong Project Duration
Besides the costs, heavy customizations will prolong the project duration. Customizations need more time to create and test. Creating customization in a rush often resulted in quality and project stabilization issues.
Due to the tight timeline and poor project management, testing of customization was often not probably conducted. This led to bugs discovered when the project went live. There will be more time needed for bug fixes of these customizations, and it took a long time to stabilize the ERP Projects. This became even more challenging when live data was continuously entered into the ERP while consultants were trying to fix these bugs.
Cost of Upgrading
More customization will lead to more services cost in future upgrading. The consultants will need additional effort to migrate each customization to the later ERP version, and the process is laborious.
Limitation of Customization on Cloud ERP
Cloud ERPs that are hosted on the public cloud set limit to the extent of customization permissible. Unlike on-premise ERP, cloud ERP will receive bug fixes and enhancement regularly. Sometimes, these bug fixes and enhancements may conflict with the existing customizations.
How to Handle Customization Request
Understanding why you should minimize customization in ERP projects does not mean that you should not have any customization. There are various considerations that you need to take note when face with customization requests.
Do a Thorough Evaluation
The first thing that you should do is to ensure that you do a thorough evaluation of the ERP and the implementation vendors. You may like to read my previous article on “How to Select ERP for SME” for more information.
Doing a thorough evaluation will increase the chances of finding a better matching ERP solution and a vendor who can implement the project well.
Some customizations are unavoidable. Printed document such as invoice, purchase order, sales order, etc. should be customized. The alternative is to try using the standard formats that are already available in the standard ERP.
You can consider to customized reports that will be viewed or printed frequently. Reports running from within the ERP, either through customization or standard report tools usually run faster than external reporting tools.
In cases that there will be frequent ad-hoc versions of the management report, third party reporting or business intelligence tools that allow users to create their report design can be considered.
Opening of a Flood Gate
Do take note that once you started a few customizations, you will unlikely be able to stop other requests for customization.
Automation with Sufficient ROI
There is no limit to the imagination about automation request in an ERP project. Many users wish to use ERP to minimize their daily work. These users tend to request for more customizations to automate their work.
How are you going to decide which customization requests that you should proceed? There are at least three keys that you should consider when faced with such request:
- What is the ROI of this automation?
- Do not assume that your current business process is better than the standard process in the ERP. Try out the standard ERP process first.
- Group customizations into those that are needed before the project goes live and those that can be decided after the project goes live.
Delay Customization Until Project Stabilize
I often tell my customers to delay their decision on the customizations until their project went live and stabilized. And they were surprised later that some of those customization requests could be avoided.
Below is an actual project customization request in one of our projects previously:
This customer requested for eight customizations before the project went live. I managed to convince them to put aside these customizations and focus on the project, then re-look into these after the project is live. Two weeks after their project went live; we reviewed this list again. We realized that we could combine point 2, 3 and 4 into one program instead of 3 programs. Users also found that they did not need point 5 and 8 after using the system for two weeks.
Insist on Source Code
Always make it clear to the selected vendor from the beginning that you should have the right to owe the customization source codes that you paid. This will make it easier for you to change the vendor if needed.
I have gone through in length to explain why you should minimize customization in your ERP projects. And, I hope you can understand why there will be a heavy price to pay to want your ERP to customize to exactly what you want.
Project management is the key to minimize customization in your ERP project; You may like to read my previous article on “10 Keys to Successful ERP Implementation” for ideas to implement your ERP project better.
If you like to have further discussion on this topic, you are welcome to contact us.
Posted 11 June 2020
About the Author
Raymond Yap is a veteran in ERP who implemented the world first Cloud Enterprise Resource Planning (ERP) for his manufacturing company in 1996. It was a Singapore government-sponsored ERP program called “MRP Online” to help Singapore SME towards digitization.
Since then, he spent his career in the ERP industry as consultant, sales, and management of ERP companies.
Raymond also taught in Nanyang Polytechnics, Temasek Polytechnics, and other Universities on topics related to manufacturing, ERP, and IT. He also conducted public ERP seminars in Singapore and Mauritius about the evaluation and implementation of ERP Solutions.
Raymond accumulated rich knowledge and experience on ERP and its application to business operations both as end-user and vendor. He has dealt with hundreds of companies in Singapore and the region on ERP projects. This allows him to share on the practical approach to ERP selection, implementation and maximizing the ROI of ERP Projects.