Por que mapear o processo antes de escrever código
Automatizar um processo bagunçado só deixa a bagunça mais rápida e mais cara. Entenda por que o mapeamento vem antes do código e como fazer o seu.
Mapear antes de codificar serve para descobrir o que não deve ser automatizado. Em quase todo processo real existem etapas de conferência, retrabalho e aprovação que só existem porque outra etapa falha. Se você programa o fluxo do jeito que ele é hoje, paga para congelar esses desperdícios em software.
Mapear o processo antes de escrever código serve para uma coisa concreta: descobrir o que não deve ser automatizado. Todo processo que roda há anos acumula etapas que só existem porque alguma outra etapa falha, conferência dupla, planilha paralela, e-mail de aviso, aprovação de algo que ninguém nega. Se você programa o fluxo do jeito que ele está hoje, paga para transformar esse desperdício em software, com manutenção mensal inclusa.
O software não corrige processo. Ele executa mais rápido aquilo que você mandou executar.
O que acontece quando você automatiza sem mapear
O padrão se repete. A empresa contrata um sistema descrevendo as telas que quer, o time entrega exatamente aquilo, e seis meses depois o resultado é:
- Etapas mortas viraram tela. Um campo de "aprovação do supervisor" que na prática é sempre aprovado, mas agora trava o fluxo digitalmente.
- A planilha continua. As pessoas usam o sistema para registrar e a planilha para trabalhar, porque o sistema copiou um fluxo que já não servia.
- O gargalo não se moveu. Automatizou-se a etapa fácil (a que a TI entendeu) em vez da etapa lenta. O lead time total ficou igual.
- Cada exceção virou chamado. Ninguém mapeou os casos fora do padrão, então todo caso fora do padrão precisa de programador.
O último ponto é o mais caro. Em processo não mapeado, a exceção parece rara para quem descreve e é frequente para quem executa.
O que um mapeamento precisa ter
Um mapeamento útil não é um desenho bonito. Ele precisa responder, para cada etapa:
| Item | Pergunta que responde | Por que importa no software |
|---|---|---|
| Gatilho | O que faz esta etapa começar? | Vira evento, agendamento ou ação de usuário |
| Executor | Quem faz, em qual papel? | Define permissão e responsabilidade |
| Entrada | Qual informação precisa existir antes? | Define validação e campos obrigatórios |
| Regra de decisão | O que separa "segue" de "volta"? | Vira condicional, não bom senso do operador |
| Tempo de execução | Quanto tempo leva de fato? | Base para provar ganho depois |
| Tempo de espera | Quanto tempo fica parado entre etapas? | Costuma ser 80% do lead time |
| Exceções | O que acontece quando dá errado? | Evita que todo caso raro vire chamado |
A separação entre tempo de execução e tempo de espera é o item que mais muda a conversa. Um pedido que leva quatro dias para ser faturado raramente tem quatro dias de trabalho: tem 40 minutos de trabalho e três dias e meio de fila esperando alguém olhar. Automatizar os 40 minutos economiza pouco. Atacar a fila economiza muito.
Como mapear um processo em uma semana
Não é preciso um projeto de meses. Um roteiro que funciona em empresa pequena e média:
- Escolha um recorte com começo e fim claros. "Do pedido aprovado até a nota emitida", não "o comercial".
- Acompanhe a execução real. Sente ao lado de quem faz e observe. O que as pessoas descrevem em reunião é a versão oficial; o que elas fazem é o processo.
- Desenhe em raia (quem faz o quê). Cada raia é um papel. Toda seta que cruza de uma raia para outra é um ponto de espera em potencial.
- Cronometre com amostra pequena. Dez casos já mostram a ordem de grandeza. Anote data e hora de entrada e saída de cada etapa.
- Marque os três tipos de etapa: as que agregam valor para o cliente, as que não agregam mas são obrigatórias (fiscal, legal, auditoria) e as que são puro desperdício.
- Valide com quem executa, não só com quem chefia. É nessa conversa que aparecem as regras não escritas.
O passo 5 é o que decide o escopo. Etapa de desperdício se elimina, não se automatiza. Etapa obrigatória se simplifica. Etapa que agrega valor é candidata a software.
O que o mapeamento revela e a reunião de escopo não revela
Três descobertas aparecem quase sempre:
Ninguém sabe o processo inteiro. Cada área conhece o próprio pedaço e supõe o resto. As suposições erradas costumam estar exatamente nas transições entre áreas, onde o tempo se perde.
Existe mais de uma versão do mesmo processo. Dois vendedores, dois fluxos. Isso não é detalhe: um sistema não consegue implementar duas regras contraditórias sem alguém decidir qual vale. Se a decisão não for tomada no mapeamento, será tomada por um desenvolvedor no meio do sprint, sem contexto.
Parte do problema não é de sistema. Às vezes a correção é mudar quem aprova, juntar duas etapas ou eliminar uma conferência redundante. Sai de graça e resolve mais do que o software resolveria.
Quando o mapeamento mostra que o software não é necessário
Acontece, e é um bom resultado. Se ao final do mapeamento o desperdício estava em uma aprovação inútil e em um retrabalho causado por cadastro incompleto, a correção é padronizar a entrada e cortar a aprovação. Nenhuma linha de código.
Em outros casos, o mapeamento não elimina o sistema, ele reduz o escopo. É comum um pedido inicial de "sistema de gestão completo" virar dois módulos bem definidos depois que o fluxo real fica visível, porque as outras funções ou não são usadas ou já são atendidas por uma ferramenta existente. Nos projetos da Retti Tech, esse corte de escopo antes do desenvolvimento é rotina, e costuma ser a parte que mais economiza dinheiro do cliente.
O critério para começar a codificar
Você está pronto para desenvolver quando consegue responder três perguntas sem consultar ninguém:
- Qual é a regra de decisão de cada bifurcação do fluxo, escrita em uma frase?
- Qual é o tempo atual do processo ponta a ponta, com número, não com "demora"?
- O que exatamente vai mudar de posição no fluxo depois que o sistema existir?
Se a terceira pergunta não tem resposta clara, o projeto ainda não é de software. É de processo.
Perguntas frequentes
Mapear não atrasa o início do projeto?
Atrasa a primeira linha de código em alguns dias e economiza semanas de reescrita depois. O custo de mudar uma caixa no diagrama é minutos; o custo de mudar a mesma regra depois que ela virou tela, banco e relatório é de dias.
Preciso de uma ferramenta cara de BPM para mapear?
Não. Papel, quadro branco ou um diagrama simples resolvem a maioria dos casos de pequena e média empresa. A ferramenta importa menos do que entrevistar quem executa a tarefa e cronometrar o que acontece de verdade.
E se o processo hoje é só improviso, sem nada escrito?
Aí o mapeamento é ainda mais necessário. Processo que só existe na cabeça das pessoas costuma ter três versões diferentes, e você descobre isso na primeira reunião comparando o que cada um descreve.
Tem um processo que consome o time?
Me conta como funciona hoje. Se der para automatizar, eu te digo por onde começar — a conversa de diagnóstico não é cobrada.
Natiam Gabriel é AI Engineer & Full-Stack Developer e fundador da Retti Tech, estúdio de desenvolvimento de software que atende empresas em todo o Brasil. Constrói sistemas web sob medida, automações e integrações, com ou sem inteligência artificial, do levantamento de requisitos até a operação em produção. Mais de 20 empresas usam em produção os sistemas que desenvolveu.