Architecture

ERP customisations: how to manage, control, support, and decide

A practical governance guide to ERP customisations, including decision criteria, support implications, and pros and cons.

Customisation is one of the most misunderstood areas in ERP programmes. Teams often swing between two poor extremes: either “never customise” or “the system must match exactly how we do everything today”.

The right answer is governance. Some custom work is justified and valuable. Too much custom work creates upgrade drag, support complexity, and a platform that only a few people truly understand.

A practical customisation strategy helps the business choose deliberately which gaps should be solved through process change, configuration, extensions, third-party tools, or controlled spreadsheets.

A simple hierarchy for solution decisions

• First: can the business adopt a standard process without harming service, control, or commercial performance?
• Second: can configuration solve the need without creating brittle design?
• Third: is a targeted extension justified by durable business value and stable process needs?
• Fourth: if the need is temporary or low-value, should it remain outside the core ERP under controlled ownership?

When customisation is usually justified

• The process creates significant commercial or control value and is unlikely to change frequently.
• The standard system would force unacceptable workarounds or manual risk.
• The extension is small, well-bounded, and can be supported cleanly through upgrades and releases.
• The business can name an owner for the process and for the ongoing support of the change.

Governance practices that keep customisation under control

• Run a design authority or architecture review for all requested extensions.
• Assess each request against value, process stability, support load, security, and upgrade impact.
• Keep an extension register with owner, purpose, release history, and retirement criteria.
• Review the extension portfolio quarterly so low-value bespoke logic does not become permanent clutter.

Pros and cons

• Pros: better fit for critical processes, reduced manual work, stronger controls in justified areas, and clearer user adoption where standard behaviour is genuinely weak.
• Cons: higher support cost, more complex testing, upgrade friction, dependency on specialist knowledge, and risk of preserving poor legacy habits.

Support model

• Define who owns break-fix support, regression testing, documentation, and release approval for each custom component.
• Do not rely on “the partner will know” as the support model. Capture enough design detail that the business is not trapped.

FAQ

• Are spreadsheets always bad? No. Uncontrolled spreadsheets are bad.
• Is third-party software better than customisation? Sometimes, but it still needs governance and ownership.
• What is the biggest mistake? Approving custom work without thinking about its life after go-live.