Automação que sobrevive a refactor — não RPA frágil

O problema que vemos no mercado

Toda empresa que cresceu além de uma certa receita carrega um cemitério de automações. Aquele macro de Excel que ninguém entende mais. O Zapier de 18 passos que cobra 700 dólares por mês e quebra silenciosamente quando o ERP muda formato de data. O bot RPA que clicava na tela do sistema antigo e parou de funcionar no dia que TI atualizou o navegador. O Python script numa máquina embaixo da mesa de alguém que saiu da empresa há dois anos.

Cada um desses foi uma vitória pequena na época. O problema é que automação sem governança vira passivo técnico. Quando a quinta automação quebra no mesmo trimestre e ninguém sabe porque, a operação volta a ser manual — só que pior, porque agora o processo nem está documentado direito. O time perde a confiança em automatizar e cada novo projeto é vendido contra o histórico de cinco que falharam.

A segunda armadilha é tentar automatizar antes de estabilizar o processo. Automatizar caos não economiza tempo — multiplica caos por velocidade. Se o processo manual tem cinco caminhos diferentes que dependem da intuição de quem executa, automatizar significa formalizar essa ambiguidade em código, e depois manter o código junto com toda a exceção que ninguém previu.

Como entregamos

Antes de tocar em automação, mapeamos o processo. Uma a duas sessões de 90 minutos com quem executa hoje — não com quem descreve em PowerPoint, com quem realmente faz. Documentamos os passos, identificamos onde tem exceção, mensuramos volume e tempo. Saímos da sessão com um diagrama enxuto e três perguntas respondidas: o processo é estável o suficiente pra automatizar; o ROI cobre o esforço de build e manutenção; e qual o caminho mínimo que entrega valor sem cobrir 100% dos casos de uma vez.

Build acontece em camadas, com a stack escolhida por adequação ao caso. Para orquestração visual com IT no time, n8n self-hosted resolve bem: workflows versionáveis em JSON, hooks customizados em código quando o nó pronto não cobre, e custo previsível em VPS pequena. Para fluxos críticos com retry, timeout e compensação (sagas), Temporal é o que usamos — vale a curva de aprendizado quando o custo de uma falha silenciosa é alto (financeiro, fiscal, compliance). Para fluxos simples e específicos, código direto em Node.js ou Python com BullMQ + Redis como fila e cron como gatilho — sem framework, sem SaaS, só o que precisa.

Em cima dessa stack, princípios fixos. Idempotência: rodar duas vezes a mesma operação não deve duplicar o efeito (nada de criar dois pedidos no ERP por causa de retry). Observability: cada execução tem trace, cada passo tem timing, cada erro tem stack — sem isso, debug em produção é arqueologia. Versionamento: workflows e código viram commit em git, não "export do n8n" perdido no email. Rollback explícito: cada workflow tem um caminho de reversão quando algo dá errado em produção.

Stack que usamos em produção hoje

Orquestradores: n8n self-hosted é o default visual quando o cliente tem time IT que vai operar; Temporal entra quando saga distribuída e durabilidade são requisito (transações que cruzam três sistemas, com compensação). Apache Airflow só quando o cliente já está no ecossistema dele — caso contrário a operação é overkill pra automação típica de PME-grande.

Código e filas: Node.js com TypeScript ou Python, dependendo do que já está estabelecido no cliente. BullMQ + Redis pra fila de jobs (rate limit, retry com backoff exponencial, prioridade); Postgres pra histórico e lock distribuído. Cron via systemd ou Coolify-scheduled-task — sem dependência de SaaS pra gatilho.

Integrações: webhooks idempotentes (sempre com chave de idempotência verificada em Postgres), polling com ETag/Last-Modified quando a contraparte não suporta webhook, SFTP/EDI quando o sistema legado é dos anos 2000 (acontece com frequência). APIs internas do cliente são abstraídas em adapters tipados — quando o ERP muda, o adapter quebra explicitamente em build, não silenciosamente em produção.

Deploy: Coolify quando o cliente está nessa stack; Kubernetes (EKS, GKE) quando o cliente já opera nesse ambiente; VPS Ubuntu com docker-compose pra projetos menores. Sem Vercel/Lambda pra workflows longos — limite de 5-15 minutos por invocação não é compatível com automação de batch.

O que vai (e o que não vai) entregar valor

Onde automação entrega ROI rápido: processos com alto volume e baixa variância (mais de 50 execuções/dia, mais de 80% dos casos seguem o mesmo caminho), processos onde erro manual é caro (reconciliação financeira, lançamento fiscal, integração entre ERP e e-commerce), e fluxos que cruzam sistemas mas o usuário humano hoje é só o copiador entre telas.

Onde automação não vale a pena (e sugerimos não fazer): processos que rodam menos de 10 vezes por semana — o custo de build + manutenção não paga; processos onde cada execução tem variação significativa e exige julgamento — automatizar significa engessar erro; processos onde o sistema de origem ou destino tem atualizações frequentes e quebradoras (alguns ERPs legados são assim) — o custo de manutenção vai engolir o ganho.

A regra que usamos: ROI deve ser visível no primeiro trimestre pós-go-live. Se o cálculo só fecha em 18 meses considerando crescimento futuro, não fechamos o projeto — porque até lá o processo provavelmente mudou.

Propriedade · tudo no seu nome

Os workflows viram código versionado no seu repositório, com runbooks e documentação navegável. Nada de export perdido em SaaS de terceiro: a automação é um ativo seu, auditável e transferível — não uma caixa-preta de fornecedor.

Próximo passo

O diagnóstico de automação é uma conversa de 30 minutos onde escolhemos um processo específico que está dando dor e respondemos três perguntas: tem ROI claro, tem maturidade de processo pra automatizar, e qual o caminho mínimo até a primeira automação rodando em produção. Sem proposta de plataforma genérica, sem demo de ferramenta — só diagnóstico do processo do cliente.

Veja também

• sistemas sob medida quando automação não basta
• APIs e integrações por trás dos workflows