Configure or Customise ERP

To start, we need to understand the difference between configuring and customising an ERP system.  A good explanation I’ve seen is from Alan Rencher’s LinkedIn post, edited slightly . . . . .

A customisation is a feature, extension or modification that requires custom coding or some form of unique implementation.  Configuration is the use of native system tools to change an application’s behaviour or features.  The key differentiator is this: Does the work done roll with an upgrade?

Configurations are a given during the implementation of a new ERP system by changing system parameters, including

  • Organisation Structure
  • Time Zones, Tax Rules, Currencies, Language etc.
  • Fiscal Calendars
  • Personalisation and Tailoring
  • User Roles, Authorities, Securities, Segregation of Duties and Access Rights
  • Revenue and Cost Recognition Rules
  • Stocking Rules
  • Process Automation using Process Workflows, and the like

These configurations tend to remain static during the life of the ERP but can be modified with varying degrees of effort and disruption should the need arise, and they almost always survive system upgrades – most modern ERPs ensure they do.

The similarity or otherwise of an out the box ERP’s functionality to an organisation’s requirements will give a Requirements Gap.  The size and nature of each gap will decide whether a configuration or customisation is needed. 

Let’s assume the gap is the way the ERP handles a business process differently to the way the organisation handles that process.  There are two options here; either the organisation must change its process, or the ERP must.  If it’s a case of just changing a system workflow, most modern ERPs can achieve this as a configuration.  If not, and the organisation is adamant its process gives it a competitive advantage in its market, then customisation is unavoidable.  And it is those ERPs that can be customised by extending their functionality using built in tools that excel – cost, time and upgradeability-wise.

Larger gaps need increasingly severe (read time-consuming, costly and disruptive) customisations.  There are several ways in which this can be achieved each with its own pros and cons.  For example, if an ERP doesn’t have Human Resources functionality, you might have to develop from scratch or buy a third-party add-on product customised to your requirements and develop the integrations to your chosen ERP system.

Customising an ERP’s code can have unwanted side effects

  • Regulatory Compliance
  • Vendor Warrantees
  • Total Cost of Ownership
  • Availability of Support
  • Implementation Timelines, Risks, and Costs
  • Cost and Disruption when Upgrading
  • No Advantage gained from the ERP’s research and development in Best Practices

As a result, few organisations want to customise a new ERP.  It is normally the case that the strategy for a new ERP implementation is “vanilla and out the box as far as possible”.  But people don’t like to change the way they work so this is not often stuck to – scope creep is the culprit (more about that in a later Blog).  Also, what starts out as a “minor change” grows as business analysts and developers spec and code the customisation.

Panorama Consulting Solutions’ 2018 ERP Report found that just 11% of its respondents implemented their ERP without customisations and that 37% did significant customisations to their ERP system.  ‘Significant’ was 26 to 50% customisation!  Yet Panorama’s rule of thumb is that over 20% customisation should raise a red flag.  

So how do you address the issue when the degree of customisation is influenced by the choice of ERP to start with.

Choose the ERP with the best fit – All organisations operate differently.  This means that before even starting the selection process, you need to have a documented and agreed list of requirements and then stick to them by choosing the ERP that best fits the list. 

Choose an ERP with tools that extend functionality without changing code – You can then solve business problems with built in tools that don’t require code changes.  This brings new functionality faster and cheaper and enables data integration – you can create custom business apps without the time and expense of custom software development.

Choose an ERP that integrates extensively and seamlessly with your choice of office application.

Decide upfront to limit customisations – Agree to change business processes to match the ERP’s processes wherever possible.  Customisations should be considered only if they give a competitive advantage.

Use strong project management and control. Don’t allow users’ wish lists and resistance to change derail your decision to minimise customisations.  Park them for future phases which often don’t materialise.

Choose an ERP that has an extensive array of OEM certified third-party product extensions – Not add‑ons and bolt‑ons which will limit upgradability.  OEM vendor certification ensures that the extension developer is forewarned of ERP enhancements in time to confirm their extensions will upgrade with the ERP.