Conception : L’importance de la qualité des données
- Introduction
- Cadre général du projet décisionnel
- Conception : Étude Préalable
- Conception : Collecte des besoins (spécifications très peu détaillées)
- Conception : Analyse des besoins
- Conception : Analyse des indicateurs
- Conception : L’importance de la qualité des données
- Conception : Spécifications des restitutions (ce que j’envisage de vous proposer)
Dans leur Atelier-Données du 5 juillet 2021 (Rivet & Valeins, 2021) mettent en évidence le coût de la non-qualité des données en ces termes : « Harvard Business Review estimait en 2017 qu’une tâche effectuée avec une donnée erronée engageait un coût 100 fois supérieur à celui d’une tâche réalisée à partir d’une donnée initialement vérifiée et correcte. » puis nous alarment sur l’étendue de la problématique « Selon l’analyse Gartner 2020 sur les solutions de gestion de qualité des données, plus de 25 % des données critiques des plus grandes entreprises sont erronées, au point que le coût moyen d’une mauvaise qualité des données pourrait s’élever à 11M€ par an pour les organisations. Les répercussions économiques, positives ou négatives, sont donc à considérer avec la plus grande attention. »
Pour Laure Berti-Equille (Berti-Equille, 2012) la qualité des données peut être analysée selon 9 indicateurs : Pertinence, Accessibilité, Facilité d’interprétation, Unicité, Cohérence, Conformité, Exactitude, Complétude et Consistance. Il serait trop long de détailler ici chacune de ces caractéristiques, notons cependant que pour l’auteure « les principaux défauts qui peuvent résulter des erreurs humaines ou des défaillances logicielles durant le cycle de vie d’une application sont : les doublons, les données manquantes ou incomplètes, les valeurs non standards, les inconsistances, les laveurs inexactes, les données obsolètes et inutiles ».
Au lancement du projet les données présentes dans le CRM sont affectées, de manière plus ou moins forte, par l’ensemble de ces défauts. Aussi, afin de déterminer le niveau de ces défauts, afin de mesurer la qualité des données, il est impératif d’explorer de manière pragmatique, les différentes bases de données, les différentes tables, d’analyser les résultats obtenus grâce aux requêtes SQL, de valider ces résultats ou de les faire valider par les opérationnels, puis d’affiner progressivement les requêtes de sélection. Une fois de plus c’est un long travail qui pourrait, sous, certains aspects s’apparenter à la phase de « nettoyage amont » des données. Ce qui ne sera pas nettoyé en amont sera ensuite écarté ou transformé dans les différentes requêtes de sélection. Voyons ceci sur quelques exemples.
Par exemple, en analysant les données de manière tout à fait élémentaire la première des choses est de savoir si la donnée dont nous avons besoin dans notre rapport est systématiquement saisie. En langage SQL une requête de type SELECT DISTINCT nous permet de savoir où nous en sommes. Afin d’illustrer la démarche, à titre d’exemple, nous allons, ci-après, vérifier la qualité des données pour les axes Origine, Programme, Agence et Rendez-vous. A titre d’exemple car ce travail est, en réalité, bien plus fastidieux et plus complexe.
Origines : Donnée indispensable pour la plupart des rapports à construire. Voyons si elle est systématiquement renseignée dans la fiche prospect en exécutant une requête sur la table Company. La présence de la ligne NULL (voir Figure 6) interroge. Elle prouve que l’information n’est pas systématiquement saisie.
Mais nous devons en savoir plus. Est-ce qu’il s’agit d’une situation exceptionnelle ou est-ce qu’elle se produit régulièrement (ce qui aurait un impact fort sur la fiabilité des rapports) ? Voyons, toujours grâce au langage SQL, combien de lignes sont concernées par ce défaut de saisie. Nous voilà face à une situation problématique.
Nous avons 19849 lignes, soit 19849 contacts qui n’ont pas d’origine. Comment bâtir un rapport donnant une répartition des contacts par origine avec un tel déficit de saisies ?
Après quelques échanges avec les services demandeurs nous arrivons à la conclusion que ce qui nous intéresse ce sont uniquement les prospects (une nouvelle notion apparait ici, en effet la fiche contact du CRM permet d’enregistrer aussi bien les prospects que les salariés des prescripteurs, qui ne sont pas des clients potentiels), créés depuis le 1er janvier (car avant cette date l’origine n’était pas saisie) et qui n’ont pas été supprimés du CRM.
Une nouvelle requête permet alors de comprendre que cela correspond à 19 contacts sur un total d’environ 20000 fiches saisies annuellement soit 0.01% . C’est peu mais cela modifie néanmoins l’expression du besoin car, à la suite des échanges internes, dans la plupart des rapports il sera désormais nécessaire d’ajouter une nouvelle catégorie « Sans Origine ». Cela ouvre également le portail de restitution à une nouvelle dimension, comme nous le verrons plus tard, de manière plus détaillée : l’outil devient également progressivement un outil de contrôle des saisies et plus uniquement un outil de pilotage et de suivi.
Dans la requête ci-dessus nous nous intéressons toujours au nombre de contacts par origine (exprimée en code) mais cette fois-ci la requête comprend plusieurs paramètres tels que la date de création, l’état du contact (non supprimé) ainsi que la famille qui doit correspondre à ‘Prospect’ (par opposition avec ‘Partenaire’ qui correspond aux salariés des agences immobilières qui sont également enregistrés dans le CRM). Comme on peut le constater la requête renvoie 19 lignes sans origine.
Demandes programmes : Sur le même principe nous pouvons analyser les données relatives aux demandes de programmes. 527 contacts sur quelques 20000 lignes n’ont pas d’information relative à la demande de programme (voir Figure 7). Cela peut sembler considérable mais ici il s’agit d’une donnée qui n’est pas obligatoire. En effet, nous pouvons voir arriver dans notre système d’information un contact qui n’a pas d’idée précise sur le programme immobilier dans lequel il souhaiterait acheter un bien.
L’exhaustivité des données relatives à la demande de programme apparait ici comme une caractéristique relative. La demande de programme non renseignée peut être considérée comme une donnée manquante non aléatoire (MNAR) (Ibarrera, 2020)
C’est aussi la raison pour laquelle dans certains cas à la place d’un programme immobilier précis l’opérateur de saisie enregistre une notion plus générique qui est celle de la ville
La requête ci-dessus permet d’obtenir le nombre de contacts par programme demandé. Le code du programme demandé est également affiché. Afin d’obtenir le libellé du programme demandé une jointure est faite avec la vue vcustom_captions (comme on peut le constater cette jointure se fait sur le code mais aussi sur la famille qui doit correspondre à ‘comp_Pythagoredemprog’ ceci illustre le manque de modélisation relationnelle évoqué dans précédemment). La copie d’écran met également en évidence le fait que le champ « demande programme » peut également contenir une notion de ville. Information plus générique, enregistrée lorsque le prospect n’est pas précis dans la détermination de son besoin. Le tri se fait ici de manière descendante. La copie d’écran présentée ne reflète pas l’intégralité des résultats.
Agence : La notion d’agence est dérivée de l’utilisateur (responsable du compte) associé au contact. Le responsable du compte est toujours renseigné, la complétude est donc globalement satisfaite pour cette information. En revanche une autre anomalie apparait. La force de vente connait, dans la conception et vente, un turnover important. Aussi sur une population de 50 personnes, chaque mois, le service commercial enregistre entre 2 et 3 nouveau vendeurs. Afin de bâtir des rapports fiables le paramétrage des vendeurs réalisé par les « opérationnels » dans le CRM doit être beaucoup plus précis car dans certains cas le vendeur n’est pas lié à une agence.
En effet comme nous pouvons le remarquer sur la figure ci-dessous , 4 vendeurs ne sont pas rattachés à une agence. Les cas de Denis et de Fanny ne sont pas problématiques dans la mesure où il s’agit de salariés soit supprimés soi désactivés, en revanche les cas des Bénédicte et de Cyprien, sans correction, auraient pour conséquence de fausser nos rapports.
Rendez-vous : La gestion des rendez-vous a été certainement le cas le plus problématique à gérer, en matière de complétude de données. Pour cause, nous l’avons déjà mentionné, ces données n’existaient pas ou quasiment pas ; elles
étaient saisies occasionnellement par les vendeurs les plus motivés. Comme nous l’avons vu, cette situation a nécessité des aménagements fort dans le CRM. Il est important de préciser que ces aménagements ne seront pas suffisants. En effet peu de temps après la mise en production de la première version du portail de restitution il sera nécessaire de lancer un autre projet structurant : le développement, en PHP – SQL, du CRM Mobile. Il s’agira d’une version « allégée » du CRM qui permet aux vendeurs de consulter l’essentiel des informations (contacts, réservations, options) et bien sûr de saisir les rendez-vous et de modifier le statut de ces derniers.