When to configure an ERP and when to build around it

The question usually arrives in a form that cannot be answered: should we configure the product we have bought, extend it, or build our own. Put that way it turns into an argument about which approach is more modern, and it is won by whoever presents best. The narrower version is more useful. Which of these decisions can the organisation still live with in five years, once the product has been through several upgrade cycles, the people who made the decision have moved on, and a regulator or an external auditor has asked for something nobody anticipated at the time. What follows is a way of putting that question to one process at a time.

The test that settles most of it is whether the process is genuinely distinctive to the business or merely the way the business grew up. A distinctive process is one the organisation competes on, or one its sector’s regulator requires in a particular form, or one its customers would notice if it changed. The other kind is a form laid out to match a paper one, an approval chain that mirrors an organisation chart from two restructures ago, a spreadsheet that exists because two systems were never connected. Both kinds are defended with equal conviction in a workshop, usually by whoever has maintained them longest. Separating them before any decision about software is the discipline, because configuring the product means accepting its shape for everything in the second group, and accepting its shape is the cheapest thing an organisation can do. Building custom software to preserve an accident of history is the most expensive way to keep it.

Extending a product has a boundary, and the boundary is the upgrade path. Most products offer a surface designed for extension: configuration, scripting in defined places, an API, a way to add a field or a report without touching the code underneath. Work that stays on that surface usually survives an upgrade with a regression test and a day of fixes. Work that goes past it, into the core tables or the screens the vendor rewrites in the next release, is a modification the organisation now owns for the life of the system. Its cost is invisible on the day it is made and arrives three years later: every upgrade becomes a project of its own, the version in production is one the vendor no longer supports, and security patches wait because nobody is confident the modifications will survive them. The practical rule is to ask, before each change, what will have to happen to it at the next upgrade, and to refuse the answer "we will deal with that then" more than a few times.

A good share of what is asked for as customisation is a request for a different experience, not for different accounting. Field staff want to submit something from a phone. A department wants a screen with four fields instead of the product’s thirty. A director wants a view that combines what two systems know. None of that requires changing how the ledger works, and none of it belongs inside the product. It belongs in an application built outside, talking to the product through an integration layer, with the product left standard as the system of record. That separation is also where the bilingual question is best settled: Arabic and English interfaces with a right-to-left layout that behaves correctly are hard to guarantee across a product’s own screens and much easier in an application you control. Where the classification of the data requires it, that layer and anything it stores sit on infrastructure inside the Kingdom, in the same boundary as the records they draw on.

"The vendor said it can do that" is worth taking apart every time it is said, because it is usually true in one of four senses. The capability may be standard, in a module that is not in the quoted price. It may be on the roadmap, which tells you about intent and says nothing about a date. It may be possible with custom development by an implementation team, billed separately from the licence. Or it may be possible if the organisation changes its process to the shape the product expects, which is sometimes the right answer and is never a small ask. The way to find out which one is on offer is to have the capability shown on your own data, following your own process, operated by someone from your team on a system nobody has arranged in advance for the occasion, and then to have the answer written into the contract, where a meeting note has no standing.

Data migration is the line most often underestimated, because it is read as a technical task and is mostly an editorial one. Moving rows is the easy part. Deciding which of three records is the supplier, what the opening balances are, which master data is carried forward and which is retired at the boundary, how much history has to come across for the finance function to compare this year against the last two, and what becomes of the documents attached to old transactions: these are decisions only people from the business can make, and those people have a job already. The audit requirement sits on top of that work. Closing balances in the old system have to reconcile to opening balances in the new one, the reconciliation has to be signed, and the trail between them has to stay intelligible to an external auditor years later, when nobody who did the work is still in the building. A migration plan should name who signs each reconciliation before the first load is attempted.

A phased cutover is chosen to reduce risk, and it reduces risk only if each phase can be reversed. Reversible means something specific: the old system stays intact and queryable for the whole parallel period, its decommissioning a separate decision taken later; the two systems run together for a defined stretch with a reconciliation between them that someone actually reads; the rollback has been rehearsed on a copy of production and somebody knows how long it takes; and the criteria for going forward are written down and agreed before the phase begins, so that the decision at two in the morning on a Sunday is a matter of checking a list. The sequence matters as much as the mechanism. Start with the part of the system that can stumble without stopping payroll, a payment run or a shipment, and leave the parts that cannot until the organisation has learnt how the new system behaves on a bad day.

The answer that holds up is usually a mixture rather than a doctrine: configure the great majority of it, and change the habits the product’s shape makes awkward; extend at the product’s own extension points where the process really is the organisation’s own; build separately, outside the product, where the experience or a distinctive process warrants it; and connect the pieces through an integration layer the organisation owns. As important as the mixture is that the reason for each decision is recorded where a successor will find it, together with what was rejected and why. The organisation should hold the code, the configuration and the documentation for everything built around the product from the first commit, because the five-year question will be answered by people who were not in the room when it was decided.