# Mapear processos antes de automatizar: guia prático

> Como mapear processos para automação: registre o fluxo real, meça volume, tempo e exceções e escolha o que automatizar primeiro pelo retorno, sem acelerar erro.

Fonte: https://pervian.tech/blog/mapear-processos-antes-de-automatizar · Pervian Tech · publicado em 2026-10-01

A decisão de automatizar costuma nascer de um incômodo concreto. O financeiro passa a manhã de segunda conferindo boletos, o comercial [redigita pedidos que chegaram por e-mail](https://pervian.tech/blog/automatizar-entrada-de-pedidos), o almoxarifado preenche a mesma informação em três lugares. Alguém sugere um robô ou um sistema, o projeto começa, e meses depois a equipe continua com uma planilha paralela "para garantir".

Quase sempre, o problema não foi a tecnologia escolhida. Foi automatizar o processo que estava no manual, e não o que acontecia de verdade na mesa das pessoas. As exceções que ninguém documentou, os atalhos que a equipe inventou e as [aprovações informais por WhatsApp](https://pervian.tech/blog/workflow-de-aprovacao-por-alcada) ficaram de fora, e cada uma delas virou um caso que o sistema não sabe tratar.

Este guia mostra como mapear um processo antes de automatizar: como descobrir o fluxo real, quais números levantar e como decidir o que automatizar primeiro.

## A resposta curta: como mapear processos para automação

Se você tem só um minuto, aqui está o essencial. Mapear um processo para automação tem cinco etapas:

1. **Delimite o processo**: onde começa, onde termina e qual resultado entrega (exemplo: "do pedido recebido por e-mail até o pedido lançado no ERP").
2. **Descubra o fluxo real** com três fontes ao mesmo tempo: entrevista com quem executa, observação do trabalho acontecendo e dados dos sistemas.
3. **Meça volume, tempo e exceções**: quantas vezes por mês, quanto tempo cada execução leva e com que frequência algo sai do caminho padrão.
4. **Simplifique** o que não precisa existir antes de pensar em ferramenta.
5. **Priorize pelo retorno**: automatize primeiro o trecho com mais volume, regra mais clara e erro mais caro.

O resto do texto detalha cada etapa.

## Por que automatizar um processo ruim só acelera o erro

Automação executa regras. Se a regra está errada, incompleta ou depende do bom senso de alguém, a automação reproduz o defeito com mais velocidade e menos gente olhando.

Três situações aparecem com frequência:

- **Etapa que não agrega nada.** Um relatório impresso, assinado e escaneado que ninguém consulta. Automatizar a geração desse relatório é investir em algo que deveria ser eliminado.
- **Regra que mora na cabeça de uma pessoa.** "Cliente do Nordeste com pedido acima de tanto passa pela Ana." Se a regra não está escrita, o sistema não a conhece, e as primeiras férias da Ana revelam o buraco.
- **Retrabalho tratado como parte do fluxo.** Quando metade dos pedidos volta para correção, o processo real inclui um laço de idas e vindas. Automatizar só o caminho feliz deixa o laço inteiro na mão da equipe.

O mapeamento existe para encontrar essas três coisas antes que virem requisito de software.

## Processo do manual x processo real

Toda empresa com alguns anos de operação tem duas versões de cada processo. A do manual, do fluxograma da certificação ou da apresentação de integração de novos funcionários. E a que a equipe executa, com os ajustes que foram se acumulando.

| Aspecto | Processo do manual | Processo real |
|---|---|---|
| Entrada | Pedido pelo portal, com campos obrigatórios | Pedido por portal, e-mail, WhatsApp e telefone |
| Aprovação | Gerente aprova no sistema | Gerente aprova por mensagem e alguém registra depois |
| Exceções | "Casos especiais tratados pela supervisão" | Lista longa de casos que cada pessoa resolve do seu jeito |
| Ferramentas | ERP | ERP, duas planilhas e um caderno |
| Tempo | Um dia útil | Varia muito conforme quem está de plantão |

A diferença não é desonestidade. É adaptação: a equipe encontra atalhos para fazer o trabalho andar. Só que esses atalhos são exatamente o que a automação precisa conhecer. Se o pedido chega por WhatsApp em boa parte dos casos, uma automação que só lê o portal resolve uma fatia pequena do problema.

Por isso, o ponto de partida do mapeamento é sempre a pergunta "como isso acontece hoje, de fato?", e não "como deveria acontecer?".

## Como mapear: entrevistas, observação e dados

Nenhuma fonte sozinha mostra o processo inteiro. Entrevista revela intenção, observação revela prática e dado revela frequência. Use as três.

### Entrevistas com quem executa

Converse com quem faz o trabalho, não só com quem gerencia. O gestor conhece o objetivo; o analista conhece as exceções. Algumas perguntas que funcionam:

- "Me mostra o último caso que você tratou, do começo ao fim."
- "O que você faz quando falta alguma informação?"
- "Qual caso te faz perder mais tempo?"
- "Que planilha ou anotação você mantém que não está no sistema?"
- "Se você saísse de férias amanhã, o que a pessoa que te substitui erraria?"

Peça exemplos reais, não descrições genéricas. "Normalmente a gente confere o cadastro" vira algo útil quando a pessoa mostra o que confere, em qual tela e o que faz quando o cadastro está errado.

### Observação do trabalho acontecendo

Acompanhe a execução por algumas horas, em dias diferentes, incluindo o dia de pico (fechamento do mês, segunda-feira de manhã, véspera de feriado). Pode ser presencial ou por compartilhamento de tela. Anote cada troca de sistema, cada copiar e colar, cada vez que a pessoa espera alguém responder.

A observação costuma revelar coisas que ninguém menciona na entrevista porque viraram hábito: a aba de conferência aberta o dia inteiro, o filtro que precisa ser refeito a cada consulta, o arquivo baixado e renomeado antes de ser importado.

### Dados dos sistemas

ERP, CRM, caixa de e-mail e planilhas guardam rastros do processo. Datas de criação e de conclusão mostram tempo de ciclo; status de cancelamento e de devolução mostram retrabalho; campos de observação mostram exceções. Mesmo uma exportação simples de um mês de registros já permite contar volume e identificar os casos fora do padrão.

### Como registrar o mapa

Não precisa de notação sofisticada. Para cada etapa, registre:

- **Quem faz** (cargo, não nome).
- **Onde faz** (sistema, planilha, e-mail, papel).
- **O que entra e o que sai** (documento, dado, aprovação).
- **Regra de decisão**, se houver, escrita como "se... então...".
- **O que acontece quando dá errado.**

Um quadro com raias por área, ou uma tabela com essas colunas, resolve. O importante é que quem executa olhe o mapa e diga "é isso mesmo".

## Volume, tempo e exceções: os números que importam

Sem números, a prioridade vira opinião. Você não precisa de precisão de auditoria; precisa de ordem de grandeza confiável. Para cada processo ou etapa, levante:

- **Volume**: quantas execuções por dia, semana ou mês. Conte nos sistemas sempre que possível.
- **Tempo por execução**: cronometre alguns casos reais durante a observação, incluindo o tempo de espera, não só o de trabalho.
- **Taxa de exceção**: de cada lote de casos, quantos saíram do caminho padrão? Classifique as exceções por tipo.
- **Retrabalho**: quantos casos voltaram para correção, e por quê.
- **Custo do erro**: o que acontece quando dá errado? Multa, cliente perdido, nota cancelada, estoque divergente, horas de conferência.
- **Dependência de pessoa**: quantas pessoas sabem executar o processo do começo ao fim.

A taxa de exceção merece atenção especial. Um processo com poucas exceções, bem classificadas, é ótimo candidato para automação completa. Um processo em que quase todo caso é "especial" pede outra abordagem: automatizar a parte repetitiva e deixar a decisão com uma pessoa, com o sistema organizando a fila e as informações para ela.

## Como priorizar o que automatizar primeiro

Com o mapa e os números na mão, a escolha fica mais objetiva. Pontue cada candidato de 1 a 5 em cinco critérios:

| Critério | Pontua alto quando | Pontua baixo quando |
|---|---|---|
| Volume e frequência | Acontece todo dia, muitas vezes | Acontece poucas vezes por ano |
| Clareza da regra | Dá para escrever sem "depende" | Cada caso exige julgamento |
| Estabilidade | O processo não muda há algum tempo | Está em reorganização ou mudança de regra |
| Custo do erro | Erro gera multa, perda de cliente ou retrabalho caro | Erro é corrigido em minutos |
| Facilidade técnica | Os sistemas envolvidos têm API ou arquivo estruturado | Depende de tela instável ou [documento em papel](https://pervian.tech/blog/digitalizar-processos-em-papel) |

Some os pontos e ordene. Alguns cuidados ao ler o resultado:

- **Comece por um processo de retorno visível e risco controlado.** A primeira automação serve também para a equipe confiar na ideia. Um projeto enorme e arriscado como estreia costuma gerar resistência.
- **Processo instável espera.** Se a regra muda no mês que vem, automatize depois que ela assentar.
- **Facilidade técnica define o "como", não só o "se".** Quando o sistema tem API, a integração direta tende a ser mais robusta; quando não tem, outras abordagens entram em jogo. A comparação está no texto sobre [RPA ou integração via API](https://pervian.tech/blog/rpa-ou-integracao-via-api).
- **Planilha no centro do processo é um sinal à parte.** Se o processo só funciona porque existe uma planilha compartilhada fazendo papel de sistema, o problema pode ser maior que automação. Vale ler [quando substituir planilhas por um sistema](https://pervian.tech/blog/substituir-planilhas-por-sistema).

## Simplificar antes de automatizar

Antes de [transformar o mapa em requisito](https://pervian.tech/blog/como-descrever-requisitos-de-software), passe por ele com quatro perguntas, etapa por etapa:

1. **Eliminar**: essa etapa precisa existir? Quem usa o resultado dela?
2. **Juntar**: duas pessoas conferem a mesma coisa? Dois sistemas recebem o mesmo dado digitado à mão?
3. **Padronizar**: as exceções podem virar regra escrita? A entrada pode chegar sempre no mesmo formato (um formulário em vez de e-mail livre, por exemplo)?
4. **Mover a validação para o começo**: o erro descoberto no fim do fluxo pode ser barrado na entrada?

Essa etapa costuma ser barata e muitas vezes resolve parte do problema sem uma linha de código. Uma aprovação que deixa de existir, um formulário que substitui o e-mail livre ou um campo obrigatório no cadastro reduzem a taxa de exceção e deixam a automação seguinte menor e mais confiável.

Cuidado com um ponto: simplificar exige decisão de gestão. Eliminar uma conferência ou mudar quem aprova é escolha de negócio, não de quem vai programar. Envolva os responsáveis de cada área antes de cortar.

## Do mapa ao escopo do projeto

Um bom mapa vira quase diretamente o escopo da automação. O que levar para a conversa com quem vai desenvolver:

- **O processo novo desenhado**, já simplificado, com as etapas automáticas e as que continuam humanas.
- **As regras de decisão escritas**, incluindo os "se... então..." levantados nas entrevistas.
- **A lista de exceções classificadas**, com o tratamento esperado para cada tipo: resolver automaticamente, mandar para uma fila com responsável ou bloquear.
- **Os sistemas envolvidos** e o que cada um oferece para integração (API, exportação de arquivo, só tela).
- **Os números de antes**: volume, tempo, exceções e retrabalho. Eles serão a base para medir se a automação funcionou.
- **O dono do processo**: a pessoa que decide quando surge um caso novo que ninguém previu.

Esse material encurta bastante a fase de entendimento de um projeto de software. É, na prática, o coração de um [discovery de software](https://pervian.tech/blog/discovery-de-software): a etapa em que se valida o problema, o fluxo e as regras antes de estimar e construir.

### Checklist antes de iniciar a automação

- O mapa foi validado por quem executa o processo?
- Sabemos o volume mensal e o tempo médio por execução?
- As exceções estão classificadas por tipo e frequência?
- Cada exceção tem um tratamento definido?
- Etapas desnecessárias foram eliminadas ou a decisão de mantê-las foi registrada?
- Existe um dono do processo com autoridade para decidir casos novos?
- Sabemos como medir o resultado depois de colocar no ar?

Se várias respostas forem "não", ainda é cedo para escolher ferramenta.

## Erros comuns no mapeamento

- **Mapear só com a gerência.** O resultado é o processo do manual, desenhado com mais capricho.
- **Querer mapear a empresa inteira de uma vez.** Escolha um processo, entregue resultado e só então siga para o próximo.
- **Ignorar o dia de pico.** O processo que funciona numa terça tranquila pode ser outro no fechamento do mês.
- **Tratar exceção como detalhe.** É nela que a automação quebra. Exceção sem tratamento definido volta para a mão de alguém sem aviso.
- **Pular a medição de antes.** Sem os números iniciais, ninguém consegue dizer depois se o projeto valeu a pena.
- **Escolher a ferramenta primeiro.** Quando a decisão começa pelo nome do software, o processo é forçado a caber nele. Veja como decidir entre [Pipefy ou fluxo sob medida](https://pervian.tech/blog/pipefy-ou-fluxo-sob-medida).

## Perguntas frequentes

### Preciso de um software específico para mapear processos?

Não. Mapear processos antes de automatizar dispensa notação sofisticada e software específico. Um quadro com raias por área ou uma tabela com quem faz, onde faz, o que entra e sai, a regra de decisão e o que acontece quando dá errado resolve. O essencial é que quem executa o processo valide o mapa.

### Quem deve participar do mapeamento de processos?

Quem executa o trabalho, além de quem gerencia. O gestor conhece o objetivo do processo, mas o analista conhece as exceções, os atalhos e as planilhas paralelas. Também é preciso envolver o dono do processo, com autoridade para decidir casos novos e aprovar simplificações que mudam quem confere ou quem aprova.

### Quanto tempo leva para mapear um processo?

Depende do tamanho do processo, do número de áreas envolvidas e da quantidade de exceções. O recomendado é mapear um processo por vez, com entrevistas, observação em dias diferentes, inclusive no dia de pico, e levantamento de volume e tempo nos sistemas, em vez de tentar mapear a empresa inteira de uma vez.

### Qual a diferença entre mapeamento de processos e discovery de software?

O mapeamento de processos descobre o fluxo real, mede volume, tempo e exceções e indica o que automatizar primeiro. O discovery de software usa esse material para validar o problema, as regras e o fluxo antes de estimar e construir o sistema. Um bom mapa encurta bastante o discovery, porque já entrega boa parte do escopo.

### Vale a pena automatizar um processo com muitas exceções?

Em parte. Quando quase todo caso é especial, automatizar o processo inteiro tende a falhar. O caminho costuma ser automatizar o trecho repetitivo, deixar a decisão com uma pessoa e usar o sistema para organizar a fila e as informações. Antes disso, vale tentar transformar as exceções mais frequentes em regras escritas.

## Como a Pervian Tech trabalha mapeamento e automação

Na Pervian Tech, todo projeto de [automação de processos](https://pervian.tech/solucoes/automacao-de-processos) começa pelo mapeamento: conversamos com quem executa, acompanhamos o trabalho real, levantamos volume e exceções nos sistemas e devolvemos um mapa validado pela equipe, com a sugestão do que simplificar e do que automatizar primeiro. A escolha entre integração por API, automação sobre arquivos ou um sistema novo vem depois, como decisão de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software), e não antes.

O diagnóstico inicial é gratuito e serve para entender se o processo já está pronto para automação ou se precisa de ajustes antes. A partir dele, o projeto é sob medida, em fases, com prazos definidos depois de conhecer o processo, e o investimento é sob consulta. Outros textos sobre o tema estão na categoria [automação](https://pervian.tech/blog/categoria/automacao). Se existe um processo na sua empresa que consome horas da equipe e você não sabe por onde começar, [conte como ele funciona hoje](https://pervian.tech/#contato).