When to customise your ERP, and when to change how you work

Some weeks into most implementations, a request appears: the system does not do it the way we do it, so change the system.

Sometimes that is right. Often it is not. And the two look the same when the request is made, which is what makes this decision difficult.

First, the distinction that matters

Configuration and customisation get used interchangeably and are not the same thing.

Configuration is using settings the platform provides — a custom field, a workflow, a print format, a role. It survives upgrades and needs no developer.

Customisation is code that changes behaviour. It works, and it becomes something you own: it must be tested against every future upgrade, and whoever maintains it later has to understand it.

A surprising share of requests turn out to be configuration once examined properly. Establishing which one you are dealing with is the first step, and it is often the last.

Four questions worth asking

Is this how the business works, or how this software worked?

Processes calcify around whatever tool preceded them. A step that exists because the old system required it is not a business requirement, but it feels like one to the person who has done it for nine years.

Worth asking: if we were starting today with no system at all, would we still do this?

Does it differentiate us, or is it just familiar?

If a process is genuinely how you compete — a pricing structure customers value, a service others do not offer — customise. It is the reason customers choose you.

If it is an internal habit, the question is why you are paying to preserve it. Most requests fall here.

What happens if we do it the standard way?

Sometimes: real cost, real risk, genuine inefficiency. Then customise.

Often: some irritation for a few weeks, then it becomes normal. That irritation feels enormous during a rollout and is usually forgotten within a month.

Who maintains this in three years?

Customisation is permanent in a way that configuration is not. Every upgrade has to be tested against it. If your ERP partner changes, someone new has to understand it.

That is fine for something valuable. For something convenient, it is a cost paid repeatedly for a benefit received once.

Requests that are almost always worth building

Not an argument against customisation. Some categories consistently pay for themselves:

• Statutory and compliance requirements specific to your state or industry — not optional
• Integrations with equipment you already own — weighbridges, biometric devices, batching plants, lab analysers
• Documents customers or authorities see, where format is prescribed or expected
• High-volume repetitive work, where saving seconds per transaction compounds into real time
• Genuinely industry-specific processes — royalty passes, mix designs, RA billing — that generic ERP has no concept of

The sequencing that avoids most of the argument

Run the standard configuration for one full cycle first — a month for payroll, a quarter for project billing — then review the list of requests.

It is uncomfortable, and it consistently works. Some requests disappear because people find the standard route. Some turn out to be configuration. The ones that survive contact with real use are the ones genuinely worth building, and by then you can describe them precisely, which makes them cheaper to build.

Building the whole list up front means paying for all of it, including the parts nobody would have asked for twice.

A reasonable rule

Customise where you are different in ways that matter to customers or to the law. Adapt where you are merely used to something.

Most businesses are far less unique operationally than they believe, and far more unique commercially. Spending customisation budget on the second and standard processes on the first is usually the right allocation.

If you want a view on which of your requirements are which, see how we approach customisation for ERPNext and Odoo or book a consultation.