Go to content

Derrière la face cachée d’un tableau de bord : la perspicacité des équipes Data Solutions

Régulièrement chez CONIX nos équipes Data Solutions effectuent un bilan de leurs missions clients.

La compilation de ces bilans offre un panorama d’ensemble d’une très grande richesse.

Dans ces bilans une prise de recul sur les enseignements et difficultés rencontrées est réalisée.

Nous vous proposons dans cet article une synthèse des petits et grands obstacles que nos équipes rencontrent, affrontent et résolvent pour atteindre le graal du tableau de bord ou de la data visualisation satisfaisant.

Outre les compétences techniques attendues, ce bilan de bilans montre toute l’importance de la maîtrise de problématiques cachées qui, l’expérience le montre, sont décisives.

C’est cette dimension cachée, l’habilité que cela nécessite (rarement mise en avant) que nous voulons mettre en lumière.

NB : dans la suite de l’article, « en italic » verbatims de nos équipes repris tel que de nos exercices de bilan.

Savoir parler plusieurs langues :

  • Babel métier & sémantique :
    • Pas de définition des données disponibles … jusqu’à même parfois la non maîtrise du sens métier (« Manque de connaissance métier autour du réseau et de ce qui le compose») ou le conflit de définition entre métiers (« Pas de communication entre les différentes équipes métier du client »).
      • « Le référencement des données métier pivot et des indicateurs clés pour l’entreprise peut être très difficile à arrêter, à définir : la gouvernance des données et l’identification des « propriétaires » est incontournable. »
    • Ambiguïtés, fausse simplicité derrière la définition d’indicateurs (« Une des difficultés est de parvenir à facilement s’accorder sur la définition des indicateurs demandés par le commanditaire. Ce dernier ne mesure parfois pas les cas multiples qui existent pour un indicateur à priori simple à calculer. »).
    • Culture métier nouvelle et complexe … nécessitant malgré tout de s’adapter quasiment immédiatement

 

  • Babel projet : dialogues MOE / MOA
    • Multiples traductions pour respecter les cadres de développements near et off shore, « A l’exception notable du chef de projet Intégrateur, les intervenants n’étaient pas anglophones natifs, et possédaient des niveaux d’expression, de compréhension et d’interprétation très hétérogènes. », « L’agilité en near-shore est complexe et peu efficace »)
    • « De cette expérience, l’enseignement principal que j’en ai retenu, est que la mise en place d’une application décisionnelle en parallèle de la mise en place d’une application opérationnelle qui en est la source, n’est pas impossible, mais tout de même compliquée. Cela nécessite une rigueur et une communication optimale et fréquente entre les différentes équipes ».

 

  • Babel des données :
    • Pas de référentiels communs pour faciliter les rapprochements et consolidations
      • « Référentiels plus ou moins officieux sous forme de fichiers Excel »
    • Pas de nomenclatures officielles et partagées
    • Pas de catalogue de données disponible
    • Des transcodifications cachées un peu partout dans les chaînes de production

 

  • Babel technique :
    • Les sources de données sont hétérogènes (formats propriétaires voire ad hoc dont on a perdu les spécifications … quand elles ont existé, format résultat d’un expert métier sans maîtrise technique mais à l’imagination excel débordante ou à l’inverse résultat d’un expert technique ayant exploité toutes les subtilités d’un format … XML par exemple)
      • (« Difficultés pour appréhender l’environnement source propriétaire, relativement hermétique et assez peu documenté »)
    • Les sources sont inaccessibles (format à reconstituer, l’ouverture des flux est un éternel problème)
    • Résister au fantasme Big data alors que les données sont relationnelles et de faible volume (« Les technologies big data n’ont pas de plus-values quand toutes les sources de données sont transactionnelles et que le volume de données n’est pas significatif »)
    • « Perte de connaissance du système existant liée au changement d’intégrateur »

 

Dompter les chaînes de production :

  • En RUN
    • Niveaux de services non en adéquation avec le niveau de qualité attendu par le métier.
      • « Services techniques qui dysfonctionnent et entravent la bonne avancée des travaux »
    • Données non complètes, rejets (fonctionnels et techniques) non correctement traités voire « oubliés »
      • « Difficulté de communication entre les mondes opérationnels et financiers et nécessité de motiver la bonne saisie dans le respect des calendriers du Groupe »
      • « Non-reproductibilité des traitements d’alimentation du datawarehouse »
    • En mode Projet et MCO (maintien en condition opérationnelle)
      • Difficultés de débugger de bout en bout une chaîne (« difficulté à analyser les causes de problèmes de données provenant de différentes sources externes … formatage non respecté, données manquantes… »), maîtriser une multitude de composants de l’extraction à la présentation du tableau de bord en passant par le stockage (« nécessité de s’adapter à une multitude de framework », « manque de continuous integration »), l’accès aux données est lourd (« La difficulté réside dans l’autonomie d’accès aux donnée »),
      • Moyens techniques sous-estimés pour répondre à un niveau de qualité à l’état de l’art. Complexité d’intégration invisible aux yeux du client
        • « Moyens techniques imposés par le client incompatibles avec le niveau d’exigence technique et fonctionnel, tel que :
          • Abandon de la solution ETL imposé par le client pour des raisons d’économie, alors qu’il nous est demandé de traiter / transformer / historiser les données selon un modèle spécifié par le métier… impliquant de très nombreuses limites en matière de transformation complexes, qui risquent de nous faire défaut durant les évolutions futures du modèle
          • Abandon de la solution de Supervision, alors qu’il est demandé de planifier, ordonnancer et superviser nos traitements »
        • « L’intégration de bout en bout, des flux à la production des états en pensant par tous les composants Big Data dont, la mise en œuvre de l’architecture AWS a été un véritable challenge »
      • La qualité des données n’est pas sous contrôle (« L’octroi est mal renseigné dans les Datamarts, les données emprunteurs peuvent être parfois dupliquées, des problématiques de précision de données faussent les comparaisons en pourcentage. Problème de qualité de données en particulier sur les sources de données manuelles nécessitant un retraitement important »)

 

Faire preuve d’une résilience pédagogique :

Au fil des obstacles rencontrés, la tentation est grande de renoncer à délivrer un résultat de qualité. Il ressort des bilans une énergie importante, non formalisée auprès du client, non mesurée également, des équipes pour surmonter les difficultés.

  • « Culture Excel et Access du client, pratiques incompatibles avec une vision industrielle »
  • « Les analyses sur les problèmes relèvent plus du reverse engineering … que d’une réelle analyse des causes faute de pouvoir interroger aisément les sources de données au-delà d’une simple consultation »

Comme cela est bien dit dans ce dernier verbatim, l’effort de rétro-engineering est quasi systématique. Et le résultat de cet effort doit rentrer dans des explications (pédagogiques) des obstacles résolus qui doivent éclairer le client.

 

A la question « Que se passe-t-il derrière un tableau de bord ? », la réponse est : une énergie, un état d’esprit, une mobilisation de savoir-faire et savoir-être, de « débrouille », une maîtrise d’une vision d’ensemble qui vont bien au-delà de la simple expertise technique des outils décisionnels et de data visualisation qui accaparent toute la lumière !

Et pour aller plus loin, nous vous conseillons vivement la lecture du procédé que nous avons publié en début d’année : « Construire un tableau de bord ? Une activité plus exigeante et plus gratifiante que vous ne le pensez ! »