Automation is often evaluated through time saved and errors avoided. Those are useful measures, but they leave out another change: the movement of decision-making authority. When a process becomes software, judgments that were once made during the work are increasingly made when the system is designed.
A rule determines what proceeds automatically. A threshold decides what receives attention. A required field defines which account of a situation the organization is willing to accept. The person handling a case may become less able to interpret it, even as the overall process becomes faster.
Follow the exceptions
This is not necessarily a loss. Consistency can protect people from arbitrary decisions and reduce dependence on individual judgment. The question is whether the system preserves an appropriate way to recognize circumstances its rules do not adequately describe.
An exception process should identify who can reconsider a result, what evidence they can use, and whether they have authority to change the outcome. A queue labeled “manual review” is not enough if the reviewer can only repeat the original rule.
The same issue appears upstream. Who can alter the rule? How are effects observed? Can the organization distinguish a successful policy from a system that merely processes cases as configured? Without those distinctions, technical correctness can conceal an institutional mistake.
A complete assessment of automation therefore asks two questions together: what work becomes more efficient, and where judgment moves. Understanding the second helps determine whether the first is actually an improvement.
The design of a workflow is also a design of authority. Treating it that way makes the consequences easier to examine before the software makes them routine.