Solução de problemas de dados
Solução de problemas de dados
Os problemas de dados se manifestam de formas específicas: casos que se dividem, eventos na ordem errada, etapas ausentes e números que parecem impossíveis. Esta página parte do sintoma até chegar à causa e, depois, à correção, dentro do ProcessMind, quando uma configuração resolve o problema, ou no arquivo extraído, quando nenhuma outra medida funciona.
Para ver o fluxo de preparação completo, incluindo como devem ser os dados de qualidade e como chegar lá, consulte Limpeza e preparação de dados. Para conhecer as verificações que a plataforma executa nos seus dados, consulte Qualidade dos dados.
Primeiras verificações
Antes de analisar o arquivo de origem, veja o que o ProcessMind já informa:
- A lista vermelha acima dos painéis. Na aba Geral do conjunto de dados, uma lista vermelha identifica o bloqueio: ID do caso, Atividade ou Hora de término ausentes, atividades sem dados, atributos sem valores ou uma incompatibilidade entre um arquivo carregado novamente e o tipo de processo usado no carregamento. Comece por aí.
- O selo e o painel de qualidade. A pontuação considera valores ausentes, valores inconsistentes e problemas de timestamp; o painel detalha atualização, cobertura de atributos e análise de atividades.
- Recomendações de dados da IA. Uma análise do conjunto de dados lista os problemas encontrados e sugere mapeamentos e correções.
- Atributos do conjunto de dados. Defina o nome de exibição, o tipo de dados e o formato do timestamp, ou oculte uma coluna, sem precisar exportar nada novamente.
A maioria dos problemas está relacionada a três campos
ID do caso identifica a instância do processo, Atividade dá nome à etapa e Hora de término a posiciona na linha do tempo. Hora de início, Usuário, Custo e tCO₂e adicionam contexto. Se você mapear um dos campos obrigatórios para a coluna errada, tudo o que vem depois parecerá incorreto.
Sintomas no grafo do processo
Os casos estão divididos em vários casos
Você vê: uma instância do processo aparece como vários casos curtos, com uma ou duas etapas cada, deixando o grafo como uma linha plana de atividades.
Por quê: a coluna mapeada como ID do caso identifica algo menor que a instância do processo, como um item de linha, um número de fatura ou um número de documento de um sistema.
Correção: mapeie a coluna que identifica a instância inteira: o pedido, o chamado ou a solicitação. Se nenhuma coluna fizer isso sozinha, a unificação deverá acontecer antes: una os identificadores em SQL ou no seu processo de ETL para que todos os eventos de uma instância tenham o mesmo ID do caso e, depois, carregue os dados novamente. As convenções de nomenclatura de cada sistema estão descritas em Onde obter dados.
Os eventos estão fora de ordem
Você vê: atividades que acontecem mais tarde aparecem antes das atividades anteriores, como uma fatura datada antes do pedido.
Por quê: há três suspeitos comuns. O timestamp foi interpretado com o formato errado, com um 03/04/2025 valor lido como 4 de março em vez de 3 de abril. Eventos de sistemas em fusos horários diferentes foram misturados sem conversão. Ou a coluna errada foi mapeada como campo de tempo.
Correção: verifique o formato em atributos do conjunto de dados e confirme se o tipo é Timestamp, e não texto. Converta todas as fontes para um único fuso horário antes de combinar as exportações, ordene cada caso pelo timestamp e faça uma verificação pontual de alguns casos do início ao fim.
As etapas estão ausentes
Você vê: o grafo pula uma etapa que certamente acontece.
Por quê: a etapa não deixa rastros nos dados, como uma aprovação por telefone ou uma assinatura em papel, a atividade nunca foi mapeada ou um filtro a removeu da visualização.
Correção: mantenha visíveis as etapas que existem, mas não são registradas, marcando a atividade como uma etapa de fluxo de dados, e mapeie as demais com Mapeamento e desmapeamento de atividades. As atividades não mapeadas aparecem translúcidas, com conexões pontilhadas. Depois, verifique quais filtros estão ativos.
Os casos nunca terminam
Você vê: muitos casos simplesmente param sem chegar a um evento de término.
Por quê: a exportação termina em uma determinada data enquanto os casos ainda estão em andamento, o modelo não tem um evento de término ou a atividade de encerramento não está no conjunto de dados.
Correção: adicione ao modelo um evento de término real ou aceite os casos abertos e mantenha-os fora da análise de tempo, pois as métricas de tempo consideram apenas casos encerrados. Um caso que ainda não terminou não é um erro de dados.
As contagens parecem infladas
Você vê: uma atividade é executada com frequência suspeita ou a contagem de casos é maior que a dos relatórios do negócio.
Por quê: há linhas duplicadas, com o mesmo evento registrado duas vezes por uma integração ou por uma extração repetida.
Correção: remova duplicidades usando o ID do caso, a atividade e o timestamp antes de carregar os dados. O fluxo de preparação explica de onde normalmente vêm as extrações duplicadas.
O mapa está poluído
Você vê: centenas de atividades, a maioria delas técnicas.
Por quê: logins, novas tentativas e tarefas em segundo plano estão na mesma extração que as etapas do negócio.
Correção: oculte os atributos que você não analisa, filtre os eventos que não fazem parte do processo e agrupe eventos de baixo nível na atividade à qual pertencem. Definir o limite entre detalhe e ruído é uma decisão dos especialistas do processo.
Os dados de vários sistemas não estão alinhados
Você vê: o processo tem lacunas onde um sistema deveria ter contribuído.
Por quê: os sistemas são extraídos em momentos diferentes, usam nomes diferentes para a mesma etapa ou uma das extrações foi completamente esquecida.
Correção: alinhe as janelas de extração e o vocabulário de atividades antes de combinar os dados e defina a função de cada conjunto de dados como principal e de comparação, em vez de concatenar arquivos incompatíveis.
Sintomas no conjunto de dados
O carregamento é rejeitado
Você vê: o carregamento termina com um erro ou o arquivo é carregado como uma única coluna.
Por quê: o arquivo não atende a um dos requisitos de estrutura. Os mais comuns são uma linha de cabeçalho ausente, que deve estar na primeira linha, linhas em branco entre os dados, números armazenados como texto e arquivos do Excel cujos dados estão na segunda planilha. Apenas a primeira planilha é lida.
Correção: coloque o cabeçalho na linha 1, remova as linhas em branco, confirme que os números estão formatados como números e mova os dados de eventos para a primeira planilha. Delimitadores e aspas em CSV, TSV e TXT são detectados automaticamente. Portanto, um resultado com uma única coluna geralmente significa que o arquivo não pode ser interpretado. Exporte-o novamente como CSV ou Parquet.
As colunas ou os tipos estão incorretos
Você vê: uma coluna está ausente ou um timestamp é tratado como texto.
Por quê: o arquivo mudou desde o último carregamento ou o tipo foi detectado incorretamente.
Correção: defina manualmente o tipo e o formato dos dados ou oculte a coluna. Depois de substituir um arquivo, verifique a lista vermelha para identificar uma incompatibilidade entre o novo arquivo e o conjunto de dados no qual ele foi carregado.
Os timestamps não são reconhecidos
Você vê: a coluna de timestamp está vazia ou as durações ficam muito longas.
Por quê: o formato é incomum, a ordem de dia e mês depende da localidade, há precisão misturada, com segundos e milissegundos na mesma coluna, ou as conversões de fuso horário foram aplicadas duas vezes.
Correção: defina o formato explicitamente em atributos do conjunto de dados, separe na origem as exportações com precisão misturada e padronize um único fuso horário antes de carregar os dados.
Os valores estão em branco
Você vê: a cobertura de atributos no painel de qualidade mostra lacunas ou um gráfico tem uma categoria nula.
Por quê: o sistema de origem não registra o valor para todos os casos ou a exportação descartou os campos vazios.
Correção: preencha as lacunas na origem quando possível e use funções de tratamento de valores nulos em um atributo calculado quando um valor em branco puder ser substituído por um padrão adequado.
Os nomes das atividades não coincidem
Você vê: “Aprovar pedido” e “Aprovação do pedido” listados como duas atividades com o mesmo significado, ou a mesma etapa com nomes diferentes em cada país.
Por quê: cada sistema de origem usa seu próprio nome para o mesmo trabalho.
Correção: defina um único nome para cada etapa. Depois, normalize os valores na extração ou adicione um atributo calculado que mapeie as variações para um único nome e faça o mapeamento da atividade a partir dele.
Sintomas nos números
As médias parecem baixas demais
Você vê: uma duração média de caso que o negócio não considera realista.
Por quê: as métricas de tempo consideram apenas casos encerrados, então os casos inacabados são excluídos. Além disso, os casos concluídos costumam ser os mais rápidos, especialmente em um período recente.
Correção: compare situações equivalentes. Restrinja o período aos casos que tiveram tempo para terminar, leia as definições em Métricas de tempo antes de tirar conclusões com base em uma única média e observe a distribuição, não apenas a média.
As médias são dominadas por valores atípicos
Você vê: médias muito acima do caso típico.
Por quê: alguns poucos casos extremos elevam a média. Às vezes, são exceções reais; outras vezes, são erros de dados.
Correção: analise a cauda dos casos lentos, comparando P90 com a mediana, em vez da média. Verifique se os casos extremos são legítimos e exclua apenas o que estiver realmente errado. Uma exceção rara, mas real, é um insight. Métricas de tempo explica cada medida.
Uma comparação não mostra nada
Você vê: um conjunto de dados de comparação informa Não presente (0 casos, 0% de cobertura).
Por quê: os filtros ativos ou o período selecionado não contêm casos desse conjunto de dados ou as atividades dele não estão mapeadas para o modelo.
Correção: amplie o período, verifique o mapeamento do conjunto de dados de comparação e confirme qual conjunto de dados é o principal.
Quando o problema é o tamanho dos dados
Alguns problemas não são erros de dados, mas de escala:
- Carregamentos lentos: prefira Parquet ou ORC e, para arquivos do Excel, XLSB em vez de XLSX. Consulte Formatos de dados compatíveis.
- Arquivos em crescimento: adicione novos períodos com um carregamento incremental (delta) em vez de substituir o arquivo inteiro.
- Análise lenta: remova as colunas que ninguém analisa, filtre o caminho feliz quando estiver procurando exceções e analise um período ou uma região por vez. O guia de performance mostra o impacto do tamanho dos dados.
- Conjuntos de dados que podem ser arquivados: arquive o que você não analisa mais para que o espaço de trabalho contenha os dados sobre os quais você realmente toma decisões.
Corrigindo na origem
Toda correção feita dentro do ProcessMind evita uma nova ida e volta, mas alguns problemas só desaparecem na origem: um sistema de origem ausente, fusos horários misturados ou identificadores que nenhuma exportação unifica. Esses problemas devem ser resolvidos na extração e, se voltarem a ocorrer, no sistema que a produz. Consulte Onde obter dados para conhecer as opções de cada sistema e ETL para Process Mining para ver as práticas que mantêm uma extração confiável.
Ainda com problemas?
Se as verificações acima não explicarem o que você está vendo, entre em contato com o time de suporte e informe o nome do conjunto de dados, o caso analisado, o que você esperava e o que aparece na prática. Uma captura de tela do grafo e outra do painel de qualidade geralmente resolvem a questão mais rápido que uma descrição.
Tópicos relacionados
- Qualidade dos dados - o que o selo verifica e como ler o painel
- Configurando seu conjunto de dados - a lista vermelha de validação e os campos obrigatórios
- Formatos de dados compatíveis - linhas de cabeçalho, planilhas e tipos de arquivo
- Limpeza e preparação de dados - o fluxo de preparação completo
- Carregamento incremental de dados - conjuntos de dados em crescimento sem novos carregamentos
- Perguntas frequentes - as perguntas mais comuns