There's something deeply ironic about the way many organizations approach automation. It is presented as a promise of efficiency, as an almost inevitable solution to scale operations without increasing costs. In strategic meetings, there is talk of automatic flows, of decisions assisted by artificial intelligence, of processes that will no longer depend on human intervention. Automation is "the Canarian ointment". And it all sounds logical. It all seems aligned with a very attractive narrative: if we manage to automate enough, we will be able to do more with less. Fewer people (although the idea is not to fire but to reassign), fewer errors, less time wasted on repetitive tasks. The problem is that this story usually omits an uncomfortable part. Automating something doesn't necessarily make it better. Automating simply means that the system will execute a process automatically, exactly as it was designed. And if the process was designed badly, the system will execute it badly... only now it will do it with more speed, more consistency and many more times a day.
Over the years one learns to recognize this pattern easily. It appears in companies of all sizes and in virtually every industry. The project is enthusiastically approved, a powerful platform is implemented, the team celebrates that the process is finally "automated" – "Now we are going to solve our headaches... and weeks or months later the strange signs begin to appear. The system throws more exceptions than expected. Teams begin to create parallel paths to solve situations that the flow does not contemplate. People start saying things like "the system won't let us do it" or "we used to solve this faster." No one will openly say that the process got worse, but the feeling is slowly starting to set in. And the funny thing is that the problem is rarely in technology. What usually fails is something much more basic: a process that was already flawed from the start was automated.
One of the most frequent scenes in automation projects is also one of the quietest. The team identifies a time-consuming process. Maybe it requires multiple approvals, involves different areas, or relies on endless emails to move forward. The diagnosis seems obvious: the problem is the lack of automation. So he sets out to implement a system that manages the flow, notifies those responsible, records decisions, and ensures that each step happens in the correct order – typical. At first glance, the logic seems impeccable. What almost never happens at that moment is something much simpler and at the same time much more uncomfortable, which is to stop and analyze whether the process itself makes sense.
Has anyone wondered why the process has so many steps? Why are there certain validations? What risks were you trying to avoid when this flow was designed? Do those risks still exist today? In many organizations, these questions don't come up because the business process is already part of the operational landscape. "We've been doing it this way for 30 years" or "That's how it's been done all our lives". No one remembers exactly when it was defined, but everyone knows that this is how it is done. And when something has worked for years, even if imperfectly, no one thinks of questioning it. So automation is advancing with a fairly clear objective, which is to digitally replicate what is already happening. The result is predictable. The system executes the process exactly as it was defined. The same steps, the same approvals, the same dependencies between areas, the same bureaucracy. Only now everything happens within a platform.
Sometimes automation is presented as a huge leap towards efficiency, but when you look calmly at what was actually implemented, you discover something much more modest: it simply digitized the existing bureaucracy. A process that once relied on emails now happens within a system. Approvals that were previously recorded informally now appear as statuses within a flow. There are automatic notifications, traceability and dashboards that show what stage each request is in. From the outside, everything seems more orderly. The problem is that the process that was automated may still be unnecessarily complex.
Let's imagine a flow that requires five approvals to move forward. No one clearly remembers why there are five. There were probably valid reasons at some point: tighter financial controls, increased operational risk, or just a smaller, inexperienced organization that needed to review everything manually while staff learned how to do it. Over time the process survived and became the "normal" way of doing things. When automation comes, the discussion rarely revolves around reducing those approvals. The goal is to build a flow that allows them to be managed digitally. Each manager receives their notification, reviews the request, approves or rejects and the system records the decision. The process now looks sleek on screen, but it still has five approvals. And the most curious thing is that now it will be much more difficult to change it, because what was once a flexible organizational practice is now a programmed or "burned" logic within a system.
When a manual process is flawed, people often find ways to adapt. They look for the rope to the stick as it is popularly said. Experience and criteria function as compensation mechanisms. If an approval is unnecessary, someone calls the person in charge directly to speed up the process. If a rule does not contemplate a particular case, people talk and decide how to proceed. Informality, to a certain extent, allows the organization to survive its own imperfect processes. But when that same process is automated, that flexibility disappears. And we realize that we got into a straitjacket and very expensive passage.
Systems don't improvise. Systems execute rules. And when the rules were defined without questioning their logic, the system will apply them with absolute discipline. It is at that moment that curious situations begin to appear. The system blocks a request because a validation is missing that no one really considers necessary. The flow does not allow progress because a specific condition is not met exactly as programmed. People know that the case should be resolved in another way, but the system does not contemplate that possibility. Then improvised solutions begin to appear around the system. Duplicate records, parallel mails, exceptions that are handled manually outside the platform. Instead of simplifying the process, automation ends up creating new layers of complexity.
>> What is a Business Process Manager and what is it for? <<
Conversations about digital transformation often have a rather persistent conceptual confusion. And I hate her! Many organizations talk about automation as if it were synonymous with optimization. However, both things answer completely different questions. Automate means executing a set of steps automatically. On the contrary, optimizing means questioning whether those steps should exist in the first place. The problem is that questioning processes can be uncomfortable. It involves reviewing decisions that someone made in the past, reviewing assumptions that may no longer apply, and recognizing that some practices were simply out of habit. That impacts the ego and a wounded ego does not collaborate.
For that reason, many automation initiatives start directly with the design of the digital flow. It defines who approves what, in what order the validations occur and what conditions trigger each stage of the process. What almost never comes up in that conversation is a much more radical question: could this process be simpler? Maybe some decisions could be eliminated. Maybe certain approvals don't add value. Perhaps the process exists only because there was once a reason that no longer applies today. Mea culpa that at the beginning of my career as a consultant I didn't do them either. When those questions aren't asked, automation becomes a sophisticated way to preserve existing complexity.
A faulty process executed manually has a relatively limited impact. It can lead to friction, consume time, or cause delays, but people often find ways to adapt and get the job done. The problem becomes much more serious when that same process is automated. Automation introduces speed and scale. The flow that used to run a few times a day can now run tens or hundreds of times. Decisions that once relied on conversations now become programmed rules that affect the entire organization. In this context, a small design error ceases to be an annoying operational inconvenience and becomes a structural problem.
In addition, correcting that problem later is usually much more difficult. What was once an organizational habit is now embedded in the system's architecture. Changing it involves reviewing logic, modifying integrations, and testing to make sure other processes aren't affected. Suddenly, something that could have been solved with a conversation between teams becomes a technical project.
There is a quiet expectation that appears in many automation projects. Technology is expected to bring order to processes that the organization has never fully structured. Vague responsibilities, ambiguous rules or decisions that depend on individual interpretations. In this context, the system seems to offer an attractive solution. If everything is defined within an automated flow, the process should become clearer. However, systems do not invent order. Systems execute rules. And if the rules aren't clear, the system will simply reflect that same ambiguity in the form of exceptions, blocks, or flows that no one quite understands.
Over time, familiar comments begin to appear within the organization. People say that the system is too rigid, that it does not contemplate certain cases or that it forces unnecessary steps to be followed. It simply does not adapt to the organization. But the system is only running what it was asked to execute. In many cases, the irony is that the technology ends up exposing, more clearly, the design problems that already existed in the original process.
When discussing an automation project, the conversation often focuses on the visible costs: software licenses, implementation time, integrations with other systems. However, there is another type of cost that rarely appears in initial analyses. It is the cost of institutionalizing processes that perhaps should never have existed. Every unnecessary process that is automated becomes something that the organization will have to maintain, update, and endure for years. Over time, new rules, new validations, and new dependencies on other systems are added. You can imagine all the maintenance that IT will have to be giving for each exception that came out after the go-live.
The paradox is that the original goal was to reduce operational complexity. But when you automate without questioning the process, the complexity simply shifts places. It ceases to be in the interaction between people and begins to live within the system.
Interestingly, when one observes organizations that have managed to automate processes with real impact, the starting point is usually very different. Before talking about technology, they talk about processes, that's what my friend Joe says. Before building digital flows, they review decisions. Before programming rules, they eliminate unnecessary steps. That exercise often yields interesting discoveries. Processes that seemed complex can be significantly simplified when their assumptions are revised. Some approvals stop making sense. Some validations may be consolidated. Some decisions can be automated because they actually follow pretty clear rules.
At that point, automation ceases to be an attempt to tame complexity. It becomes a way to sustain the simplicity that was already achieved in the redesign of the process. I love that phrase!
After seeing many automation projects, one ends up coming to a fairly straightforward conclusion. Technology does not correct bad processes. Bad automated processes are still bad, only now they are executed faster, with more consistency, and with greater reach within the organization. And when that happens, the company ends up with something that no one expected at the beginning of the project. It has more technology, more systems and more automation... But it doesn't necessarily have better processes.
Perhaps that's why the most important question in any automation initiative shouldn't be what technology to implement or which platform to use. The really uncomfortable question comes up before all that. It appears when someone stops to observe the process calmly and dares to ask a question that is rarely raised at the beginning of projects.
Do we really need this to happen this way? What do you think?