Como interpretar resultados de process mining e transformar o diagnóstico em plano de melhoria

Interpretar o resultado de um process mining é fazer quatro leituras na ordem certa: quanto do volume segue o caminho previsto (variantes), o que volta para trás (retrabalho), onde o caso espera (lead time) e o que fura a regra (conformidade). Depois vem o passo que separa um diagnóstico útil de um relatório bonito: descobrir a causa de cada achado, colocar um valor em reais nele e ordenar tudo por valor, esforço e risco. O que sai disso é um plano de melhoria, com dono e prazo, que o mesmo log consegue medir depois.

A maior parte dos projetos de process mining não falha na extração do dado nem no algoritmo. Falha no dia seguinte ao primeiro mapa, quando o time olha um emaranhado de 200 variantes e não sabe por onde começar. Este guia é para esse dia. Ele parte do princípio de que você já sabe o que é a técnica. Se ainda não sabe, comece pelo guia de mineração de processos, que explica o log de eventos, os três tipos de análise e a diferença para BI.

Antes de interpretar: confira se o mapa merece confiança

Um mapa errado leva a um plano errado com toda a convicção do mundo. Antes de discutir qualquer achado, passe o resultado por seis conferências. Elas levam uma tarde e evitam semanas de discussão sobre um problema que não existe.

1. O período cobre um ciclo completo? Processos administrativos têm sazonalidade de fechamento, de orçamento e de férias. Seis a doze meses costumam bastar. Três meses podem pegar só a parte boa ou só a parte ruim do ano.
2. O caso é o objeto certo? Se uma requisição vira três pedidos, ou uma conta médica tem várias guias, a escolha do identificador de caso muda o mapa inteiro. Confirme que todos entendem o que é "um caso" no mapa que estão lendo.
3. Há carimbos em lote? Rotinas noturnas que gravam o mesmo horário em centenas de casos criam atividades "simultâneas" e tempos de zero minuto. Elas distorcem o lead time e a ordem das atividades.
4. O carimbo é do fato ou do registro? Se a nota fiscal é lançada uma semana depois de chegar, o sistema mede o tempo de lançamento, não o de recebimento. Saber isso muda a leitura do gargalo.
5. Os casos abertos foram tratados? Casos que começaram antes do período ou ainda não terminaram puxam o lead time para baixo ou para cima. Filtre só os completos para medir tempo e mantenha os abertos para medir fila.
6. Quem executa reconhece o mapa? Mostre o caminho principal para duas pessoas que trabalham no processo. Se elas não reconhecem, o problema está no dado ou na definição das atividades, e não no processo.

Com essas seis respostas em mãos, o mapa deixa de ser um desenho e vira evidência.

Como ler as variantes

Variante é uma sequência única de atividades. Dois casos que passaram pelas mesmas etapas, na mesma ordem, formam a mesma variante. É a primeira coisa que todo painel mostra, e a mais mal interpretada.

O número de variantes não é o problema

Um processo de compras com 214 variantes parece caótico. Muitas vezes não é. Uma variante pode diferir da outra só porque um caso teve duas notas fiscais em vez de uma, ou porque a aprovação aconteceu antes do cadastro do fornecedor sem que isso mude nada de relevante. O número absoluto depende de quantas atividades você extraiu: quanto mais fino o log, mais variantes aparecem.

A pergunta útil é outra: quanto do volume as cinco ou dez primeiras variantes explicam? Se as dez primeiras cobrem 80% dos casos, o processo é razoavelmente estável e a cauda de variantes raras merece atenção só onde tiver valor alto. Se as dez primeiras cobrem 30%, o processo não tem padrão de verdade, e isso é um achado em si.

O caminho previsto como régua

Defina com o dono do processo qual é o caminho previsto (o happy path) e meça a fração do volume que segue por ele. Depois faça a mesma conta em valor. É comum o caminho previsto responder por metade dos casos e por menos da metade do valor, porque os casos grandes são justamente os que recebem exceção, renegociação e aprovação extra.

Leia a variante pelo que ela tem a mais

Para cada variante relevante fora do caminho previsto, pergunte o que ela tem a mais ou a menos: uma aprovação repetida, uma etapa pulada, uma ordem invertida. Essa diferença é o achado. "Variante 7" não diz nada a ninguém. "Pedido aprovado duas vezes porque o preço mudou depois da aprovação" diz o que corrigir.

Como ler o retrabalho

Retrabalho, no mapa, é tudo o que volta: uma atividade que se repete no mesmo caso (o self-loop) ou um caso que retorna a uma etapa anterior. Aprovação refeita, alteração de preço, estorno, reabertura de chamado, conta devolvida para correção. O guia sobre o custo do retrabalho aprofunda as causas mais comuns.

Três números descrevem o retrabalho de um processo:

• Taxa de casos com retrabalho: quantos casos tiveram pelo menos uma volta.
• Voltas por caso afetado: um caso que volta uma vez é diferente de um que volta quatro.
• Tempo acrescentado por volta: a diferença de lead time entre casos com e sem a volta.

O valor em reais sai de uma conta simples, que todo achado de retrabalho deveria trazer escrita:

custo anual = voltas por ano × minutos de trabalho por volta ÷ 60 × custo da hora

O tempo de trabalho por volta não está no log, porque o sistema registra quando a atividade aconteceu e não quanto tempo a pessoa gastou nela. Ele vem de quem executa, por estimativa ou por entrevista. Por isso a conta deve mostrar a premissa. A calculadora de custo do retrabalho faz essa conta para uma área inteira.

Um cuidado: nem toda volta é desperdício. Uma conta médica devolvida porque a auditoria achou um item indevido é o controle funcionando. O retrabalho que importa é o que nasce de falha evitável: dado errado na origem, regra mal configurada, aprovação feita antes de a informação estar completa.

Como ler o lead time

Lead time é o tempo do primeiro ao último evento do caso. É o indicador que mais engana quando lido pela média.

Use mediana e percentil, não só a média

Uma média de 38 dias pode esconder dois processos: um que fecha em 20 e outro que leva 70. Olhe três números juntos: a mediana (o caso típico), o percentil 90 (o caso ruim, mas não o pior) e a distribuição em faixas. Quando a distância entre a mediana e o percentil 90 é grande, o problema não é o processo inteiro, é um grupo de casos. O passo seguinte é descobrir o que esse grupo tem em comum. O guia de lead time cobre as definições.

Separe espera de execução

O tempo entre duas atividades é quase sempre espera, e não trabalho. Um pedido que leva 12 dias da requisição à emissão raramente teve 12 dias de alguém trabalhando nele. Teve horas de trabalho e dias de fila. O mapa mostra onde está a fila. É ali que está o gargalo, e não na etapa que a equipe considera mais trabalhosa.

Quebre por atributo

O lead time só vira ação quando é quebrado: por filial, fornecedor, categoria, faixa de valor, convênio, tipo de atendimento, usuário. A pergunta é sempre "onde esse tempo se concentra?". Uma filial com o dobro do tempo das outras é um achado com endereço.

Como ler a conformidade

A análise de conformidade compara o que aconteceu com o que deveria acontecer: a política, a alçada, o modelo desenhado. Ela aponta cada caso que tomou um atalho. Os desvios mais comuns em processos administrativos:

• pedido de compra criado depois da nota fiscal;
• aprovação fora da alçada, ou feita pela mesma pessoa que pediu;
• pagamento sem entrada de mercadoria;
• fracionamento de pedido para ficar abaixo do limite de aprovação;
• etapa obrigatória pulada, como a cotação acima de um valor.

O detalhamento de cada tipo está em análise de conformidade. Para interpretar, classifique cada desvio em duas dimensões. A primeira é a gravidade: o desvio é risco de fraude, risco fiscal, perda de preço ou só falta de formalidade? A segunda é a intenção do processo: o desvio é falha, ou é a forma que a operação encontrou para funcionar porque a regra não cabe na realidade? Um pedido retroativo em compra emergencial de manutenção pode ser a única forma de não parar a fábrica. Nesse caso a correção é criar um caminho formal para a emergência, e não punir quem a usou.

E desconfie da taxa de conformidade alta demais. Às vezes ela só significa que a regra testada é fácil de cumprir, ou que o desvio acontece fora do sistema, onde o log não vê.

Do sintoma à causa: o que o mapa não responde

Os quatro grupos de achados acima são sintomas. O log diz que 15% dos pedidos foram aprovados duas vezes. Ele não diz por quê. Três caminhos levam à causa, e os bons diagnósticos usam os três.

1. Cruzar atributos. Os casos com o problema têm algo em comum? Mesmo fornecedor, mesma categoria, mesmo aprovador, mesma faixa de valor, mesmo mês? Uma concentração forte costuma apontar a causa direto.
2. Abrir casos concretos. Escolha dez casos do grupo problemático e leia a história de cada um, evento por evento, com os documentos ao lado. A causa costuma aparecer no terceiro ou quarto caso.
3. Perguntar a quem executa. O que acontece fora do sistema, em planilha, e-mail e mensagem, explica boa parte dos desvios. É aqui que entra o mapeamento de processos com IA, em que um agente entrevista todas as pessoas da área e devolve o trabalho que o log não registra.

Uma regra prática: não leve para a reunião de priorização nenhum achado sem uma hipótese de causa escrita. Achado sem causa vira discussão. Achado com causa vira decisão.

Como transformar os achados em plano de melhoria priorizado

Com os achados e suas causas em mãos, o plano sai de quatro perguntas por achado.

1. Quanto vale, em reais por ano? Horas de trabalho perdidas, preço pago acima do histórico, multa, juro, desconto perdido, glosa. Se não dá para pôr em reais, ponha em horas e diga a premissa.
2. Quanto custa corrigir? Esforço em semanas de pessoas e se precisa de TI, de mudança de política ou de tecnologia nova.
3. Qual o risco de não corrigir? Alguns desvios valem pouco em reais e muito em risco, como a segregação de funções quebrada.
4. Quem é o dono? Achado sem dono não sai do relatório.

Com isso, cada achado cai em um de quatro quadrantes: valor alto e esforço baixo (faça já), valor alto e esforço alto (planeje), valor baixo e esforço baixo (agrupe e resolva em lote) e valor baixo e esforço alto (registre e não faça agora). O risco entra como exceção: um achado de risco alto sobe de quadrante mesmo com valor baixo.

Exemplo com números

Os números abaixo são hipotéticos, de um contas a pagar ilustrativo, e servem para mostrar a mecânica da priorização. A empresa extraiu 12 meses do ERP: 9.600 faturas. O custo carregado da hora é de R$ 80, premissa declarada.

Achado	Medida no log	Conta do valor anual	Valor anual	Esforço	Prioridade
Fatura bloqueada por divergência de preço com o pedido	1.920 faturas (20%)	1.920 × 35 min ÷ 60 × R$ 80	R$ 89.600	Médio: revisar a tolerância e a origem do preço no pedido	1
Pagamento com multa por atraso	310 faturas, R$ 41 mil em multa e juro	Valor direto lido no lançamento	R$ 41.000	Baixo: alerta de vencimento na fila de bloqueio	2
Lançamento manual da mesma nota em duas etapas	2.400 faturas (25%)	2.400 × 8 min ÷ 60 × R$ 80	R$ 25.600	Alto: integração de recebimento	4
Aprovação fora da alçada	96 faturas (1%)	Risco, não horas	Não se aplica	Baixo: ajuste de cadastro de alçada	3, pelo risco
Desconto por antecipação não aproveitado	140 faturas elegíveis	Valor direto: soma do desconto oferecido	R$ 18.200	Baixo: regra de prioridade de pagamento	2

Três leituras saem da tabela. O maior valor não é o maior desvio: a fatura bloqueada ganha por volume, não por gravidade. A aprovação fora da alçada é pequena em reais e sobe na fila por ser risco de controle. E o lançamento em duas etapas, que é o que a equipe mais reclama, fica por último porque o esforço de corrigir é o maior. O plano de 90 dias seria atacar as prioridades 1, 2 e 3, que somam R$ 148.800 por ano de valor estimado e um ajuste de controle, e deixar a integração para o planejamento do ano seguinte.

Os quatro tipos de ação que um achado pode pedir

Nem todo achado de process mining pede tecnologia. Na prática, cada um cai em um destes tipos, e saber qual é o tipo muda o dono e o prazo.

Tipo de ação	Quando é o caso	Exemplo	Quem resolve
Ajuste de regra ou cadastro	A causa é uma configuração errada no sistema	Tolerância de preço muito apertada, alçada desatualizada	Dono do processo com o TI
Política e treinamento	A causa é comportamento ou falta de caminho formal	Compra emergencial sem fluxo próprio	Gestor da área
Automação por regra	A tarefa é repetitiva, estável e tem regra clara	Conferência de três vias em nota padronizada	TI, RPA ou integração
Agente de IA	A tarefa tem volume, decisão e exceção que a regra fixa não cobre	Negociar a recompra de baixo valor, revisar contas antes do faturamento	Operação com agente e alçada definida

A coluna da direita importa. Um achado de configuração entregue ao projeto de automação leva meses para algo que se resolve numa tarde. E uma tarefa de decisão entregue a um robô de regra fixa quebra na primeira exceção. O guia sobre onde aplicar IA nos processos detalha os critérios para separar o caso de automação do caso de agente.

Como medir se a melhoria funcionou

A vantagem do process mining sobre o diagnóstico por entrevista é que o mesmo dado que mostrou o problema mede a correção. Para isso, três cuidados.

• Registre a linha de base antes de agir. O número de cada achado, no período, com a definição exata de como foi medido. Linha de base reconstituída depois da mudança não convence ninguém.
• Meça o indicador do achado, não um indicador geral. Se a ação foi ajustar a tolerância de preço, meça a taxa de faturas bloqueadas por divergência, e não o lead time total do contas a pagar, que mistura tudo.
• Compare janelas equivalentes. Mesmo número de dias úteis, mesmo momento do ciclo de fechamento. Comparar dezembro com fevereiro mede o calendário, não a melhoria.

Quando o dado é atualizado com frequência, a medição vira monitoramento: o desvio aparece enquanto o caso ainda está aberto. É essa passagem, do retrato para o acompanhamento contínuo e para a ação, que define a process intelligence.

Erros comuns na leitura de um diagnóstico de process mining

• Tratar o mapa como o entregável. O mapa é o meio. O entregável é a lista de achados com causa, valor e dono.
• Perseguir a variante rara. Uma variante com 12 casos e um caminho estranho chama atenção e quase nunca vale o esforço, a menos que os 12 casos sejam de valor alto ou de risco.
• Ler a média de tempo sem quebrar. A média esconde o grupo de casos que está causando o problema.
• Confundir controle com retrabalho. Uma devolução que impede um pagamento errado é o processo funcionando.
• Priorizar pelo que a equipe reclama. A dor percebida e o valor medido raramente coincidem. As duas informações importam, mas a ordem do plano vem do valor e do risco.
• Esquecer o que acontece fora do sistema. O log é exato sobre o que passa por ele e cego para o resto. O manifesto da força-tarefa de process mining do IEEE já tratava a qualidade e a completude do log de eventos como condição para qualquer conclusão (Process Mining Manifesto, IEEE Task Force on Process Mining).

Perguntas frequentes

Como interpretar os resultados de um process mining?

Em quatro leituras, nesta ordem: quanto do volume segue o caminho previsto (variantes), o que volta para trás (retrabalho), onde o caso espera (lead time, pela mediana e pelo percentil 90) e o que fura a regra (conformidade). Depois, para cada achado, descubra a causa cruzando atributos, abrindo casos concretos e ouvindo quem executa, ponha um valor em reais com a premissa escrita e ordene por valor, esforço e risco.

O que fazer depois do process mining?

Transformar os achados em plano. Cada achado precisa de causa, valor anual em reais, esforço de correção, risco e dono. Com isso, os achados de valor alto e esforço baixo entram no plano de 90 dias, os de valor alto e esforço alto vão para o planejamento, e a linha de base de cada um é registrada antes de agir, para que o mesmo log meça se a correção funcionou.

Muitas variantes significam que o processo está ruim?

Não necessariamente. O número de variantes depende de quantas atividades foram extraídas e cresce com o detalhe do log. A medida útil é quanto do volume as primeiras cinco ou dez variantes explicam e quanto do volume e do valor segue o caminho previsto. Um processo com 200 variantes e 80% dos casos nas dez primeiras é mais estável do que parece.

Como calcular o custo do retrabalho encontrado no process mining?

Multiplique o número de voltas por ano pelos minutos de trabalho de cada volta, divida por 60 e multiplique pelo custo da hora. O log dá o número de voltas, mas não o tempo de trabalho, que vem de estimativa ou de entrevista com quem executa. Por isso a conta deve trazer a premissa escrita. Voltas que são controle funcionando, como uma devolução que evitou um pagamento errado, não entram.

Por que a média de lead time engana?

Porque ela mistura grupos de casos diferentes. Uma média de 38 dias pode vir de casos de 20 dias e de casos de 70. A leitura correta usa a mediana, o percentil 90 e a distribuição em faixas, e quebra o tempo por filial, fornecedor, categoria ou tipo de caso para achar onde ele se concentra. Separar o tempo de espera do tempo de execução mostra onde está a fila.

Todo achado de process mining precisa de automação?

Não. Boa parte se resolve com ajuste de regra ou de cadastro no próprio sistema, ou com uma política que crie um caminho formal para o que hoje acontece por fora. Automação por regra serve à tarefa repetitiva e estável. Agente de IA serve à tarefa com volume, decisão e exceção. Classificar o tipo de ação antes de escolher a tecnologia evita meses de projeto para um problema de configuração.

Como saber se a melhoria funcionou?

Registrando a linha de base de cada achado antes de agir e medindo depois o indicador específico daquele achado, no mesmo log, em janelas comparáveis. Se a ação foi ajustar a tolerância de preço, o indicador é a taxa de faturas bloqueadas por divergência, e não o lead time geral. Com o dado atualizado com frequência, a medição vira monitoramento contínuo.

Como a UpFlux faz

Na UpFlux, o process mining é a primeira de três camadas. A Process Intelligence lê o processo real a partir dos dados do SAP, do Protheus, do Datasul, do Tasy e do MV, sem alterar nada no sistema, e entrega cada achado com causa, valor em reais e dono, não só o mapa. Na segunda camada, os agentes de IA executam a parte da rotina que o diagnóstico mostrou ser de volume e decisão, dentro desses mesmos sistemas e com alçada definida. Na terceira, o RoAI mede em reais o que cada ação devolveu, no mesmo dado que mostrou o problema.

Para o que o sistema não registra, o censo de processos por agente de IA entrevista todas as pessoas da área e completa o diagnóstico com o trabalho feito em planilha, e-mail e mensagem. Se você já tem um mapa e não sabe por onde começar, ou ainda não tem nenhum, o diagnóstico é o ponto de partida.