Vous disposez d’un outil de reporting qui vous sert dans vos prises de décision. Un outil qui vous assiste dans vos tâches de tri d’information et vous permet de visualiser facilement l’information essentielle.
Avec le temps, vous pouvez être amené à faire évoluer cet outil ou à vouloir en changer, par exemple dans un souci d’intégration de nouvelles fonctionnalités (interface plus intelligente et ergonomique, calcul et affichage d’information prédictive, suggestions d’actions prioritaires, …)
Ces évolutions de votre outil de visualisation de données vont cependant entraîner des modifications de la chaîne sous-jacente (parfois complexe) prenant actuellement en charge son alimentation en données, depuis les systèmes sources desdites données (applications productrices, bases de données référentielles, …).
Quels sont ces impacts potentiels sur votre chaîne d’intégration de données ? Quels sont les problèmes à résoudre, pour adapter votre chaîne d’alimentation de données et exploiter votre outil efficacement ?
Identification des sources de données pertinentes ou supplémentaires
Votre Système d’Information peut avoir évolué avec le temps. Différents progiciels et outils de gestion ont pu s’y ajouter, différentes applications d’intégration (ETL, bases de stockage buffer, …) peuvent être entre les référentiels d’où proviennent vos données et votre outil de visualisation.
Les données que vous récupérez actuellement sont dans ce cas issues d’intermédiaires plutôt que d’un référentiel, à ce titre elles peuvent avoir subi des traitements que vous ne souhaitez pas :
• Traitements techniques de filtrage, mapping, agrégations…
• Règles de gestion fondées sur une logique spécifique du métier (exclusions, cas particuliers, …)
Elles peuvent aussi ne pas représenter la collection exhaustive de données dont vous avez besoin. Vous manquerez alors d’une vue d’ensemble en lien direct avec le manque de complétude du jeu de données que vous recevez.
Par exemple, vous pouvez avoir un catalogue de produits cosmétiques que vous mettez à jour et que vous communiquez le cas échéant à vos points de vente, vos clients, etc., selon plusieurs canaux de communication. Vous ne communiquerez peut-être pas le catalogue complet à tous les destinataires (produits de grande distribution, produits professionnels, luxe, …).
En conséquence, si votre outil de visualisation de données va s’alimenter sur l’une de ces applications, elles-mêmes destinataires de votre référentiel produit, il ne récupérera qu’une vue partielle de votre catalogue.
Il devient alors nécessaire de questionner le circuit que parcourt la matière première de votre outil :
• Une opération de filtrage sur un set brut de données a-t-elle écarté en amont des données en définitive utiles à vos rapports ?
• Toutes les données dont vous avez besoin pour votre outil de visualisation cible sont-elles extraites automatiquement ?
• A contrario, sont-elles répertoriées dans un fichier (Excel, csv, …) qui est alimenté manuellement à un moment ou un autre du parcours de votre donnée ?
Reconstruction des flux d’alimentation de données
Comme évoqué précédemment, vos données peuvent avoir subi des traitements intermédiaires entre leurs systèmes sources et la visualisation que vous avez actuellement.
Ces données pré-travaillées peuvent cependant être utiles à votre outil de visualisation cible et vous pourriez avoir besoin de les reconstruire (métriques, données agrégées…). Les traitements en question ont parfois servi aussi à fournir plus de qualité dans la donnée.
Ainsi, si vous avez préalablement fait une analyse textuelle à partir de rapports d’audit sur vos fournisseurs pour examiner leurs prestations, vous avez probablement appliqué un certain nombre de nettoyages préalables sur les données issues de ces corpus (racinisation, filtrage de mots vides, …) pour les rendre exploitables.
Il faut dans ce cas identifier ces traitements pour les conserver.
Parallèlement, vous préférerez peut-être éviter de multiplier les sources d’alimentation de votre système cible, en déléguant certains flux d’alimentation à votre chaîne existante et en attribuant les autres à votre nouvelle chaîne d’acheminement de la donnée.
Dans ce cas il peut être intéressant de reconstituer la séquence de traitements appliquée à vos données, au moyen :
• D’extractions et d’analyse de données en sortie de chaque système intermédiaire, entre la source de votre donnée et votre outil de visualisation
• D’ateliers avec les différents responsables (IT ou métier) de la donnée en question, pour distinguer et rétro-documenter les traitements techniques et les règles de gestion métier
Sélection des données du dataset à visualiser
La problématique in fine est de rassembler les données pertinentes pour alimenter votre outil cible et ses fonctionnalités d’analyse et de visualisation plus évoluées.
Pour cela, il faut collecter des données à la bonne maille, au bon niveau de détail : temporel (ai-je besoin de données journalières ? au mois ?), de granularité (ai-je besoin d’établir des statistiques d’utilisation de mon produit sur chacun de mes clients ? Ou devrais-je les regrouper en groupes d’individus ?), etc.
Par exemple, si vous voulez faire une analyse du nombre d’utilisateurs de vélos en libre-service par heure sur Paris, il va vous falloir relever et récupérer une traçabilité de cette utilisation à la maille horaire.
Il faut par ailleurs aussi, comme indiqué précédemment, s’assurer de la complétude de l’ensemble des données collectées
Enfin votre outil cible de visualisation de données peut avoir des objectifs différents de votre outil existant.
Par exemple, là où votre application permet d’observer l’évolution de métriques mises à jour toutes les semaines ou tous les mois, vous souhaitez peut-être passer sur un fonctionnement plus réactif pour des besoins opérationnels.
Vous voulez par exemple pouvoir visualiser jour par jour, le nombre et la gravité d’incidents survenus sur les chaines de production de fournisseurs, pour pouvoir déclencher le cas échéant un audit avec un délai réduit. Cette analyse nécessitera alors de récupérer les données quotidiennement, au lieu d’une collecte mensuelle.
La chaîne d’alimentation des données vers votre outil devra dans ce cas garantir une collecte et une fréquence de mise à jour adéquates.
Pour résumer…
L’évolution ou le changement d’un outil de visualisation de données peut impliquer des évolutions d’architecture de données importantes en amont (choix de référentiels sources, niveaux de granularité, rafraîchissement…).
Il reste maintenant à évoquer les outils pouvant servir d’accélérateurs pour résoudre les problèmes précédemment évoqués (dont certains éléments de réponse sont exposés dans un précédent article sur la Data Virtualization) et les étapes de transition vers votre outil de visualisation de données cible.
Je vous propose d’aborder le sujet dans un prochain article.
