When an operation starts to feel slow, the conversation inside a mid-sized company almost always begins with what is missing. A CRM. An inventory module. A reporting tool. And now, an AI pilot. The implicit question is what to buy.
It is a common diagnosis, and usually the wrong one. In many mid-sized companies, the problem is not the absence of software. There is already an ERP, a billing system, an e-commerce platform, a warehouse module left over from an implementation that never quite finished, and a master spreadsheet that someone guards closely. None of them was designed to talk to others, and nobody ever made an explicit decision to connect with them.
What is striking is that, in those companies, integration does exist. It simply was never built — it is embodied. It is done by a person who exports a file every Monday, cleans it, cross-checks it against another one and loads it into the second system. That person is, in practice, the company’s integration layer.
This strikes me as one of the structural decisions most often deferred in a mid-sized business, and for an understandable reason: it has no natural owner. It does not belong to operations, because it involves systems. It does not belong to technology, because it involves business rules. It ends up belonging to no one, and in the meantime the operation works — until it stops working.
When the integration layer is a person
A process held together by manual data movement has three properties worth naming, because none of them shows up in a cost report.
It concentrates knowledge that is written down nowhere.
The real rules of the process — which columns are ignored, which customers are treated differently, what to do when a reference number does not match — live in the head of whoever does the work. When that person is away, the process does not stop abruptly. It degrades quietly, and the consequence surfaces weeks later somewhere else.
It leaves no trace.
When a figure comes out wrong in a report, there is no way to reconstruct where the discrepancy entered, or whether it was an error or a deliberate and sensible correction. The discussion turns into who is right rather than what happened.
Its cost grows in step with volume.
Doubling orders, locations or product references doubles the work of moving data across. It is a cost that appears on no budget line, because it is spread across the time of people hired to do something else.
The question is not which tool is missing, but where the correct data lives
Adding another tool without solving the connection adds one more version of the truth. Every system arrives with its own database and its own notion of what a customer is, what a product is, and when a transaction counts as closed.
The symptom is easy to recognise: nobody trusts a report until someone "reconciles" it. And reconciling means a person decided on their own judgement and without leaving a record, which of the conflicting figures was the right one.
Before connecting anything there is a decision to make, and it is not a technical one: for each master record — customer, product, price, balance, stock — which system is the system of record. Which one wins. The others may hold a copy, but not authority. That definition is uncomfortable, because it forces different functions to give up control over information, they currently manage their own way. It is also what makes everything else possible.
Integrating is not connecting everything
There is a maximalist version of this project — synchronising everything with everything, in real time — that is expensive, fragile and almost never necessary. In practice, integrating well is a series of bounded decisions, and three questions settle most of the design.
How often does this data need to move?
Not everything requires real time. A product catalogue that changes once a week does not need the same infrastructure as a stock balance that determines whether an order can be accepted. Overspecifying frequency is one of the most common ways to make an integration expensive without gaining anything in return.
What happens when it fails?
This is the question most often skipped. An integration that works most of the time and fails silently the rest is worse than a manual process, because nobody is watching. Every automated flow needs a predefined answer to what happens to the record that did not go through, who finds out, and how quickly.
Who maintains it once it is live?
Vendors update their interfaces, formats change, business rules move. An integration is a living component, not a deliverable that closes. Without an assigned owner, it will break at some point, and nobody will know until someone complains.
Why this is becoming more urgent now
Until recently this problem could be tolerated. The company grew, the cost of manual data movement grew with it, but it was a known and predictable cost.
What changed is that almost the entire current promise of AI applied to operations — anticipating demand, prioritising collections, detecting anomalies, responding with context — depends on reading data that today sits scattered across systems that do not talk to each other. No model can reason over information that does not exist coherently anywhere.
So, for a mid-sized company working out where to start with AI, the recommendation is almost never to start with the model. It is to draw the map: which systems exist, which data wins in each case, who moves information today and under what rules. Building that map tends to be uncomfortable, because it makes visible informal arrangements that have been running for years. And it is, by some distance, the work with the best return — not because it enables AI, but because it fixes the operation a model follows.
This article was co-created with the assistance of artificial intelligence under strict supervision, editing, and verification of our team.