The acquisition debt: eight sites, 25,000 items, one thin connector.

A European boatbuilding group did its IT modernisation by the book - cloud ERP kept close to standard, a PLM as the product-data master. And still it hit a wall. Because the hardest data problems don’t live inside any system. They live between them.

The situation

A company doing the modernisation right

This is not a story about a company that neglected its IT. The group - roughly 600 people across eight-plus sites, grown rapidly through acquisitions - had spent three years building what most of its peers still lack: a genuine central IT organisation, hardened security, modern infrastructure, and a company-wide transformation programme.

The target architecture was textbook, too: SAP S/4HANA Public Cloud as the core ERP, deliberately kept close to standard; a leading PLM positioned upstream as the master for product data; a clear principle of digital continuity - data is created once, lives in its master system, and is consumed from there without duplication. Around 600 users, down to the production floor, work with the ERP daily.

And the rollout kept lagging. Not on the systems - on what the acquisitions had left behind, and on everything that has to flow between the systems.

Failure point #1

Every acquisition brought its own truth

Growth by acquisition is a data event, not just a financial one. Each acquired company arrived with its own systems, its own item codes, its own supplier records - and nobody merges master data in the heat of a deal. The result, years later: an item master of roughly 25,000 items riddled with duplicates, a supplier master in the same condition. The same physical part exists several times over, under different codes, at different sites.

The damage is quiet but compounding: purchasing can’t see its real volume per supplier; stock-outs occur at one site while another reorders the same part; and any group-level figure is based on records that were never reconciled. Migrating this into a clean new ERP doesn’t fix it - it imports it.

Failure point #2

One part, two legitimate truths

Even where the duplicates are resolved, a subtler problem remains - and this one can’t be cleaned away, because nobody is wrong.

The problem in one image
Take a composite deck panel. Engineering classifies it by what it is: a structural composite component, in a technical family alongside hulls and bulkheads. Purchasing classifies it by how it’s bought: it lands under deck hardware, with the supplier and commodity logic that category implies. Both classifications are correct - for their purpose. Forcing one department to adopt the other’s logic breaks one of them. So a second, parallel hierarchy gets built and maintained by hand, forever.

This is the trap of standardisation: trying to settle on the one right classification when the real requirement is for several correct views of the same object to coexist - mapped to each other, not flattened. Harmonisation over standardisation. Most master-data projects fail precisely because they attempt the flattening.

Engineering and purchasing are both right. The architecture has to let them be.

Failure point #3

One thin connector - and a ceiling you can’t customise through

Between the PLM and the ERP sat exactly one integration: a hard-wired connector carrying items, bills of materials and routings, in one direction. Necessary - and nowhere near sufficient. The business needs flows the connector simply doesn’t cover:

• Data flowing back. Real purchase prices and live stock levels belong in front of the engineers in the PLM - engineering decisions are made against target prices that procurement reality has long overtaken. The connector only flows the other way.
• Every adjacent domain, its own interface. Time and attendance, maintenance, production feedback, warehouse status - each needs its own point-to-point link, each with its own logic, each re-tested at every upgrade. Connector sprawl, one well-intentioned interface at a time.
• A shop floor routing around its tools. The integrator-built interfaces for production reporting were so cumbersome that the people meant to use them avoided them - and the data quality showed it.

The core escape route is closed by design: a public-cloud ERP deliberately limits deep customisation. That’s the right call - it’s what keeps upgrades safe - but it means the gaps get patched in the only place left: Excel. KPIs were assembled by manual extraction and macros - slow, fragile, undocumented, and dependent on the handful of people who know how the macros work. The group’s reporting ran on critical infrastructure that lived in spreadsheets.

A modern core kept clean - and the complexity didn’t disappear. It moved into the gaps between systems.

The way out

Not a bigger connector. A layer between everything.

None of these problems is solved inside the ERP or inside the PLM - they all live between systems. Which is why the answer isn’t a wider connector, more interfaces, or a data lake full of copies. It’s one integration layer above the systems, doing five jobs at once:

• Resolve the duplicates - gradually, in the layer. The 25,000 items get matched against one harmonised reference; the rest is guided review. The sites keep their local codes, while the group gains one identity per part and per supplier - no big-bang cleanup, no forced recoding.
• Let both truths coexist. Engineering’s technical families and purchasing’s commodity logic become two governed views mapped onto the same objects - maintained once, instead of as parallel hierarchies maintained by hand.
• Make flows bidirectional and governed. BOMs flow to the ERP; real prices and stock flow back to engineering. Direction, ownership and conflict rules are explicit - data stays in its master system exactly as the group’s own digital-continuity principle demands.
• Take the logic out of the spreadsheets - without putting it into the ERP. The KPI and integration logic living in Excel macros moves into the layer: documented, reproducible, no longer tied to the ERP’s release cycle or to the three people who understand the macros. The cloud ERP stays standard - which was the point.
• Give the shop floor interfaces people actually use. Task-oriented apps on tablet, phone or terminal sit on the layer and write back to the right core system underneath - UX decoupled from the systems of record.

And the next acquisition - there will be one - stops being a data crisis: the new company’s systems connect once to the layer and map into the same harmonised reference, instead of adding another thousand duplicates to the pile.

The lesson travels

The paradox of the clean core

Here’s the part that generalises far beyond boatbuilding: the more disciplined you are about keeping your core systems standard, the more you need a dedicated place for everything that doesn’t fit inside them. Cross-system identifiers, coexisting classifications, bidirectional flows, group-wide KPIs - none of it belongs in a standard ERP, and forcing it in there is how technical debt gets built.

The warning signs to look for in your own landscape: an item or supplier master swollen by acquisitions; parallel classification hierarchies maintained by hand; one hard connector carrying a fraction of what actually needs to flow; and Excel macros that have quietly become critical infrastructure. Each one is a gap between systems - and a layer between systems is what closes them. That layer is exactly what the boTec DataBridge is built to be.