When to customise an ERP and when to change the process instead

Collect every request on one sheet, whether from accounts, stores or sales, and write it as a sentence about work rather than a screen. A good one reads like “warehouse staff must see the supplier’s batch number at goods receipt”, while “add a field” tells nobody anything.

Then assign one of four outcomes. Configure means the standard product already does it through settings, number series, approval rules or print layouts, while customise means changing the product’s own code or database. Integrate means a separate tool does the job and exchanges records with the ERP, and adopt means your team changes the way it works instead.

Most land in configure or adopt. A request that looks like custom work is often a missing setting, such as an approval limit, a number series or a print layout nobody has opened yet.

Ask how often the task happens. A step done forty times a day by six people in dispatch deserves real effort, while a year-end step done by one accountant can stay a spreadsheet macro.

Next, ask what is at stake. A wrong tax code on an invoice, a missed expiry date on a stocked item or a credit limit that fails to block an order all carry real cost. A tidier delivery note does not.

Ask what the change does to upgrades. Teams forget this one. Vendors ship patches and new versions every few months, and every change to the core must be retested, merged and sometimes rewritten. Score each wish high, medium or low on all three questions, and treat two highs with a low upgrade burden as the only fair candidate for customising.

A customisation is not a one-time purchase. It is a standing obligation to retest. Each time the vendor changes a table, an API or a screen the custom code touches, someone has to read the release notes and test the change.

Ten small changes become a project. Merge conflicts alone eat weeks. Each one needs a test script, a person who understands why it exists and a decision on whether it still applies, and the work repeats at every release. Teams that skip this work end up frozen on an old release, missing the vendor’s security patches and unable to adopt the new reporting screens.

Keep a register. Every customisation goes in it with its owner, the process it supports and the upgrade test that proves it still works, plus the date it was last used. Without an owner, it goes.

Standard processes carry accumulated experience. The approval route, the three-way match of purchase order, goods receipt and supplier invoice, and the month-end close order have usually been tested against thousands of firms.

Your habits may outlast their reasons. Ask why the current practice exists. If the answer is “the last system did it that way”, try the standard path for one full cycle, such as a single month-end close, before building anything.

Some wishes are genuinely different, though. A job-costing rule peculiar to your trade, or a pricing matrix that drives your margin, can be the reason you win work. Protect those. Spend customisation effort on the few places where your method is your edge, and let the standard screens carry everything around them.

Take the full wish list and give each line its bin, its three scores and a named person who owns the call. One page per module. No more.

Ask the vendor or implementer to confirm which wishes settings already cover, since many teams find a third of their list disappears at that step. Settings cover more than expected.

Bring the shortlist of true customisations to a single review with finance, operations and the warehouse supervisor in the room, and record the decision beside each line. Anything that still lacks a named owner after that meeting goes back to the adopt bin, whatever its sponsor thinks of the idea. No exceptions.