When to Automate and When to Redesign
Decide between automation and redesign by testing whether the outcome, steps, decisions, inputs, and controls still make sense.
Challenge the outcome and constraints
Ask whether the process still serves a necessary outcome and which constraints are real. Steps created for old system limitations, manual information transfer, or historical approvals should not automatically survive.
Assess variation and consequence
Stable, observable work with clear exceptions may suit automation. Ambiguous work with consequential errors needs redesigned decision support, stronger context, and deliberate human authority rather than unattended execution.
Remove before accelerating
Eliminate unnecessary steps, combine related decisions, improve inputs, and clarify policy before adding automation. Speed magnifies both sound design and structural waste.
Common Mistakes
- Automating every visible task
- Treating all variation as noise
- Ignoring downstream exception work
Market Signals
- Automation increases exception volume
- The process exists to reconcile disconnected systems
- Teams cannot explain why approvals occur
Questions for Leaders
Executive decision guide
Should we automate this workflow or redesign it?
Automate when the existing process produces the right outcome and its rules, exceptions, and ownership are understood. Redesign first when handoffs, incentives, or approvals are the source of failure. Automating a broken process can make rework faster and preserve avoidable operating costs.
Practical editorial guidance. This comparison is not a client case study, a promise of results, or a validated proprietary methodology.
For defining human responsibilities and oversight in an AI workflow, see NIST AI RMF, GOVERN 3.2. The framework supports risk management practice, not a claim about financial returns from John’s work.
| Decision criterion | Useful evidence or fit | Warning sign |
|---|---|---|
| Stable repetitive work | Automate a bounded step with observable inputs and outputs | Using an autonomous agent when a simple rule would suffice |
| Too many handoffs | Redesign accountability and remove unnecessary transfers | Keeping every handoff and adding another software layer |
| High consequence decisions | Assist a responsible human with evidence and review | Giving the system authority without an escalation boundary |
| Unclear customer outcome | Clarify the service promise and map the whole journey | Optimizing a local task while the customer still waits |
Before the next executive review
- Map one real case from request to completed customer outcome.
- Record waiting time, rework, review effort, and exception volume separately.
- Remove redundant steps before selecting the automation mechanism.
- Specify who may override the system and how the original process can be restored.
- Test normal work and exceptions before widening the deployment boundary.