Most transformation programmes begin by buying new tools and leave the data where it was. Sales works in a CRM, finance in SAP or Tally, HR in its own platform and support in a ticketing tool, and every handoff between them is still a person copying values from one screen to another. Adding a new tool to that arrangement adds one more place where the data is out of date. Integration is the part of the programme that decides whether the new tools change how the company works or only how it looks.
Silos show up as handoffs
The symptoms are specific, and most finance or operations heads will recognise several of them. Sales passes closed deals to finance by hand, often as a message with a screenshot, so that an invoice can be raised. HR data never reaches the workforce planning sheet, so a regional team is budgeted at last quarter's headcount. A support agent cannot see order history while the customer is on the line and asks them to hold.
At the leadership level the symptom is a delay. Someone asks for one view of revenue, cost and headcount, and an analyst spends two days compiling it from three exports, by which point the numbers have moved. The cost of these handoffs is easy to overlook because it is spread across many people in small amounts; our piece on the hidden costs of disconnected systems looks at that side of it in more detail.
Each of these is a handoff without a defined path. The data exists; what it lacks is an agreed route from the system where it is created to the systems where it is needed.
What a defined path changes
Integration gives each handoff an agreed route and format, and a person who owns it. The order flow is usually the first one worth building, because it crosses the most departments and carries the most retyping.
- 01Order in CRMDeal closed
- 02Invoice in financeCreated from the order
- 03Request in ERPFulfilment starts
- 04Status to supportVisible to agents
Each step reads from the one before it, so nobody retypes the order.
Once that flow exists, several things follow without separate projects. Leaders see customer, financial and supply chain information together in place of three exports. Support has the purchase history on screen while the customer is speaking. Marketing and sales work from the same record of a customer. And when a cloud, IoT or AI tool arrives later, there is an integration layer to connect it to, so it does not become another export that someone runs on Mondays.
Ownership is a rule about data
When people hear "single source of truth" they tend to picture one large database with everything in it. What works is a rule. Each piece of data has one system that owns it, and the other systems hold copies that are refreshed from the owner. Customer contact details belong to the CRM, invoices to the finance system, stock levels to the ERP and headcount to HR. Integration carries changes from the owner to the copies, in one direction.
- CRM owns customers
- Finance owns invoices
- ERP owns stock
- HR owns headcount
- Support reads copies
- Reporting reads copies
Each record has one owning system; the layer carries changes outward from it.
Without the rule, two systems both accept edits to the same field, and the integration spends its life reconciling them while a dealer receives two different credit limits in the same week. With it, conflicts have an answer before they occur.
The rule also decides how cheaply the company can change later. When a business opens a new region or launches a subscription product, the new system should need a connection to the owners of customer, order and finance data, and nothing more. If adding it means rebuilding flows that already exist, the ownership rule was never set.
How programmes go wrong
The first mistake is treating integration as an IT project. The people who own the process are not present when mapping rules are decided, and they reject the result afterwards. Mapping rules are business rules, and they need the business in the room.
The second is automating a broken process. If sales and finance disagree on what counts as an active customer, connecting their systems does not settle the disagreement; it only makes it travel faster. The third follows from the previous section: no one is named as the owner of each field, so sync conflicts have no rule to follow and are resolved by whoever notices first.
The fourth is building dashboards before the data underneath them is reconciled. Each department's dashboard then shows a slightly different total, and the dashboards lose credibility, taking the programme's credibility with them. The fifth is making a legacy replacement the precondition for everything else. Old systems usually need to keep running for a year or more while data moves out of them, and a plan that depends on switching one off first rarely starts.
Mapping once in Profit Lever Models
Profit Lever Models is a driver-based financial modelling platform with a connected three-statement engine covering profit and loss, cash flow and the balance sheet. Its Assumptions Hub gives each input an owner, notes, effective dates and approvals, with every change logged. Actuals arrive by CSV or API and are mapped to the chart of accounts once, then roll forward each month so variance against plan can be viewed without rebuilding the model.
The stack is a Next.js App Router front end, a Django REST API, PostgreSQL, Redis with Celery for background jobs, S3 for file storage and OAuth/SSO for sign-in, deployed in containers on AWS.
Mapping once is the part worth copying. The accounting system keeps ownership of actuals, the model holds a copy and reads it, and the mapping between them is a stored, reviewable artifact. The alternative, a monthly spreadsheet exercise that one person in finance knows how to do, is a handoff without a defined path in exactly the sense described above.
Choosing the first process
Pick one process that crosses two departments, such as order to invoice, and ask where people retype the most data today. In most companies the answer sits between a sales system and a finance system. Before building anything, you should be able to answer three questions about that process. Which system owns each field in it? Have both departments approved the mapping in writing? Who is alerted when the flow fails?
Build that one flow and let it run for a full monthly cycle before adding the next. Our enterprise application integration work follows the same sequence. The order matters because each later flow inherits the ownership rules of the first; a company that sets them carefully on its first process will find the tenth one an afternoon's work, and one that skips them will find each new system reopening the same arguments.
