Before eight in the morning, Alex was walking the operations floor with John, an outside operating adviser he had asked to pressure-test the work before the next leadership review. He had a process map folded under his arm.
John nodded at it and told him not to start there.
“This is the current workflow,” Alex said.
John glanced toward the floor. “No. That is the approved workflow.”
The difference between those two sentences is where most AI business cases quietly go wrong.
What The Map could Not Show
They stopped behind an employee comparing a system record to a spreadsheet. She was not hiding it. There was no panic and no apology. The spreadsheet was simply part of the work. The system held the official status. The spreadsheet held the notes the team trusted when timing changed, substitutions appeared, or a customer needed an exception handled before the next update cycle. If she waited for the system alone, she said, the order would still move. It might move wrong.
Alex asked whether the spreadsheet was the problem. Not yet, John said. It might be the problem, or it might be the only reason the customer gets the right answer today. Call it noncompliance too early and you lose what it is teaching you.
They kept walking. At another desk, an employee waited to release an order until purchasing confirmed a part number through a message thread. At the next, a manager reviewed a report that existed only because two systems did not agree often enough to trust either one alone. None of it looked dramatic, which is exactly what made it important. This was not a broken process collapsing in obvious ways. It was a functioning operation held together by human judgment, local memory, and small corrections repeated all day long.
John had made the same point years earlier in another company’s transformation review, when a team was presenting a clean update on order delays. He interrupted with one question: who touches the order after the system says it is complete? The answer took longer than it should have. Someone still checked a shared spreadsheet, confirmed a part number with purchasing, and called the warehouse to see whether the customer had changed the ship date. Everyone in the room knew the routine. Nobody had written it down.
He did not treat that as a failure. He treated it as evidence. That is the work.
Late is a Status. What Matters is a Judgment.
Further down the floor, a supervisor was reviewing a short list of delayed orders. It had been exported from the system, printed, marked up by hand, and sorted into three groups. The labels were written in the margin: wait, call, push today.
Alex asked why she did not sort them in the system.
She looked up, not defensive, just busy. “Because the system tells me what is late. It does not tell me what matters.”
Late is a status. What matters is a judgment. The system could identify one. She was supplying the other. She knew which customer was waiting on a jobsite, which substitute part would be accepted, and which delay would turn into a bigger problem if nobody called today.
From a conference room, that hand-marked list reads as inefficiency, and the obvious question is whether AI could eliminate it. Standing beside her, a different possibility appears. The list is not extra work. It is where context enters the process.
That does not mean it should survive forever. Do not romanticize the workaround, John said. It exists for a reason, and that reason is not proof that it is the best way to keep doing the work. A shadow process is the unofficial work people do to make the official process succeed. It is not something to celebrate blindly or eliminate automatically. It is evidence. It shows where the formal process lacks context, where systems disagree, and where employees have learned to protect the customer.
Almost No Company Understands Its Own Processes
This is not one company’s problem. Marcus, a chief executive Alex called when he wanted the view from the top of a company, stated it as a rule: he had never worked in a company that understood its own processes.
Every company believes it does. Most have the documentation to prove it — process maps, standard operating procedures, training material, all current and all approved. In every case, the documented process described something adjacent to the work rather than the work itself.
The difference lives in the exceptions. The workarounds nobody wrote down. The step a supervisor added after a bad quarter and never removed. The handful of customers or vendors handled differently because someone promised it years ago. The system field used for a purpose it was never designed for. None of it appears on the map, and all of it is the job.
Which is why automating the documented process is such an expensive mistake. You do not get a faster operation. You get the wrong process running faster, with the judgment that was holding it together now designed out of it.
Help the User Before Redesigning the Process
The better starting point is smaller than redesign, and it lands differently with the people doing the work.
Start with the employee, John said. What decision are they trying to make? What information do they chase? What do they check because they do not trust the system? What do they remember because no one captured it? What part of the day do they spend protecting the customer from the process?
For the supervisor, that might mean an assistant that pulls current order status, customer priority, substitution history, inventory constraints, and open messages into one view before she sorts the late orders. It might suggest which orders deserve attention first and explain why. It might flag where the data conflicts instead of hiding the conflict. It might draft the customer update and leave the final judgment with the person who understands the stakes.
From her perspective, the best first change may not feel like a new process at all. It may feel like the work finally has the context it was always missing.
That difference shows up in the rollout conversation. One version sounds like: we redesigned the process, and here is what you need to do differently. The better version sounds like: we watched where the work depends on your judgment, we found the places where systems make that harder than it needs to be, and this release gives you better context and less repeated checking.
Autonomy is Earned in Stages
Alex wrote the operating sequence in his notebook, and each step earns the next. Assist the user. Recommend with reasons. Automate the routine, low-risk cases. Escalate exceptions clearly. Learn from outcomes.
The test arrived sooner than he expected, as a vendor demonstration. The proposed agent would review delayed orders, contact suppliers, update customers, and release routine decisions without waiting for a person. On paper it was exactly what leadership wanted.
Standing on the floor, the risk was obvious. If the agent acted before the data was reliable, before the exception path was clear, or before employees trusted the recommendations, the company would not have built a more reliable operation. It would have built a faster failure mode.
John put it in a sentence that belongs in any AI review: it is moving faster than the work can explain itself.
Roles will change, and they should. But let the work show what people can stop carrying, what AI can support reliably, and where human judgment becomes more valuable rather than less. Redesign the roles before the work has proven any of that, and you are not managing a transformation. You are guessing, at scale.
Adapted from Feasible, Not Achieved: Why AI Transformation Stalls and the NINE Decisions That Finish It, by Weston A. Jones, MBA and Jacob C. Roxon, PhD (JRNine Press).
The Jones-Roxon Nine™ is the Operator’s System for AI Transformation.