Automation has a way of becoming the goal instead of the means. A team sets out to reduce manual work in a process, succeeds, and the success itself becomes the story: we automated forty percent of this workflow. What gets lost is the question that should have come first, which is whether that workflow, automated or not, was actually the right one to be running.
This matters because automation is very good at making an existing process faster and very bad at telling you the process was wrong in the first place. If a reconciliation step exists because of a control gap that was patched over a decade ago and never revisited, automating that step makes the patch permanent and faster, not better. The work of automation should always start with the work of asking whether this step should exist at all, and that question gets skipped more often than it should, because it's slower and less satisfying than shipping a working automation.
The organizations that get this right treat automation as one tool inside a broader operating model decision, not as the decision itself. They ask what the process should look like if it were being designed today, with current technology and current volumes, and only then ask which parts of that redesigned process are worth automating. The sequence matters: automation applied to a process that's been rethought tends to compound, while automation applied to a legacy process tends to just lock in the legacy.
There's a real organizational temptation to skip this and just automate what already exists, because it's measurable and fast and doesn't require the harder conversation about why the process looks the way it does. That temptation is worth resisting. The value isn't in the automation. It's in the operating model the automation is serving, and that's the part that actually deserves the strategic attention.