Les causes racines de non-qualité des données

par | Data 4 Business, Data Governance

Si votre médecin vous prescrit un sirop contre la toux alors que vous vous râclez la gorge à cause de reflux acides, cela vous fera peut-être un peu de bien localement mais votre problème ressurgira promptement.

Il en va de même pour la non-qualité des données, s’attaquer aux symptômes plutôt qu’aux causes racines est une perte de temps et d’énergie. Ce qui m’amène à la question posée par cet article : quelles sont les causes racines de non-qualité des données ?

Et avant d’y répondre, je vous invite à ouvrir notre dernier article sur les chantiers data quality : les bonnes questions pour réussir.

Reconnaître les symptômes

Les symptômes de mauvaise qualité de données sont variés et nombreux.

De la plainte consommateur aux activités directes de correction de données, on peut également détecter le recommencement de travaux, les incidents d’interfaces applicatives, l’inutilisation de reporting, les décisions trop souvent prises à l’intuition, les chiffres non concordants d’un service à l’autre, l’inefficacité d’une équipe…

Naturellement, chacun de ces symptômes pourrait avoir une autre cause racines que la non-qualité des données. Et seule leur analyse approfondie vous le dira.

Remonter aux causes racines et évaluer l’intérêt d’agir

Employez pour ce faire les méthodes éprouvées comme les 5 pourquoi du Lean Management ou le diagramme des causes et effets d’Ishikawa (d’autres sont sans doute efficaces mais j’ai pu éprouver celles-ci avec succès) : elles vous permettront de hiérarchiser les causes et donc de mieux choisir comment vous souhaitez intervenir.

Car oui, si en médecine la cause racine doit être traitée (dans mon exemple, ni le sirop ni les antiacides ne serviront tant que l’hygiène de vie n’aura pas été améliorée), en entreprise c’est moins évident car il y a parfois des causes auxquelles on ne peut s’attaquer. Pour autant l’action peut rester utile et indispensable alors même qu’on sait ne pas s’attaquer à la cause racine des causes racines.

Peut-être faudra-t-il re-prioriser ou simplement attendre de pouvoir agir sur la cause racine. Chez AEKIDEN, nous priorisons nos initiatives et projets par la valeur, en cohérence avec nos valeurs. Mon conseil est de maîtriser vos causes racines et de faire l’évaluation du ROI des actions que vous imaginer pour les contrer.

5 causes racines majeures de non-qualité des données

Si la ou les causes racines de non-qualité des données dépendent fortement du contexte de l’organisation, on peut par expérience donner celles qui sont le plus souvent rencontrées. Vous noterez qu’il peut évidemment y avoir des liens de causalité même entre ces causes, c’est la beauté du jeu :

L’intuition

La première des raisons, c’est l’absence de capacité de mesure de la qualité des données : si vous ne pouvez évaluer par des indicateurs (KPI) automatisés l’état de qualité des données, vous vous soumettez à l’impression des collaborateurs, par nature virale et peu fiable.

– « Moi je ne consulte même plus le rapport hebdo, il est truffé d’erreurs ! »

– « Depuis qu’ils ont passé Phoenix au format web, je n’ai plus confiance dans les données »

– « Michel a regardé le mois dernier, selon lui les données ne sont pas bonnes »

Vous l’aurez compris, la cause racine numéro 1, ce n’en est pas une : pour savoir si vous avez un problème de data quality, commencez par disposer que quelques KPI fiables, et là seulement vous saurez s’il faut réfléchir aux causes racines.

Un autre jour je vous raconterai les deux missions de data quality où le résultat était « vos données sont bonnes, vos utilisateurs ont juste perdu confiance en elles… »

Nos amis les silos

Les données sont manipulées par des acteurs différents, intervenant au titre de processus différents, à différents moments du cycle de vie de la donnée. Le mot clé ici c’est … non je vous laisse deviner.

Oui la donnée est un objet transverse aux processus de l’organisation et les acteurs de la chaîne de valeur n’en ont peu voire pas conscience. Incidemment, ils se focalisent sur leur usage de la donnée, ignorant les besoins amonts ou avals de leurs collaborateurs.

L’absence de connaissance et de compréhension des autres exigences de l’organisation vis-à-vis d’une donnée implique au mieux l’ignorance de la non-qualité et au pire la production de non-qualité.

La qualité en entrée

L’entrée et/ou la modification des données n’est pas maîtrisée.

Qu’il s’agisse de nouveaux collaborateurs non formés ou de fonctionnalités applicatives non alignées sur les règles de gestion cadrant la donnée et ses usages, cela est producteur de non-qualité.

– « Ça fait deux mois que je laisse vide ce champ en croyant qu’il est réservé aux clients VIP… faut le remplir pour tous les clients ? »

– « Zut je viens d’oublier le genre avant de valider… bah ce sera Monsieur Josiane… c’est fou que l’application ne détecte pas l’incohérence »

– « Vu le turnover de l’équipe, personne ne sait plus comment renseigner cet onglet »

L’expression consacrée pour cette cause racine est « garbage in, garbage out ».

Je me souviens également avoir compris gamin que pour réorienter le courant d’un ruisseau il fallait s’y prendre toujours plus en amont. C’est pareil avec la qualité des données : l’input est critique car la corriger a posteriori est toujours compliqué et coûteux.

La dette informationnelle

Dans quasiment la même catégorie – mais je souhaite le mettre en évidence de manière distincte – et rencontré dans quasiment tous les environnements où j’ai adressé la question : la dette informationnelle – issue elle-même de mauvaises reprise des données.

Vous avec changé deux fois de CRM en 15 ans ? Avez-vous nettoyé vos données à chaque changement d’application ? Non ? Vous avez donc accumulé des données de mauvaise qualité et gagné en dette informationnelle.

Et en récompense vous recevez des reporting qui ne sont plus significatifs, des équipes commerciales peu enclines à renseigner/corriger le CRM, des doublons et autres incohérences qui rendent le travail de relation client impossible… et pourtant le budget alloué à la reprise des données dans les projets applicatifs est souvent le parent pauvre (avec celui pour l’interfaçage au reste du SI, mais c’est un autre sujet… quoi que…).

L’absence d’orientation data-driven

L’absence de data management et de gouvernance des données dans la construction du système d’information de l’entreprise – corollaire malheureux et inévitable de l’absence de conscience du patrimoine informationnel comme contributeur essentiel à l’avantage concurrentiel que pourrait avoir l’organisation dans son écosystème (respirez ici) – est la cause de bien des maux en termes de data quality.

Qu’il s’agisse de l’absence de toute logique référentielle (golden source), de vue d’ensemble sur le cycle de vie des données clients ou produits (pour ne citer qu’elles), de data lake qui se remplissent sans dictionnaire pour en maîtriser le contenu et les sources…

Oui, prendre un peu de temps sur ces sujets vous aidera à être plus efficient opérationnellement (la bonne donnée, en qualité, au bon moment, au bon acteur) mais également à gagner de la valeur (innover sur les usages, prévoir et prescrire, découvrir des opportunités de nouvelles branches du business model).

 

Je ne saurais conclure cette courte liste sans évoquer la cause racine de toutes les causes racines : le manque de culture data de l’organisation.

Et vous, où sont vos problématiques data quality ? Quelles en sont les causes racines ?

Venez échanger avec nos experts et prenez directement contact avec eux.

Abonnez-vous également aux insights AEKIDEN et ne ratez rien de nos publications.