Como mapear processos antes de começar um projeto de automação

Mapear processos é a etapa que mais projetos de automação saltam, e a que mais os faz descarrilar. A pressão para saltar é compreensível: toda a gente na empresa já sabe qual é o processo lento, a ferramenta já foi escolhida, e parar duas semanas a desenhar caixas e setas parece tempo tirado ao trabalho a sério.

O problema é que uma automação faz exatamente aquilo que lhe for descrito. Se a descrição estiver incompleta, o resultado não é um processo mais rápido. É um processo errado a correr mais depressa, e com menos gente a olhar para ele.

Três pessoas, cinco versões do mesmo processo

Peça a três colegas que descrevam como funciona a aprovação de despesas na empresa. Vai receber três respostas diferentes, e provavelmente nenhuma delas descreve o que acontece na prática. A Celonis, que vive de reconstruir processos a partir dos registos deixados nos sistemas, resume o problema na sua análise sobre descoberta de processos: se perguntar a três pessoas como funciona um processo, recebe cinco respostas diferentes.

Não é má-fé nem desatenção. Cada pessoa conhece bem o troço em que trabalha, mais um bocado antes e um bocado depois. Ninguém tem o processo inteiro na cabeça — e o processo inteiro é precisamente aquilo que a automação vai executar.

Mapear é o exercício de juntar esses troços num só desenho e confrontar as versões umas com as outras. Metade do valor aparece logo na sala, quando duas pessoas descobrem que fazem a mesma verificação em duplicado, ou que ninguém faz uma verificação que ambas julgavam estar a cargo da outra.

O que um mapa tem mesmo de conter

Um mapa útil para automação não é um fluxograma bonito. É a resposta a cinco perguntas, passo a passo:

• O que dispara o processo? Um e-mail, um formulário submetido, uma hora do dia, uma linha nova numa folha de cálculo. Se não conseguir nomear o gatilho com precisão, não há automação possível.
• Quem faz, e em que sistema? O nome do papel e o nome da aplicação. "O comercial confirma no CRM" serve. "É validado" não serve para nada.
• Que dados entram e saem? Campos concretos: NIF, referência da encomenda, data de entrega prevista. É esta lista que determina se dois sistemas conseguem falar um com o outro.
• Onde é que há uma decisão? Todas as bifurcações, com o critério explícito. "Acima de 5.000 €, precisa de aprovação da direção."
• Quanto demora e com que frequência acontece? Sem estes dois números não há forma de priorizar, nem de provar mais tarde que valeu a pena.

Repare que nada disto exige software. Uma folha com estas cinco colunas, preenchida numa reunião de duas horas com quem executa o processo, já é melhor mapa do que a maioria dos documentos que as empresas guardam em PDF.

As exceções são o mapa a sério

Quando se pede a uma equipa que descreva um processo, o que sai é o caminho feliz: a sequência que acontece quando tudo corre bem. É o caminho que toda a gente consegue descrever de cor, e normalmente é também o que menos trabalho dá.

O custo está no resto. Em processos reais, uma minoria dos casos gera a maioria das variantes, e são essas variantes que consomem o tempo das pessoas, porque cada uma obriga alguém a parar e a pensar.

Um exemplo, com números ilustrativos e o cálculo à vista. Uma empresa de 30 pessoas recebe 60 pedidos de proposta por mês. No caminho feliz, cada pedido leva cerca de 12 minutos: ler o e-mail, verificar o histórico do cliente no CRM, preencher o modelo, enviar. São 12 horas por mês.

Só que cerca de um em cada cinco pedidos envolve um produto configurável e obriga a uma ida à produção para confirmar prazos. Esse desvio acrescenta uns 35 minutos ao pedido. Doze pedidos vezes 35 minutos dão mais sete horas. O processo real custa perto de 19 horas por mês, não 12.

Se automatizar apenas o caminho feliz, resolve 12 das 19 horas. E as sete horas restantes ficam piores do que estavam: deixam de ter um percurso reconhecido, passam a ser tratadas caso a caso, sem registo e sem responsável claro.

O mapa é o que permite fazer esta conta antes de gastar o orçamento, e não depois. É o mesmo raciocínio que aplicámos ao calcular quanto custa manter processos manuais, só que passo a passo, em vez de tratar o processo como um bloco único.

Que notação usar, e quando chega uma tabela

Para a maioria das PME, a tabela das cinco colunas mais um diagrama de pistas — uma linha por departamento — resolvem o problema. A força das pistas é tornar as passagens de testemunho visíveis: é entre pistas que o trabalho fica parado, à espera que alguém repare.

Quando o processo atravessa vários sistemas e vai ser implementado por quem não esteve na sala, vale a pena subir para BPMN, a notação mantida pela Object Management Group e hoje o padrão de facto para diagramas de processos de negócio. O BPMN distingue coisas que mudam mesmo a implementação: um evento temporal não é um evento de mensagem, e uma decisão exclusiva não é uma bifurcação paralela.

Um aviso sobre BPMN: a especificação completa tem mais de uma centena de elementos e quase ninguém precisa deles. Cinco ou seis símbolos — início, tarefa, decisão, fim e evento de erro — cobrem praticamente tudo o que uma PME vai automatizar no primeiro ano.

O mapa também serve para dizer que não

Nem todo o processo mapeado deve ser automatizado. O valor do mapa está em permitir tomar essa decisão com argumentos, em vez de com entusiasmo.

Três sinais de que é melhor parar:

• O processo muda de trimestre para trimestre. Automatizar uma regra instável é comprar manutenção permanente.
• Volume baixo e variabilidade alta. Quinze casos por mês, todos diferentes, raramente pagam o fluxo que os trataria.
• O mapa revelou passos que não deviam existir. Aqui a resposta é eliminar, não automatizar. Um passo removido custa zero a manter.

Este último ponto é o mais frequente e o mais desaproveitado. Muitas vezes o maior ganho de um exercício de mapeamento não é a automação que vem a seguir. É o campo que ninguém lê há dois anos e que deixa de ser preenchido.

Do mapa ao fluxo

Um mapa bem feito converte-se quase diretamente em implementação. Os gatilhos tornam-se nós de arranque, as decisões tornam-se ramos condicionais e os sistemas nomeados tornam-se ligações — o catálogo oficial do n8n lista atualmente mais de duas mil integrações, pelo que a pergunta raramente é "consegue ligar-se?".

O que o mapa dá e a intuição não dá são as exceções. Cada ramo de erro identificado no papel corresponde a um comportamento que alguém vai ter de decidir no fluxo: repetir, seguir em frente, ou parar e avisar uma pessoa. A documentação do n8n sobre tratamento de erros descreve os dois níveis onde isso se define: no nó individual e no workflow inteiro, através de um fluxo de erro dedicado iniciado por um nó Error Trigger.

Sem mapa, ninguém se lembra destes ramos durante a construção. Lembram-se em produção, quando um fornecedor envia um PDF sem número de encomenda e o fluxo falha em silêncio durante três dias.

Depois do mapa vem a fase de desenho, que tem regras próprias — já escrevemos sobre como desenhar um workflow que a equipa realmente adota.

Por onde começar na próxima semana

Escolha um processo. Um só. De preferência um que aconteça pelo menos 20 vezes por mês e que envolva dois departamentos, porque é nas passagens entre equipas que o tempo se esconde.

Marque duas horas com as pessoas que o executam, não com quem o gere. Desenhe o caminho feliz em 20 minutos e gaste o resto do tempo a perguntar "e quando é que isto não acontece assim?". Registe cada resposta como um ramo separado.

No fim, some os tempos e veja que fatia do custo total está no caminho feliz e que fatia está nas exceções. Se ainda não sabe que processos são bons candidatos, a nossa lista dos 20 processos que compensa automatizar ajuda a escolher o primeiro.

A pergunta que fecha o exercício de mapear processos não é "dá para automatizar isto?". É outra, mais desconfortável: agora que vimos o processo desenhado, ainda o queremos exatamente assim?