The Integration Tax: What Your Point-to-Point Connections Really Cost

How the Web Gets Built

No manufacturer sets out to build a tangle of integrations. It happens one reasonable decision at a time.

The quality team buys a quality management system and connects it to the ERP so inspection results can update lot status. Shipping adds a carrier system that needs order and address data. The engineering group connects its product lifecycle management tool so released bills of material flow into the ERP. Sales adopts a CRM, finance adds an expense tool, the warehouse brings in a scanning application, and a customer requires electronic data interchange. Each connection was built quickly, often by a different person, using whatever method was handy: a nightly file export, a database trigger, a script on a server under someone's desk, a feature of a vendor's product.

A few years later, the ERP sits in the middle of a web of a dozen or more connections.

A few years later, the ERP sits in the middle of a web of a dozen or more connections. Nobody has a complete list. Several of them were built by people who have since left. And every one of them is a place where something can quietly break.

The Tax You Pay Every Year

The cost of this web does not appear on any invoice, which is why it is so rarely managed. It shows up instead as a recurring tax on the organization.

It shows up as failures. A nightly file does not arrive, orders do not reach the carrier system, and nobody notices until a customer calls. It shows up as upgrade paralysis. The ERP vendor releases a new version, but upgrading would break several connections that depend on the old database structure, so the upgrade is postponed again. It shows up as data that disagrees. The same customer has a different address in the CRM and in the ERP because the synchronization runs one way only. And it shows up as dependency on individuals. When the one person who understands a critical integration is on vacation, a failure can stop operations for days.

Inventory Every Connection

The first step is simply to know what you have. Build a list of every system that exchanges data with the ERP and, for each connection, record what data moves, in which direction, how often, by what method, who built it, who owns it now and what happens when it fails.

This exercise is almost always revealing. Most companies find connections nobody knew about, connections that duplicate each other, and connections whose failure would be serious but which have no monitoring at all.

Monitoring Before Rebuilding

Before rebuilding anything, add monitoring. Every important integration should report whether it ran, whether it succeeded and how many records it moved, and a failure should alert a named person, not wait to be discovered by a customer. This is often the highest-return step in the entire effort, because it turns silent failures into visible ones.

Move From Point-to-Point to a Pattern

The long-term fix is to stop building each connection as a one-off. Instead of every system talking directly to the ERP database in its own way, establish a standard pattern. That might be the ERP's own published interfaces used consistently, an integration platform that sits between systems and handles the routing, transformation, error handling and logging, or a well-defined set of services that every new connection must use.

The principle is the same in each case. Systems should exchange data through documented interfaces, not by reaching into each other's databases. When connections use stable interfaces, the ERP can be upgraded without breaking everything around it, and a new system can be connected by reusing a pattern rather than writing another custom script.

Treat Integration as Part of Every Purchase

Finally, make integration a formal part of every software decision. When a department proposes a new system, the evaluation should include how it will connect to the ERP, who will build and support that connection, and what it will cost to maintain over time. A tool that looks inexpensive can become expensive once the integration tax is added.

The Bottom Line

The web of connections around a mid-market manufacturer's ERP is rarely designed. It accumulates, and it imposes a hidden tax of failures, postponed upgrades, inconsistent data and dependence on individuals. Manufacturers that get ahead of it inventory every connection, add monitoring first, standardize how systems exchange data, and include integration cost in every software decision.

At Cherry Street, this is the work we do. We help manufacturers map the connections around their ERP, add the monitoring that turns silent failures into visible ones, and design an integration approach that makes the next system easier to add rather than harder.