Qualidade dos dados, tratamento e limpeza
O diagnóstico da base operacional e a prestação de contas do tratamento aplicado.
1.1Em uma página
A base operacional da Trans Fictício BR foi examinada por inteiro: 18 tabelas, 133 colunas e 31.163.097 registros, referentes à carga de 2026-08-27. Foram encontrados 7 problemas, dos quais 4 de severidade alta.
O resumo honesto é este: a base está estruturalmente saudável e é utilizável. Não há duplicata de chave, não há inversão de datas, não há número impossível e nenhuma referência aponta para registro inexistente. Os problemas encontrados se concentram no texto digitado por pessoas e em duas ausências que são de processo, não de sistema.
O que isso significa na prática. Os defeitos de digitação nós corrigimos, e a correção está prestada conta neste documento. Os dois achados de processo (transferência sem recebedor e item sem valor) não foram corrigidos de propósito: preenchê-los seria inventar informação que ninguém coletou, e apagaria do relatório justamente o que precisa chegar até vocês.
1.2O estado da base, problema por problema
Cada problema abaixo traz o que ele causa no dia a dia, o que foi feito com ele e o que ainda depende de decisão de vocês. A leitura técnica de cada um está no Relatório Técnico.
A mesma cidade cadastrada de quatro jeitos
alta tratadoUm relatório por cidade mostrava São Paulo dividida em quatro linhas, cada uma com uma parte do volume. Qualquer decisão tomada sobre concentração geográfica, dimensionamento de frota ou escolha de base partia de um número menor do que o real, e o erro não aparecia na tela: as quatro linhas pareciam quatro cidades legítimas.
Evidência: 121 valores em grafia múltipla reduzidos a 0.
Endereço abreviado e por extenso na mesma base
alta tratadoO mesmo endereço escrito como R. das Flores e como Rua das Flores é tratado como dois destinos diferentes por qualquer sistema que cruze a base com mapa, CEP ou malha de rotas. Metade dos cruzamentos falha em silêncio, e o custo por rota sai errado sem que nada acuse erro.
Evidência: 10.097 abreviados reduzidos a 0.
O mesmo endereço cadastrado mais de uma vez
alta marcado333 endereços físicos existem no cadastro em duplicata, somando 676 registros. Um cliente atendido nos dois cadastros aparece como dois pontos de entrega, o que distorce contagem de pontos atendidos, produtividade por rota e qualquer análise de cobertura. Não fundimos os cadastros, porque eliminar registro quebraria o histórico dos pedidos antigos e a escolha de qual cadastro sobrevive é decisão de vocês, não nossa.
Evidência: 333 grupos, 676 cadastros, 343 registros seriam eliminados numa fusão.
Transferência para base não registra quem recebeu
alta preservadoEm 1.241.334 transferências entre bases, o campo de quem recebeu a carga está vazio. Na última milha, o mesmo campo está preenchido em 99,97% dos casos. A diferença não é falha de digitação, é ausência de processo: não existe conferência formal na chegada à base. Isso significa que, entre a saída de uma base e a chegada na outra, não há responsável identificado pela carga.
Evidência: 1.241.334 ausências no Bronze e as mesmas 1.241.334 no Silver.
Nome de quem recebeu digitado de formas diferentes
média tratadoOs 56 nomes distintos de recebedor na base eram, na verdade, 32 pessoas escritas de jeitos diferentes. Uma análise de recorrência de recebedor por cliente estaria dividida quase pela metade, e o erro é invisível na tela porque Maria Silva e Maria Silva parecem idênticos.
Evidência: 56 nomes distintos reduzidos a 32.
Itens sem valor unitário
média preservado345 itens do cadastro não têm valor unitário. Toda conta que dependa de valor da carga (seguro, indenização, priorização por valor) ignora esses itens ou os trata como se valessem zero. Não preenchemos nenhum deles, porque inventar um valor de mercadoria é criar um número que ninguém coletou e que entraria em cálculo financeiro como se fosse real.
Evidência: 345 ausências no Bronze e as mesmas 345 no Silver.
Observação de ocorrência preenchida com texto sem conteúdo
baixa tratado717 ocorrências tinham a observação preenchida com -, N/A ou sem informacao. Num agrupamento por motivo de ocorrência, esses valores apareceriam como se fossem uma categoria real, competindo em volume com motivos de verdade e sujando o ranking que orienta a ação da operação.
Evidência: 717 registros convertidos para ausência.
1.3O que mexemos nos seus dados
Esta seção existe porque a pergunta que sempre vem depois de uma limpeza não é "vocês limparam?", é "o que vocês mexeram?". A resposta está abaixo, e ela é verificável célula a célula, porque a cópia original permanece intocada e disponível para comparação.
A base tem 190.194.916 campos preenchidos ao todo. Alteramos 190.991 deles, o que é 1 campo em cada 995. As correções se concentraram em 5 campos de texto, todos de preenchimento manual:
O que não foi tocado é o mais importante desta lista. Nenhum peso, volume, quantidade, valor, data ou número de documento foi alterado. Nenhuma chave que liga uma tabela à outra foi modificada. Todo indicador operacional e financeiro que vocês já usam continua saindo dos mesmos números de antes.
As três garantias que conferimos uma a uma
| Garantia | Resultado |
|---|---|
| Nenhum registro foi perdido nem agregado | 18 de 18 tabelas com a contagem exata de antes |
| Nenhum campo vazio foi preenchido com valor inventado | 1.241.334 e 345 ausências chegaram intactas do lado de cá |
| Rodar o processo de novo dá o mesmo resultado | as 7 regras de tratamento são idempotentes |
1.4O que depende de vocês
Nem tudo que encontramos se resolve no nosso lado. Os pontos abaixo são de decisão ou de sistema de origem, e enquanto não forem tratados na fonte, voltam a cada nova carga.
| # | Ponto | Quem decide | O que precisa acontecer |
|---|---|---|---|
| Q1 | A mesma cidade cadastrada de quatro jeitos | Operação e TI | O cadastro de endereço aceita texto livre no campo de cidade. Enquanto não houver validação ou lista de municípios na entrada, o problema volta na próxima carga. |
| Q2 | Endereço abreviado e por extenso na mesma base | Operação e TI | O campo de logradouro é texto livre. Vale avaliar preenchimento assistido por CEP na tela de cadastro. |
| Q3 | O mesmo endereço cadastrado mais de uma vez | Operação e TI | Conferir os 333 grupos e decidir quais cadastros são o mesmo lugar. A decisão precisa de registro de quem decidiu e quando, porque é irreversível. |
| Q4 | Transferência para base não registra quem recebeu | Operação e TI | Definir se a conferência na chegada à base passa a ser obrigatória. É decisão de operação, com impacto em responsabilidade sobre avaria e extravio. |
| Q5 | Nome de quem recebeu digitado de formas diferentes | TI | O aplicativo do motorista aceita texto livre onde poderia haver seleção ou validação. É a origem do ruído. |
| Q6 | Itens sem valor unitário | TI | Definir a regra de valor para item sem preço cadastrado, ou completar o cadastro. |
Duas decisões travam trabalho futuro. A regra de valor para os itens sem preço (Q6) precisa existir antes de qualquer cálculo financeiro por carga, e a conferência dos endereços duplicados (Q3) precisa acontecer antes de qualquer análise de cobertura geográfica. As duas são decisões de negócio, e nós não as tomamos no lugar de vocês.
1.5O caminho do projeto
Este documento cresce a cada etapa concluída. O capítulo abaixo marcado como concluído é o que vocês estão lendo agora; os demais entram aqui conforme forem entregues.
| Capítulo | O que entrega | Situação |
|---|---|---|
| 1. Qualidade dos dados, tratamento e limpeza | O diagnóstico da base operacional e a prestação de contas do tratamento aplicado. | concluído |
| 2. O que os dados dizem sobre a operação | A leitura analítica do histórico: prazo por etapa, concentração, sazonalidade e as heurísticas do negócio confrontadas com o que o dado mostra. | previsto |
| 3. Previsão de atraso e nova data prevista | O modelo de previsão de OTIF e a projeção de nova data de entrega, com o desempenho medido e as limitações declaradas. | previsto |
| 4. Operação do modelo e monitoramento | Como o modelo entra em produção, como é acompanhado e o que dispara uma reavaliação. | previsto |
A ordem não é negociável por um motivo técnico: modelo treinado sobre dado sujo aprende a sujeira. Só depois de a base estar conformada e a conformação estar prestada conta é que faz sentido perguntar o que os dados dizem sobre a operação, e só depois disso faz sentido prever.
O que os dados dizem sobre a operação
A leitura analítica do histórico: prazo por etapa, concentração, sazonalidade e as heurísticas do negócio confrontadas com o que o dado mostra.
Este capítulo entra aqui quando a etapa for entregue. Aparece desde já, de propósito: o caminho inteiro do projeto fica visível desde a primeira reunião, e não só o trecho pronto.
Previsão de atraso e nova data prevista
O modelo de previsão de OTIF e a projeção de nova data de entrega, com o desempenho medido e as limitações declaradas.
Este capítulo entra aqui quando a etapa for entregue. Aparece desde já, de propósito: o caminho inteiro do projeto fica visível desde a primeira reunião, e não só o trecho pronto.
Operação do modelo e monitoramento
Como o modelo entra em produção, como é acompanhado e o que dispara uma reavaliação.
Este capítulo entra aqui quando a etapa for entregue. Aparece desde já, de propósito: o caminho inteiro do projeto fica visível desde a primeira reunião, e não só o trecho pronto.