Como mapear processos com BPMN: guia passo a passo

Mapear processo não é desenhar bonito. É levantar a realidade — com data, responsável e tempo — e só depois colocar isso num diagrama que alguém vai usar para decidir algo. A maioria dos mapeamentos que travam, ou que viram só um PDF esquecido na pasta, erra antes mesmo de abrir o editor: pula etapa, confia no que "deveria ser" em vez do que de fato acontece, ou desenha sozinho sem validar com quem está na ponta.

Esse guia é um roteiro de quem já mapeou processo de verdade, não um exemplo de curso com três tarefas e um gateway. Vamos do levantamento bruto até o diagrama validado, na ordem que evita retrabalho.

Se você ainda não decidiu onde vai modelar isso, vale ler antes como escolher um sistema de BPMN — porque a ferramenta errada vira gargalo antes mesmo do processo entrar no papel.

Antes de abrir o editor

O erro mais caro em mapeamento de processos BPMN não está no desenho, está na delimitação. Antes de desenhar qualquer caixa, defina duas coisas por escrito:

• Onde o processo começa e termina. "Atendimento ao cliente" não é um processo, é uma área. "Do recebimento do chamado até o fechamento com avaliação do cliente" é um processo — tem início e fim claros.
• Quem participa de ponta a ponta. Liste as áreas e cargos envolvidos, não só o nome de quem você já conhece. É comum descobrir, já na entrevista, que uma área "invisível" (compras, jurídico, TI) entra no meio do fluxo e ninguém tinha mencionado.

Sem esse escopo fechado, você vai mapear até onde a conversa te levar — e isso quase nunca coincide com o processo real.

1. Levante o processo com quem executa

   O manual oficial, o procedimento documentado, a instrução de trabalho — nenhum desses é o processo real. É a versão que alguém escreveu uma vez e ninguém atualizou. O processo real está com quem executa a tarefa todos os dias.

   Entreviste ou observe a pessoa fazendo o trabalho. Pergunte o que ela faz quando o sistema cai, quando falta uma informação, quando o cliente liga fora do horário previsto — são essas exceções que revelam o processo de verdade, não o caminho feliz que todo mundo descreve de cabeça.

2. Desenhe o AS-IS sem julgar

   Essa é a etapa onde mais gente erra: começa a "corrigir" o processo enquanto ainda está desenhando. Resista. O AS-IS é um retrato, não uma sugestão de melhoria.

   Use os elementos certos da notação — eventos de início e fim, tarefas, gateways de decisão, raias por responsável. Se você ainda confunde quando usar um gateway exclusivo ou um evento intermediário, vale revisar a notação BPMN 2.0 e sua simbologia antes de seguir, porque um diagrama com símbolo errado confunde mais do que ajuda na validação.

   Desenhe exatamente o que foi relatado na etapa anterior, incluindo os retrabalhos, os "manda de volta para o gestor aprovar de novo" e os desvios informais. É feio. É normal. É o ponto de partida.

3. Atribua tempo e responsável a cada tarefa

   Isso é o que separa um desenho de uma análise. Um diagrama sem tempo associado a cada tarefa é só uma ilustração — não dá para saber onde está o gargalo, quanto custa a etapa, ou quem está sobrecarregado.

   Para cada tarefa, registre: quem executa, tempo médio de execução, e se há espera entre uma tarefa e a próxima (essa espera, sozinha, costuma ser maior que o tempo de trabalho de todo o processo). É esse dado — tempo por tarefa, custeado e atribuído — que transforma o BPMN de planta baixa em ferramenta de decisão.

4. Valide com quem participa

   Antes de tirar qualquer conclusão ou apresentar o mapeamento para a diretoria, volte para as mesmas pessoas que você entrevistou e mostre o diagrama. Pergunte diretamente: "é assim que funciona?".

   Essa validação não é formalidade. É comum a primeira versão do AS-IS ter um passo fora de ordem, uma exceção que ficou de fora, ou um responsável errado numa raia. Corrigir isso agora custa cinco minutos. Corrigir depois que a análise já foi apresentada custa a credibilidade do mapeamento inteiro.

5. Só depois, desenhe o TO-BE

   Com o AS-IS validado e os tempos atribuídos, agora sim você tem dados para comparar — não opinião. É nesse ponto que entra a análise quantitativa: olhar onde o tempo de espera supera o tempo de execução, onde uma tarefa não agrega valor para o cliente final, onde uma raia está sobrecarregada enquanto outra está ociosa.

   Um diagrama Yamazumi aplicado sobre essas tarefas custeadas mostra isso em segundos: cada barra é uma raia ou um responsável, e o desbalanceamento fica visível sem precisar explicar nada. É a partir desse retrato — e não de uma reunião de brainstorming — que o TO-BE deve nascer.

Um TO-BE desenhado sem dado de tempo é só uma opinião com caixinhas. O TO-BE que sobrevive à execução é o que nasce de um AS-IS medido.

Erros que atrasam o mapeamento

Três erros aparecem com uma frequência alta demais para serem coincidência:

• Mapear sozinho, na frente do computador. Reconstituir o processo de memória ou a partir só da documentação produz um AS-IS bonito e errado. Quem não participou da execução real sempre esquece uma exceção.
• Pular a etapa de tempo e custo. Entregar um diagrama sem tempo por tarefa é entregar metade do trabalho — e geralmente é a metade que ninguém vai usar para decidir nada.
• Misturar AS-IS com TO-BE no mesmo desenho. Tentar já "corrigir" o processo enquanto mapeia o atual produz um diagrama que não representa nem a realidade nem a proposta — e que não serve para comparar nada.

Evitar esses três pontos já coloca o mapeamento na frente da maioria dos que travam em PowerPoint, sem versão, sem tempo associado e sem validação de quem participa do processo de fato.