Le coût du carburant par mile dans un hub de distribution, Elm Yard, a augmenté de 9 % sur deux mois. La plateforme télématique suivant les mêmes camions sur la même période n'a montré aucun changement de kilométrage, aucun nouvel itinéraire et aucune variation du temps de marche au ralenti. Aucun des deux nombres n'était erroné.
Cette combinaison correspond au mode de défaillance dont traite cet article : il ne s'agit pas de données corrompues, mais de deux systèmes qui transmettent chacun des informations exactes depuis leur propre source de référence et qui n'ont jamais été conçus pour s'accorder entre eux. La plateforme de cartes carburant enregistre les montants débités sur la carte d'un conducteur. La plateforme télématique suit les déplacements physiques d'un camion. Tous deux ont fait leur travail, et la divergence se situait dans l'espace qui les sépare, et non à l'intérieur de l'un ou de l'autre.
La comparaison standard se fait d'agrégat à agrégat : les dépenses totales de carburant de ce mois-ci par rapport à celles du mois dernier, le kilométrage total de ce mois-ci par rapport à celui du mois dernier. Cette comparaison masque précisément le type de divergence en jeu ici, car elle n'examine jamais les transactions et les trajets individuels sous-jacents aux totaux. Deux agrégats peuvent diverger pour des raisons qui n'ont rien à voir avec la qualité des données, et tout à voir avec des définitions, des planifications, et des règles métier que personne n'a consignées au même endroit.
Les équipes qui ne comparent que les totaux ne découvrent une anomalie que des jours ou des semaines après qu'elle a commencé à leur coûter cher. Au moment où un chiffre agrégé semble erroné, l'anomalie sous-jacente persiste généralement en silence depuis un certain temps. C'est exactement ce qui s'est passé à Elm Yard.
Pourquoi les chiffres ne concordent pas : les quatre mécanismes à l'origine des écarts entre systèmes
Les divergences entre systèmes proviennent de quatre mécanismes, et presque chaque cas semblant mystérieux remonte à l'un d'eux : le décalage temporel et de latence, des logiques métier différentes d'un système à l'autre, la dérive de schéma ou de catégorisation, et les enregistrements en double ou partiels.
Le décalage temporel et de latence est le plus simple à expliquer et le plus facile à diagnostiquer à tort. Le flux de cartes carburant d'Elm Yard enregistrait les transactions le jour même où le conducteur utilisait sa carte. Le flux de données télématiques relatives au kilométrage était actualisé lors d'un traitement par lots nocturne. Un camion faisant le plein le lundi soir n'affichait pas de kilométrage correspondant avant l'exécution du traitement par lots du mardi matin, un décalage d'un jour que l'équipe a d'abord interprété comme une véritable incohérence et qu'elle a passé une semaine entière à analyser avant que quelqu'un ne compare directement les deux planifications d'actualisation.
Une logique métier divergente est plus discrète et plus difficile à détecter, car les deux systèmes peuvent fonctionner exactement comme prévu. La requête de cumul des dépenses de carburant filtrait strictement sur les codes de catégorie de commerçant 5541 et 5542, les deux codes marqués « carburant ». Lorsque le relais routier près d'Elm Yard a ajouté un comptoir de café, le réseau de cartes a reclassé le commerçant sous le code MCC 5499, « commerce de proximité ». Les transactions de carburant continuaient d'arriver dans le flux de données brutes exactement comme avant ; elles ont simplement disparu du compartiment « coût du carburant » que la requête de l'équipe financière était conçue pour intercepter, parce qu'une règle enfouie dans une requête ne correspondait plus à une règle que le réseau de cartes avait discrètement modifiée.
La dérive de schéma et de catégorisation se manifeste également dans des endroits moins évidents. Le même mécanisme, une définition qui évolue sans que quiconque ait décidé de la modifier, peut transformer du jour au lendemain une limite de géorepérage décalée en un indicateur de temps de présence « hors site » dans un système de répartition. La plateforme de répartition n'a pas cessé de fonctionner. Sa définition de la limite du site s'est déplacée de quelques mètres, et tout ce qui se trouve en aval a hérité de ce décalage.
Les enregistrements en double ou partiels complètent la liste, et ils se comportent différemment des trois autres, car deux enregistrements existent, sans qu'aucun des deux ne soit techniquement erroné. Certains conducteurs d'Elm Yard consignent encore manuellement le kilométrage sur papier, au lieu de s'appuyer sur le boîtier télématique. Ces saisies manuelles sont proches de la valeur télématique pour le même trajet, mais rarement identiques, avec quelques dixièmes de mile d'écart ou une heure de départ arrondie. Supprimer l'enregistrement qui paraît « en trop » entraîne la perte d'informations ; un quasi-doublon nécessite une solution différente de celle d'un véritable doublon.
Remontez suffisamment loin l'un de ces quatre éléments, et ils convergent vers la même cause première. En apparence, chacun d'eux ressemble à un problème de qualité des données. En réalité, il s'agit d'une définition, d'une planification, ou d'une règle métier qui a changé dans un système et pas dans l'autre, sans que personne ne surveille la divergence qui s'installe entre les deux.
Prenez un instant pour y réfléchir : laquelle de ces quatre situations est la plus susceptible d'être déjà présente, sans être détectée, dans les systèmes que votre propre équipe compare chaque mois ?
Ce que coûte une divergence non détectée avant que quiconque ne la qualifie de problème de données
L'équipe d'Elm Yard a passé six semaines à traiter un artefact de données comme une tendance opérationnelle avant que quiconque ne remette en question la méthode de comparaison elle-même. C'est au cours de cette période de six semaines que le coût réel s'est accumulé, non pas dans le chiffre de 9 % lui-même, mais dans chaque décision prise alors que l'équipe pensait que ce chiffre était réel.
Le service de maintenance a immobilisé deux véhicules pour examen après qu'ils ont tous deux été signalés pour « consommation élevée de carburant » pendant cette période. Les mécaniciens n'ont rien trouvé d'anormal sur aucun des deux camions. Les alertes provenaient de l'écart fantôme de 9 % entre deux systèmes, et non d'un dysfonctionnement au niveau des camions, et l'atelier a perdu des heures à diagnostiquer des équipements qui n'avaient jamais posé problème.
L'anomalie est remontée suffisamment haut dans la hiérarchie pour que la direction commence à préparer un dossier visant à renégocier le contrat du fournisseur de cartes carburant, sur la base d'une tendance de coûts qui n'existait pas. Une négociation avec un fournisseur fondée sur un artefact de données est coûteuse à annuler une fois qu'elle est déjà engagée, et celle-ci a failli aller plus loin qu'un simple projet.
Ce problème n'est pas propre à une seule équipe de flotte. Gartner estime le coût annuel moyen de la mauvaise qualité des données pour les entreprises à plusieurs millions de dollars, et les recherches de Forrester sur le sujet ont révélé qu'une part significative de professionnels des données signalent des pertes de 25 millions de dollars ou plus liées à la même cause première : des données qui semblaient exploitables et qui n'ont jamais été vérifiées par rapport aux systèmes avec lesquels elles étaient censées concorder.
Le coût le moins visible perdure au-delà de l'incident lui-même. Dès lors qu'une équipe de routage ou financière a été échaudée par une fausse tendance, elle commence également à ignorer les signaux réels provenant de ces mêmes systèmes. Six mois plus tard, une véritable anomalie ne suscite qu'un haussement d'épaules au lieu d'une enquête, parce que la précédente s'est révélée n'être rien, et cette érosion de la confiance est bien plus difficile à réparer que l'anomalie initiale ne l'a été à détecter.
Il y a également ici un angle lié au risque d'audit, qui compte davantage pour les responsables analytiques que pour l'équipe sur le terrain. Une divergence de cette ampleur est passée inaperçue pendant six semaines, a motivé une décision de maintenance et a failli aboutir à un contrat fournisseur. C'est un défaut de traçabilité sur lequel un auditeur finira par poser des questions, non pas parce que quelqu'un a commis une faute, mais parce que personne n'a pu montrer à quel moment les deux systèmes ont commencé à diverger ou pourquoi il a fallu six semaines pour s'en apercevoir. Six semaines, c'est long pour laisser une tendance fantôme persister sans être remise en question, et c'est la raison pour laquelle la section suivante commence par la conception, et non par les outils.
Ce qu'une conception de détection résiliente fait différemment
Une conception de détection résiliente compare les enregistrements individuels entre deux systèmes et indique ce qui concordait, ce qui ne concordait pas, et pourquoi. Elle ne se limite jamais à comparer deux totaux agrégés, car c'est exactement dans les totaux que l'anomalie d'Elm Yard est restée masquée pendant six semaines.
Le guide de mappage source-cible d'Alteryx aborde directement ce type d'incompatibilité entre systèmes : comment les champs se déplacent, se transforment et parfois disparaissent discrètement d'un système à l'autre. Il vaut la peine d'être lu, quels que soient les outils qu'une équipe finit par utiliser pour résoudre le problème qu'il décrit.
Les équipes qui tentent déjà d'unifier les données des systèmes ERP, d'entrepôt et de flotte en une vue comparable trouveront peut-être également une lecture utile dans les ressources d'analytique de la chaîne d'approvisionnement d'Alteryx, non pas comme une solution spécifique au cas d'Elm Yard, mais comme un éclairage sur ce qu'implique réellement l'unification de ce type de données multisystèmes.
Appliquée à Elm Yard, la comparaison au niveau des enregistrements consiste à joindre le flux de transactions de cartes de carburant au journal des événements de télématique et de répartition sur l'identifiant du véhicule et une fenêtre d'horodatage, plutôt qu'à comparer les dépenses totales de carburant de ce mois-ci au kilométrage total de ce mois-ci. Une fois cette jointure exécutée, les enregistrements sans correspondance deviennent l'objet de l'investigation au lieu de l'écart global. Un outil conçu pour comparer des enregistrements entre plusieurs sources et identifier les correspondances et les non-correspondances entre jeux de données produit trois résultats : les enregistrements qui correspondent, les enregistrements qui existaient uniquement dans le flux de cartes de carburant et les enregistrements qui existaient uniquement dans le flux de télématique. Ce deuxième compartiment, les transactions par carte de carburant sans correspondance télématique, est celui où les frais reclassifiés par code MCC seraient apparus directement dès le premier jour au lieu d'une vague tendance six semaines plus tard.
Les relevés kilométriques manuels nécessitent une approche différente, car ils ne manquent dans aucun des deux systèmes. Ils ne correspondent tout simplement jamais exactement. Faire correspondre le kilométrage saisi par le conducteur avec les enregistrements télématiques nécessite un outil conçu pour identifier les doublons non identiques dans différents fichiers d'entrée, en utilisant un seuil de similarité configurable plutôt qu'une règle de correspondance exacte. C'est toute la différence entre détecter « ces deux enregistrements décrivent le même trajet » et exiger que « ces deux enregistrements soient identiques », ce que les relevés manuels ne seront jamais.
Toutes les apparences de doublon ne correspondent pas réellement à des doublons. Un outil conçu pour séparer les enregistrements uniques des enregistrements en double est utile ici, mais sa propre documentation comprend une mise en garde honnête : deux enregistrements qui semblent identiques, avec le même nom et des chiffres approximativement identiques, ne décrivent pas nécessairement la même chose. Cela mérite d'être signalé afin qu'une personne puisse le vérifier, plutôt que d'être résolu automatiquement.
Le profilage des champs de chaque source avant toute comparaison est ce qui aurait permis de détecter le problème de MCC dès le début, au lieu de six semaines plus tard. Le profilage au niveau des colonnes, qui couvre les valeurs nulles, les valeurs uniques, les plages de valeurs ainsi que les valeurs minimales et maximales, signale précisément le type de modification discrète qui a affecté le cumul des dépenses de carburant : l'ensemble de valeurs d'un champ qui change sans que personne ne modifie une requête. Avant toute comparaison, la standardisation de la casse, de la ponctuation, et des codes sur les deux flux permet d'éviter dès le départ de confondre une simple différence de formatage avec une réelle divergence.
Rien de tout cela ne fonctionne de manière autonome. Chaque élément ici, la jointure, la correspondance de similarité, la recherche de doublons, le profil, est un élément qu'une équipe configure pour ses deux propres systèmes, et non une caractéristique qui analyse un environnement et transmet des rapports sans intervention humaine. Le principe de conception importe plus que n'importe quel outil unique : comparez les enregistrements, et non les totaux, et concevez la comparaison pour qu'elle continue de s'exécuter au lieu d'attendre que quelqu'un remarque qu'un chiffre semble anormal.
Comment intégrer la détection dans des systèmes qui existent déjà
L'intégration de la détection ne nécessite pas de remplacer le système de cartes carburant, la plateforme télématique, ou les systèmes de répartition et de maintenance qui les entourent. Cela nécessite une couche de comparaison planifiée entre eux qui n'existait pas auparavant, laquelle exécute la jointure automatiquement au lieu d'attendre qu'une personne effectue une vérification ponctuelle des totaux une fois par mois.
Les systèmes existent déjà. Ce qui manque, c'est un workflow qui s'exécute selon une planification, et non une nouvelle source de données. La création de ce workflow se résume à trois étapes.
Standardisez d'abord les codes marchands et de catégories ainsi que les horodatages sur les deux flux avant de les associer, afin qu'une reclassification telle que la modification du MCC ne puisse pas fausser silencieusement la comparaison une deuxième fois. Exécutez ensuite la jointure ou la comparaison par correspondance partielle selon une planification liée à la fréquence réelle d'actualisation des données sous-jacentes, chaque nuit pour correspondre au cycle de traitement par lots de la télématique plutôt qu'au rythme qu'un calendrier d'audit pourrait spécifier. Acheminez enfin les enregistrements non appariés vers un responsable nommément désigné pour examen, plutôt que de les laisser atterrir dans un export que personne n'ouvre. Cette troisième étape fait la différence entre détecter une anomalie en quelques jours ou en plusieurs semaines : un fichier d'enregistrements non appariés auquel aucun nom n'est associé se comporte exactement comme l'export que personne n'a vérifié à Elm Yard pendant six semaines.
L'intérêt de mettre cela en place dès maintenant, plutôt que plus tard, ne fait que se renforcer à mesure que les volumes de données augmentent. L'étude de McKinsey sur l'adoption des données et de l'IA en entreprise d'ici 2030 met en évidence la même pression : à mesure que les volumes de données et les cas d'usage basés sur l'IA se multiplient, la discipline consistant à suivre la circulation et la définition des données à travers les systèmes devient plus que jamais indispensable. Une comparaison manuelle et ad hoc ne permet pas une mise à l'échelle harmonieuse face à cette croissance. Une couche de comparaison planifiée gagne en valeur à mesure que le nombre de systèmes et le volume qui y circule augmentent tous deux.
L'assistance en langage naturel, comme Ask Alteryx, peut aider une équipe à créer ou à configurer plus rapidement un workflow de comparaison de ce type, en particulier pour les analystes qui ne vont pas coder manuellement une jointure. Il convient de la considérer comme une aide à la création de workflows, et non comme un outil capable de trouver l'écart par lui-même ; aucun outil actuel ne réalise cette partie automatiquement. Une fois qu'un écart a été attribué à une modification de workflow ou de définition, les journaux d'audit filtrables peuvent aider à identifier les changements et leur date, ce qui importe davantage pour le responsable analytique devant justifier l'écart de six semaines que pour l'analyste exécutant la jointure.
Aucune de ces options n'est la seule bonne réponse. Les équipes dont la logique de comparaison est réellement complexe, à fort volume ou déjà prise en charge par l'ingénierie des données seront peut-être mieux servies par un pipeline basé sur le code, Python, dbt ou SQL que par un workflow de comparaison low-code. Le véritable test consiste à savoir qui est responsable de la logique aujourd'hui. Si cette réponse est un analyste qui s'en occupe quand il le peut, un workflow planifié comble un véritable manque ; si une équipe d'ingénierie des données exécute déjà son propre pipeline, c'est probablement dans ce pipeline qu'il convient d'ajouter cette comparaison plutôt que de superposer un nouvel outil.
Commencez par la jointure que vous n'avez pas encore exécutée
Le moyen le plus rapide de savoir si ce mode de défaillance est déjà présent dans vos propres systèmes consiste à exécuter une jointure au niveau de l'enregistrement entre deux systèmes censés concorder, et à examiner ce qui ne correspond pas. Pas un audit complet. Une jointure, deux systèmes, un regard honnête sur la sortie non concordante.
Alteryx One est conçu pour prendre en charge ce type de travail de comparaison intersystèmes, en associant, appariant, profilant et nettoyant les données, sans avoir à écrire de code personnalisé, ce qui compte le plus pour les équipes où la logique de comparaison relève des analystes plutôt que d'un backlog d'ingénierie des données.
Commencez un essai gratuit d'Alteryx One et lancez la comparaison sur vos deux propres systèmes. L'écart, s'il y en a un, ne restera pas caché pendant six semaines.