O custo de combustível por milha em um Hub de distribuição, Elm Yard, aumentou 9% ao longo de dois meses. A plataforma de telemática que monitorava os mesmos caminhões durante o mesmo período não mostrou nenhuma mudança na quilometragem, nenhuma rota nova nem alteração no tempo ocioso. Nenhum dos números estava errado.
Essa combinação é o modo de falha de que trata este texto: não dados corrompidos, mas dois sistemas que reportam com precisão, cada um a partir de sua própria fonte da verdade, e que nunca foram projetados para funcionar em conjunto. A plataforma de cartões de combustível monitora o que o cartão de um driver cobrou. A plataforma de telemática monitora por onde um caminhão passou fisicamente. Ambos fizeram seu trabalho, e a discrepância estava no espaço entre eles, não dentro de nenhum dos dois.
A comparação padrão é de agregado para agregado: o gasto total com combustível deste mês em relação ao do mês passado, a quilometragem total deste mês em relação à do mês passado. Essa comparação oculta o tipo exato de incompatibilidade em questão aqui, porque nunca analisa as transações e viagens individuais por trás dos totais. Dois agregados podem divergir por motivos que nada têm a ver com a qualidade dos dados e tudo a ver com definições, agendamentos e regras de negócios que ninguém registrou em um só lugar.
As equipes que apenas comparam totais só descobrem uma discrepância dias ou semanas depois que ela começou a gerar custos. Quando um número consolidado parece errado, a incompatibilidade por trás dele geralmente já está ocorrendo silenciosamente há algum tempo. Foi exatamente o que aconteceu em Elm Yard.
Por que os números divergem: os quatro mecanismos por trás das discrepâncias entre sistemas
As discrepâncias entre sistemas surgem a partir de quatro mecanismos, e quase todo caso que parece misterioso pode ser rastreado até um deles: defasagens de tempo e latência, lógicas de negócios divergentes entre os sistemas, desvios de esquema ou categorização e registros duplicados ou parciais.
A defasagem de tempo e latência é a mais simples de explicar e a mais fácil de diagnosticar incorretamente. O feed de cartões de combustível da Elm Yard lançava as transações no mesmo dia em que o motorista passava o cartão. O feed de quilometragem da telemática era atualizado em um lote noturno. Um caminhão abastecido na segunda-feira à noite só mostrava a quilometragem correspondente depois da execução do lote da manhã de terça-feira — uma defasagem de um dia que a equipe inicialmente interpretou como uma divergência real e passou uma semana inteira investigando, antes que alguém comparasse os dois cronogramas de atualização diretamente.
Uma lógica de negócios divergente é mais silenciosa e difícil de detectar, porque ambos os sistemas podem estar funcionando exatamente como foram projetados. A consulta de consolidação de gastos com combustível filtrava estritamente os códigos de categoria de comerciante 5541 e 5542, os dois códigos marcados como “combustível”. Quando o posto de combustível para caminhões perto de Elm Yard adicionou um balcão de café, a rede de cartões reclassificou o comerciante sob o MCC 5499, “loja de conveniência”. As transações de combustível continuaram fluindo para o feed de dados brutos exatamente como antes; elas apenas deixaram de entrar no bucket de “custo de combustível” que a consulta da equipe financeira foi criada para capturar, porque uma regra oculta em uma consulta não correspondia mais a uma regra que a rede de cartões havia alterado silenciosamente.
O desvio de esquema e de categorização também aparece em lugares menos óbvios. O mesmo mecanismo, uma definição que muda sem que ninguém decida mudá-la, pode transformar um limite de cerca virtual deslocado em uma sinalização de tempo de permanência “fora do local” em um sistema de despacho da noite para o dia. A plataforma de despacho não quebrou. Sua definição de onde o pátio termina mudou alguns metros, e tudo nas etapas seguintes herdou esse deslocamento.
Registros duplicados ou parciais completam a lista e se comportam de maneira diferente dos outros três, porque ambos os registros existem e nenhum deles está tecnicamente errado. Alguns motoristas da Elm Yard ainda registram a quilometragem manualmente em papel em vez de depender da unidade de telemática. Esses registros manuais ficam próximos ao valor da telemática para a mesma viagem, mas raramente são exatos, variando por alguns décimos de milha ou por um horário de início arredondado. Apagar o registro que pareça “extra” descarta informações; um registro quase duplicado precisa de uma correção diferente da de um duplicado verdadeiro.
Rastreie qualquer um desses quatro até a origem e eles convergem para a mesma causa-raiz. Superficialmente, cada um parece um problema de qualidade de dados. Por trás disso, trata-se de uma definição, um agendamento ou uma regra de negócio que mudou em um sistema e não no outro, sem que ninguém ficasse atento ao distanciamento entre os dois.
Vale a pena refletir por um instante: qual destas quatro opções tem mais chances de já estar ativa, sem ser detectada, nos sistemas que a sua própria equipe compara todo mês?
Quanto custa uma discrepância não detectada antes que alguém a chame de problema de dados
A equipe da Elm Yard passou seis semanas tratando um artefato de dados como uma tendência operacional antes que alguém questionasse o método de comparação em si. Essa janela de seis semanas é onde o custo real se acumulou, não no número de 9% em si, mas em cada decisão tomada enquanto a equipe acreditava que o número era real.
A equipe de manutenção recolheu dois veículos para revisão depois que ambos foram sinalizados como “alto consumo de combustível” durante esse trecho. Os mecânicos não encontraram nada de errado em nenhum dos dois caminhões. As sinalizações tinham vindo da discrepância fantasma de 9% entre dois sistemas, e não de algo que estivesse acontecendo nos caminhões, e a oficina perdeu horas diagnosticando equipamentos que nunca foram o problema.
A anomalia subiu tanto na hierarquia que a liderança começou a elaborar uma proposta para renegociar o contrato do fornecedor de cartões de combustível, baseada em uma tendência de custos que não existia. Uma negociação com fornecedor fundamentada em um artefato de dados custa caro para ser revertida depois que já está em andamento, e esta quase foi além de um rascunho.
Esse não é um problema exclusivo de uma equipe de frotas. A Gartner estima o custo médio anual da baixa qualidade dos dados para as organizações na casa dos milhões de dólares, e a pesquisa da Forrester sobre o tema revelou que uma parcela significativa de profissionais de dados relata perdas de US$ 25 milhões ou mais ligadas à mesma causa-raiz: dados que pareciam utilizáveis e nunca foram verificados em relação aos sistemas com os quais deveriam concordar.
O custo menos visível dura mais do que o próprio incidente. Quando uma equipe de roteamento ou de finanças se queima com uma falsa tendência, ela também começa a desconsiderar sinais reais dos mesmos sistemas. Uma anomalia legítima seis meses depois gera apenas um dar de ombros em vez de uma investigação, porque a última acabou não sendo nada, e essa erosão da confiança é mais difícil de reparar do que foi encontrar a discrepância original.
Há também uma perspectiva de risco de auditoria aqui, que importa mais para os líderes de analytics do que para a equipe em campo. Uma discrepância dessa dimensão passou despercebida por seis semanas, motivou uma decisão de manutenção e quase chegou a um contrato com fornecedor. Essa é uma lacuna de rastreabilidade sobre a qual um auditor eventualmente perguntará, não porque alguém tenha feito algo errado, mas porque ninguém conseguiu mostrar quando os dois sistemas começaram a divergir ou por que levou seis semanas para que alguém percebesse. Seis semanas é muito tempo para uma tendência fantasma persistir sem ser questionada, e é por isso que a próxima seção começa com design, e não com ferramentas.
O que um design de detecção resiliente faz de diferente
Um design de detecção resiliente compara registros individuais entre dois sistemas e gera como resultado o que coincidiu, o que não coincidiu e o motivo. Ele nunca se limita a comparar dois totais agregados, porque foi exatamente nos totais que a discrepância de Elm Yard ficou escondida por seis semanas.
O guia de mapeamento de origem para destino do Alteryx aborda diretamente esse tipo de incompatibilidade entre sistemas: como os campos se movem, se transformam e, às vezes, são descartados silenciosamente entre um sistema e outro. Vale a pena ler independentemente das ferramentas que uma equipe acabe usando para resolver o problema descrito.
As equipes que já tentam unificar dados de sistemas de ERP, armazém e frota em uma visão comparável também podem considerar os recursos de supply chain analytics da Alteryx uma leitura adicional útil, não como uma solução específica para o caso da Elm Yard, mas como contexto sobre o que a unificação desse tipo de dados multissistema realmente envolve.
Aplicada ao Elm Yard, a comparação em nível de registro significa fazer a junção do feed de transações de cartão de combustível ao log de eventos de telemática e despacho com base no ID do veículo e em uma janela de carimbo de data/hora, em vez de comparar os gastos totais com combustível deste mês com a quilometragem total deste mês. Depois que essa junção for executada, os registros sem correspondência se tornam o objeto de investigação em vez da lacuna agregada. Uma ferramenta desenvolvida para comparar registros entre fontes e identificar correspondências e não correspondências entre conjuntos de dados gera três resultados: registros que tiveram correspondência, registros que existiam apenas no feed de cartão de combustível e registros que existiam apenas no feed de telemática. Esse segundo bucket, transações de cartão de combustível sem correspondência de telemática, é onde as cobranças reclassificadas por MCC teriam aparecido diretamente logo no primeiro dia, em vez de como uma tendência vaga seis semanas depois.
Os logs manuais de quilometragem precisam de uma abordagem diferente, porque eles não estão ausentes em nenhum dos sistemas. Eles simplesmente nunca coincidem exatamente. A comparação da quilometragem inserida pelo motorista com os registros de telemetria exige uma ferramenta desenvolvida para identificar duplicatas não idênticas em diferentes arquivos de entrada, usando um limite de similaridade configurável em vez de uma regra de correspondência exata. Essa é a diferença entre identificar que “estes dois registros descrevem a mesma viagem” e exigir que “estes dois registros sejam idênticos”, o que os logs manuais nunca serão.
Além disso, nem toda duplicata aparente é de fato uma. Uma ferramenta criada para separar registros exclusivos de duplicados é útil aqui, mas sua própria documentação inclui um alerta sincero: dois registros que parecem idênticos, com o mesmo nome e os mesmos valores aproximados, podem não descrever de fato a mesma coisa. Vale a pena sinalizar isso para que uma pessoa verifique, em vez de resolver por conta própria.
O perfilamento dos campos de cada fonte antes da execução de qualquer comparação é o que teria identificado o problema de MCC logo no início, em vez de seis semanas depois. O perfilamento no nível da coluna, abrangendo nulos, valores únicos, intervalos de valores e valores mínimos e máximos, sinaliza exatamente o tipo de alteração discreta que afetou o resumo dos gastos com combustível: um conjunto de valores de campo mudando sem que ninguém altere uma consulta. Antes de qualquer dado ser comparado, padronizar o uso de maiúsculas/minúsculas, a pontuação e os códigos nos dois feeds garante que uma diferença de formatação nunca seja confundida com uma discrepância real, em primeiro lugar.
Nada disso é executado por conta própria. Cada elemento aqui — a junção, a correspondência por similaridade, a verificação de duplicatas e o perfil — é algo que uma equipe configura para seus próprios dois sistemas, não um recurso que examina um ambiente e gera relatórios sem intervenção. O princípio de design importa mais do que qualquer ferramenta isolada: compare registros, não totais, e crie a comparação para que ela continue sendo executada, em vez de esperar que alguém perceba que um número parece estranho.
Como adaptar a detecção a sistemas que já existem
A detecção de adaptações não exige a substituição do sistema de cartões de combustível, da plataforma de telemática ou dos sistemas de despacho e manutenção relacionados a eles. Ela exige uma camada de comparação programada entre eles, que não existia antes e executa a Junção automaticamente, em vez de esperar que uma pessoa faça uma verificação pontual dos totais uma vez por mês.
Os sistemas já existem. O que falta é um fluxo de trabalho executado de acordo com um agendamento, e não uma nova fonte de dados. A criação desse fluxo de trabalho se resume a três passos.
Padronize os códigos de comerciante e de categoria e os carimbos de data/hora em ambos os feeds antes de juntá-los primeiro, para que uma reclassificação como a mudança de MCC não faça a comparação falhar silenciosamente uma segunda vez. Execute a junção ou a comparação por correspondência parcial em um agendamento vinculado à frequência com que os dados subjacentes realmente são atualizados a seguir, todas as noites para corresponder ao ciclo em lote de telemática, em vez de qualquer cadência especificada por um calendário de auditoria. Encaminhe registros não correspondentes a um responsável específico para revisão por último, em vez de permitir que eles parem em uma exportação que ninguém abre. Esse terceiro passo diferencia a detecção de uma discrepância em dias da detecção em semanas: um arquivo de registros não correspondentes sem o nome de ninguém associado se comporta exatamente como a exportação que ninguém verificou em Elm Yard durante seis semanas.
A justificativa para criar isso agora, em vez de mais tarde, fica mais forte à medida que os volumes de dados aumentam. A pesquisa da McKinsey sobre a adoção de dados corporativos e IA até 2030 aponta para a mesma pressão: à medida que os volumes de dados e os casos de uso orientados por IA se expandem, a disciplina de monitorar como os dados se movem e são definidos entre os sistemas se torna mais necessária, e não menos. A comparação manual e ad hoc não escala bem com esse crescimento. Uma camada de comparação programada se torna mais valiosa à medida que o número de sistemas e o volume que flui por eles aumentam.
A assistência em linguagem natural, como o Ask Alteryx, pode ajudar uma equipe a criar ou configurar um fluxo de trabalho de comparação como esse com mais rapidez, especialmente para analistas que não vão codificar uma junção manualmente. Vale a pena tratar isso como uma ajuda na criação de fluxos de trabalho, e não como algo que encontra a discrepância por conta própria; nenhuma ferramenta atual faz essa parte automaticamente. Quando uma discrepância é rastreada até uma alteração de definição ou de fluxo de trabalho, os logs de auditoria filtráveis podem ajudar a mostrar o que mudou e quando, o que importa mais para o líder de analytics que precisa responder pela lacuna de seis semanas do que para o analista que executa a junção.
Nada disso é a única resposta certa. Equipes cuja lógica de comparação é genuinamente complexa, de alto volume ou já gerenciada pela engenharia de dados podem ser mais bem atendidas por um pipeline baseado em código, Python, dbt ou SQL, do que por um fluxo de trabalho de comparação com pouco código. O verdadeiro teste é quem é responsável pela lógica hoje. Se essa resposta for um analista que faz isso quando pode, um fluxo de trabalho agendado soluciona uma lacuna real; se uma equipe de engenharia de dados já executa seu próprio pipeline, esse pipeline provavelmente é o lugar certo para adicionar essa comparação, em vez de sobrepor uma nova ferramenta a ele.
Comece com a junção que você ainda não executou
A maneira mais rápida de descobrir se esse modo de falha já está ativo em seus próprios sistemas é executar uma junção no nível do registro entre dois sistemas que deveriam concordar e observar o que não corresponde. Não uma auditoria completa. Uma junção, dois sistemas, uma análise honesta do resultado não correspondente.
O Alteryx One foi projetado para dar suporte a esse tipo de trabalho de comparação entre sistemas, unindo, combinando, criando perfis e limpando dados, sem precisar escrever código personalizado, o que é fundamental para equipes em que a lógica de comparação pertence aos analistas, e não a um backlog da engenharia de dados.
Comece uma avaliação gratuita do Alteryx One e execute a comparação com os seus dois sistemas. A lacuna, se houver, não ficará oculta por seis semanas.