Faster Confusion: What Happens When You Automate a Broken Operating Model
Automation multiplies whatever organization it's applied to, including the parts that don't work.
Most leadership teams feel real pressure to adopt AI and automation quickly. Competitors are moving, employees want better tools, and a quarter of delay can feel like lost ground. That pressure is legitimate, but speed only creates value when an organization knows what it is accelerating toward.
Built on a clear operating model, automation reduces friction, improves consistency, and gives people more time for work that needs judgment. Built on a fragmented one, it takes the existing confusion and moves it faster.
A familiar scenario
Consider a composite example. A procurement team wants shorter approval times, so it automates purchase-request routing. The workflow needs rules about three things:
which requests go to finance;
what dollar amount requires a director's sign-off;
what counts as an exception.
Nobody had written those rules down. Experienced staff had been making judgment calls for years.
Working against a deadline, the project team filled the gaps itself. It set thresholds from an old policy memo and sent anything unusual to a shared inbox. After launch, average approval time fell by half.
Six months later, the picture had changed:
The shared inbox held hundreds of requests nobody owned.
Finance was reviewing purchases it never needed to see.
Several departments had gone back to emailing approvers directly.
The dashboard still reported faster approvals, because the workflow was doing exactly what it had been configured to do.
What a broken operating model looks like
An operating model is the working system that turns an organization's intent into results. It determines:
who decides;
what information they rely on;
how work passes between teams;
who owns outcomes;
how exceptions and risks get handled.
When those answers are unclear, contradictory, or out of step with how work really happens, the model is broken.
Most leaders will recognize the symptoms. Two teams each believe they own a decision, or neither does. Employees keep spreadsheets and side channels running so the formal process can function. Approval steps have piled up, and nobody remembers why. Exceptions outnumber standard cases, and the same issues return to the governance forum month after month.
Automation leaves all of this in place and writes it into software.
How ambiguity becomes executable
When a rule is unclear in a manual process, different people interpret it differently. That wastes time, but the inconsistency is visible. People ask questions, managers step in, and experienced staff find their way around the gaps.
Automation hides the inconsistency while leaving the ambiguity intact. Someone has to turn policy into logic and choose which conditions trigger which actions. Where leaders haven't made those choices, the project team makes them. It usually does so under deadline, and often without the people accountable for the outcome.
The result looks like technical configuration, but it amounts to decisions about authority, policy, and risk. The system then applies those decisions to every case it touches. A misunderstanding that used to affect ten requests can now affect ten thousand.
Four ways the confusion compounds
Weak decisions scale. Every workflow encodes choices about priority, exceptions, and when a person has to step in. If nobody made those choices deliberately, the organization becomes more consistent while possibly being consistently wrong.
Workarounds harden. The process people can see usually carries years of accumulated approvals and reconciliations. Some of them manage real risk. Others exist only because two systems were never integrated. Digitizing that process without questioning it turns yesterday's workaround into tomorrow's architecture, which is harder and more expensive to change.
Local gains hide enterprise losses. A team automates its own step and reports a productivity win while sending more incomplete work downstream. An AI drafting tool helps people write faster and quietly adds review and compliance work somewhere else. The team's metric improves while the end-to-end result stays flat or gets worse.
Accountability gets lost. When an automated outcome goes wrong, each party has a defensible answer:
The business points at the technology.
IT points at the approved requirements.
The vendor says the system performed as configured.
The data team says it used the sources it was given.
The result still has no owner. People respond sensibly: they recheck outputs, keep parallel records, and route around a system that was meant to save them work.
AI raises the stakes
Traditional automation follows fixed rules. AI works on probability and inference, and its behavior can shift as models, prompts, and data change. That makes operating-model clarity matter even more.
Before handing work to AI, leaders need to settle several questions:
Which decisions may AI inform, which may it make, and which stay with people?
What evidence must a recommendation come with?
Who can override the system?
Who watches whether its results stay acceptable over time?
These are governance questions first. The answers belong inside the workflow itself, where decisions are actually made, rather than in a policy document filed alongside the program.
Five questions before you automate
Before funding an automation initiative, leaders should be able to answer these:
What outcome are we improving? "Reduce manual effort" rarely suffices. Name the business, customer, or mission result.
Who owns that outcome from start to finish? An owner of one step or one system has too narrow a view.
Do we understand the process as it actually runs? The official diagram and the real workflow often differ, and you need to know both.
Are the inputs trustworthy, and is there a governed path for exceptions? Bad data makes automated errors arrive faster. Without an exception path, edge cases pile up with nobody responsible for them.
How will we measure value and harm? Track quality, risk, trust, and downstream effects alongside speed and cost.
A team that can't answer these probably needs to fix its operating model before it has anything worth automating.
A better sequence
Nobody needs a perfect organization before automating. What helps is doing things in the right order:
Watch how the work really happens.
Settle what outcome it serves and who owns it.
Strip out steps that no longer earn their place, since there's little point paying to automate them.
Decide where technology acts and where people decide.
Automate in small, bounded pieces.
Judge each piece by its effect on end-to-end results.
Clarity comes first
Leaders often frame automation as a tradeoff between speed and caution. The more useful distinction is whether the organization accelerates with clarity or without it.
Clarity here means being explicit about the outcome, who has authority, what evidence counts, and where the technology's boundaries sit. Some uncertainty will always remain. Organizations that do this work tend to move faster anyway, because fewer problems stay hidden and fewer decisions get reopened.
With a healthy operating model underneath it, automation multiplies value. Without one, it still multiplies something, and leaders may not like what they find.
Yasser Haridi is CEO and Co-Founder of BIITLAB, where he and his partners advise leaders on AI adoption, operating-model design, and complex transformation. He is a former NASA Chief Enterprise Architect.
Comments