You Don't Need One Giant ERP. You Need Four Connected Systems.

Almost every operator we meet has had the same conversation twice. Once with a large platform vendor, who explained that the answer is a single system of record and a two-year programme to move onto it. And once internally, where everyone agreed that was too much money, too much disruption and too much risk — and quietly went back to the spreadsheet.

Both sides of that conversation were reasonable. The vendor is right that data scattered across six tools is a real problem. The internal veto is right that reshaping the business around someone else's software is a brutal way to solve it. What neither side questioned is the premise: that those were the only two options.

Why the monolith made sense for thirty years

The single-platform argument was never really about features. It was about economics. Custom software used to cost so much per unit of functionality that the only rational way to buy it was in enormous, heavily-amortised blocks. If you were going to pay for a data model, an interface layer, a permissions system and an integration framework, you wanted to pay once and use it for everything — even the parts where it fit badly.

That is why enterprise software has the shape it has. The module you love and the module everyone hates came from the same vendor because unbundling them was uneconomic. And it is why "we will adjust our process to match the system" became a normal sentence. Nobody wanted that. It was just cheaper than the alternative.

The cost of building custom software has now fallen by an order of magnitude. That does not make the monolith wrong. It makes the reasoning that produced it obsolete, and almost nobody has gone back to redo the arithmetic.

What actually breaks in a six-tool business

It is worth being precise about the real problem, because "we have too many systems" is a diagnosis that leads straight to the wrong cure. Having several systems is fine. Here is what actually hurts:

• The same entity — a customer, a job, a part — exists in four places with four identifiers and no agreed master.
• Moving data between tools is a person's job, which means it happens at human speed and human accuracy.
• No single system can answer a question that spans two of them, so reporting becomes an export-and-join exercise.
• A rule that should be enforced everywhere is enforced in one place, so it is routinely bypassed everywhere else.
• There is no system at all for a third of the work, so that third lives in inboxes and spreadsheets.

Notice that only the first two of those are about having multiple systems. The rest are about not having shared data, and about not having software for work that never got any. A monolith solves them by absorbing everything. But you can also solve them by agreeing on one data layer and building the missing pieces properly around it — which is dramatically cheaper, faster, and reversible.

The split that works

The practical version looks like this. Keep the systems of record that are genuinely commodity and genuinely good: the accounting package, payroll, probably your CRM. Nobody has ever won a customer by having bespoke general-ledger software, and rebuilding it is a way to spend a year producing something slightly worse than what you already pay for.

Then build the operational layer — the part that is specific to how your business actually works, that no vendor ships, and that is currently being done by people and spreadsheets. That is the quoting logic reflecting how you really price. The dispatch rules that encode which engineer can do what. The compliance register that knows which document blocks which action. The workflow that routes an exception to the right person. This is the layer that differentiates you, and it is exactly the layer nobody could afford to build before.

Underneath both, insist on one thing: a shared data layer where each entity has one master definition. Not one database, necessarily — one agreed answer to "what is a customer, and which record is authoritative". Most of the pain attributed to having many systems is really the pain of having no answer to that question.

Four systems, not forty

The obvious objection is that this simply recreates the sprawl. It does not, provided you are disciplined about two things. First, each system owns a clear domain and the data within it — no shadow copies. Second, you build them one at a time, in sequence, each live and paying for itself before the next starts.

In practice most mid-sized operators need three or four purpose-built systems, not forty. An operations system, a customer-facing system, a finance-adjacent one, and a decision layer that reads across all of them. That is a tractable amount of software, and each piece is small enough to be genuinely well-built rather than merely delivered.

Why the order matters more than the architecture

The strongest argument for the incremental approach is not technical, it is political. A two-year platform programme asks an organisation to absorb cost and disruption for eighteen months before anyone sees a benefit — which is why so many die in month fourteen, when the sponsor changes or the budget moves.

Shipping one working system in a few weeks changes that dynamic entirely. The people who use it become advocates rather than obstacles, because it made their Tuesday better. The business sees a return before it has committed to the rest. And you find out early, cheaply, whether your assumptions about the process were right — which they frequently are not.

Where to start

The right first system is rarely the biggest problem. It is the one with a clear before-and-after, a team that actively wants it, and data that already exists. Pick that, ship it, and let it earn the right to the second one.

If you want a concrete starting point, our Rebuild Library describes the processes we see most often — how each runs today, the signals that it is costing more than anyone measured, and what the rebuilt version does. Read the "how it runs today" section of a few of them. The one that makes you wince is your first project.