Why You Should Minimize Customization in ERP Projects
Customizations used to be a bad thing in ERP projects. When I first joined the ERP (Enterprise Resource Planning) industry, my seniors often discouraged their customers from customizing their ERP projects.
But time has changed. These days, ERP projects are being more and more heavily customized. Some ERP vendors and consultants are very proud of the customizations that they have done.
I have spoken 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, while the other group is puzzled about my recommendation.
Very often, the group who concurred with me were people who had experience in ERP implementation. On the other hand, the puzzled group was often those who had no experience. The latter could not understand why they should not make ERP work the same as they are working now through customizations.
I have 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 beneficial to the customers in the long run:
- 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 backgrounds instead of operations and finance backgrounds. It is second nature to them to suggest customizations as part of their solution. You may 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 have limited time to research and test out standard functionalities to meet the user requirement. Sometimes, they intentionally create more customizations to recover lost services revenue. Such a strategy was often adopted, especially when the vendors realized they were 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. This makes it difficult for another vendor to take over.
- More customizations will result in more support services required. As the customers are now locked down, vendors will be able to charge their support services at a higher price.
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 than the built-in functionalities developed for hundreds or thousands of customers.
In some projects that I came across, the customization cost was more than two times the initial implementation services.
For best practice in ERP project management, companies should keep additional customization costs within 30% of the total ERP project costs.
Lock-down (Source Code)
ERP vendors will lock you down. Some vendors do not share the source codes of their customizations with the customers. Heavy customization also makes it harder to change to another vendor.
Quality and bugs
Customizations are often done under a tight timeline. As vendors usually try to save development costs, quality control in customizations is difficult. Due to time constraints, programmers tend to ignore future maintenance and configuration considerations when creating customizations. This often leads to more customizations in the future.
On the other hand, quality control on the development of standard ERP products is much more systematic and detailed.
In an ERP project, programmers need to understand ERP’s standard processes before creating any customizations. Without a proper understanding of the standard ERP process, the customizations may result in unexpected problems down the road.
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 customization code before identifying the issue. Support for customization issues will also incur more consulting resources than support for standard ERP processes.
Most of the bugs usually come from customizations. Consequentially, the cost of supporting 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 results in quality and project stabilization issues.
Very often, customization testings are not properly conducted due to the tight timeline and poor project management. Bugs will only be discovered after the project has gone live. This results in a longer time taken to fix the bugs and to stabilize the ERP project. This will further complicate the job of the support consultants as they have to fix these bugs all whilst having live data being fed continuously into the ERP system.
Cost of Upgrading
More customization will lead to more servicing costs in future upgrading. The consultants will need additional effort to migrate each customization to the later ERP version, and the process will be laborious.
Limitation of Customization on Cloud ERP
Cloud ERPs that are hosted on the public cloud sets a limit to the extent of customization allowed. 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 customize. There are various considerations that you need to take note of when face with customization requests.
Do a Thorough Evaluation
The first thing you should do is 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 it well.
Some customizations are unavoidable. Printed documents such as invoices, purchase orders, sales orders, etc. should be customized. The alternative is to try using the standard formats that are already available in the standard ERP.
You can consider customizing reports that your company will need to view or print frequently. Reports running from within the ERP, either through customized 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 note that once you start on a few customizations, it will be difficult for you not to request other customizations.
Automation with Sufficient ROI
There is no limit to the imagination about automation requests in an ERP project. Many users wish to use ERP to minimize their daily work. These users tend to request customizations that can automate their work.
How are you going to decide which customization requests to continue forth? I have listed three keys below for you to consider when faced with such a 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 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 rethink their stand on customizations until after their project has gone live and stabilized. Most found that they could in fact do away with some of their earlier requests and were amazed.
Below is an actual project customization request in one of our projects previously:
The 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 and then re-look into them after the project has gone live. Two weeks after their project went live, we then reviewed the list again. We realized that we could combine points 2, 3, and 4 into one program instead of 3 different programs. Users also found that they did not need points 5 and 8 after using the system for two weeks.
Insist on Source Code
Always make it clear to the selected vendor that you have the right to own the customization source codes you paid for. This will make it easier for you to change the vendor later if needed.
I have gone through in length to explain why you should minimize customizations in your ERP projects. I hope you now understand why there will be a heavy price to pay to have your ERP customized exactly as you wanted. It is even riskier if the companies engaged programmers to customize ERP from the ground up.
Project management is the key to minimize customization in your ERP project. In my previous article, you may also like to read “10 Keys to Successful ERP Implementation” for ideas on how 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 has spent his career in the ERP industry as a consultant, sales, and ERP company management.
Raymond also taught at 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 an end-user and vendor. He has dealt with hundreds of companies in Singapore and the region on ERP projects. This allows him to share the practical approach to ERP selection, implementation and maximizing the ROI of ERP Projects.