There is a principle in manufacturing that predates software by decades: do not automate a broken process. The logic is straightforward. Automation amplifies whatever is already happening. If the process is efficient, automation makes it more efficient. If the process is broken, automation makes it break faster, at higher volume, with less opportunity for human intervention to catch the errors before they compound.
This principle is as relevant to AI-enabled automation as it was to factory floor automation in the 1970s. And it is violated constantly.
I see it most often in organizations that come to an automation engagement with a clear idea of what they want to automate and a strong preference for moving quickly to technology selection. The process has been running for years. The team knows how it works. The pain points are obvious. Why spend time mapping something everyone already understands?
The answer is that what everyone understands is usually the official version of the process, the one that is documented, the one that gets described in meetings, the one that new employees are trained on. The actual process is almost always different. It has workarounds that developed because the official process did not handle edge cases well. It has informal dependencies on specific people who carry knowledge that was never documented. It has steps that exist because of a system constraint that no longer applies, or a regulatory requirement that was misunderstood, or a decision made years ago by someone who has since left the organization.
When you automate without surfacing these things, you automate the workarounds, the informal dependencies, and the vestigial steps along with the legitimate process logic. The automation works, in the sense that it executes the process as it actually exists, but it does not work well, because the process it is executing was never designed to be automated.
The most valuable work in any automation engagement is the process analysis that happens before technology is selected. This means mapping the process as it is actually practiced, not as it is documented. It means identifying which steps add value and which exist for other reasons. It means understanding the edge cases and exceptions that the official process does not account for. And it means making deliberate decisions about which parts of the process should be automated, which should be redesigned before automation, and which should remain human-executed because they require judgment that cannot be reliably encoded.
This work takes time. It requires access to the people who actually do the work, not just the people who manage it. It requires a willingness to question assumptions that may have been in place for years. And it requires a consulting partner who is willing to slow down the technology conversation until the process conversation has been had.
At benel Solutions, we have made this a non-negotiable part of how we approach automation engagements. We will not select a technology until we understand the process. We will not automate a step until we have asked whether that step should exist. And we will not close a project until we have built the monitoring infrastructure to detect when the automated process is not behaving as intended.
The organizations that get the most value from automation are the ones that treat it as a process improvement discipline, not a technology deployment project. The technology is the last step, not the first.