Como automatizar processos de negócio: os 5 passos que evitam automatizar o erro
Autor: Pedro Tebaldi PM do KeepGreenAutomação não corrige processo ruim. Ela executa o processo ruim mais rápido, sem pausa para alguém perceber o problema. O defeito que antes aparecia em dez pedidos por semana passa a aparecer em mil.
Esse é o motivo pelo qual tantos projetos entregam ganho no piloto e somem no relatório do trimestre seguinte. A escolha do candidato foi feita por quem falou mais alto na reunião, não por critério, então a automação nasceu em cima de um fluxo que ainda mudava toda semana.
O caminho que funciona tem ordem. Primeiro escolher o processo certo, depois estabilizar, só então automatizar o menor recorte possível, instrumentar como serviço de produção e medir contra a linha de base. Os cinco passos abaixo detalham essa sequência, com a régua de pontuação que resolve o empate entre candidatos.
O que precisa estar verdadeiro antes de começar
Três condições separam o projeto que sobrevive do piloto que morre. A primeira é ter o processo escrito em algum lugar: quem inicia, quais decisões existem, onde ele termina.
A segunda é ter um dono no negócio, com nome. Automação sem dono vira órfã na primeira mudança de regra, porque ninguém tem a obrigação de avisar a TI que o fluxo mudou.
A terceira é a linha de base. Sem medir volume, tempo de ciclo e taxa de retrabalho antes, não existe como provar ganho depois: o projeto vira discussão de percepção. Esse trabalho preparatório é o núcleo do Business Process Management e antecede qualquer escolha de ferramenta.
Vale separar dois territórios que costumam se confundir. Automatizar tarefa de infraestrutura, deploy ou chamado é outro assunto, com outras ferramentas, tratado em automação de TI. Aqui o objeto é o processo que atravessa áreas do negócio.
Passo 1: mapeie o fluxo que existe, não o que está desenhado
O desenho oficial do processo costuma descrever a intenção. O fluxo real inclui a planilha paralela, o e-mail de aprovação fora do sistema e a ligação para desbloquear caso urgente. Automatizar o desenho oficial produz uma automação que ninguém usa.
Acompanhe três execuções reais de ponta a ponta, com quem executa, cronômetro na mão. Anote cada espera, cada troca de sistema, cada retorno para trás. Uma sessão de duas horas costuma revelar mais que um mês de reunião de levantamento.
Registre o resultado em notação padrão quando o fluxo tiver ramificação relevante. A especificação mantida pela OMG resolve a ambiguidade entre desvio, evento e tarefa manual, o que evita retrabalho na etapa de implementação. Para fluxos simples, uma lista numerada de passos com responsável já basta.
Leve para essa sessão quem executa a tarefa todo dia, não apenas o gestor da área. O gestor descreve o processo como ele deveria ser, enquanto o analista descreve o que realmente acontece quando o cliente liga cobrando.
O produto deste passo é objetivo: o mapa do fluxo real, com o tempo gasto em cada etapa e a lista de pontos onde ele para. Se você usa BPMN, o diagrama entra aqui, com as raias que mostram onde o trabalho troca de mão.
Passo 2: pontue os candidatos e escolha um
Com dois ou três fluxos mapeados, a escolha deixa de ser opinião. Pontue cada candidato de 1 a 5 nos seis critérios seguintes e some as notas. O que ganha é o primeiro da fila, não o mais visível politicamente.
- Volume: quantas execuções por mês
- Repetição: quanto do fluxo segue o mesmo caminho
- Clareza da regra: decisão objetiva ou julgamento
- Taxa de exceção: quantos desvios saem do sistema
- Acesso aos sistemas: existe API ou apenas tela
- Custo do erro: o impacto se ninguém perceber a falha
| Critério | Como medir no seu ambiente | Sinal de bom candidato |
|---|---|---|
| Volume | Execuções por mês, contadas no sistema de origem | Alto volume dilui o custo de construir. |
| Repetição | Proporção de execuções que seguem o mesmo caminho | Acima de 80% no caminho principal. |
| Clareza da regra | A decisão cabe em condição objetiva ou depende de julgamento? | Regra escrita que duas pessoas aplicam igual. |
| Taxa de exceção | Desvios tratados fora do sistema em 90 dias | Baixa. Exceção alta é critério de bloqueio, não de nota. |
| Acesso aos sistemas | Existe API ou apenas tela? |
Interface programática reduz manutenção pela metade. |
| Custo do erro | O que acontece se a automação errar sem ninguém ver? | Erro reversível e detectável no mesmo dia. |
A leitura da soma é direta. Duas faixas decidem sozinhas e a do meio pede trabalho antes.
| Soma dos seis critérios | Decisão |
|---|---|
| 24 a 30 Entra | Primeiro da fila |
| 15 a 23 Depois | Estabilize o fluxo primeiro |
| Abaixo de 15 Fora | Redesenhe o processo, não automatize |
Um alerta sobre a nota de exceção. Ela funciona como veto, não como ponto: um fluxo com taxa de exceção alta produz automação que interrompe a cada duas execuções e devolve para o humano em pior estado do que estava antes.
Guarde a planilha de pontuação com as notas justificadas. Ela responde sozinha a pergunta que sempre volta seis meses depois, quando outra área pergunta por que o processo dela não foi o primeiro da fila.
Passo 3: estabilize o processo antes de automatizar
Processo estável tem três marcas: a regra não muda a cada mês, quem executa chega ao mesmo resultado, o desvio é raro e conhecido. Sem essas três, cada mudança vira uma alteração de código e o custo de manutenção engole o ganho.
Estabilizar costuma exigir decisões chatas que ninguém quer tomar: eliminar a segunda via de aprovação, definir quem decide o caso de fronteira, padronizar o campo que cada área preenche de um jeito. É trabalho de gestão, não de tecnologia.
Esse é também o momento de tratar as causas que fazem o fluxo tropeçar, assunto detalhado em como evitar problemas em processos internos. Automatizar antes dessa faxina apenas registra a bagunça em código, com a diferença de que agora ela roda sozinha.
Critério de saída deste passo: a regra do processo cabe em uma página e sobreviveu a 30 dias sem alteração. Se ela mudou nesse período, o relógio recomeça.
Sinais de que o fluxo ainda não está pronto
Quatro sintomas indicam instabilidade que a automação vai amplificar. O primeiro é a existência de duas versões da verdade: o sistema diz uma coisa, a planilha da área diz outra. Quem executa confia na planilha.
O segundo é a etapa que depende de uma pessoa específica para destravar. O terceiro é o campo preenchido de formas diferentes conforme quem digita, o que quebra qualquer regra automática de roteamento.
O quarto é a fila de casos “especiais” que ninguém categoriza. Enquanto o especial não virar categoria com regra, ele volta como exceção na primeira semana de operação da automação.
Trate esses quatro pontos antes de escrever a primeira linha de integração. O tempo gasto aqui é menor que o tempo de corrigir a automação depois, com o processo já rodando em produção.
Passo 4: automatize o menor recorte que entrega resultado
A tentação é começar pelo fluxo inteiro, com todas as integrações e todos os casos previstos. Esse escopo produz seis meses de projeto e uma entrega que chega quando o processo já mudou.
Recorte melhor: pegue a etapa que consome mais tempo e tem regra mais clara, automatize só ela, coloque em produção em semanas. O resto do fluxo continua manual. A próxima etapa entra depois, com o aprendizado da primeira.
No projeto com a Velonet, o primeiro recorte foi o menor possível: a notificação automática do vencimento de contrato, disparada 120 dias antes, junto da abertura de chamado a partir da própria trigger de monitoramento.
Só depois vieram o inventário por descoberta de rede e os painéis de saldo de horas por cliente, consultados diretamente pelo cliente final. O relato do projeto da Velonet descreve essa sequência.
Escolha a tecnologia depois do recorte, nunca antes. Integração via API resolve a maioria dos casos com menos manutenção. Robô de tela, que é o território do RPA, entra quando o sistema de origem não oferece interface programática.
Cuidado especial com a onda atual de agentes autônomos. A tecnologia é promissora, porém a régua de seleção continua valendo: processo instável não fica estável porque um modelo passou a executá-lo.
A projeção do Gartner aponta que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, por custo crescente, valor de negócio pouco claro ou controle de risco insuficiente.
Passo 5: trate a automação como serviço de produção
No dia em que entra em produção, a automação vira mais um serviço do seu ambiente. Ela quebra quando o parceiro muda a API, quando o certificado vence, quando o layout do arquivo ganha uma coluna. A diferença perigosa é que ela quebra em silêncio.
Quatro itens tornam a falha visível. Alerta quando a execução falha ou quando o volume esperado não acontece, o que pega a automação que parou de rodar. Trilha do que foi executado, com identificador de origem. Fila de exceção com dono e prazo. Modo manual documentado para quando ela precisar ficar desligada.
A regra de ouro é a segunda: monitorar ausência, não apenas erro. Uma automação que deixa de disparar não gera exceção, gera silêncio. Esse silêncio passa despercebido por semanas, até alguém do negócio perguntar pelo relatório que nunca chegou.
O mesmo raciocínio já é padrão do lado da infraestrutura, na remediação automática de incidentes: toda ação automática precisa de registro, limite de tentativas e escalada para humano quando falha duas vezes seguidas.
Quem cuida da automação depois
Toda automação precisa de dois nomes desde o primeiro dia. O dono do processo responde pela regra de negócio e avisa quando ela mudar. O responsável técnico responde pela execução, pelo alerta e pela correção quando o fluxo quebra.
Junte a esses nomes uma página de operação curta: o que a automação faz, com que frequência roda, quais sistemas toca, o que fazer quando ela falha, como executar o processo no modo manual.
Parece burocracia até a primeira madrugada em que a automação para e o plantonista de sobreaviso nunca ouviu falar dela. Sem essa página, a alternativa é acordar quem construiu, o que só funciona enquanto essa pessoa continuar na empresa.
Reserve ainda uma janela de revisão anual. Automação antiga sobre processo que mudou é fonte silenciosa de dado errado: ninguém audita aquilo que roda sem reclamar.
Como saber se a automação deu certo
Compare com a linha de base do passo zero, nos mesmos indicadores. Tempo de ciclo do processo ponta a ponta, horas de trabalho manual por execução, taxa de erro ou retrabalho, volume processado por período.
Acrescente dois indicadores da própria automação: taxa de sucesso das execuções e proporção que caiu na fila de exceção. Automação que manda um terço das execuções para exceção não é automação, é triagem automática de trabalho manual.
Meça depois de estabilizar, entre 60 e 90 dias de operação. Medição na primeira semana captura o ajuste, não o regime, então costuma produzir um número bonito que não se repete.
Inclua o custo na conta. Horas de construção, licença da plataforma, horas de sustentação por mês: sem essas linhas, o ganho medido em horas economizadas conta apenas metade da história e some na primeira pergunta do financeiro.
Publique esses números onde o dono do processo enxerga. É o mesmo princípio da monitoração de processos de negócios: indicador que vive em relatório mensal não muda comportamento, indicador visível no painel muda.
Seus KPIs de TI e negócio visíveis para quem precisa tomar decisão.
Construímos painéis interativos que conectam métricas operacionais a indicadores de negócio em tempo real, com atualização automática.
Por onde a sua primeira automação deve começar
Escolha um processo que ninguém defende com paixão. O fluxo politicamente disputado atrai atenção antes de ter resultado, então a primeira automação deve ser discreta, de volume alto e regra simples.
Rode a sequência inteira nesse candidato: mapeie o fluxo real com quem executa, pontue nos seis critérios, estabilize o que estiver instável, automatize a etapa mais cara, instrumente com alerta de falha e de ausência.
Depois meça contra a linha de base entre 60 e 90 dias. Com número na mão, o segundo processo entra sem discussão de orçamento, porque o pedido deixa de ser promessa e passa a ser repetição de um resultado já demonstrado.
Uma última recomendação: registre por escrito o que foi automatizado, quem é o dono e o que fazer quando falhar. Automação sem essa página vira caixa-preta no dia em que a pessoa que a construiu sair da empresa.
Quer enxergar seus processos automatizados em tempo real e receber alerta quando um deles parar de rodar? Fale com um especialista da OpServices.
