What 'systemic rebuild' actually means, and why bolt-on integrations don't survive contact with reality

August 2, 2026 · erp-systems, systems-engineering, odoo

Every AI capability we build — the query layer, the document ingestion, the compliance checking — assumes there’s a real system underneath it to plug into. Most of the time, there isn’t. There’s a core ERP or accounting system, and then five to fifteen years of bolt-on integrations, automation chains, and “temporary” spreadsheets that became permanent, each one solving a problem the core system couldn’t, none of them aware the others exist.

That’s the actual reason most “AI features” fail quietly: they get bolted onto the bolt-ons, and inherit every crack already in the foundation.

The point of improvement

The symptom is always the same shape. Data lives in four different places — the ERP, a spreadsheet someone built during a busy quarter three years ago, a second system that handles the one thing the ERP couldn’t, a form nobody remembers the original reason for. Nobody fully trusts a report, because everyone on the team knows some subset of transactions never made it in from one of the disconnected systems. Every new integration gets scoped defensively around what might break, instead of around what the business actually needs it to do.

What we build instead

  1. The current system mapped before anything gets touched. Every point solution and spreadsheet-that-became-a-system gets documented for what it’s actually doing today — not what it was originally built to do. That gap is usually where the real requirements are hiding.
  2. The core system configured around the business, not the business bent to fit a template. Custom modules get built where the process is genuinely different, not because a standard workflow was inconvenient to learn.
  3. One system of record, not a new integration layer stacked on the old ones. The rebuild’s job is to retire the bolt-ons it replaces, not add another node to the integration graph. If a rebuild finishes and the old spreadsheet is still the version people quietly trust more, it didn’t work.

Why this has to come first

This is the least visible part of what we do, and the part every other capability depends on. A natural-language query layer is only as good as the schema underneath it. Document intelligence only writes clean records if there’s a clean system to write them into. Skip this step and every AI layer on top is just a smart interface onto a system nobody fully trusts yet.

Some businesses plan to modernise the core system once the AI features have proven their worth. That’s backwards — the AI features can’t prove themselves reliably on a foundation that’s already unreliable. Fix the foundation first, and everything built on top of it gets easier, not harder.

There’s a shorter way to say all of this: you can not automate a mess. All you get is an automated mess — the same untrusted numbers and disconnected systems, just moving faster and harder to unwind. A systemic rebuild is the work of clearing the mess out before anything gets automated, so the automation actually does the job it was built for.

← Back to Insights

See a bottleneck in this article that looks like yours?

Book a Discovery Call