In short
Audit integration by mapping where the same piece of data exists in more than one system and who moves it between them. Every manual bridge is a recurring cost and a source of contradictory records. Fix in this order: declare one system of record per data type, eliminate the duplicates you do not need, then automate only the bridges that survive that pruning. Automating a bridge you should have deleted makes the wrong data flow faster.
Key takeaways
- Count human bridges, not integrations. Every place a person retypes data is an unfunded recurring cost.
- Declare one system of record per data type before you connect anything. Without it, integration just spreads disagreement.
- Most stacks can lose one or two tools entirely, which is cheaper and better than integrating them.
- Duplicate data does not stay duplicate; it diverges, and then nobody knows which record is true.
- Automate last. An automated bridge between two systems that should not both exist is a permanent liability.
How a sensible stack becomes an incoherent one
No business decides to run on six disconnected systems. The sequence is always reasonable in the moment.
Sales needs a pipeline, so a CRM arrives. Delivery needs to track work, so a project tool arrives, purchased by a different person for a different reason. Finance needs invoices, so accounting software arrives. Someone builds a spreadsheet to reconcile the three, because the reconciliation is nobody's job and the spreadsheet takes twenty minutes. Two years later that spreadsheet is load-bearing, one person maintains it, and the business cannot answer a simple question — how many active clients do we have — without opening three tabs and adjudicating between them.
Every tool was bought to solve one problem well. Nobody was ever assigned the space between them, which is where the business actually operates.
The three costs of a disconnected stack
| Cost | How it shows up | Usually noticed? |
|---|---|---|
| Transfer labour | Hours per week copying, pasting, exporting, reformatting, importing | Rarely — absorbed into salaries |
| Divergence | Two systems hold the same field with different values; nobody knows which is right | Only during a dispute or an audit |
| Decision latency | Questions that should take seconds take a morning of reconciliation | Felt constantly, attributed to “we need better reporting” |
The third cost is the one that compounds. A business that cannot cheaply answer questions about itself stops asking them, and starts making decisions on impression rather than evidence.
The audit: map the human bridges
The unit of analysis is not the tool. It is the bridge — any point where information moves from one system to another. Two hours with a whiteboard is usually enough.
Step 1: list the systems, including the informal ones
Every application, plus the spreadsheets, plus the shared inbox, plus the WhatsApp group where approvals actually happen. The informal systems are usually where the real integration work is being done, by hand, by one person.
Step 2: list the core data types
For most businesses this is a short list: customer, contact, deal or order, project or job, invoice, employee, supplier. Six to nine entries.
Step 3: build the grid
Data types down the side, systems across the top. In each cell record whether that system creates, stores, reads or does not hold that data type. The picture emerges immediately: any data type stored in three or more systems is a divergence waiting to happen.
Step 4: name the bridge for every duplicate
For each pair of systems holding the same data, record four things:
- Who moves it — a person, a scheduled export, a real integration
- How often, and how long it takes each time
- What happens if it is skipped for a week
- Which side wins when the two disagree — and whether anyone has ever actually decided this
That last question is the most revealing in the entire exercise. In most audits, at least one important bridge turns out to have no agreed authority, meaning the business has been quietly running on whichever record the last person happened to open.
A common finding: businesses with six to eight tools typically discover four or more human bridges they had never counted, at least one of which is maintained entirely by a single person who has never mentioned it because it only takes them a few minutes.
Declare a system of record before you connect anything
This is the decision that makes everything afterwards straightforward, and it is free.
- System of record
- For a given data type, the single system whose version is authoritative. When any other system disagrees with it, the other system is wrong by definition and must be corrected, not debated.
One line per data type. Written down. Published. For example:
| Data type | System of record | Everything else |
|---|---|---|
| Customer and contact details | CRM | Reads only; never edits |
| Signed commercial terms | Accounting system | CRM shows a copy for reference |
| Work status and delivery dates | Project tool | CRM reflects, does not drive |
| Employee records | HR system or payroll | Nothing else stores personal data |
Two rules make this work in practice. Edits happen only in the system of record. If someone can fix a phone number in the project tool, the CRM will drift within a month, no matter how good the integration is. And the system of record should be the system where the data is naturally created, not the one that is most pleasant to use, or you will fight the workflow forever.
Prune before you connect
The instinct after an audit is to start automating bridges. Do the cheaper thing first: work out which bridges should not exist at all.
Take each bridge and ask, in order:
- Does the destination system need this data at all? A surprising amount of copying exists to populate fields nobody reads. Confirm someone actually uses it before preserving the flow.
- Could one of these tools be retired? Overlap is common: two tools each doing 60% of a job, with the gap covered by a person. Consolidating to one is usually cheaper than integrating two, and removes the bridge permanently.
- Could the work move to where the data already is? Sometimes the answer is not to move data but to move the task.
- Could a link replace a copy? Referencing a record beats duplicating it. A link cannot diverge.
Only bridges that survive all four questions are candidates for automation. In most audits, between a third and a half do not survive — which is the highest-return outcome of the exercise, because deleting a bridge costs nothing to run and nothing to maintain.
On consolidation
Retiring a tool is unpopular and usually correct. The objection is always the same: this tool does one thing better. Weigh that specific advantage against the full cost of the bridge it requires — the transfer labour, the divergence risk, the licence, the onboarding burden of one more system for every new hire. The specialist tool has to be substantially better to win that comparison, and often it is not.
Automating the bridges that remain
For the survivors, choose the simplest mechanism that works and can be understood by someone other than its author.
| Option | Good for | Watch out for |
|---|---|---|
| Native integration | Anything the vendors already support | Check what it syncs and in which direction before assuming |
| Automation platform | Simple, low-volume, one-directional flows | Silent failure. Untested error handling is the norm. |
| Custom script or API work | High volume, or logic the platforms cannot express | Becomes key person risk the moment one person owns it |
| Deliberate manual step | Low frequency, or where human review adds real value | Must be documented and owned, not merely tolerated |
Whatever you choose, three requirements are not optional:
- Failures must be visible. The most dangerous integration is one that stops working quietly. Route failures to a channel a human reads, not to an inbox nobody opens.
- Direction must be explicit. Two-way sync between systems that both allow edits is how you manufacture conflicts. Prefer one-directional flows out of the system of record.
- Ownership must be named. An integration without an owner is an outage waiting for a vendor to change an endpoint — the same principle as operational ownership generally.
And note the last row of that table. A documented, owned manual step is a legitimate answer. It is undocumented manual work that hurts, because it is invisible, unowned and dependent on one person remembering.
Keeping the stack coherent as you grow
Integration debt regenerates. Every new tool is a new set of potential bridges, and tools arrive faster than they are retired. Three habits keep it under control without slowing anyone down.
1. A purchase question, not a purchase process. Before buying any tool, answer three things: which data types will it hold, which of those it will be the system of record for, and which bridges it creates. If it becomes a second home for data that already has a system of record, that needs a deliberate justification.
2. A named owner per system. Someone responsible for its configuration, its integrations, its licences and its data quality. Not IT generally — a person.
3. An annual bridge count. Re-run the grid once a year. The number of human bridges is the single best summary measure of stack health, and it should trend down even as the business grows.
The goal is not a fully integrated stack. It is a coherent one: every data type has an obvious home, every remaining bridge is deliberate and owned, and anyone can answer a basic question about the business without adjudicating between systems.
The Mayim Ops assessment scores systems and technology alongside automation maturity and measurement, and reports where your stack is creating manual work rather than removing it.
Frequently asked questions
How do I audit my business software stack?
Build a grid with your core data types down the side and every system across the top, including spreadsheets and shared inboxes. Mark whether each system creates, stores, reads or does not hold each data type. Any data type living in three or more systems is a divergence risk, and every pair of systems holding the same data represents a bridge that someone is maintaining.
What is a system of record?
For a given data type, the single system whose version is authoritative. When another system disagrees with it, the other system is wrong by definition. Declaring one system of record per data type is free and prevents integration work from simply spreading disagreement faster.
Should I integrate my tools or reduce the number of tools?
Reduce first. Consolidating two overlapping tools into one is usually cheaper than integrating them, because it removes the bridge permanently rather than automating it. Only bridges that survive a pruning pass, where you ask whether the data is needed, whether a tool can be retired and whether a link could replace a copy, are worth automating.
What is the risk of two-way sync between systems?
If both systems allow edits to the same field, they will eventually disagree, and the sync then has to choose a winner in a situation where nobody has decided which should win. Prefer one-directional flows out of the system of record, with other systems reading rather than editing.
How much manual data entry is normal?
Some is unavoidable and occasionally desirable, where human review adds real value. The problem is undocumented manual entry that nobody has counted and one person quietly performs. Track the number of human bridges in your stack as a metric and expect it to fall over time even as the business adds systems.