AI operations management fails most often because automation gets applied to a process nobody ever defined. A vague process run by people is corrected quietly by judgment at every step. The same process run by software repeats the vagueness at speed, and the errors arrive faster than anyone can intercept them.
Judgment Is the Hidden Correction Layer
Most business processes are far less defined than the people running them believe. The documented version describes a clean path. The actual version contains dozens of small corrections nobody records.
A clerk notices that an address looks wrong and checks it. A dispatcher sees an order that does not fit the usual pattern and calls the customer. A technician spots a part number that has changed and substitutes the correct one.
None of those corrections appear in any procedure document. They happen inside the head of an experienced person, in the space between one documented step and the next.
That correction layer is doing enormous work. It absorbs ambiguity, patches missing rules, and prevents bad inputs from travelling downstream. It is also invisible, which is why it gets removed by accident.
When a process is automated, the documented steps get encoded. The correction layer does not, because nobody knew it was there to encode.
The people who supplied the corrections rarely raise an objection either. They do not experience the corrections as work, since each one takes seconds and feels like ordinary attention rather than a task.
Asked whether the process is well understood, they answer yes and mean it. Their confidence is genuine and it describes their own competence rather than the process itself.
Speed Turns Ambiguity Into Volume
A vague process performed by hand produces occasional errors that people catch. The same process performed by software produces the same error rate applied to far more transactions.
Rate matters less than volume here. An error that appeared a few times a month becomes an error that appears a few times an hour, and the mechanism that used to catch it is gone.
Detection also degrades. Human errors are varied and noticeable, because different people fail in different ways. Automated errors are uniform, and uniformity looks like correct operation to anyone glancing at a summary.
The consequence is a delay between the start of the problem and the discovery of it. That delay is where the real cost sits, since every affected transaction has already moved downstream.
Reporting makes the delay worse rather than better. Dashboards summarise, and a summary of uniform output looks healthy right up to the point where someone opens an individual record.
Confidence in the numbers also rises after automation, because the figures now arrive without manual handling. Trust increases at exactly the moment scrutiny should have increased.
Some of those transactions reached customers. Some entered the accounting system. Unwinding them takes longer than the process took to run, which is how a productivity project becomes a cleanup project.
The Exception Rate Nobody Measured
Every process has an exception rate, meaning the share of cases that do not follow the standard path. Almost no business knows what its exception rate is, because exceptions are handled rather than logged.
The exception rate determines whether automation is a good idea. A process where nearly everything follows the standard path automates well. A process where a meaningful portion requires a decision does not.
The trouble is that people describe their work as if exceptions were rare. Asked how a process runs, they describe the standard path, because the standard path is what they think of as the process.
The exceptions live in habit rather than memory. They are handled so routinely that they stop registering as departures from anything.
Managers tend to guess low, and the people doing the work tend to guess low as well. Both groups are estimating from memory, and memory discards anything resolved without difficulty.
A short observation period fixes this cheaply. Watching the work for two weeks and marking every case that required a decision produces a number that no interview will produce.
Sound operational management of automated work treats that number as the entry criterion. Where exceptions are common, the correct move is to reduce them first, not to encode them.
What Definition Actually Requires
Defining a process is not the same as documenting it. Documentation records what people say happens. Definition establishes what should happen, including in the cases nobody wants to discuss.
A defined process states the outcome it exists to produce. Without that, no one can judge whether a variation is an error or an improvement, and the automated version will preserve both equally.
A defined process states its inputs and what makes an input acceptable. Most automation failures trace back to inputs that were always slightly wrong and always silently fixed.
A defined process states what happens when something does not fit. Not a vague escalation, but a named person, a stated timeframe, and a rule for what the system does while waiting.
A defined process states who is accountable for the output. Automated work loses ownership faster than manual work, because nobody feels responsible for a step they do not perform.
Definition also has a political dimension that documentation avoids. Writing down what should happen forces a choice between two departments who both believed their version was standard.
That choice belongs to a person with authority, and it cannot be resolved by a workshop. Processes without a decision maker end up defined by whoever is most persistent.
Producing those four statements takes days rather than months. Skipping them takes no time at all and costs considerably more later.
Where the Exposure Shows Up First
Certain processes reveal their lack of definition immediately under automation, and knowing which ones saves considerable pain.
Anything involving customer communication exposes fastest. Tone, timing, and appropriateness were all being judged in the moment by someone who knew the customer. Encoding the words without the judgment produces messages that are technically correct and situationally wrong.
Anything involving pricing or quoting exposes next. Quotes routinely include informal adjustments for relationship, urgency, or risk that never made it into any rule. Removing the adjuster produces quotes that are consistent and commercially poor.
Anything involving intake exposes soon after. Intake is where bad data enters, and it is usually the point where the most correction was happening invisibly. Automating intake without validation moves the error deeper into the business.
Scheduling sits somewhere in between. Assignment rules look simple until the informal factors appear, such as which technician a particular customer trusts and which route the dispatcher knows is slower than the map suggests.
Those factors were never written down because they change constantly and everyone doing the work already knew them. Encoding the visible rule alone produces a schedule that is defensible on paper and worse in practice.
Approval steps expose more slowly and more expensively. An approval that was always granted looks like a formality, until the case arrives where it should have been refused and nobody was watching.
Careful application of generated output inside operating work begins with the steps where a wrong result is visible immediately, not the ones where it hides in a ledger.
The Order That Works
The productive sequence is unglamorous and it has not changed. Observe, define, simplify, then automate whatever survives.
Observation comes first because description is unreliable. People are honest and still inaccurate about their own work, which is a well-established feature of how habits form.
Definition comes second, and it will surface disagreements. Two people who have run the same process for years will describe different rules, and discovering that before automation is a gift rather than a problem.
Simplification comes third and is the step most often skipped. Many steps exist because of a supplier who is gone, a system that was replaced, or a mistake made years ago. Automating them preserves history nobody needs.
Automation comes last and covers less ground than expected. A well-defined process usually reveals that only part of it is worth automating, with the judgment-heavy portion better left to a person supported by better information.
Each stage should also produce something usable on its own. Observation improves training. Definition improves onboarding. Simplification improves throughput before a single tool is purchased.
Sequencing the work that way removes the pressure to justify a spend. Value appears early and does not depend on whether the final automation step is ever taken.
That outcome disappoints people expecting a fully automated function. It also produces something that keeps working after the person who built it moves on, which the ambitious version rarely does.
The uncomfortable finding in most of this work is that automation was never the constraint. Businesses reach for tooling because the alternative is admitting that a process everyone relies on was never actually agreed. Agreeing it surfaces conflicts between departments that have been managed by avoidance for years. The technology arrives as a way to skip that conversation. It does not skip it. It stages the conversation publicly, at speed, in front of customers, which is a more expensive venue than a meeting room.
Frequently Asked Questions
How do you know whether a process is defined well enough to automate?
Ask three people who run it to describe what happens when a case does not fit the standard path. Consistent answers indicate a defined process. Different answers, or hesitation, indicate that judgment is filling a gap that no rule covers. That gap is exactly what disappears when the work moves to software.
What is an exception rate and how is it measured?
It is the share of cases that require a decision rather than following the standard path. Measuring it requires observation rather than interviews, because people underreport exceptions they handle by habit. A short logging period, where anyone touching the process marks cases needing judgment, produces a usable figure. That figure predicts automation success better than any feature comparison.
Should a business fix the process before buying anything?
Yes, and the fixing is usually cheaper than the software. Definition work requires attention rather than expenditure, and it produces benefits even when nothing gets automated afterward. Buying first creates pressure to encode the process as it currently stands, including the parts that should have been removed. That pressure is the mechanism by which bad processes become permanent.
What happens when experienced staff leave after automation?
The business loses the ability to judge whether the automated output is still correct. Judgment about acceptable output lives with people who performed the task, and that knowledge decays quickly once they stop performing it. Keeping a manual fallback and rotating someone through it periodically preserves the capacity to evaluate. Without that, errors persist until a customer reports them.
Which processes are the worst candidates?
Anything with a high exception rate, anything where a wrong result stays hidden for a long time, and anything where the standard was never written down. Approval steps are particularly risky, because their value only appears in the rare case that should be refused. Customer communication is risky for a different reason, since errors there are visible externally and damage trust immediately.
Is partial automation a failure?
Partial automation is usually the correct answer rather than a compromise. Most processes contain a mechanical portion and a judgment portion, and separating them cleanly delivers most of the benefit at a fraction of the risk. Attempts at full coverage tend to encode judgment badly and then require constant correction. A person supported by better information often outperforms a system asked to decide.
No comments:
Post a Comment