Por que documentar processos antes de automatizar com IA

Existe um erro clássico em projetos de automação que se repete com frequência suficiente para merecer um artigo próprio:

A empresa decide automatizar um processo, passa meses implementando com toda a tecnologia correta, e no final descobre que automatizou um processo quebrado.

O resultado não é um processo ruim que agora é mais rápido. É um processo ruim que agora cria problemas em escala, mais rápido do que antes, de forma mais difícil de reverter.

Automatização amplifica o que existe. Se o que existe é bom, o resultado é excelente. Se o que existe é ruim, o resultado é desastre acelerado.

Por que a documentação é ignorada (e por que isso é um erro)

Documentar processos parece trabalho burocrático antes do trabalho real. As empresas querem resultados rápidos, e passar semanas desenhando fluxogramas parece o oposto disso.

Existe uma pressão real: “vamos só começar e vemos no caminho”, “todo mundo sabe como funciona, não precisa escrever”, “documentação é perda de tempo, já fizemos isso antes”.

Mas existe um paradoxo aqui: projetos que pulam a documentação para “ir mais rápido” frequentemente terminam mais lentos — e às vezes não terminam.

A razão é simples: quando você tenta automatizar um processo sem documentá-lo, as exceções aparecem na implementação.

E cada exceção que surge na implementação custa 10x mais para resolver do que se tivesse sido identificada antes:

• Código já foi escrito → precisa ser reescrito
• Integrações já foram feitas → precisam ser refeitas
• Prazo foi dado ao stakeholder → atraso gera perda de confiança
• Orçamento foi consumido → precisa pedir mais budget

No pior caso, a exceção descoberta tarde invalida a abordagem inteira e o projeto precisa recomeçar.

O que documentar (e o nível de detalhe necessário)

Não precisa de um fluxograma BPMN com todas as exceções possíveis do universo documentadas em 50 páginas. Isso é over-engineering de documentação.

O nível de documentação necessário para automação com IA é específico:

1. O fluxo principal (happy path)

Quais são os passos em sequência para o caso padrão — o caso que acontece 70-80% das vezes?

Perguntas essenciais:

• Quais são os passos? (início ao fim)
• Quem faz cada passo? (pessoa, função, departamento)
• O que é produzido em cada etapa? (documentos, registros em sistemas, comunicações, decisões)
• Quais sistemas são usados? (ERP, CRM, planilha, e-mail)
• Quanto tempo leva cada etapa? (estimativa realista, não ideal)

Exemplo: processo de aprovação de compra (happy path):

1. Solicitante preenche formulário de solicitação de compra (Google Forms) - 10 min
2. Sistema envia e-mail para gestor direto do solicitante - automático
3. Gestor aprova ou rejeita (se valor < R$ 5.000) - 1-2 dias
4. Se aprovado, e-mail vai para Compras - automático
5. Compras solicita cotações de 3 fornecedores - 1-3 dias
6. Compras compara propostas e seleciona fornecedor - 1 dia
7. Compras emite pedido de compra no ERP - 30 min
8. Pedido é enviado ao fornecedor - automático

2. As exceções frequentes (não todas, só as que importam)

Quais situações fogem do fluxo padrão? Com que frequência acontecem? Como são tratadas hoje?

Regra prática: documente exceções que representam 5%+ do volume ou que têm impacto crítico (mesmo que raras).

Exemplo de exceções no processo de compra:

Exceção	Frequência	Tratamento atual
Valor > R$ 5.000	30% dos casos	Requer aprovação adicional de diretor
Urgência (emergencial)	8% dos casos	Pula etapa de cotação, vai direto para fornecedor pré-aprovado
Item não tem fornecedor cadastrado	12% dos casos	Compras precisa homologar novo fornecedor (processo separado)
Gestor não responde em 3 dias	15% dos casos	Solicação automaticamente sobe para gerente superior

Uma exceção que acontece 5% do tempo pode representar 20% do esforço se for complexa de tratar. Precisa estar documentada.

3. Os critérios de decisão (regras explícitas vs julgamento)

Em quais pontos do processo alguém toma uma decisão? Com base em quais informações? Quais são os critérios?

Tipos de decisão:

Regras explícitas (fáceis de automatizar):

• “Se valor < R$ 5.000 → gestor direto aprova”
• “Se valor R$ 5.000-20.000 → gestor + financeiro aprovam”
• “Se valor > R$ 20.000 → diretoria aprova”

Julgamento humano (difíceis de automatizar, mas pode-se explicitar fatores):

• “Compras decide qual fornecedor escolher com base em: preço (40%), prazo (25%), histórico de qualidade (25%), condições de pagamento (10%)”

Se a decisão é 100% julgamento sem critérios explícitos (“eu sei quando vejo”), isso sinaliza que:

• Ou o processo não está maduro o suficiente para automação
• Ou precisa de um trabalho de explicitação antes de automatizar

4. As dependências (inputs de outros processos/sistemas)

O processo depende de inputs de outros sistemas, outras pessoas, outros departamentos?

Perguntas críticas:

• Onde esses inputs chegam? (e-mail, sistema X, planilha compartilhada)
• Em qual formato? (PDF, CSV, JSON, texto livre)
• Com qual frequência? (tempo real, diário, semanal, sob demanda)
• O que acontece se o input não chega ou chega errado?

Exemplo: “O processo de faturamento depende de confirmação de entrega que chega por e-mail do time de logística em PDF. Às vezes o PDF vem digitalizado (imagem), às vezes vem como texto. Às vezes não vem e precisamos ligar para confirmar manualmente.”

Esse tipo de detalhe é crítico. Se a automação assume que o PDF sempre vem estruturado e 30% das vezes é imagem, vai falhar 30% das vezes.

5. O que pode dar errado (pontos de falha conhecidos)

Quais são os erros mais comuns no processo hoje? Quando o processo falha, como é detectado? Quem é notificado? Como é corrigido?

Exemplo:

• Erro: Fornecedor envia NF com valor divergente do pedido
• Detecção: Financeiro percebe ao lançar NF no sistema
• Tratamento: Liga para Compras, que valida com fornecedor
• Frequência: ~3% das NFs

A automação precisa prever esse cenário e ter um tratamento explícito.

A técnica de mapeamento para automação

A forma mais eficiente de documentar um processo para automação não é sentar em uma sala de reunião com consultores desenhando fluxogramas de memória.

É conversar com quem faz o processo — e observar enquanto faz.

1. Entrevistas com os executores

As pessoas que executam o processo sabem de detalhes que nenhum manual captura.

Perguntas essenciais:

• “Me conta como você faz esse processo, passo a passo. Pode compartilhar tela e mostrar?”
• “Quando é que algo dá errado? Me dá um exemplo recente.”
• “O que você precisa saber ou ter em mãos para conseguir fazer esse processo?”
• “Tem algo nesse processo que você acha desnecessário ou que poderia ser diferente?”

Essa última pergunta revela frequentemente oportunidades de simplificação antes de automatizar — o que é muito melhor do que automatizar complexidade desnecessária.

Exemplo real: Em um projeto de automação de aprovação de despesas, descobrimos na entrevista que 40% do tempo do aprovador era gasto validando se o centro de custo estava correto — porque o solicitante frequentemente preenchia errado.

Solução: em vez de automatizar a aprovação com validação de centro de custo (complexo), mudamos o formulário para pré-selecionar o centro de custo correto com base no departamento do solicitante. Simplificação antes de automação.

2. Shadowing (observação em tempo real)

Observe alguém executando o processo em tempo real. Você vai ver coisas que as entrevistas não capturam:

• As gambiarras (planilha auxiliar que ninguém menciona formalmente mas todos usam)
• Os sistemas não documentados (WhatsApp para confirmar urgências)
• Os atalhos (copiar e colar de aprovação anterior em vez de preencher do zero)
• Os “jeitos que sempre foram feitos assim” (que podem não fazer mais sentido)

3. Process mining (para processos já digitalizados)

Se o processo já acontece majoritariamente em sistemas digitais (ERP, CRM, plataforma de tickets), process mining — análise automática dos logs de eventos — pode revelar como o processo realmente acontece, não como se pensa que acontece.

A diferença frequentemente é surpreendente.

Ferramentas de process mining:

• Celonis (enterprise, caro)
• UiPath Process Mining
• Microsoft Power Automate Process Advisor (integrado com Power Platform)
• Open-source: PM4Py, ProM

O que process mining revela:

• Sequência real de passos (não a sequência “oficial”)
• Variações do processo (quantos caminhos diferentes existem na prática)
• Bottlenecks (onde o processo empaca)
• Retrabalho (passos que são refeitos com frequência)

O artefato de documentação para a equipe de IA

Quando você vai para uma equipe técnica implementar a automação, precisa entregar:

1. Fluxo principal documentado

Diagrama (pode ser simples) + descrição textual de cada passo.

Não precisa ser BPMN formal. Pode ser um fluxograma em Miro, Lucidchart, ou até desenho à mão fotografado — desde que seja claro.

2. Lista de exceções

Tabela com (exceção | frequência | tratamento atual | proposta de tratamento na automação).

3. Regras de decisão explícitas

Para cada ponto de decisão no fluxo: quais são os inputs, qual é a lógica, qual é o output.

Se a decisão envolve julgamento, explicite os fatores considerados e, se possível, o peso relativo de cada um.

4. Exemplos reais

5-10 casos reais do processo (com dados anonimizados se necessário) que cobrem:

• 2-3 casos típicos (happy path)
• 2-3 casos com exceções mais frequentes
• 1-2 casos complexos ou limítrofes

Exemplos reais são ouro para quem vai implementar. Testes serão baseados nesses casos.

5. Critérios de sucesso

O que significa o processo ter sido executado corretamente?

Exemplo para processo de aprovação de compra:

• Solicitação foi aprovada ou rejeitada em < 3 dias úteis (95% dos casos)
• Aprovação seguiu alçadas corretas (100% dos casos)
• Compras recebeu notificação automática após aprovação (100%)
• Histórico de aprovação ficou registrado (100%)

Com essa documentação, a equipe técnica consegue construir um sistema que realmente funciona — em vez de construir o que imagina que o processo é.

Um sinal de alerta (red flag)

Se alguém na empresa diz:

“Não precisa documentar, é simples — todo mundo sabe como funciona.”

Esse é o sinal de que a documentação é mais necessária ainda.

“Todo mundo sabe” é geralmente evidência de conhecimento tácito não documentado — o tipo de conhecimento que:

• Fica preso nas cabeças de 2-3 pessoas
• Sai da empresa quando essas pessoas saem
• Não pode ser capturado por um sistema automatizado sem ser explicitado
• Tem variações entre pessoas (“todo mundo sabe” mas cada um faz de um jeito ligeiramente diferente)

Regra de ouro: se você não consegue escrever o processo em 2 páginas, não consegue automatizá-lo bem.

---

Se você está iniciando um projeto de automação com IA e quer ajuda para mapear os processos da forma certa antes de começar a construir, agende uma conversa. Temos metodologia própria de diagnóstico de processos para automação que identifica exceções, dependências e pontos de falha antes que virem problema na implementação.