Como criar um piloto de automação que demonstre valor antes de escalar

Quase todas as empresas que travam um projeto de automação travam-no no mesmo sítio: depois do piloto. A demonstração correu bem, toda a gente concordou que era impressionante, e três meses depois o fluxo continua a correr para duas pessoas enquanto o resto da operação faz tudo à mão.

Um piloto de automação que serve para alguma coisa não é uma demonstração. É uma medição.

A Gartner previu, num comunicado de julho de 2024, que pelo menos 30% dos projetos de IA generativa seriam abandonados depois da prova de conceito até ao final de 2025, e apontou como causas o valor de negócio pouco claro, a escalada de custos e a má qualidade dos dados. Nenhuma destas causas é técnica. Todas se evitam na forma como o piloto é desenhado.

O piloto não existe para provar que a tecnologia funciona

Isso já está provado. Extrair campos de um PDF, escrever num ERP, notificar alguém no Slack: nada disto está em dúvida.

O que está em dúvida é outra coisa. Se neste processo, com estes dados e com esta equipa, a automação poupa tempo suficiente para justificar o que custa mantê-la.

É essa a pergunta que o piloto responde. E só a consegue responder se for desenhado para produzir um número, não uma impressão.

A diferença nota-se no fim. Um piloto-demonstração termina com "ficou bom, vamos ver". Um piloto-medição termina com "poupou 25 horas por mês, custou quatro mil euros, paga-se em cinco meses, escalamos".

Escolher o processo: volume alto, risco baixo, dono identificado

Três critérios, por esta ordem.

Volume alto. Um processo que corre 15 vezes por mês não produz amostra suficiente em 60 dias para distinguir ganho real de sorte. Procura algo que aconteça dezenas ou centenas de vezes durante o piloto.

Risco baixo. No primeiro piloto, um erro não pode chegar ao cliente nem às finanças. Processos internos, reversíveis, com uma pessoa a validar a saída, são o terreno certo. Automatizar a emissão de notas de crédito não é um bom primeiro piloto.

Dono identificado. Uma pessoa concreta, que faz hoje aquele trabalho, que vai usar o fluxo e cujo nome fica associado ao resultado. Sem isso ninguém reporta os erros e o piloto morre em silêncio.

O processo mais visível raramente é o melhor candidato. Mapear os processos antes de começar é o que separa uma escolha informada do palpite de quem fala mais alto na reunião.

Medir o antes, antes de tocar em seja o que for

Este é o passo que quase toda a gente salta e o único que é irrecuperável.

Depois de o fluxo estar a correr, o estado anterior já não se consegue medir. Ficam estimativas de memória, do género "isto demorava aí uma manhã", que não convencem ninguém que tenha de aprovar um orçamento.

Duas semanas de baseline chegam. O que registar:

• Quantas vezes o processo corre, por semana.
• Quanto tempo demora cada execução, cronometrado e não estimado.
• Quantas vezes falha ou precisa de correção posterior.
• Quantas pessoas lhe tocam, e em que momento.
• Quanto tempo passa entre o pedido chegar e ficar resolvido.

O último é o que mais surpreende as direções. O tempo de trabalho efetivo num pedido de aprovação pode ser de quatro minutos, distribuídos por seis dias de espera. A automação raramente acelera muito os quatro minutos; o que ela elimina são os seis dias.

O método para converter estas horas em euros está detalhado no artigo sobre quanto custam os processos manuais.

O cálculo que convence quem assina

Os números seguintes são um exemplo de cálculo, não um caso de cliente. O que vale aqui é o método, não os valores.

Processo: lançamento de faturas de fornecedor.

Baseline, medido em duas semanas. 340 faturas por mês, seis minutos cada. São 34 horas por mês.

Custo dessas horas. O custo horário médio do trabalho na União Europeia foi de 34,90 euros em 2025, segundo o Eurostat. Em Portugal é bastante mais baixo, mas usemos o valor publicado em vez de inventar um. 34 horas x 34,90 euros dá 1 187 euros por mês, ou cerca de 14 200 euros por ano, só neste processo.

Depois do piloto, medido em 60 dias. As faturas com correspondência exata à encomenda passam sem intervenção. As restantes vão para uma fila de revisão. O tempo humano cai de 34 para 9 horas por mês.

Poupança. 25 horas x 34,90 euros dá 872 euros por mês.

Custo do piloto. Quatro mil euros de construção, mais 50 euros por mês de infraestrutura e manutenção.

Retorno. 4 000 a dividir por 822 euros de poupança líquida mensal dá 4,9 meses até o investimento estar pago.

Repara no que este quadro tem e no que não tem. Tem um número medido antes, um número medido depois e um custo real. Não tem "aumento de eficiência de 70%" nem "os colaboradores ficam livres para tarefas de maior valor". São estas duas frases que fazem um piloto ser arquivado.

Instrumentar o piloto para que ele se meça sozinho

Se a medição depender de alguém preencher uma folha de cálculo, deixa de acontecer à terceira semana.

Numa plataforma como o n8n, o registo vem de série. Cada execução fica guardada com o estado — sucesso, falha, em execução ou em espera — a hora de início e a duração, e a lista pode ser filtrada por qualquer um desses campos. Uma execução falhada pode ser repetida a partir dessa lista, com os dados originais ou já com o fluxo corrigido.

Vale a pena ir um passo mais longe e etiquetar cada execução com dados do negócio. Com uma linha no nó de código, do género $execution.customData.set("fornecedor", nome), a execução passa a guardar dados personalizados e a lista passa a poder ser filtrada por eles. No fim do piloto, em vez de "correu bem", tens quantas execuções houve por fornecedor e exatamente quais falharam.

Duas limitações que é melhor conhecer antes. Os dados personalizados de execução só existem nos planos Cloud Pro e Enterprise, ou em self-hosted Enterprise e Community registada, e não no plano de entrada. E apagar um workflow apaga com ele todo o histórico de execuções. O piloto que alguém apaga por arrumação leva as provas atrás.

Critérios de saída, definidos antes de começar

Um piloto sem data de fim e sem limiar de decisão transforma-se em produção acidental: o fluxo fica a correr para sempre, sem nunca ter sido aprovado nem rejeitado.

Antes do primeiro dia, fixa três coisas por escrito.

Duração. Seis a oito semanas costumam chegar num processo de alto volume. Menos do que isso e os casos raros ainda não apareceram.

Limiar. O número que decide. Por exemplo: pelo menos 70% das faturas processadas sem intervenção humana e menos de 2% de erros a chegar ao ERP.

A decisão associada a cada resultado. Acima do limiar, escala-se, com orçamento já pré-aprovado. Abaixo, corrige-se uma causa identificada ou desliga-se. As três respostas são legítimas. O que não é legítimo é chegar ao fim sem ter combinado qual delas se aplica.

Quando o piloto diz que não

Um piloto que falha e é desligado não é dinheiro perdido. É a resposta mais barata que alguma vez vais ter àquela pergunta.

Os motivos de um "não" são quase sempre os mesmos, e nenhum é da ferramenta.

O processo tem demasiadas exceções. Se 40% dos casos precisam de julgamento humano, a automação gera uma fila de revisão que custa quase tanto como o trabalho original.

Os dados de entrada não são estáveis. Fornecedores que mudam o formato da fatura todos os trimestres transformam a manutenção em trabalho permanente.

O processo estava prestes a mudar. Automatizar algo que vai ser substituído dentro de seis meses é construir em cima de areia. Este é o mais caro dos três e o mais fácil de evitar: bastava ter perguntado.

O que muda quando se escala

Um piloto bem-sucedido prova um fluxo. Não prova um programa.

Quando o mesmo padrão passa de um processo para dez, aparecem problemas que não existiam à escala de um. Quem mantém os fluxos quando sair quem os construiu. Onde ficam as credenciais. Quem é avisado quando algo falha às três da manhã. E como é que alguém dá pela falta de um fluxo que deixou de correr há duas semanas.

A altura de responder a isto é durante o piloto, não depois. As mesmas métricas que serviram para decidir passam a servir para vigiar, e isso implica escolhê-las com cuidado desde o primeiro dia, como abordámos a propósito das métricas de transformação digital que vale a pena acompanhar.

A pergunta a fazer esta semana

Não é "que processo queremos automatizar". É esta: qual é o processo de que conseguimos medir o custo atual nas próximas duas semanas, sem pedir autorização a ninguém?

Se houver resposta, o piloto tem por onde começar. Se não houver, o problema ainda não é de automação. É de medição.