Why Intelligent Operations Are Hard to Build
Most operations were assembled over decades, one system and one workaround at a time. Making them intelligent means connecting what was never designed to connect.
Most complex operations were never designed as a single system. They evolved over time. New technology was added to solve specific problems. Processes changed as customer requirements changed. Teams developed local ways of working to handle exceptions, volume and circumstances that the original process never anticipated. New controls were introduced, responsibilities shifted, and experienced employees learned how to keep work moving across the gaps.
When we talk about an Intelligent Operation, we mean an operation that can see what is happening across that environment, understand what is driving performance, and use that understanding to improve how the work gets done. For an executive, the difference is practical: you should be able to move from seeing that a metric is off to understanding why, deciding what to change, and knowing whether the change actually worked.
The result can be an operation that performs reasonably well while remaining surprisingly difficult to see as a whole. The data needed to understand performance may sit across several systems. A process can cross multiple functions without anyone owning it end to end. The documented workflow may describe the standard path while much of the real effort occurs in exceptions, handoffs and workarounds. Important operating knowledge may live with a handful of people who have learned through experience what works and what does not.
Those gaps become increasingly important as organizations introduce more automation and AI. Technology can make individual activities faster, automate decisions and surface information that was previously difficult to access. But it also depends on the operation around it. An automated workflow still encounters poorly defined handoffs. An AI agent still needs clear decision rights. Better analytics can identify a performance problem without resolving fragmented ownership of the response.
This is where many efforts to create more intelligent operations begin to stall: at the seams between people, processes, systems, data and decisions. Those seams are often where context gets lost, ownership becomes unclear and people compensate for weaknesses in the operating model through manual effort and experience.
That is especially true in distributed workplace, document and logistics environments. One site develops a workaround because of a customer requirement, another uses a different system, and an experienced supervisor understands why a particular metric behaves strangely. Finance sees the cost one way, while the operating team sees what it takes to deliver the service every day. Connecting them would be hard enough on a blank sheet; meanwhile organizations have to do it while they keep the operation running.
No One Owns the Whole Problem
Many operational problems persist because they cross organizational lines. A missed service level might trace back to staffing, workflow design, technology, equipment, customer behavior and a policy set by another function, all at once. A single process can start in one department, pass through two systems, wait on another team's approval and eventually depend on someone at a site resolving an exception manually.
The customer experiences all of that as one service. Inside the company, responsibility may be spread across half a dozen owners. One team is measured on cost and another on service. Technology owns the platform, Operations owns the workflow, Finance owns the business case and Risk determines what can be automated.
Nobody needs to be told silos exist. A 2025 Harvard Business Review article cites research attributing 67% of collaboration failures to silos. It also cites a 2002 American Management Association survey in which 83% of executives reported silos in their companies and 97% said those silos had a negative impact on the business. That survey is more than twenty years old. The numbers probably wouldn't look much different today.
The trouble lives in the space between those functions. Fixing the outcome often means several teams changing something at once, and none of them controls the whole result.
The Real Process Lives Off the Page
Before an operation can be improved, leaders need to understand how the work actually gets done. The documented process is only part of that picture.
Experienced operators know the real workflow includes exceptions, judgment calls, informal handoffs and local fixes. Someone bypasses a system because a customer has an unusual requirement. A supervisor changes the sequence of work during peak periods. One site discovers a faster approach, but that practice never makes it into the standard operating procedure.
Some of those adaptations are the reason the operation works at all. Others are leftovers nobody remembers the reason for. A redesign that can't tell the difference will get both wrong.
We see this constantly. A process may appear standardized at the enterprise level while operating differently across locations because of building layout, customer requirements, technology, work mix or the experience of the local team. Automating the documented workflow without understanding those differences can remove useful judgment, automate the wrong activity or simply create another workaround.
The people closest to the work therefore need to be part of understanding it. They know where work slows down, which exceptions keep returning and where the official process has drifted from operating reality. Getting that knowledge out of people's heads and into a form the rest of the organization can use is one of the hardest parts of this work.
When Every Team Wins and the Operation Loses
Organizations are usually good at improving individual pieces of the work. One team reduces handling time, another lowers labor cost, Technology improves system availability and Finance standardizes a control. Each decision can make sense on its own while creating friction somewhere else.
Consider a common pattern in distributed operations. Work is moved into a centralized queue to improve utilization and reduce local cost. The site now has fewer resources assigned to that activity, so its efficiency measure improves. The centralized team also performs well against its productivity target.
The complication appears with exceptions. The centralized team lacks some of the local context needed to resolve them quickly, so work waits longer or returns to the site for clarification. Local employees begin finding ways around the new process to protect customer service. Both groups continue to report acceptable numbers, while delay and manual effort have moved into the handoff between them. Nobody's dashboard shows it. The customer feels it anyway.
BCG's research on AI-first enterprise operations reaches a similar conclusion. Across its agentic deployments, BCG reports cost reductions of up to 60% in some end-to-end redesigns, compared with less than 20% from more incremental approaches. Whatever the exact figures in any given environment, optimizing individual tasks does not guarantee that the whole flow of work improves.
Operating Knowledge Still Lives With People
For all the investment in systems, much of the real operational intelligence still sits with people who have done the work long enough to recognize its patterns.
Experienced employees know which customer requests tend to cause problems, which equipment behaves differently under certain conditions and which metric needs additional explanation because of how the underlying system records it. They can often hear the description of a problem and know where to look first.
Organizations depend heavily on this knowledge but have relatively few ways to retain it when people change roles or leave. Their successors inherit documentation, reports and standard procedures without necessarily inheriting the reasoning behind years of operating decisions.
Another knowledge repository won't fix this. Most organizations already have one, and nobody searches it in the middle of a problem. Useful knowledge has to be connected to the circumstances in which it matters. A recurring exception, for example, becomes much easier to investigate when teams can see the operating conditions around similar incidents, what actions were taken and whether those actions improved the outcome.
AI can make buried information easier to find, while knowledge graphs and process intelligence can help connect customers, sites, workflows and events that would otherwise remain scattered. Those capabilities become substantially more useful when the organization has already determined which operating knowledge matters and how it relates to the work being performed.
The Operation Keeps Changing
Even a well-designed operation continues to evolve as demand shifts, customers introduce new requirements, employees change roles, new technology enters the environment and controls are updated. A process that performed well two years ago may now be operating under very different conditions.
Deloitte's 2026 Global Technology Leadership Study illustrates the speed of that change. Nearly 75% of technology leaders surveyed said their operating models would need to change within 12 to 18 months to sustain progress with AI, while only about a quarter reported refreshing their operating models on a continuous or dynamic basis.
That gap has little to do with AI. Transformation programs end. Operations don't. Exceptions accumulate, local practices diverge and new employees learn the process from the people around them. Gradually, the environment can move away from the design that produced the original improvement.
Alignment can drift as well. The 2026 Harvard Business Review article The False Alignment Trap describes how leadership teams may appear to agree on why change is needed, what will change and how it will happen while holding different assumptions underneath that agreement. Those differences tend to emerge during execution, when decisions become specific.
That is particularly relevant to operations. Finance may expect a cost outcome while Operations prioritizes service. Technology may push for standardization while a local team believes customer requirements demand flexibility. Risk may introduce controls that change the economics of the workflow. Sustaining improvement requires those decisions to remain aligned long after the original transformation team has moved on.
Improvement Needs a Memory
Most organizations solve the same problem more often than they'd like to admit.
A team identifies why a bottleneck is occurring, changes the process and improves performance. Months later, another location encounters a similar issue and starts its investigation with little knowledge of what happened the first time.
The organization improved the process, but it did not retain enough of the learning.
An Intelligent Operation should make each intervention useful beyond the immediate problem. The original signal, the operating conditions, the action taken and the result all provide information that can improve the next decision. Successful interventions become evidence that can be tested elsewhere, while unsuccessful interventions help eliminate approaches that did not work under similar conditions.
This is how operating experience begins to compound. Knowledge created at one site can inform another without requiring the same people to be involved, and teams can approach recurring problems with a stronger starting point than they had the first time.
Measure, Analyze and Improve Have to Connect
We have introduced Measure → Analyze → Improve throughout this series because each part addresses a different requirement of Intelligent Operations.
Measure establishes a reliable picture of what is happening. Analyze connects those signals to process, operating conditions and previous experience. Improve turns that understanding into action and evaluates what happened afterward.
In many environments, those activities remain disconnected. Reporting occurs in one system, analysis takes place in meetings or spreadsheets, and the action that follows is tracked somewhere else. When the outcome of the intervention never reconnects with the original problem, part of the learning disappears.
Connecting the loop allows performance management to become more continuous. A change becomes visible, teams can examine the conditions surrounding it, and the response can be measured against the outcome. That creates the feedback needed to determine which improvements should be repeated, adjusted or abandoned.
Technology is an important part of that loop, but so are common measures, process knowledge, clear ownership and the management discipline needed to act on what the operation is showing.
The Hard Part Is at the Seams
The hardest parts of Intelligent Operations tend to appear where one part of the environment meets another. Systems meet processes. Enterprise standards meet local conditions. Human judgment meets automation. An insight has to reach the person or agent capable of acting on it, and the action eventually has to connect back to an outcome.
Seams are easy to miss because nobody owns them. They are also where a great deal of operational friction, lost information and dependence on individual experience accumulates.
Canon Business Process Services helps organizations find and strengthen the seams where operations break down: where information is lost, ownership becomes unclear, local knowledge substitutes for process design, or improvement depends too heavily on a few experienced people. Through our Intelligent Operations capabilities, we help connect those gaps so performance can be understood and improved more systematically.
Contact Canon Business Process Services to learn how Intelligent Operations can help create a more connected, measurable and continuously improving operation.
Once those connections begin to take shape, a different question emerges. Organizations need a practical way to run this model every day: what should be measured, how should signals be interpreted, who acts when something changes, how should people and AI work together, and how does the organization retain what it learns? Those questions move the series from the foundations of Intelligent Operations into the operating model itself.
Next in the series: The Operating Model Behind an Intelligent Operation.