There is a specific moment in most operations conversations where the room turns. Someone has finished describing a workflow that takes four days, touches six people, and produces a spreadsheet nobody fully trusts, and someone else says: this should be automated. Everyone nods, because it is obviously true. The work is repetitive, the rules are mostly written down, and the tooling to do it has never been cheaper or more capable.
What almost nobody asks in that moment is whether the process deserves to exist in the shape it currently has. Automation is a multiplier, and it is indifferent to the sign of what it multiplies. Applied to a workflow that earns its steps, it compounds. Applied to a workflow that accumulated its steps (one approval added after an incident years ago, one reconciliation added because two systems disagree, one handoff that exists because a role changed and the process never did), it does something worse than fail. It succeeds, and makes the accumulated mess permanent, cheap to run, and much harder to argue with.
Why "automate it" is the wrong first question
The reason the question gets skipped is not carelessness. It is that automation has a clean business case and redesign does not.
Automating a known process is legible: here is the time it takes today, here is the time it takes after, here is the difference in cost. You can put that in a deck. Redesigning the process first is a proposal to spend money and political capital before you can name the saving, on the grounds that the shape of the work is wrong, which is an argument about judgement rather than arithmetic. Between a legible case and a correct one, organizations reliably fund the legible one.
The cost of that choice shows up later, and rarely in the automation budget. It shows up as a workflow that now runs in minutes but still routes to an approver whose approval has not changed an outcome in two years. It shows up as three systems automatically reconciling a discrepancy that should have been fixed at its source. It shows up most expensively as the freeze: once a process is encoded in software, changing it stops being a conversation between two managers and becomes a change request with a queue, a cost, and an owner in another department. Automation converts process debt into technical debt, and the exchange rate is bad.
None of this is an argument against automating. It is an argument for a short, cheap step before it, which is deciding what the process should be while that decision is still free.
Four tests before you automate
Run these against the specific workflow in front of you. They take a working session, not a project, and any one of them coming back badly is a reason to redesign before encoding.
1. Can you draw the process as it actually runs?
Not the process document. The real one, including the workarounds. The test is whether the people who do the work every day would recognize the drawing.
This sounds trivial and it is the test most organizations fail. The gap between the documented process and the practised one is where the interesting information lives: every workaround is a person routing around a step that does not work, and they have usually been right for longer than anyone senior has known about it. If you cannot produce that map, you do not yet know what you would be automating. You know what you would be told you are automating, which is a different thing, and the software will be built to the second one.
There is also a sequencing point here. Mapping is the cheapest diagnostic in operations and it is the one most often skipped on the grounds that the process is already understood. It is worth the week.
2. Would you defend every step to someone paying for it?
Take the map and go step by step with one question: what would break if this stopped happening tomorrow?
Some steps have an immediate answer (a control that a regulator requires, a check that catches real errors, a decision that genuinely needs a human). Those stay. Others produce a pause, then a version of that's how it's always been done, or finance wanted it, or a name of someone who left. Those are candidates for removal, and removal is strictly better than automation: a step that does not run costs nothing, breaks nothing, and needs no maintenance, whereas an automated version of the same step costs a build, a licence, and a permanent line in someone's support queue.
The discipline is to make elimination the default question and automation the fallback. A 12-step workflow where 4 steps exist only to compensate for an upstream defect is not a 12-step automation candidate; it is an 8-step process plus a defect, and the defect is the cheaper thing to fix. Most workflows have more removable steps than anyone expects, because the steps were added one at a time by people acting reasonably, and nobody has ever been assigned to take one away.
3. Is the process stable, or still being argued about?
Automation encodes agreement. If the underlying agreement does not exist, the software will not create it; it will freeze whichever version happened to be in the room when the requirements were written, and the unresolved argument will resurface as a stream of exceptions and change requests.
The signal to watch for is a process where two functions describe the same step differently, or where the definition of the output is contested. If sales and finance do not agree on what counts as a qualified opportunity, an automated pipeline will not settle it. It will produce a number faster, that both sides continue to dispute, with the added disadvantage that the disagreement is now buried in configuration rather than visible in a meeting. Settle the definition first. That is a strategy conversation, and it is cheaper than the integration work it replaces.
4. Who owns the output when the software owns the work?
Every manual process has an implicit owner: the person who notices when the number looks wrong. Automation removes the noticing without removing the need for it, and that role frequently goes unassigned because it was never formally assigned in the first place.
So before you build, answer three things. Who reviews the output, and how often? What tolerance triggers a look? Who has the authority to stop the process when it is producing confident, wrong answers? A workflow that runs unattended with nobody accountable for its output is not an efficiency gain that has been banked. It is a risk that has been moved somewhere less visible, and this is sharper again when the automation involves a model rather than a rule, because the failure mode is plausible output rather than an error message. That is the point at which this stops being an operations question and becomes an AI implementation one, with its own governance decisions to make before anything goes live.
What to do with a process that fails the tests
Failing a test is not a verdict of "do nothing." It is a redirection of the same budget toward a cheaper intervention, in a specific order.
Eliminate first. Every step that survives question two only because nobody has challenged it. This costs a decision, not a build.
Then resolve. Every definition or ownership question that two functions answer differently. This costs a meeting with the right people in it and a written outcome, which is harder than it sounds and still cheaper than encoding the ambiguity.
Then simplify. Reduce handoffs, since most of the elapsed time in a four-day process is not work, it is waiting between people. Cutting three handoffs to one often does more for cycle time than automating any single step would, and it does not require a system.
Then automate what is left. By this point the process is smaller, agreed, and owned, and the automation case is both legible and correct. It will also be a materially cheaper build than the one you would have scoped at the start, because you are no longer paying to encode steps you were about to delete.
Then instrument it. Put a measure on the redesigned process so the gain stays visible after attention moves elsewhere. Processes drift back toward their old shape, and the drift is invisible without a number.
When automating first is the right call
The order above is a default, not a rule, and there are honest cases for inverting it.
The clearest is when the process is genuinely simple, high-volume, and uncontested: data moving between two systems, a rules-based check with an unambiguous definition, a report assembled the same way every month by a person who would rather be doing something else. There is nothing to redesign. Automate it and move on.
The second is when automation is the diagnostic. Instrumenting a workflow (even crudely) sometimes produces the first honest measurement of where the time actually goes, and that measurement is what makes a redesign arguable. Just be explicit that this is what you are buying, and keep the build small enough to throw away.
The third is timing. Occasionally the process is bad, the redesign is the right answer, and there is no organizational appetite for it this quarter. Automating a narrow slice can buy relief and credibility while the larger decision waits. That is a legitimate trade, and it is a different thing from mistaking the slice for the answer. Say which one you are doing, in writing, so the follow-through does not quietly become optional.
Where this fits
The decision of what to redesign, and the work of getting people to run the new way, is the part of operations that does not automate. Mapping the real flow, separating value from friction, and rebuilding the workflow around what actually creates value is business process consulting; doing it across the whole operating model, rather than one workflow, is digital transformation. Either way the outcome depends on adoption, which is why the change management question belongs in the scope from the start rather than at the launch event. And where the automation in question is AI rather than rules, the harder problem is usually defining the return before the build, not the build itself, which is what the two week diagnostic is for.
If you have a workflow that is slow, duplicated, or expensive and you are not certain whether it needs software or a decision, that is worth an hour before the budget is committed rather than after. Start a scoping conversation: we would rather tell you the process is sound and the automation is straightforward than sell you a redesign you do not need.