Mapeamento de processos: o que fazer antes de automatizar

Existe um padrão previsível em projetos de automação que dão errado. A empresa escolhe a ferramenta, contrata, integra, treina — e seis meses depois o processo continua demorando quase o mesmo tempo, com a diferença de que agora ninguém entende direito o que acontece.

O motivo quase nunca é a ferramenta. É que automatizar não melhora um processo; ele apenas passa a acontecer mais rápido do jeito que já era. Se o jeito que era tinha três aprovações desnecessárias e uma etapa que existe desde 2019 por um motivo que ninguém lembra, você acabou de acelerar isso.

A tese em uma frase: automação é multiplicador, não conserto — e multiplicar um processo ruim entrega mais rápido o resultado ruim, com a agravante de que agora ele está escondido dentro de um fluxo que ninguém revisa.

Mapeamento de processos: desenhe o real, não o oficial

O primeiro erro é mapear o processo documentado. Ele descreve a intenção — e a intenção é sempre mais limpa do que a prática.

O processo real tem coisas que não estão em documento nenhum:

• A planilha paralela que alguém mantém porque o sistema não faz.
• A mensagem no WhatsApp que destrava a aprovação antes de o e-mail oficial chegar.
• A exceção que "quase nunca acontece" e acontece em 30% dos casos.
• A etapa que existe porque um cliente reclamou uma vez, há três anos.

A única forma de capturar isso é perguntar a quem executa, e perguntar da forma certa. "Como funciona o processo?" traz o documento. "Me conta o último caso, do começo ao fim" traz a realidade — com as gambiarras, que é justamente o que interessa.

Um sinal útil: toda gambiarra é um pedido de melhoria não atendido. Quando alguém mantém uma planilha paralela, ela está compensando uma lacuna. Automatizar o processo oficial sem resolver a lacuna faz a planilha continuar existindo, agora ao lado da automação.

Meça espera, não execução

Aqui está o diagnóstico que mais muda decisão.

Na maioria dos processos, o tempo de trabalho é de minutos e o tempo total é de dias. A diferença inteira é fila: item parado esperando aprovação, esperando informação do cliente, esperando a única pessoa que sabe fazer aquilo voltar de férias.

Isso significa que otimizar a etapa mais trabalhosa costuma render pouco. Se a proposta leva 40 minutos para ser escrita e 4 dias para ser aprovada, automatizar a escrita economiza 40 minutos num ciclo de 4 dias.

O que procurar, na ordem:

1. Onde o item para. Anote o tempo entre "ficou pronto" e "alguém pegou".
2. Quantas vezes ele volta. Retrabalho é desperdício disfarçado de trabalho.
3. Quantas pessoas tocam. Cada passagem de mão é uma fila em potencial.
4. Quantas decisões precisam de alguém específico. Dependência de pessoa é o gargalo mais comum e o menos discutido.

Cortar vem antes de acelerar

Esta é a etapa que quase todo mundo pula, e a que mais economiza dinheiro — porque etapa eliminada não precisa de ferramenta, licença nem manutenção.

Quatro perguntas para cada etapa do mapa:

• Ela existe por quê? Se ninguém souber responder, é forte candidata a sumir.
• O que acontece se ela não existir? Se a resposta for "nada de grave", experimente por um mês.
• Essa aprovação já reprovou alguma coisa? Aprovação que nunca reprova é registro, não controle — e registro o sistema faz sozinho.
• Esse dado é usado por alguém? Campo obrigatório que ninguém lê é fricção pura.

O ganho aqui é maior do que parece. É comum um processo perder de 20% a 40% das etapas nessa revisão, e boa parte do problema original desaparecer sem que nenhuma automação tenha sido contratada.

Só então automatizar

Depois de cortar, o que sobrou merece a pergunta seguinte: isso vale a pena automatizar? — que é assunto do post sobre o que não vale a pena automatizar.

Quando a resposta for sim, o caminho fica bem mais barato, porque você automatiza um processo enxuto e conhecido. As ferramentas que o blog já cobre entram aqui: n8n, Zapier ou Make para orquestrar, Mautic para marketing, webhooks para conectar sistemas.

A diferença é que agora você sabe o que está automatizando e por quê — e consegue medir se melhorou, porque tem o número de antes.

Sobre notação e ferramenta de modelagem

Uma opinião que contraria boa parte do material sobre o tema: para a maioria das empresas, papel resolve.

Notação formal como BPMN é excelente quando o processo é regulado, precisa ser auditado, ou vai ser implementado por um time externo que não participou da conversa. Fora desses casos, ela adiciona uma barreira: quem executa o processo não lê o diagrama, e o mapa vira artefato de consultoria em vez de instrumento de decisão.

O critério prático: o mapa é bom se a pessoa que faz o trabalho olha e diz "é isso mesmo" — ou "não, aqui a gente faz diferente". Essa segunda resposta é a mais valiosa da reunião inteira, e ela só aparece se o formato for legível.

Como fazer, em uma tarde

1. Escolha um processo com começo e fim claros. "Do pedido do cliente até a nota emitida", não "a operação comercial".
2. Junte quem executa. Não apenas quem gerencia — a diferença entre as duas visões é justamente o que você procura.
3. Peça o último caso real, do começo ao fim, com nomes e horários.
4. Anote as esperas, não só as tarefas.
5. Marque cada etapa com eliminar, simplificar, padronizar ou manter.
6. Execute os "eliminar" primeiro. São de graça.

Se a empresa já tem alguma disciplina de gestão, isso conversa com os modelos de boas práticas de TI e com indicadores de desempenho — mas nada disso é pré-requisito para começar.

O ponto que fica

O mercado de automação tem um incentivo óbvio para pular esta etapa: ninguém vende licença de mapeamento de processo. A conversa comercial começa direto na ferramenta, e a empresa compra a solução antes de ter definido o problema.

O contrapeso é chato e barato: uma tarde, as pessoas certas na sala e a pergunta "essa etapa existe por quê?" repetida até incomodar.

Se depois disso ainda sobrar processo suficiente para justificar automação, ela vai custar menos, funcionar melhor e ser mais fácil de manter — porque você está automatizando algo que entende.