ERP Flexibility and the Ability to Customize

July 25, 2011
By djohnson

Customizing ERPIn a recent Panorama Consulting blog post, Eric Kimberling discusses if SaaS ERP is right for everyone. In the analysis, he says:

The fact of the matter is that SaaS ERP systems are still not as flexible as on-premise solutions. While this may change, it is generally more difficult to change SaaS offerings to fit your business.

Every ERP software provider claims “flexibility and customization” as a selling point – but what does it really mean to be customizable?

Every ERP can be Customized

I have never seen an ERP vendor advertise that they have a non-customizable system. The word ‘never’ is a strong one, but I think in this case it is justified.

There are two main drivers behind this.
(1) With enough time and money software can be changed/re-written to meet almost any client need.
(2) Sales people explain that their software can do anything. The ‘anything’ can involve a minor configuration or a major customization.

Some software is more customizable than others

Given that the above is true (any system can be customized with enough time and money), here are some key factors that can help buyers determine the feasibility of customizations.

(1) Configuration versus Coding

Software configuration is accomplished using the product interface and menus without writing new code. If your business requirements can be configured as part of the installation process, then costs and ongoing support for the system will be lower than a customized system.

Unfortunately, the definition of configuration is not always black and white. Some ERP software includes utilities that enable users to add database fields and modify business logic. If vendors call these types of changes “configurations,” then it’s clear that not all configurations are the same. A “configuration” involving adding fields to and modifying a business workflow is going to behave like a customization in terms of cost and implementation time.

Most ERP software solutions offer an application programming interface (API) to enable customizations outside the core code base. A well-documented API still requires coding so your definition of ‘flexible’ and ‘inexpensive’ may be stretched, but the good news is that product upgrades can be accomplished without breaking customizations (assuming APIs are backwardly compatible from release to release).

(2) SaaS versus Licensed Software

As Eric Kimberling from Panorama Consulting pointed out “SaaS ERP systems are still not as flexible as on-premise solutions.” This is primarily because many SaaS systems are shared across companies (see article on multi-tenant ERP software) on a single environment in order to drive down costs. The fact that many users share a single architecture means that some things can be customized, but these customizations are limited.

SaaS systems are hosted in an off-site datacenter. Therefore, communication with legacy on-premise systems requires a network connection. If the integration is a daily update of sales orders or invoices, then connectivity will not be an issues. However, if integration requires real-time communication of large inventory quantities and serial numbers, then bandwidth and timing should be considered.

(3) Access to Source Code

An ERP solution that provides access to source code will be more customizable than one that does not. The source code that is available should utilize industry standard tools to ensure competitive pricing for customizations. Higher level programming languages lower costs by providing pre-written code for common tasks (imagine how difficult it would be to write instructions in 0′s and 1′s), but proprietary tools and abstractions reduce the amount of flexibility available to third party programmers.

Other ERP Customization Considerations


Cloud software can be just as customizable as client-server or on-premise software. But before doing ERP customizations, weigh the costs (both one time and recurring) against any strategic advantage you may gain. Doing massive customizations because “that’s the way we have always done it” should raise a red-flag unless the “way you have always done it” helps you win in the marketplace. If you can modify your non-strategically important tasks to fit industry standards, then you will save money on implementation and have fewer long-term hassles as new releases become available.

Before customizing, make sure that your customizations are not locking you into the current version of the software. Ensure that your customizations are built so they do not break when the software vendor releases new versions of the software. With some changes there is always a risk, but most vendors will ensure backwards compatibility with updates done using their development tools.

I’ve heard many customers complain about an existing software vendor yet continue using their software due to the cost of switching. Customers are locked-in because they spend hundreds of thousands of dollars on custom code to fit specific company requirements. In some cases these requirements are mission critical, in other cases they are simply non-standard practices that add to the cost of software. Before implementing ERP software, buyers need to determine which customizations are required and which can be replaced by standard processes.

Feedback?
Are you in the middle of an ERP software customization? Have you successfully completed one? If so, please leave a reply below or contact us to tell us about your experience (positive or negative).

Tags: , , , ,

Leave a Reply

*