O caminho feliz não paga a conta

Toda apresentação de automação de processos com software usa o mesmo roteiro: o caso limpo. O pedido chega completo, o cadastro está atualizado, o sistema externo responde na primeira tentativa e o fluxo termina sozinho. É esse recorte que aparece no orçamento e na demonstração para a diretoria.

Em produção, o volume que dá lucro é esse, mas o custo que aparece no mês seguinte vem do resto. Um fluxo automatizado não elimina trabalho: ele desloca o trabalho para as bordas, onde o dado chega torto, o sistema parceiro cai ou a regra de negócio não cobre o caso. Se essas bordas não foram desenhadas, a automação não reduz esforço, apenas muda quem sofre com ele.

As exceções que todo fluxo carrega

Antes de escrever a primeira linha de código, vale enumerar o que pode sair do trilho. Na prática, quase tudo cai em quatro grupos:

  1. Entrada incompleta ou inválida: cadastro sem dados obrigatórios, produto sem classificação fiscal, arquivo com layout diferente do combinado.
  2. Dependência externa indisponível: ERP em manutenção, API do banco com timeout, gateway retornando erro intermitente.
  3. Regra de negócio ambígua: desconto acima da alçada, cliente com crédito bloqueado, exceção comercial que só o gestor aprova.
  4. Duplicidade e reentrega: o mesmo evento chega duas vezes, o retry dispara depois de um timeout que na verdade tinha funcionado.

Cada grupo exige três coisas: detecção confiável, registro com contexto suficiente para alguém decidir e um caminho de reprocessamento que possa rodar de novo sem gerar efeito duplicado. Sem os três, a exceção vira chamado para o time técnico.

Exemplo: a distribuidora e a aprovação de pedidos

Uma distribuidora de insumos automatiza a aprovação de crédito dos pedidos. O fluxo consulta o limite no ERP, aplica a política comercial e libera o pedido para faturamento. Funciona bem no caso comum.

O problema aparece quando o cliente tem título vencido em aberto ou o cadastro está desatualizado desde a última alteração societária. A automação não tem como decidir e o pedido fica parado em um status intermediário. Ninguém é notificado. O vendedor descobre quando o cliente cobra, liga para o time de TI, e alguém abre o banco de dados para entender em que etapa o fluxo travou.

O tempo do caso comum caiu, mas surgiu um gargalo novo: o suporte técnico virou central de exceções comerciais. Esse custo não estava no orçamento do projeto e não aparece em nenhum indicador de automação. Aparece na fila de chamados.

Na prática

Para quem mantém software em produção, automação de processos se sustenta em disciplina operacional:

  • Toda automação precisa de uma tela de pendências com dono de negócio definido. Se a única forma de destravar um caso é abrir chamado para TI, o desenho está errado.
  • Reprocessamento idempotente é obrigatório: use chave de idempotência por evento e registre o resultado de cada tentativa antes de permitir nova execução.
  • O log precisa carregar contexto de negócio (identificador do pedido, etapa, motivo da parada), não apenas stack trace. Quem resolve a exceção é a operação, não o desenvolvedor.
  • Meça exceções por tipo e revise toda semana. Se um tipo cresce, provavelmente a regra de negócio está incompleta, e não o código.
  • Defina o que acontece quando a pendência passa do prazo: escalonamento com nome e prazo, nunca silêncio.

Automação boa não é a que nunca falha. É a que falha de forma visível, reversível e barata de resolver.