ERP: build or buy, modelled over five years

Every few months a company asks us whether to buy an ERP or build one. Posed that way the question has no good answer, because it treats ERP as a single thing. It is not. It is a bundle of a dozen capabilities with wildly different economics, and the right decision is almost always different for each.

Split the estate first

Before modelling any cost, sort your requirements into three groups.

• Commodity. General ledger, accounts payable and receivable, payroll, statutory reporting, tax. These are solved, heavily regulated, and change under you as legislation moves. Building them is close to indefensible — you would be paying engineers to track tax law.
• Configurable. Inventory, basic procurement, CRM, standard approval workflows. Off-the-shelf systems handle these adequately if you are willing to adapt your process to theirs. The real question is how much that adaptation costs in retraining and lost efficiency.
• Differentiating. The workflow that is specific to your industry and how you compete — the yard logic at a bulk terminal, the batch genealogy in a regulated plant, the pricing engine that reflects contracts nobody else has. This is where custom software earns its cost, and where packaged systems force expensive, fragile workarounds.

Buy the commodity. Configure the configurable. Build only what differentiates you — and be honest about how short that list is.

The costs left out of every model we are shown

Vendor comparisons tend to model licence cost and implementation fees, then stop. The items below are what actually determine the five-year number, and they are systematically underestimated on the buy side as often as on the build side.

• Implementation, at two to four times first-year licence for a mid-market ERP. This is the largest single line and the most frequently understated.
• Data migration and cleansing. Deduplicating supplier and item masters is slow, manual and unavoidable, and it is where most go-live delays originate.
• Customisation and integration, including every connection to the systems you are keeping. Then the cost of re-testing all of it at each vendor upgrade.
• Process change and retraining, plus the productivity dip in the first two quarters after cutover. Real, large, and almost never budgeted.
• Annual maintenance at eighteen to twenty-two percent of licence, compounding with any seat growth.
• Upgrade projects every three to five years, which for a heavily customised instance approach a small reimplementation.
• On the build side: the ongoing team. Custom software with nobody maintaining it becomes the legacy problem you were trying to escape, and that is a permanent line item, not a project cost.

The middle path most companies land on

In practice the durable answer is usually a well-integrated hybrid: a packaged system as the financial system of record, custom software for the differentiating workflow, and a deliberate integration layer between them with idempotent syncs, reconciliation reports and alerting when a record fails to land.

The integration layer is the part that decides whether this works or becomes a permanent source of pain, and it is routinely treated as an afterthought. Build it with the same rigour as the applications on either side: typed contracts, retries, dead-letter queues, and a reconciliation report somebody actually reads each morning.

A test worth applying

For any capability you are considering building, ask whether a competitor could buy the same thing off the shelf tomorrow and be at parity with you. If yes, buy it. If no — if this workflow is genuinely part of why customers choose you — that is the case for building, and it is the only case that survives five years of scrutiny.