Automação virou sinônimo de progresso. Toda empresa quer "automatizar", como se a palavra por si só garantisse economia. Mas automatizar a coisa errada não economiza — acelera o desperdício. Um robô que faz um trabalho inútil só faz o inútil mais rápido, e com mais confiança.
Automatizar um processo ruim é acelerar o erro
Quando você coloca automação em cima de um fluxo quebrado, cristaliza o defeito. O que antes era um problema que uma pessoa poderia perceber e corrigir no meio do caminho vira uma engrenagem que roda sozinha, replicando o erro em escala. E fica mais difícil de mudar depois: ninguém quer mexer no robô que "já está funcionando". A automação não conserta o processo — ela o congela.
dos projetos iniciais de RPA falham, estima a EY. E a Deloitte foi além: apenas 3% das organizações conseguiram escalar a automação — muitas travam entre 3 e 5 automações por falta de dono depois que o robô entra no ar.
Fontes: EY; Deloitte (Global RPA Survey)A pergunta que vem antes da ferramenta
Antes de perguntar "como automatizo esse passo?", pergunte "esse passo precisa existir?". Boa parte do trabalho repetitivo em uma operação não deveria ser automatizado — deveria ser eliminado. A aprovação que ninguém lê, o relatório que ninguém abre, a conferência que existe porque um erro aconteceu há cinco anos. Automatizar isso é investir para manter vivo o que já deveria ter morrido.
O teste de volume × valor
Nem toda tarefa manual merece automação. O que merece tende a estar num quadrante específico: alto volume e baixo valor de julgamento. Lançar centenas de notas idênticas, mover dados entre dois sistemas, gerar o mesmo relatório toda segunda-feira — repetitivo, previsível, sem decisão humana no meio. Já uma tarefa de baixo volume ou que exige julgamento raramente compensa o custo de automatizar (e manter) a automação.
- Alto volume + baixo julgamento → automatize.
- Baixo volume → geralmente não compensa; padronize antes.
- Exige julgamento ou exceção constante → mantenha a pessoa, apoie com dado.
Automação frágil × automação que se sustenta
Existe a automação que funciona na demo e quebra na primeira exceção — e existe a que se sustenta. A diferença está no que ninguém mostra no vídeo de vendas: monitoramento, tratamento de erro, governança, e alguém responsável quando algo foge do script. Automação sem isso não é economia; é uma dívida técnica que cobra juros no pior momento possível.
Processo antes de ferramenta
O princípio é simples e quase sempre ignorado: entender e desenhar o processo certo vem antes de automatizá-lo. Diagnóstico primeiro, ferramenta depois. Quando essa ordem é respeitada, a automação entrega o que promete — libera pessoas para o que exige gente de verdade. Quando é invertida, ela vira um monumento caro a um problema que ninguém parou para resolver.
Automação boa não é a que faz mais. É a que faz o certo, de forma que se sustenta.
Automation has become a synonym for progress. Every company wants to "automate," as if the word alone guaranteed savings. But automating the wrong thing doesn't save — it speeds up the waste. A bot doing useless work just does the useless faster, and with more confidence.
Automating a bad process speeds up the error
When you put automation on top of a broken flow, you crystallize the defect. What was once a problem a person might catch and fix mid-way becomes a gear that runs on its own, replicating the error at scale. And it gets harder to change afterward: nobody wants to touch the bot that's "already working." Automation doesn't fix the process — it freezes it.
of initial RPA projects fail, EY estimates. And Deloitte went further: only 3% of organizations managed to scale automation — many stall at 3 to 5 bots for lack of ownership once the robot goes live.
Sources: EY; Deloitte (Global RPA Survey)The question that comes before the tool
Before asking "how do I automate this step?", ask "does this step need to exist?". Much of the repetitive work in an operation shouldn't be automated — it should be eliminated. The approval nobody reads, the report nobody opens, the check that exists because of an error five years ago. Automating that is investing to keep alive what should already be dead.
The volume × value test
Not every manual task deserves automation. What does tends to sit in a specific quadrant: high volume and low judgment value. Entering hundreds of identical invoices, moving data between two systems, generating the same report every Monday — repetitive, predictable, no human decision in the middle. A low-volume task, or one requiring judgment, rarely justifies the cost of building (and maintaining) the automation.
- High volume + low judgment → automate.
- Low volume → usually not worth it; standardize first.
- Constant judgment or exceptions → keep the person, support with data.
Fragile automation × automation that lasts
There's the automation that works in the demo and breaks on the first exception — and the one that lasts. The difference lies in what no sales video shows: monitoring, error handling, governance, and someone accountable when something goes off-script. Automation without that isn't savings; it's technical debt that charges interest at the worst possible moment.
Process before tool
The principle is simple and almost always ignored: understanding and designing the right process comes before automating it. Diagnosis first, tool later. When that order is respected, automation delivers what it promises — freeing people for what really needs people. When it's reversed, it becomes an expensive monument to a problem no one stopped to solve.
Good automation isn't the one that does more. It's the one that does the right thing, in a way that lasts.