The deliverable people expect
Ask most operators what an automation audit produces and they will describe a diagram. Boxes, arrows, swimlanes, a slide deck built around it.
That is the input, not the output. A map tells you what the process is. It does not tell you what to do, and the gap between those two is where every bad automation decision gets made.
Two numbers turn a map into a decision
The first is the cost of chaos: what these specific workflows lose per week to rework, waiting and dropped handoffs. Loaded hourly cost, volumes from the systems, a window long enough to catch a bad month.
The second is a score per candidate, on two axes. How feasible is this to automate reliably, and how much of that weekly cost would it actually recover at conservative assumptions.
Neither is sophisticated. Both are absent from most proposals, and the absence is not an oversight. A proposal without a measured baseline cannot be checked afterwards, which is convenient for the party writing it.
What goes wrong when the stage is skipped
Three things, in a reliable order.
The wrong process gets automated first. Without a return score, selection defaults to whoever complained most recently or whose process is easiest to describe in a meeting. Those correlate weakly with cost.
The before number gets invented afterwards. This is the expensive one. Nobody measured the old cycle time, so when the new one is reported at four hours, the old one becomes "about a day" - a figure produced by the same people who need the project to have worked. The audit before automation exists to make that reconstruction unnecessary.
The engagement cannot end in no. A diagnostic with no arithmetic in it has no mechanism for concluding that the build is not worth doing, so it never concludes that. Every audit returns yes, and the yes means nothing.
The map still has to be honest
The measurement only works if the map underneath it describes the real route, workarounds included. The shared spreadsheet nobody officially uses is load-bearing, and it is usually where the contradictions that break automation are hiding. How that map gets drawn is a subject of its own, covered in why most process maps are useless.
What the client keeps
The map, the baseline and the matrix, in writing, regardless of what happens next. That is the design: the stage has to be worth its own fee even when it kills the project, or the incentive to find a project quietly returns.
Break is one of six stages, and the ones after it depend on this output being real. The full sequence, walked through a single deployment, is in the protocol applied end to end.
Top comments (0)