Automação sem dono é risco operacional, não ganho de produtividade

A maior parte das automações que rodam hoje em empresas brasileiras não nasceu de um projeto de software. Nasceu de alguém cansado de copiar dados entre sistemas. Um analista de faturamento cria uma macro para limpar a planilha de pedidos, o time de compras monta um script que consulta o portal do fornecedor, o RH agenda um fluxo que dispara e-mails de admissão. Cada iniciativa resolve um problema concreto e costuma funcionar bem por meses.

O problema aparece quando a regra de negócio muda, quando a pessoa que criou a automação sai da empresa ou quando o sistema de origem altera o layout do arquivo. A rotina continua executando, mas executa a regra antiga. Ninguém é avisado, porque nunca houve alerta de falha, e o erro só é percebido na conciliação contábil, na reclamação do cliente ou na nota fiscal rejeitada. Aí o custo deixa de ser técnico e vira financeiro.

Para quem decide, a pergunta útil não é quantas automações a empresa tem, e sim quais delas tocam processos críticos e quem responde por cada uma. Sem essa resposta, uma troca de ERP, uma auditoria ou uma revisão de contrato de fornecedor se transforma em arqueologia.

O inventário mínimo de cada automação

Antes de discutir ferramenta, é preciso um registro simples, mantido em repositório versionado (não em uma planilha na pasta compartilhada de alguém). Cada automação em produção deveria responder:

  1. Qual processo de negócio ela cobre e qual regra aplica.
  2. Quem é o dono de negócio (a área que responde pela regra) e quem é o responsável técnico pela manutenção.
  3. Quais sistemas ela lê e escreve, incluindo credenciais e permissões usadas.
  4. Como é disparada (agendamento, evento, ação humana) e com que frequência roda.
  5. O que acontece em caso de erro: para onde vai o alerta, existe reprocessamento, a execução é idempotente.
  6. Onde ficam os logs e por quanto tempo são retidos.
  7. Como ela é desligada sem deixar dados pela metade.

Esse inventário não é burocracia. É o que permite reagir rápido quando algo quebra.

Exemplo: a distribuidora e o script do analista que saiu

Uma distribuidora de médio porte recebia pedidos de representantes em arquivos de texto e tinha um script, escrito por um analista de TI, que convertia esses arquivos para o formato aceito pelo ERP. O script rodava em uma máquina do setor comercial, sem monitoramento. Quando a política de descontos mudou, o analista já havia saído e a regra nova foi aplicada apenas no ERP. O script continuou convertendo os pedidos com a faixa de desconto antiga, e a divergência só apareceu na conciliação contábil do mês seguinte. O resultado foi retrabalho de faturamento, notas corrigidas e tempo do time comercial gasto em negociação com clientes, tudo por causa de uma rotina curta que ninguém sabia que existia.

Na prática

Para quem mantém automação em produção, alguns cuidados separam uma rotina confiável de uma bomba-relógio:

  • Nomeie um dono para cada automação e registre isso no inventário. Automação sem dono é automação sem manutenção.
  • Faça a falha ser visível: alerta em canal monitorado, não apenas log em arquivo local.
  • Torne a execução idempotente, para que reprocessar o mesmo lote não duplique pedidos, notas ou lançamentos.
  • Versione o código e as regras junto com o restante do software da empresa, com revisão antes de publicar.
  • Trate as regras de negócio como configuração explícita, não como número fixo escondido no meio do script.
  • Defina como desligar a automação e o que fazer com os dados em trânsito.
  • Revise as automações críticas a cada mudança de regra, de sistema ou de fornecedor, e depois de qualquer saída de pessoa-chave.

Automação é software. Software em produção precisa de dono, de observabilidade e de manutenção. Quando a empresa trata automação como iniciativa individual e não como ativo, ela troca trabalho manual por um risco que não consegue medir.