Why organizations over-index on automation
Automation is easier to understand, easier to scope, and easier to fund.
It fits familiar language:
- reduce manual work
- remove handoffs
- streamline tasks
- improve efficiency
Those are legitimate goals.
But automation alone does not answer the harder question:
How should the system determine what action is appropriate when conditions are changing?
That is the decision problem.
HBR's work on AI and process management is useful here because it makes clear that technology delivers more value when tied to redesigning the work itself. Gartner's 2025 survey reinforces the operating-model gap: while value and outcome delivery have become central responsibilities for data and analytics leaders, more than one-third still do not identify establishing and evolving the operating model as a primary responsibility.
That gap between technology and operating model is exactly where OADI fits.
Automation's natural boundary
Automation works best when:
- conditions are known
- rules are fixed
- action paths are stable
- exceptions are limited
The more volatility, ambiguity, contextual judgment, and policy sensitivity involved, the less automation alone is enough.
This is why many automation programs plateau. They automate steps but do not redesign how decisions are made across the workflow.
What Operational AI changes
Operational AI improves the layer before automation.
It defines:
- what signals matter
- how to evaluate them
- which action path is appropriate
- when to route to automation
- when to escalate to a human
- how outcomes will be measured
In other words, Operational AI helps the business decide when, where, and how automation should operate.
Comparison table
| Dimension | Automation | Operational AI |
|---|
| Primary role | Execute predefined actions | Evaluate live conditions and form action paths |
| Best use | Stable repetitive workflows | Dynamic operational environments |
| Triggering logic | Static or limited conditions | Contextual, governed evaluation |
| Human dependence | Often still needed upstream | Reduced through better decision design |
| Ceiling | Task efficiency | Operational responsiveness and consistency |
A practical test
If a business process is "automated," ask:
- Who still determines when the automation should run?
- Who interprets exceptions?
- Who decides priority?
- Who reroutes work when context changes?
- Who handles the situations the workflow did not anticipate?
If the answer is managers, supervisors, or experienced staff, then the business has automated execution but not operational decision-making.
Internal selling language
Our issue is not that too few steps are automated.
Our issue is that too many recurring decisions are still made manually before automation begins.
We need the infrastructure that evaluates signals, forms decisions, and then routes execution appropriately.
Closing
Automation is valuable.
But automation scales execution more than it scales judgment.
Operational AI is what lets organizations design judgment into the operating system.
When plain automation is enough
Not every manual step needs a decision layer. Automation without evaluation is the right tool when:
- the trigger is unambiguous and needs no interpretation
- the same action is correct every time the trigger fires
- there is no meaningful cost to running it when it was not strictly needed
- exceptions are rare and cheap to correct after the fact
Scheduled reports, provisioning on a confirmed signup, and archiving on a status change all fit. Adding evaluation to those is cost without benefit.
Where automation stops being sufficient
Automation encodes what to do. It has no opinion about whether to do it. The limit shows up as a specific pattern: the automation is technically correct and operationally wrong.
- it fires on a condition that was true but not meaningful
- it cannot see context that would have changed the answer
- it runs identically for a first-time customer and a decade-long account
- every refinement adds another conditional until nobody understands the whole
That last one is the reliable tell. When the automation's condition block has grown past what one person can hold in their head, you have built an evaluation layer accidentally, in the least maintainable place possible.
How to tell which you have
For a process you are considering automating:
- Write the trigger as one sentence. If you need "unless" or "except when", the branching is the real work.
- Count the conditions. More than three or four interacting conditions is evaluation logic, not a trigger.
- Ask what changes the answer. If the answer depends on state elsewhere, the decision needs context automation does not carry.
- Ask who currently decides. If a person judges before the process runs, automating the steps without the judgement just moves the bottleneck.
The relationship
Operational AI does not replace automation; it gives automation a governor. Existing workflows stay as execution mechanisms, and a decision layer determines which one applies to the current situation. The practical outcome is usually fewer, simpler automations — because the branching moves out of each workflow's conditional block and into one evaluation layer where it can be inspected, versioned, and tested.
Frequently asked
We have automated a lot already. Is that wasted?
No — it is the execution stage of the architecture, already built. Most operations find their automation is fine and the missing piece is the layer that decides when to invoke it. That is additive work.
What is the difference between a conditional in a workflow and a decision layer?
Location and inspectability. A conditional buried in one workflow applies only there, cannot be tested independently, and has to be duplicated to be reused. A decision layer is addressable, versioned, and shared — and when policy changes you edit it once rather than hunting through every workflow that encoded it.
Does this mean rewriting our workflows?
Usually not. The common path is to leave workflows as they are and remove their leading conditionals, replacing the trigger with a call from the decision layer. The workflow gets simpler; the judgement it used to contain moves somewhere it can be governed.
How do we avoid over-engineering?
Apply the test above honestly. If the trigger is one sentence with no exceptions, automate it and move on. The decision layer is for the processes where people keep intervening — and those announce themselves.
Related reading
Sources
-
Gartner, "Gartner Survey Finds One-Third of CDAOs Cite Measuring Data, Analytics and AI Impact as Top Challenge"
https://www.gartner.com/en/newsroom/press-releases/2025-02-20-gartner-survey-finds-one-third-of-cdaos-cite-measuring-data-analytics-and-ai-impact-as-top-challenge
-
Harvard Business Review, "How to Marry Process Management and AI"
https://hbr.org/2025/01/how-to-marry-process-management-and-ai