Why ERP Integration Plans Fail Before the Systems Are Even Switched On

When two businesses in the same corporate group are merged onto a single ERP, the plan usually looks straightforward from the outside. Same ownership, same group, same system. What the plan often does not account for is whether the two businesses actually operate the same way.

In most cases, they do not.

The assumption that derails integrations

ERP integration plans are typically built at board level, where two businesses look like variations of the same thing. The differences that matter are operational, and they live in the detail of how each business actually captures time, buys materials, manages projects, and tracks progress. Those differences are rarely visible in a summary org chart or a commercial overview of the business.

The consequence of missing them is not a configuration problem. It is a performance problem. The system gets built for one operating model, the other business is forced to work around it, and the data it produces is either incomplete or unreliable.

Four gaps that appear in almost every integration

Time capture

Project-driven businesses book time across multiple concurrent projects in a single day. Location-driven businesses clock in at a site and are assigned to one project for the duration. These are not minor variations in how the same thing is done. They are different architectures for how work is tracked, and a system configured for one cannot handle the other without significant modification.

Procurement

Businesses procuring bespoke engineered components go through a formal process: drawings, specifications, tender rounds, and inquiry responses before a price is established. Businesses procuring consumables buy from a catalogue. Forcing both through the same procurement workflow creates friction in one direction and risk in the other.

Materials management

Bespoke components arrive against specific packages of work, need to be traced to drawing, quality checked, and located at pallet or package level throughout a project. Bulk consumables need a stock count. These are not variations in scale. They are different information requirements, and a system built for stock management cannot provide the traceability a project environment requires.

Project controls

Businesses operating under formal contract conditions need milestone tracking, document registers, progress measurement against plan, and a structured change management process with client sign-off. Businesses managing simpler scopes of work need a schedule and a way to flag slippage. The project controls requirement in a complex contracting environment is an order of magnitude more detailed than what a site services business typically runs.

Why the plan needs to change before configuration begins

The operating model gap analysis is not a technical exercise. It is a business conversation: what does each organisation actually do, how does that differ, and which of those differences require a different system configuration, a different process, or a clear decision about which model the integrated business will use going forward.

Getting that conversation right before the system design is locked saves months of rework and avoids the most common integration outcome: a system that works well for one part of the business and creates workarounds in the other.

How PeakRatio helps

PeakRatio works with acquirers on the operating foundations that determine whether a deal delivers on its intent. That includes helping integration teams understand what they are actually integrating before committing to a system design.

If you are going into an integration or advising on one, visit [PEAKRATIO_URL] to find out how we approach the operating model alignment that most integration plans skip.