Anecdotes
Que faire des données sans correspondances ? Vive l’inconnu !
En décisionnel, l’objectif est d’intégrer des données afin de les étudier selon des axes. Par exemple, on souhaitera étudier les quantités de ventes (les faits) d’un produit (présent dans un référentiel). On aura donc, en entrée du système, une source « Ventes » et autre une source « Produits ». Lors de l’intégration, on traitera ces deux sources et, pour les relier, on utilisera un champ commun (l’identifiant unique du produit, par exemple). Dans l’ETL, c’est une étape de « lookup » qui fait le travail.
Cependant, au moment de relier les ventes aux produits, il arrive de ne pas trouver de correspondance. On se retrouve, dans notre exemple, avec une vente faite sur un produit non référencé, absent du référentiel. Gênant ensuite pour les études !
Impossible à relier ... que faire ?
Deux choix se présentent alors :
- ne pas prendre en compte les ventes qui ne rencontrent pas de correspondances
- les traiter et mettre en évidence l’absence de lien avec un produit connu
Le comportement #1 est évidemment à proscrire : si le produit n’existe pas, sa vente est par contre belle et bien réelle. Dans la somme permettant de calculer un chiffre d’affaire, la vente doit être prise en compte. On ne peut pas se permettre de l’ignorer.
Le comportement #2 est la solution à suivre. Pour cela, on va créer un produit fictif, un produit « PRODUIT INCONNU » auquel on pourra relier toutes les ventes dont on ne trouve pas le produit dans le référentiel ! La somme des ventes restera donc correcte. Certes dans le reporting l’utilisateur verra : « Produit A, Produit B, … Produit Z, Produit INCONNU ». Mais au moins le total sera bon.
De mon expérience, le taux d’inconnus est en général, d’environ 10 % … au moins ! Cest souvent bien plus ! Et c’est grave car les faits reliés à des produits inconnus sont bien des erreurs. Avec une dizaine de %, cela veut dire que les données en amont du processus décisionnel ne sont pas d’excellente qualité. Et si le taux est de 80 %, il faut se poser des questions sur la qualité de l’intégration et l’ensemble des sources.
Avec la solution de la mise en inconnu, en plus de conserver les valeurs pour les calculs, le but est que cela fasse réagir le client (ou en tout cas l’utilisateur cible). Sa réaction sera simple : « C’est quoi toutes ces valeurs en INCONNU ?? Ca ne me va pas ça ! ». Il sera alors facile de lui faire comprendre que pour avoir un reporting de qualité, il doit mettre également des moyens dans la qualité de données amont.
Une fois les problématiques d’intégrations résolues, il pourra se concentrer sur la vraie valeur du système décisionnel.
C'est quoi ce produit "inconnu" là ?
Petite anecdote pour finir : un client a demandé, lors d’un projet, de renommer les produits « inconnus » en « divers » afin de masquer les erreurs dans le système. Hors de question, bien sûr ! Mais il est vrai que, dans son reporting, le produit « INCONNU » était le deuxième produit le plus vendu 😉
Avez vous une autre astuce pour traiter ce problème ?
Comment sensibilisez-vous les utilisateurs à la qualités des données sources ?
Tags: Discussion
7 commentaires pour “Que faire des données sans correspondances ? Vive l’inconnu !”
Poster un commentaire
Incroyable ta dernière remarque, qu’avez vous fait ? Redressement de données ? Modification dans l’affichage ?
Concernant la démarche globale, j’ajouterais que le choix #2 permet en plus d’analyser la donnée suivant d’autres axes d’analyse qui eux peuvent être corrects. (ex: le magasin, le client …)
Le choix 1 (« ne pas prendre en compte les ventes qui ne rencontrent pas de correspondances ») est plus rare mais peut parfois avoir un intérêt. Si je m’intéresse aux ventes des clients ayant une carte de fidélités pour des statistiques d’achat par exemple, je n’ai pas besoin d’avoir l’exhaustivité des ventes. Perdre les données pour lesquelles je n’ai pas de code client n’est dans ce cas pas grave.
Sur certains besoins, il est parfois nécessaire de compléter l’élément ‘Inconnu’ par l’élément ‘Non renseigné’ qui permet de distinguer le cas où un produit est mal codifié du cas où il est volontairement non renseigné.
@Brice : Nous avons tenté de lui expliquer de nouveau le sens des « inconnus », il a dû se résoudre à laisser cela et à participer à l’amélioration des sources en amont. Le CoDir, qui recevait les rapports, a un peu moins rigolé cependant 😉
@Brice : Bonne remarque pour ton point #2. Il faut gérer l’inconnu sur chacun des axes, ce qui permet de « minimiser les pertes »
@Alexis : Bien vu l’exemple pour le choix #1. Cependant, ça ne « coûte rien » de gérer les inconnus.
@Alexis : Bonne précision pour l’élément « Non renseigné ». Distinguer et disposer des deux permet de mieux gérer le type de données traitées. Merci.
Bonjour, je vois une autre solution, marginale certes, mais qui peut aussi avoir de l’intérêt : référencer automatiquement les éléments manquants dans le référentiel et remonter l’info pour que les fiches correspondantes soient complétées.
Salut ! Comme Arnaud, je préfère bloquer la ligne et forcer la mise à jour du référentiel (ou d’une table de correspondance).
Toujours problématique de voir un produit inconnu qui représente 25% du CA 🙂
Mon client actuel a effectivement des « Non Applicable » sur tous les axes sauf les produits…
Après pour le CA, les 2 solutions se valent pour moi car quand tu as un poids trop important d’inconnus, le fait de ne pas en tenir compte dans le CA total te permet de faire prendre conscience aux utilisateurs type Co Dir que leurs chiffres sont faux alors que si ils doivent aller voir le détail des produits pour voir la part des inconnus c’est pas évident…
@Arnaud & @Stéphane, dans certains cas on a pas trop le choix, mais la BI sert aussi à montrer l’intérêt d’avoir des données de qualité. Le risque lorsque l’on met à jour le référentiel avec des nouvelles valeurs et de créer des doublons sans s’en rendre compte. Si le référentiel contient « Produit A » et que l’on reçoit une ligne contenant « Produita » on peut se retrouver dans le cas où 90% du CA est bien affecté au « Produit A » et le reste sur « Produita ». Un utilisateur pourrait donc prendre des décisions erronés en pensant disposer de l’ensemble du CA sur le « Produit A ». Utiliser le produit « Inconnu » c’est mettre certains utilisateurs le nez dans le caca et forcer des actions correctives.
@Arnaud et @Stéphane : merci pour vos commentaires et vos ajouts. Votre méthode est tout autant valable en effet, mais j’aime bien, à titre personnel, charger la ligne malgré tout, avec « Inconnu ».
Finalement, l’important est de se mettre d’accord avec le client et s’assurer qu’il a bien compris pourquoi il a des erreurs, où les trouver et comment les corriger.
@Alexis : merci pour l’exemple ! L’expression « le nez dans le caca » est bien adaptée 🙂
Il est bon d’avoir, dans tous les cas, un rapport dédié au suivi des erreurs et des « inconnus ». Cela peut permettre, comme le disait Stéphane, d’impliquer le CoDir et donner des objectifs chiffrés (0 inconnus, traiter 50% des erreurs en une semaine, …).