An order exists in five places at once. The CRM calls it a closed-won opportunity. The ERP calls it a sales order. The warehouse calls it an outbound shipment. Finance calls it an invoice. The customer calls it late.
Nobody designed that. It accumulated — one reasonable decision at a time.
This is the part of enterprise software economics that no vendor invoice captures. The systems each work. The work between them is where the money goes.
The costs that live between the systems
James Alan Miller's March 10, 2026 analysis for TechTarget makes the structural argument better than any vendor deck: enterprise software costs rarely rise because a single system fails. They accumulate as work moves across ERP, HR, CX and communications platforms.
The mechanism he describes is drift. Organizations add tools, patch platforms and adjust workflows to keep operations moving. Each change solves a real problem. Together they convert a structured architecture into what he calls a record of the organization's operational decisions — still running, no longer matching how the business actually operates.
Two consequences are worth naming precisely.
Duplicated effort. Teams perform similar tasks in parallel across systems without realizing the overlap, because nobody owns the whole process end to end.
Fragmented labor visibility. Workforce data sits in HR, compensation in payroll, operational spend in ERP, forecasts in finance. Each platform holds part of the picture. None holds the answer.
Decision latency is the expensive one
Miller's most useful contribution is a phrase: decision latency. It occurs when the organization technically possesses the information needed to act, but the systems cannot deliver it quickly enough to influence operations.
That is a different failure from missing data. Missing data announces itself. Decision latency feels like normal business — the Monday report describing last week, the inventory position that is accurate as of this morning, the exception that surfaces at close rather than at the moment it happened.
Automation does not automatically resolve it. Miller is direct on this: AI tools and automated workflows remove manual tasks but introduce new responsibilities around monitoring, governance and integration. The cost shifts rather than disappearing.
Anyone who has added an agent to a broken process has met that pattern.
Two cases that make it concrete
Writing in Retail TouchPoints on April 29, 2026, Sarah Hepp — an advisor to the integration vendor RoboMQ — describes a retail stack running point-of-sale, ERP, ecommerce, CRM, warehouse management, HR and identity systems side by side.
Her sharpest example is not about inventory. It is about people. Onboarding a worker requires separate updates across HR, payroll, POS and access systems. Removing someone from payroll often triggers a manual, uncoordinated removal of credentials across the same systems. When identity changes do not propagate, people retain access longer than intended — and audit preparation becomes an exercise in reconstruction.
That is a security finding, a compliance finding and a labor cost in the same event.
The second case is familiar to anyone near a warehouse. A mid-market distributor's supervisors learn about delays and inventory inaccuracies late, relying on manual updates, spreadsheets and verbal communication — producing missed delivery deadlines and incorrect expediting, as a Microsoft partner's practice blog describes it. The system recorded the transaction. Nobody received the state.
Why point-to-point stops scaling
Hepp's explanation of the failure mode is the clearest part of the piece. Point-to-point connections work in a small setup and become fragile as complexity grows. Every new platform adds several integration paths. Upgrade timing must be coordinated across linked applications. Troubleshooting requires specialists.
Where automation is absent, people bridge the gaps — IT teams act as intermediaries, handling changes and fixing inconsistencies by hand.
The alternative she describes is not more connectors. It is a centralized layer that coordinates communication among platforms, reducing the number of direct dependencies so that adding a tool does not add paths exponentially.
That distinction matters commercially. A connector is a subscription. A coordination layer is an asset you own, and it is the thing that makes the next acquisition or system replacement survivable.
The seven costs worth measuring
An Odoo implementation partner's analysis — vendor-published, and useful anyway — frames the core cost as the work required to keep multiple versions of the same business event aligned.
| Cost | What to count |
|---|---|
| Duplicate entry and verification | Every place a person rekeys, pastes, imports or re-checks existing data |
| Reconciliation | Hours and adjustments spent establishing agreement, tracked separately from correction |
| Process delay | Waiting time at each system boundary, connected to a business result |
| Exception failure | Volume, age, cause and owner of items that stopped one system but not another |
| Reporting delay | Exports, field alignment, deduplication and the explanations that follow |
| Control and audit effort | Access reviews, approval evidence, sample preparation, unexplained adjustments |
| Interface maintenance | Authentication, mappings, schedules, retries, monitoring and annual change effort per interface |
Two entries on that list get skipped in most business cases. Exception failure is one: low volume can still be material, and exceptions are where manual work quietly returns after automation. Interface maintenance is the other — it is the recurring cost that makes some integrations uneconomic even when they function.
Replace, connect, or retain
The most useful discipline in the Odoo analysis is a decision rule rather than a product pitch: standardize for common processes the business can accept, configure when native settings cover the variation, integrate when an external system provides specialist value, customize only for justified gaps, and keep manual handling for low-volume judgment work.
Each choice carries a lifecycle cost. Custom code creates testing and upgrade work. Integration creates monitoring and vendor dependency. Manual exceptions create labor and control effort. Standardization creates training needs.
Warehouse automation, engineering tools and regulated industry systems often provide capability an ERP should consume rather than reproduce. The question is not which system wins. It is which system owns each record, and how retained systems exchange data and exceptions.
The accounting rule that keeps the case honest
Here is the sentence worth pinning above the whiteboard: do not treat every minute saved as payroll reduction.
Some improvement releases cash. Much of it releases capacity — an analyst who stops reconciling does not vanish from the payroll; they do work that was previously postponed. Mixing the two inflates a business case and then fails an audit of the benefits.
The Odoo analysis recommends reporting them separately: cashable savings, usable capacity, working-capital effects and risk reduction, each judged on its own terms.
Illustrative calculation, constructed to show the method — no real company or result is described. A distribution business traces one order-to-cash chain and finds a coordinator rekeying 2,000 orders a month at four minutes each: about 133 hours monthly, roughly 1,600 annually. At a loaded $55 an hour that is $88,000 of capacity — most of it released rather than cashable. Presented as $88,000 saved, the case is fragile. Presented as $88,000 of capacity plus whatever cash actually leaves the cost base, it survives scrutiny.
What must hold before any of this is automated
Field ownership, in writing. For every field, one system is authoritative and the rest display it. If the warehouse holds the true on-hand count and the ERP shows it with a lag, any reconciliation reading ERP inventory will be confidently wrong — and consistently wrong, which is harder to notice.
Exceptions with an owner and an age. A queue without either is a report. Exceptions belong where they occur, not in a month-end discovery.
Least privilege at the boundary. The service that reads invoices should not be able to change payment terms. Segregation of duties has to hold at the integration layer, not only inside the ERP.
Only then does AI earn its place, and narrowly: ranking exceptions by value and age, detecting near-duplicates against full history rather than against a rule someone anticipated, and explaining in plain language why a reported figure moved. A model that classifies a transaction and posts it has removed the human check from the one place accounting controls exist to keep it.
Six metrics that beat dashboard counts
- Manual touches per transaction — did they fall without losing control?
- Open exceptions with owner and age — resolved, or merely reported?
- Decision delay, measured — days from period end to decision, not dashboard refresh rate.
- Reconciliation hours per period — the capacity actually recovered.
- Interface incidents — whether retained integrations are governed or merely running.
- Time to produce audit evidence — whether the system can prove a number.
The operating model question
Disconnected systems are usually described as an integration problem. They are better understood as an operating model problem, because the seams are where accountability stops.
The realistic goal is not a single platform. It is a stated answer to four questions: which system owns each record, what the coordination layer is allowed to do, where an exception goes when it appears, and who signs when the answer becomes a transaction.
Software should follow the business. When it does not, the gap is not paid by the vendor. It is paid weekly, by people reconciling versions of the truth that nobody agreed to create.
Hashtags
#CustomSoftware #SystemsIntegration #EnterpriseAI #BusinessAutomation #ERPIntegration #DataGovernance #AIGovernance #OperationalExcellence #DigitalTransformation #ITLeadership #WorkflowAutomation #DataIntegrity #RiskManagement #SupplyChain #WMS #CFO #CIO #EnterpriseArchitecture #BusinessIntelligence #CustomerExperience