Armin Sestic - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

Why customizing ERP software is usually a bad idea

To get the functions and flexibility that support your organization's competitive edge, try these five solutions first, before customizing ERP as a last resort.

Any reputable consultant, and anyone with experience using or supporting packaged ERP software, can tell you that customizing ERP is a very bad idea for several reasons.

  • Custom code is a lot more expensive to build and maintain than packaged software.
  • The required development time delays the the time-to-benefit for users.
  • Unlike packaged software suites, custom code will only address perceived current needs, with no additional functionality for growth for as-yet-unidentified future needs.
  • Modifications to a packaged system threaten the reliability of the vendor's system and invalidate any claims to integrity and auditability the vendor may have provided.
  • Most importantly, modifications make continuing the support and upgrade process difficult and expensive.

Given all of the above, why do companies still persist in customizing ERP systems? The simple answer is that they have determined that the package does not meet their needs, and these additional functions or altered capabilities are necessary and cost-justifiable.

Considering the highly competitive nature of the ERP software market, and the decades of development by many hundreds of software vendors, one might think that all possible functionality would be out there and available. And that's mostly true.

Today's ERP has more functionality and flexibility than any company could possibly use. But that, in itself, presents another problem. Tailoring the system (and altering that tailoring as needs change) can be challenging -- but not nearly as difficult or expensive as custom modifications.

Now, as always, companies must decide if they need functions that are not supported by the software package as delivered and implemented. The hierarchy of choices is as follows, in order of least to most expensive and disruptive.

  1. Use the software's tailoring capabilities to get as close to the needed functionality as possible, and fill in the gap with procedural changes (workarounds). Use the software's built-in ability to support added fields, screen changes and other customizations, if appropriate.
  2. Find third-party software that has an interface (integration) supported to your ERP.
  3. Find third-party software and build your own interface using middleware tools to enable the exchange of information.
  4. Write your own interface to third-party "point solutions" without changing the internal code of either the ERP or the add-on software.
  5. Write custom code that provides the needed functionality outside of the ERP system, with appropriate interfaces between the two, preferably using middleware and without customizing ERP code.
  6. Treat the customization of ERP code as a last resort.

What you lose from customizing ERP

The prospect of modifying business processes to fit the software has always been controversial. Companies feel -- and rightly so, in many cases -- that their unique processes are essential elements of their success and competitive edge. Bending those processes to fit the standard practices embedded in packaged software is seen as compromising that competitive edge.

On the other hand, processes and procedures embedded in packaged software are often touted to be industry best practices, so they may be better, more efficient or more effective than what the company is currently doing.

It can be hard to distinguish which way of doing things is better, especially for someone inured to the current processes who might find it hard to give an objective assessment. An outside opinion from, say, a consultant who is familiar with your industry, but who is not beholden to the vendor's way of doing things, can be a valuable resource in making that determination.

You may notice that the above list of alternatives does not specifically mention the use of spreadsheets or stand-alone business software, including data management tools such as Microsoft Access. These are to be avoided if at all possible.

The essence of ERP is the sharing of data and universal visibility. Disconnected systems and spreadsheets are, by nature, outside of the system's purview, and do not contribute to the coordination and joint effort toward achieving company goals. They also entail duplicate entries, concerns with timeliness of information and pointless discussions of whose information is correct or the most up to date.

Tailoring, configuring or customizing ERP or any packaged software product is always a controversial topic because getting it right is critically important for getting the most from your system and effectively supporting company operations and success.

The evolution of packaged software has provided many more alternatives, and far broader customization capabilities (without real modification), than ever, so customizing ERP is not as tempting as it once was. Nevertheless, it is still an issue.

Interestingly, the trend toward cloud-based systems -- with their reputation for being more difficult, if not impossible, to modify -- is another factor motivating organizations to squelch the desire to customize ERP and other packaged software. 

Next Steps

Learn about ERP integration strategies

Implement hybrid ERP

Understand ERP change management

Dig Deeper on ERP integration

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What is the main argument against customizing ERP?
I think that the main reason that companies customize their ERP and CRM is that the salesmen for these packages tell the potential customers that it will be easy, cheap, and have little risk. Try entering the following combination of words in Google.
Hi Dave, 
In more legacy packages I certainly agree.  However, modern cloud platforms make customizations much easier to complete.  You mention that cloud applications are harder to customization which I have not found to be the case having worked with a Cloud ERP provider for over 5 years now. 
Some of these customizations are point and click or workflow configurations but some do require code.  The code in these instances directly interfaces with a common object model and the vendor ensures that it has compliant specifications for writing said code so that the system is continually upgraded twice annually.  In these instances I see no reason not to be willing to undertake customizations as long as the business case supports it.  

Just because you can customize does not mean you should.  

Great article on the drawbacks of customizing legacy systems. However, I think you might want to do more research on your assumption of cloud based systems.