Do diagnóstico à produção: como funciona um projeto de automação empresarial com a Broccolli

Um projeto de automação empresarial não começa numa ferramenta. Começa numa pergunta simples: onde é que a equipa está a perder tempo, e quanto custa esse tempo?

Este artigo descreve, fase a fase, o que acontece entre a primeira conversa com a Broccolli e o momento em que um fluxo automático corre sozinho em produção. Inclui o que entregamos em cada etapa, o que pedimos do lado da empresa e o que um projeto destes não resolve.

Antes de tudo: 30 minutos para perceber se faz sentido

A primeira conversa é uma call de 30 minutos, sem custo. Não é uma apresentação comercial.

O objetivo é olhar para o maior problema operacional da empresa e responder com honestidade a duas perguntas: conseguimos resolver isto? E quanto tempo demora?

Às vezes a resposta é "não precisa de nós". Um processo que corre dez vezes por mês raramente justifica automação. Um problema que é de organização, e não de tecnologia, também não.

Fase 1: diagnóstico antes de automatizar

A regra que seguimos é a mesma de um médico: diagnosticar antes de receitar.

No diagnóstico mapeamos o processo tal como ele acontece hoje, e não como está no manual. Quem faz cada passo, em que sistema, com que dados, e onde é que as coisas ficam paradas à espera de alguém.

Deste mapa saem três listas, por esta ordem:

1. O que eliminar. Passos que já ninguém usa, aprovações duplicadas, relatórios que ninguém lê.
2. O que simplificar. Regras confusas, exceções que viraram norma, dados introduzidos duas vezes.
3. Só depois, o que automatizar.

Automatizar um processo mal desenhado só faz o erro acontecer mais depressa. Se quiser preparar este trabalho internamente, explicámos como mapear processos antes de começar um projeto de automação, com o nível de detalhe que realmente é útil.

O diagnóstico também mede o ponto de partida: volume mensal, minutos por execução, taxa de erro. Sem estes números não há forma de provar, três meses depois, que o projeto valeu a pena. O método para chegar a um valor em euros está no artigo sobre quanto custa manter processos manuais.

Fase 2: priorização, porque não se automatiza tudo

O diagnóstico costuma revelar mais candidatos do que faz sentido atacar de uma vez. A priorização escolhe o primeiro.

O critério combina impacto e risco. Impacto é tempo e erros evitados. Risco é a complexidade técnica, a qualidade dos dados e o que acontece se o fluxo falhar.

Um exemplo ilustrativo, com números redondos para mostrar o cálculo (não é um caso real nem um resultado garantido):

• Uma distribuidora recebe 600 faturas de fornecedores por mês.
• Cada uma demora 6 minutos a registar no ERP: abrir o PDF, copiar dados, conferir com a encomenda.
• São 60 horas por mês só neste passo.

Suponha que a automação trata sozinha 70% das faturas e que as restantes 30% seguem para revisão humana, como hoje. Somando meio minuto de verificação por fatura automática, o trabalho desce para cerca de 21 horas por mês.

A poupança estimada é de perto de 39 horas mensais. Mas repare no pressuposto: os 70%. Esse número não se promete, confirma-se. É para isso que serve a fase seguinte.

Fase 3: implementação em sprints de duas semanas

Não fazemos projetos de seis meses com uma entrega no fim. Trabalhamos em sprints de duas semanas, e cada sprint termina com algo que funciona e que a equipa pode ver.

O primeiro sprint é, na prática, um piloto. Corre com dados reais, num âmbito limitado: um fornecedor, uma equipa, um tipo de documento. É aqui que o pressuposto dos 70% passa a ser uma taxa medida. Detalhámos a lógica no artigo sobre como criar um piloto de automação que demonstre valor antes de escalar.

As ferramentas dependem do que a empresa já usa. Numa empresa assente em Microsoft 365, o Power Automate é muitas vezes a escolha natural. Quando há muitos sistemas diferentes, ou dados que não devem sair da infraestrutura da empresa, o n8n em servidor próprio costuma encaixar melhor. Quando o passo exige ler documentos ou interpretar texto livre, entra uma camada de IA, sempre com supervisão humana nos casos duvidosos.

Uma regra que não negociamos: nunca se desenvolve diretamente sobre o ambiente que a empresa usa no dia a dia. A própria Microsoft recomenda, no seu guia de estratégia de ambientes para o Power Platform, ambientes separados de desenvolvimento e produção, e pelo menos um ambiente de teste entre os dois.

A passagem a produção: o que muda

Um fluxo que funciona no teste ainda não está pronto. Ir para produção significa responder a outra pergunta: o que acontece quando falha?

E vai falhar. Um fornecedor muda o formato do PDF, uma API fica indisponível durante uma hora, uma password expira. Por isso, antes de ligar o fluxo a sério, garantimos quatro coisas:

• Alertas de erro. No n8n, cada fluxo pode ter um fluxo de erro associado, que arranca sempre que uma execução falha e avisa alguém por email ou Slack. Um erro silencioso é o pior cenário possível.
• Um responsável do lado da empresa. Alguém que recebe esses alertas e sabe o que fazer com eles.
• Credenciais da empresa, não nossas. As contas e acessos ficam em nome do cliente. Se a relação terminar, os fluxos continuam a funcionar.
• Documentação curta. O que o fluxo faz, de onde lê, onde escreve e como se desliga em caso de emergência.

Durante as primeiras semanas, os casos que a automação não consegue tratar com confiança seguem para uma pessoa. É preferível rever um pouco a mais no início do que descobrir um erro no fecho do mês.

Fase 4: otimização, medida contra o ponto de partida

Um projeto de automação empresarial não acaba quando o fluxo entra em produção. É aí que começa a medição.

Os números do diagnóstico voltam a ser recolhidos: horas por mês, taxa de erro, percentagem de casos tratados sem intervenção. O objetivo que fixamos é ter retorno mensurável em 90 dias.

Com dados reais, ajustam-se as regras. Casos que iam sempre para revisão podem passar a ser automáticos. Outros, que pareciam simples, podem precisar de voltar a ter uma pessoa no circuito. Só depois de o primeiro processo estar estável se passa ao seguinte da lista de prioridades.

O que este processo não resolve

Convém dizer com clareza o que um projeto destes não faz.

Não compensa dados de má qualidade. Se o ERP tem fornecedores duplicados, a automação vai registar faturas nos fornecedores errados com toda a eficiência.

Não substitui decisões de gestão. Se ninguém na empresa tem autoridade para mudar uma aprovação redundante, o diagnóstico identifica-a, mas não a elimina.

E tem custos recorrentes. Algumas funcionalidades de gestão têm preço próprio: no n8n, por exemplo, o controlo de versões com ambientes separados só está disponível nos planos Business e Enterprise. Isto entra na conta desde o diagnóstico, não aparece como surpresa depois.

Por onde começar

Se tivesse de escolher hoje um único processo para passar por estas quatro fases, qual seria? E sabe quantas horas por mês ele consome?

Se a resposta à segunda pergunta for "não sei", o primeiro passo de qualquer projeto de automação empresarial já está identificado: medir.