Erros que fazem um projeto de automação falhar

Projetos de automação falham por motivos previsíveis, e quase nenhum deles é técnico. A ferramenta funciona, a integração sobe, o fluxo roda em homologação, e ainda assim seis meses depois a equipe continua fazendo à mão o que foi automatizado. O padrão se repete tanto que dá para listar as causas antes de conhecer o caso.

Este texto descreve os sete erros que aparecem na maioria dos projetos que não entregam, os sinais que antecedem cada um e o que fazer quando o sinal aparece. A tese é que a automação raramente morre na implantação: ela morre no desenho, semanas antes de alguém escrever a primeira regra.

O que falha quase nunca é a tecnologia

Quando um projeto de automação é revisto depois de fracassar, a conclusão costuma ser a mesma: a ferramenta fazia o que prometia. O que não existia era acordo sobre qual problema estava sendo resolvido, quem responderia pelo resultado e o que aconteceria com os casos que não se encaixassem na regra.

Isso importa porque muda onde vale gastar atenção. Trocar a ferramenta depois de um projeto frustrado é o reflexo mais comum e o mais caro, porque repete o desenho que falhou com um fornecedor novo. O mesmo raciocínio vale para projetos de inteligência artificial, e pelos mesmos motivos, descritos em por que a IA falha nas empresas.

Automatizar o processo errado

O primeiro erro acontece antes de qualquer escolha técnica: escolher o processo pelo incômodo que ele causa, e não pelo volume que ele consome. São coisas diferentes, e a intuição confunde as duas com frequência.

O processo que mais irrita costuma ser o mais visível: acontece na frente de todo mundo, gera reclamação e tem um responsável que pede socorro. O processo que mais custa costuma ser silencioso, distribuído entre várias pessoas em pedaços pequenos, e ninguém reclama dele porque ninguém sente o total.

O critério que resolve é numérico. Multiplique frequência por tempo médio por custo da hora envolvida, e o ranking muda quase sempre. A conta está detalhada em o custo dos processos manuais, e os quatro atributos que fazem um processo bom candidato estão em o que é automação de processos.

Automatizar a bagunça em vez de arrumá-la

Automatizar um processo ruim produz um processo ruim mais rápido, e com uma agravante: ele fica permanente. Regra escrita em sistema é muito mais difícil de mudar do que hábito de equipe, e o que era um acidente de organização vira arquitetura.

O caso típico é a conferência dupla. Alguém confere, outra pessoa confere de novo, e ninguém sabe por quê. Quase sempre a resposta é um erro isolado que aconteceu anos atrás. Automatizar as duas conferências é preservar o medo daquele erro para sempre; a decisão correta é remover uma, e só então automatizar a outra.

Por isso o mapeamento vem antes, e não é burocracia: o objetivo dele é encontrar as etapas que só existem por inércia. O método está em como mapear um processo. Um bom mapeamento costuma eliminar de 20% a 30% das etapas antes de qualquer automação, e essa é a parte mais barata do ganho.

O escopo que cresce até não caber

O segundo erro mais comum é de tamanho. O projeto começa em uma etapa, alguém lembra que faz sentido incluir a etapa anterior, o financeiro pede para contemplar o caso dele, e três meses depois o escopo é o ciclo inteiro em todas as áreas.

Projeto grande de automação falha por uma razão estrutural: ele adia o primeiro resultado para além da paciência da empresa. Sem entrega parcial, não há prova, e sem prova o patrocínio esfria no primeiro trimestre difícil. O escopo cresce exatamente porque ninguém viu nada funcionando ainda.

O antídoto é o mesmo de produto digital: recortar a menor fatia que resolve um problema inteiro para alguém. O critério de recorte está em como definir o escopo de um produto digital, e vale igual aqui. Uma etapa em produção rendendo resultado sustenta o projeto melhor que um plano completo em apresentação.

A exceção que ninguém mapeou

Todo processo tem casos fora do padrão, e a proporção deles é sistematicamente subestimada. Perguntar à equipe quantos por cento dos casos são exceção produz respostas na faixa de 5%; medir produz respostas na faixa de 20% a 30%.

A diferença não é má vontade: é que a exceção é absorvida como parte do trabalho e não fica registrada em lugar nenhum. Quando a automação entra e ela aparece, a reação errada é tentar cobrir cada caso com uma regra nova, o que multiplica a complexidade e torna o sistema impossível de manter.

• O sistema precisa reconhecer a exceção, não resolvê-la. A função dele é identificar que o caso saiu do padrão e parar.
• A exceção precisa ter caminho, com uma fila visível e uma pessoa responsável, e não voltar a ser trabalho invisível.
• A taxa de exceção precisa ser medida, porque ela é o melhor indicador de saúde da automação: subindo, o desenho envelheceu.

Cobrir de 70% a 80% dos casos com regra simples e tratar o resto por pessoa é o desenho que sobrevive. Tentar cobrir 100% é o desenho que ninguém consegue manter dois anos depois.

O processo sem dono

Automação atravessa áreas por natureza, e é aí que ela perde o dono. A regra do rateio é do financeiro, o cadastro é do comercial, o sistema é de TI, e quando a regra precisa mudar, as três áreas concordam que alguém deveria cuidar disso.

O sintoma aparece com clareza no primeiro pedido de alteração: ele fica semanas sem resposta, alguém resolve o caso à mão, e o contorno manual vira o novo procedimento. A partir daí a automação passa a ser aquilo que se usa quando dá, que é o começo do fim.

O que resolve não é comitê: é uma pessoa nomeada, com autoridade para mudar a regra e obrigação de reportar a taxa de exceção. Sem esse nome definido antes da implantação, o projeto tem prazo de validade, e ele costuma ser o da primeira mudança relevante no negócio.

Medir o que é fácil em vez do que importa

A maioria dos projetos mede execução, não resultado: quantos fluxos subiram, quantas tarefas rodaram, quantos minutos foram economizados. Nenhum desses números responde à pergunta que a diretoria faz, que é o que mudou na operação.

Minutos economizados espalhados por muita gente não viram nada sozinhos. Para virar resultado, o tempo liberado precisa ser consolidado e redirecionado por decisão explícita: mais volume no mesmo time, prazo menor, ou crescimento absorvido sem contratar. Esse é o raciocínio de escalar operações sem aumentar equipe.

Há ainda o erro de não registrar a linha de base. Sem o número de antes, medido e não estimado, a comparação vira memória, e memória sempre favorece a decisão que já foi tomada. Duas semanas de observação antes do piloto resolvem isso e custam uma tarde de trabalho.

Os sinais que aparecem antes da falha

1. Ninguém sabe dizer o número de antes. Se a linha de base não existe, o projeto já não tem como provar nada.
2. O escopo cresceu duas vezes sem nada em produção. Sinal de que a primeira entrega foi adiada para além do patrocínio.
3. A taxa de exceção não é medida. Quando ninguém sabe informá-la, ela está sendo tratada fora do sistema.
4. O pedido de mudança leva mais de duas semanas. Indica processo sem dono, e é o sinal que antecede o contorno manual.
5. A equipe mantém a planilha paralela. É o veredito mais honesto disponível: quem opera não confia no resultado.
6. O piloto está no terceiro mês de piloto. Piloto que não vira operação é piloto que já falhou, e ninguém quis declarar.

Os seis são observáveis sem auditoria e sem reunião extra. Qualquer um deles isolado é corrigível em semanas; três ao mesmo tempo indicam que o problema é o desenho, e a correção passa por refazer o recorte, não por ajustar a ferramenta.

Por onde seguir

O desenho completo, do critério de escolha à implantação por etapas, está em automação de processos empresariais. Quando a causa raiz for sistema que não conversa com sistema, e não processo mal desenhado, o caminho é integração de sistemas, e quando não houver API do outro lado, RPA e automação de processos descreve a saída e os limites dela. Para decidir qual processo entra primeiro, o critério está em o que é automação de processos e a conta em o custo dos processos manuais. E quando a revisão mostrar que o problema não é o processo, mas o sistema que o sustenta, a decisão de substituir tem critério próprio em quando trocar o sistema legado.

Perguntas frequentes