El costo de combustible por milla en un centro de distribución, Elm Yard, aumentó un 9 % en dos meses. La plataforma de telemática que rastreaba los mismos camiones durante el mismo período no mostró cambios en el millaje, ninguna ruta nueva ni variaciones en el tiempo de inactividad. Ninguno de los dos números era incorrecto.
Esa combinación es el modo de falla del que trata este artículo: no datos dañados, sino dos sistemas en los que cada uno reporta con precisión a partir de su propia fuente de verdad y que nunca se diseñaron para coincidir entre sí. La plataforma de tarjetas de combustible registra lo que se cargó a la tarjeta de un conductor. La plataforma de telemática registra adónde fue físicamente un camión. Ambos hicieron su tarea, y la discrepancia se encontraba en el espacio entre ellos, no dentro de ninguno de los dos.
La comparación estándar es de agregado a agregado: el gasto total en combustible de este mes frente al del mes pasado, el kilometraje total de este mes frente al del mes pasado. Esa comparación oculta el tipo exacto de discrepancia en juego aquí, porque nunca analiza las transacciones y los viajes individuales que componen los totales. Dos agregados pueden diferir por razones que no tienen nada que ver con la calidad de los datos y sí con definiciones, programaciones y reglas de negocio que nadie documentó en un solo lugar.
Los equipos que solo comparan totales se enteran de una discrepancia días o semanas después de que comenzó a costarles. Para cuando un número consolidado parece incorrecto, la discrepancia subyacente por lo general ha estado ocurriendo de forma silenciosa durante un tiempo. Eso es exactamente lo que sucedió en Elm Yard.
Por qué los números no coinciden: los cuatro mecanismos detrás de las discrepancias entre sistemas
Las discrepancias entre sistemas provienen de cuatro mecanismos, y casi todos los casos que parecen misteriosos se remontan a uno de ellos: desfase temporal y de latencia, diferencias en la lógica de negocio entre sistemas, desviación de esquemas o categorización, y registros duplicados o parciales.
El retraso de tiempo y latencia es el más sencillo de explicar y el más fácil de diagnosticar erróneamente. La fuente de tarjetas de combustible de Elm Yard registraba las transacciones el mismo día en que el conductor pasaba la tarjeta. La fuente de kilometraje de telemática se actualizaba en un lote nocturno. Un camión que cargaba combustible el lunes por la noche no mostraba el kilometraje correspondiente hasta que se ejecutaba el lote del martes por la mañana, un desfase de un día que el equipo interpretó inicialmente como una discrepancia real y pasó una semana entera investigando antes de que alguien comparara directamente las dos programaciones de actualización.
Una lógica de negocio discrepante es más silenciosa y difícil de detectar, porque ambos sistemas pueden estar funcionando exactamente como se diseñaron. La consulta de acumulación de gastos de combustible filtraba estrictamente según los códigos de categoría de comerciante 5541 y 5542, los dos códigos marcados como “combustible”. Cuando la parada de camiones cerca de Elm Yard añadió un mostrador de café, la red de tarjetas reclasificó al comerciante bajo el MCC 5499, “tienda de conveniencia”. Las transacciones de combustible continuaron ingresando al flujo de datos sin procesar exactamente como antes; simplemente quedaron fuera del bucket de “costo de combustible” que la consulta del equipo de finanzas estaba diseñada para capturar, porque una regla oculta en una consulta ya no coincidía con una regla que la red de tarjetas había modificado silenciosamente.
La deriva del esquema y de la categorización también aparece en lugares menos evidentes. El mismo mecanismo, una definición que cambia sin que nadie decida cambiarla, puede convertir de la noche a la mañana el límite desplazado de una geocerca en una alerta de tiempo de permanencia “fuera del sitio” en un sistema de despacho. La plataforma de despacho no falló. La definición de dónde termina el patio se desplazó unos pocos pies, y todo lo posterior en el proceso heredó ese cambio.
Los registros duplicados o parciales completan la lista y se comportan de forma diferente a los otros tres porque ambos registros existen y ninguno es técnicamente incorrecto. Algunos conductores de Elm Yard todavía registran el kilometraje manualmente en papel en lugar de depender de la unidad telemática. Esas entradas manuales se acercan a la cifra de telemática para el mismo viaje, pero rara vez coinciden exactamente: difieren por unas pocas décimas de milla o por una hora de inicio redondeada. Eliminar el registro que parece “adicional” descarta información; un registro casi duplicado necesita una solución diferente a la de un duplicado real.
Rastrea cualquiera de estos cuatro elementos lo suficientemente atrás y convergerán en la misma causa raíz. En apariencia, cada uno parece un problema de calidad de los datos. En el fondo, se trata de una definición, una programación o una regla de negocio que cambió en un sistema y no en el otro, sin que nadie vigile que ambos empiecen a diferir.
Vale la pena pensarlo por un segundo: ¿cuál de estos cuatro es más probable que ya esté activo, sin ser detectado, en los sistemas que tu propio equipo compara cada mes?
Lo que cuesta una discrepancia no detectada antes de que alguien la llame un problema de datos
El equipo de Elm Yard pasó seis semanas tratando un artefacto de datos como una tendencia operativa antes de que alguien cuestionara el método de comparación en sí. Esa ventana de seis semanas es donde se acumuló el costo real, no en la cifra del 9 % en sí, sino en cada decisión tomada mientras el equipo creía que la cifra era real.
El personal de mantenimiento ingresó dos vehículos a revisión después de que ambos fueran señalados por “alto consumo de combustible” durante ese período. Los mecánicos no encontraron ningún problema en ninguno de los camiones. Las alertas provenían de la brecha fantasma del 9 % entre dos sistemas, no de nada que estuviera ocurriendo dentro de los camiones, y el taller perdió horas diagnosticando un equipo que nunca fue el problema.
La anomalía escaló tanto en la cadena de mando que los líderes comenzaron a elaborar un caso para renegociar el contrato del proveedor de tarjetas de combustible, basado en una tendencia de costos que no existía. Una negociación con un proveedor basada en un artefacto de datos es costosa de revertir una vez que ya está en marcha, y esta casi fue más allá de un borrador.
Este no es un problema exclusivo de un solo equipo de flota. Gartner estima que el costo anual promedio de la mala calidad de los datos para las organizaciones asciende a millones de dólares, y las investigaciones de Forrester sobre el tema revelaron que una proporción significativa de los profesionales de datos informa pérdidas de $25 millones o más vinculadas a la misma causa raíz: datos que parecían utilizables y nunca se cotejaron con los sistemas con los que debían coincidir.
El costo menos visible perdura más allá del incidente en sí. Una vez que un equipo de enrutamiento o de finanzas se ve afectado por una tendencia falsa, también comienza a desestimar las señales reales de los mismos sistemas. Una anomalía legítima seis meses después recibe un encogimiento de hombros en lugar de una investigación, porque la última resultó no ser nada, y esa pérdida de confianza es más difícil de reparar de lo que fue encontrar la discrepancia original.
Aquí también hay una perspectiva de riesgo de auditoría, una que les importa más a los líderes en analítica que al equipo en el terreno. Una discrepancia de esta magnitud pasó desapercibida durante seis semanas, impulsó una decisión de mantenimiento y casi llega a un contrato con un proveedor. Esa es una brecha de trazabilidad sobre la que un auditor tarde o temprano preguntará, no porque alguien haya hecho algo mal, sino porque nadie pudo demostrar cuándo comenzaron a discrepar los dos sistemas o por qué se tardó seis semanas en notarlo. Seis semanas es mucho tiempo para que una tendencia fantasma se ejecute sin cuestionamientos, y es la razón por la que la siguiente sección comienza con el diseño, no con las herramientas.
Lo que hace diferente un diseño de detección resiliente
Un diseño de detección resiliente compara registros individuales entre dos sistemas y genera qué coincidió, qué no y por qué. Nunca se detiene en comparar dos totales agregados, porque los totales son exactamente donde se ocultó la discrepancia de Elm Yard durante seis semanas.
La guía de mapeo de origen a destino de Alteryx aborda directamente este tipo de desajuste entre sistemas: cómo los campos se mueven, se transforman y, a veces, se pierden silenciosamente entre un sistema y otro. Vale la pena leerla, independientemente de las herramientas que un equipo termine usando para solucionar el problema que describe.
Los equipos que ya intentan unificar datos entre sistemas de ERP, almacén y flota en una vista comparable también pueden encontrar útiles como lectura adicional los recursos de analítica de la cadena de suministro de Alteryx, no como una solución específica para el caso de Elm Yard, sino como contexto sobre lo que realmente implica unificar ese tipo de datos multisistema.
Aplicada a Elm Yard, la comparación a nivel de registro implica unir el flujo de transacciones de tarjetas de combustible con el registro de eventos de telemática y despacho según el ID del vehículo y una ventana de marcas de tiempo, en lugar de comparar el gasto total de combustible de este mes con el kilometraje total de este mes. Una vez que se ejecuta esa unión, los registros sin coincidencia se convierten en el objeto de investigación en lugar de la brecha agregada. Una herramienta diseñada para comparar registros entre fuentes e identificar coincidencias y no coincidencias entre conjuntos de datos produce tres resultados: registros que coincidieron, registros que existían solo en el flujo de tarjetas de combustible y registros que existían solo en el flujo de telemática. Ese segundo Bucket, las transacciones de tarjetas de combustible sin coincidencia en telemática, es donde los cargos reclasificados por MCC habrían aparecido directamente desde el primer día, en lugar de como una tendencia imprecisa seis semanas después.
Los logs manuales de kilometraje requieren un enfoque diferente, porque no faltan en ninguno de los dos sistemas. Simplemente nunca coinciden exactamente. Comparar el kilometraje ingresado por los conductores con los registros telemáticos requiere una herramienta diseñada para identificar duplicados no idénticos en diferentes archivos de entrada, mediante un umbral de similitud configurable en lugar de una regla de coincidencia exacta. Esa es la diferencia entre detectar “estos dos registros describen el mismo viaje” y exigir que “estos dos registros sean idénticos”, algo que los logs manuales nunca serán.
Tampoco todo duplicado aparente lo es en realidad. Una herramienta creada para separar registros únicos de duplicados resulta útil en este caso, pero su propia documentación incluye una sincera advertencia: dos registros que parecen idénticos, con el mismo nombre y las mismas cifras aproximadas, podrían no describir en realidad lo mismo. Vale la pena marcarlo para que una persona lo revise en lugar de que se resuelva por sí solo.
Crear perfiles de los campos de cada fuente antes de que se ejecute cualquier comparación es lo que habría detectado a tiempo el problema de MCC en lugar de a las seis semanas. La creación de perfiles a nivel de columna, que abarca nulos, únicos, rangos de valores y mínimos y máximos, detecta exactamente el tipo de cambio silencioso que afectó al resumen de gastos de combustible: el conjunto de valores de un campo cambia sin que nadie edite una consulta. Antes de que se compare cualquier dato, estandarizar mayúsculas y minúsculas, puntuación y códigos en ambas fuentes permite evitar, en primer lugar, que una diferencia de formato se confunda con una discrepancia real.
Nada de esto se ejecuta por sí solo. Cada pieza aquí, la unión, la coincidencia por similitud, la verificación de duplicados, el perfil, es algo que un equipo configura para sus propios dos sistemas, no una característica que analiza un entorno y genera informes de forma desatendida. El principio de diseño importa más que cualquier herramienta individual: compara registros, no totales, y crea la comparación para que se siga ejecutando en lugar de esperar a que alguien note que un número parece incorrecto.
Cómo incorporar la detección en sistemas que ya existen
Adaptar la detección no requiere reemplazar el sistema de tarjetas de combustible, la plataforma telemática ni los sistemas de despacho y mantenimiento que los rodean. Requiere una capa de comparación programada entre ellos que antes no existía, una que ejecute la unión automáticamente en lugar de esperar a que una persona verifique puntualmente los totales una vez al mes.
Los sistemas ya existen. Lo que falta es un flujo de trabajo que se ejecute según una programación, no una nueva fuente de datos. Crear ese flujo de trabajo se reduce a tres pasos.
Estandariza los códigos de comerciante y categoría y las marcas de tiempo en ambas fuentes antes de unirlas, de modo que una reclasificación como el cambio de MCC no pueda romper silenciosamente la comparación por segunda vez. Ejecuta la comparación de unión o coincidencia difusa según una programación vinculada a la frecuencia con la que los datos subyacentes realmente se actualizan, por la noche para coincidir con el ciclo por lotes de telemática en lugar de cualquier cadencia que un calendario de auditoría pueda especificar. Envía por último los registros sin coincidencia a un propietario específico con nombre para su revisión, en lugar de dejar que terminen en una exportación que nadie abre. Ese tercer paso marca la diferencia entre detectar una discrepancia en días o detectarla en semanas: un archivo de registros sin coincidencia sin el nombre de nadie asignado se comporta exactamente igual que la exportación que nadie revisó en Elm Yard durante seis semanas.
El argumento para crear esto ahora, en lugar de más adelante, se vuelve más sólido a medida que crecen los volúmenes de datos. La investigación de McKinsey sobre la adopción empresarial de datos e IA hasta 2030 apunta a la misma presión: a medida que aumentan los volúmenes de datos y los casos prácticos impulsados por IA, la disciplina de rastrear cómo se mueven y se definen los datos en todos los sistemas se vuelve más necesaria, no menos. La comparación manual y ad hoc no escala de manera óptima con ese crecimiento. Una capa de comparación programada se vuelve más valiosa a medida que aumentan tanto la cantidad de sistemas como el volumen que fluye a través de ellos.
La asistencia mediante lenguaje natural, como Ask Alteryx, puede ayudar a un equipo a crear o configurar más rápido un flujo de trabajo de comparación como este, especialmente a los analistas que no van a programar manualmente una unión. Vale la pena considerarla como ayuda para crear flujos de trabajo, no como algo que encuentra la discrepancia por sí solo; ninguna herramienta actual hace esa parte automáticamente. Una vez que se identifica que una discrepancia se debe a un cambio en el flujo de trabajo o en la definición, los logs de auditoría filtrables pueden ayudar a mostrar qué cambió y cuándo, lo cual le importa más al líder de analítica que debe responder por la brecha de seis semanas que al analista que ejecuta la unión.
Nada de esto es la única respuesta correcta. Los equipos cuya lógica de comparación sea realmente compleja, de gran volumen o que ya esté a cargo del equipo de ingeniería de datos pueden beneficiarse más de un pipeline basado en código, Python, dbt o SQL, que de un flujo de trabajo de comparación de código simple. La verdadera prueba es quién es el responsable de la lógica hoy. Si esa respuesta es un analista que se encarga de ello cuando puede, un flujo de trabajo programado resuelve una brecha real; si un equipo de ingeniería de datos ya ejecuta su propio pipeline, es probable que ese pipeline sea el lugar adecuado para agregar esta comparación en lugar de superponer una nueva herramienta sobre él.
Comienza con la unión que aún no has ejecutado
La forma más rápida de descubrir si este modo de falla ya está activo en tus propios sistemas es ejecutar una unión a nivel de registro entre dos sistemas que deberían coincidir y observar qué no coincide. No una auditoría completa. Una unión, dos sistemas, una mirada honesta a la salida no coincidente.
Alteryx One está diseñado para admitir ese tipo de trabajo de comparación entre sistemas (unir, cotejar, perfilar y limpiar datos sin necesidad de escribir código personalizado), lo cual es fundamental para los equipos donde la lógica de comparación corresponde a los analistas en lugar de a un backlog de ingeniería de datos.
Comienza una prueba gratuita de Alteryx One y ejecuta la comparación con tus propios dos sistemas. La brecha, si la hay, no permanecerá oculta durante seis semanas.