Toute organisation qui investit dans un entrepôt de données finit par découvrir le même fait inconfortable : l'entrepôt ne corrige pas la qualité des données, il donne seulement aux mauvaises données un chemin plus rapide et plus visible pour atteindre tout le monde. Les tableaux de bord qui étaient discrètement faux sont désormais faux publiquement, en temps réel, devant une équipe dirigeante qui pensait que l'investissement dans l'infrastructure de données avait déjà réglé ce problème.
L'instinct à ce moment-là est d'ajouter davantage de nettoyage : des règles de validation, des tâches de déduplication, des scripts de rapprochement qui s'exécutent la nuit et corrigent le pire des dégâts avant que la direction ne les voie. Cela traite le symptôme en laissant la maladie intacte. Les problèmes de qualité des données ne sont, dans l'écrasante majorité des cas que nous observons, pas créés dans l'entrepôt du tout. Ils sont créés en amont, dans le processus opérationnel qui génère la donnée en premier lieu, et aucune quantité de nettoyage en aval ne corrige durablement un problème fabriqué à nouveau chaque jour.
Où naissent réellement les mauvaises données
Prenons une adresse client erronée dans un système de reporting. La réaction instinctive est de corriger l'adresse dans l'entrepôt de données. Mais l'adresse était erronée parce qu'un agent de centre d'appels, travaillant selon un script optimisé pour la durée de traitement plutôt que pour l'exactitude, l'a mal saisie au moment de la capture, et rien dans ce processus n'a changé. La correction dans l'entrepôt répare l'erreur d'hier. L'erreur identique de demain est déjà en train d'être créée, par le même processus, pour la même raison structurelle, et devra être corrigée de nouveau la semaine prochaine.
Ce schéma se répète pour presque tous les problèmes de qualité des données qui valent la peine d'être résolus : des fiches clients dupliquées créées parce que deux systèmes capturent le même client via des canaux différents sans identifiant commun, une catégorisation de produits incohérente parce que deux départements décrivent le même article différemment pour leur propre commodité, des valeurs manquantes parce qu'un formulaire rend facultatif un champ dont l'entreprise a réellement besoin qu'il soit rempli. Dans chaque cas, la donnée est un enregistrement fidèle d'un processus défaillant, pas un défaut de la donnée elle-même.
Un entrepôt ne crée pas la qualité des données. Il donne seulement aux mauvaises données un chemin plus rapide vers les personnes qui prennent des décisions avec elles.
La propriété est l'ingrédient manquant
La raison pour laquelle ce problème persiste dans la plupart des organisations est que personne n'est responsable de la qualité des données au point où elles sont créées. Les équipes data sont tenues responsables de l'état des données dans l'entrepôt, qu'elles n'ont pas générées et qu'elles ne peuvent souvent pas corriger à la source, tandis que les équipes opérationnelles qui créent réellement les données n'ont aucune responsabilité sur leur qualité, car leur performance est mesurée sur la vitesse, le volume ou le coût, jamais sur l'exactitude en aval de ce qu'elles produisent.
Corriger cela exige une conversation véritablement inconfortable sur les incitations. Un centre d'appels mesuré uniquement sur la durée moyenne de traitement sacrifiera toujours l'exactitude des données au profit de la vitesse lorsque les deux entrent en tension, car c'est ce que récompense l'indicateur. Tant que la qualité des données ne deviendra pas une responsabilité mesurée et assumée par l'équipe opérationnelle qui la crée, plutôt qu'un mandat non financé confié à une équipe data en aval, les mêmes erreurs continueront d'arriver au même rythme, indéfiniment.
- ·Retracer les problèmes de qualité des données jusqu'au processus opérationnel qui les a créés
- ·Confier la responsabilité de la qualité à l'équipe qui génère la donnée, pas seulement à celle qui la stocke
- ·Modifier l'incitation si le processus récompense la vitesse au détriment de l'exactitude
- ·Considérer le nettoyage en aval comme un confinement, pas comme un remède
À quoi ressemble une bonne prise de responsabilité en pratique
Dans les organisations qui gèrent bien cela, un problème de qualité des données déclenche une conversation avec le responsable du processus en amont, pas seulement une correction dans un pipeline de transformation. Des indicateurs existent au point de capture, pas seulement au point de reporting, de sorte qu'un centre d'appels ou une équipe commerciale peut voir l'exactitude de ce qu'il produit et en est mesuré au même titre que ses objectifs existants. Les systèmes sont repensés, lorsque c'est possible, pour rendre le bon comportement le comportement facile : des identifiants partagés qui empêchent les doublons plutôt que des scripts de déduplication qui les nettoient après coup, des champs obligatoires qui reflètent ce dont l'entreprise a réellement besoin plutôt que ce qui était pratique à construire.
Rien de tout cela n'élimine entièrement le besoin de nettoyage des données ; certains problèmes de qualité sont véritablement historiques et certains systèmes ne peuvent pas être modifiés rapidement. Mais cela déplace l'effort d'une opération de nettoyage en aval permanente vers une opération plus modeste et décroissante, car moins de nouvelles erreurs sont créées chaque jour à la source.
Pourquoi cela n'est presque jamais corrigé
La raison honnête pour laquelle la plupart des organisations ne franchissent jamais ce cap est que cela exige que les responsables data aient de l'influence sur des processus opérationnels qu'ils ne possèdent pas, et que les responsables opérationnels acceptent un nouvel indicateur qu'ils n'ont pas demandé. Ce sont là des combats organisationnels, pas techniques, et ils sont nettement moins confortables à mener que la commande d'un nouvel outil de nettoyage.
Mais l'arithmétique est implacable. Un pipeline de nettoyage qui traite indéfiniment la même catégorie d'erreur chaque semaine ne résout pas un problème, il le subventionne. Les organisations qui finissent par briser ce cycle sont celles prêtes à avoir la conversation la plus difficile sur l'origine réelle des données, et à tenir la bonne équipe responsable de ce qu'elle produit.
Si votre organisation exécute encore chaque semaine le même travail de rapprochement pour corriger la même catégorie d'erreur, l'outil n'est pas le problème. Le processus qui fabrique cette erreur chaque jour n'a jamais reçu l'instruction de changer, et il ne changera pas de lui-même.