Locally Rational, Globally Expensive

Look across a large organisation today and you will find the same thing happening in four places at once. IT is running AIOps to cut alert noise and route incidents. Sales operations is using a stack of tools to cut pipeline noise and route deals. Finance is automating exception handling across its reporting. Operations is running process automation that generates as much variance as it removes.

Four functions. Four names. Four vendor contracts. Four governance frameworks. One operating problem: using AI to reduce signal noise, automate routing, and handle exceptions at scale. Nobody decided to fragment it. It fragmented because each function went to market with its own local problem statement, and the market sold each one a local solution.

Each decision was rational

This is the part that makes it hard to see and harder to fix. No one acted carelessly. Each function made a locally rational choice.

The sales operations leader had a real problem, a tool that fit the domain, and a way to buy it without convening a committee. So did finance. So did IT. Each decision was faster, better targeted, and less politically costly than routing the question through a central body that would have slowed it down and understood it less. Local autonomy is exactly what you want when you are trying to move quickly. Every one of these calls would survive scrutiny on its own terms.

The problem is that the terms are local and the cost is global. The decisions are rational one at a time and destructive in aggregate, and nothing in the operating model is positioned to see the aggregate.

The bill nobody itemised

When two functions solve the same class of problem under different names, with different tools and different teams, the organisation does not just pay twice. It accumulates structural debt.

Technical debt is familiar. You cut a corner in the codebase, the shortcut compounds, and eventually the interest consumes more time than new work. Structural debt works the same way one level up, in the organisation rather than the code. Every quarter that IT matures on its stack while another function buys its own point solution, the gap widens: different tools, different skills, different governance, different maturity curves, all running in parallel, none connected.

The financial edge of this is measurable even though the structural part is not. SaaS management research analysing tens of millions of licences puts average enterprise waste on redundant and unused software at around 18 million dollars a year, rising. Nobody ran the consolidation analysis, because nobody noticed the functions were solving the same problem. And the timing matters: consolidating in year one is a procurement decision, consolidating in year five, after each function has built skills, processes, and governance around its own stack, is a transformation programme. The fragmentation gets more expensive to unwind every quarter it persists.

The vendor market is shaped by your org chart

There is a second-order effect worth naming. The vendor landscape an enterprise navigates was not designed by its architecture team. It was shaped by its org chart.

Because each function named the problem differently, the market built separate categories to match: one for IT operations, another for revenue automation, another for intelligent process automation, another for AI-assisted reconciliation. Different vendors, different budgets, different buyer conversations, for the same underlying mechanism. The fragmentation inside the organisation gets sold back to it as four distinct markets, at full price, and each purchase deepens the fragmentation that created the market. The org chart became the procurement strategy.

The same mistake, three times

This is not a one-off. The pattern has run three times in a decade.

In 2016 it was chatbots, AI at the interface. Every customer-facing function bought one independently, the results were mixed, and the programmes fragmented and quietly died. Around 2018 it was AIOps, AI in the control room. IT formalised it, named it, and kept it, while the rest of the business built parallel capabilities under other labels and never caught up. Now it is agents, AI in the workflow. Sales has its AI SDR, finance its reconciliation agent, IT its incident-response agent, each bought, named, and governed by the function that discovered it first.

Three waves, three labels, one operating problem that no function has ever been asked to own at the enterprise level. The structural debt from the first two waves is already on the balance sheet. The third is loading more onto it, and the budget has already been approved.

The fix is not centralisation

The reflex, once this is visible, is to centralise: one platform, one owner, one committee. That is the wrong move, and it is an IT-level answer to an operating-model question. Centralising decision rights would reintroduce exactly the latency that drove each function to go it alone in the first place.

The executive question is different. Not which platform to standardise on, but whether anyone in the organisation has the mandate to look across all of these disciplines at once, not to own them, but to govern the common underlying mechanism. To decide, deliberately, which functions get which capability, on what shared standards, with what connective tissue, while leaving local execution local. That is the difference between coordinated autonomy and uncoordinated fragmentation, and it is a property of the operating model, not of any one tool.

This is the structural incompatibility The Kinetic Enterprise describes, seen from one specific angle: an operating model that can let every function move independently but cannot govern what they are collectively building. The local speed is real. So is the global cost. Both come from the same structure.

CEZ Consulting works with executives to find where this fragmentation is accumulating, and to design the governance that captures the local speed without paying the global bill.