Retour d’expérience sur l’accompagnement d’un projet de Cloud Data Platform au service de la data visualisation dans le retail
Les projets autour de la data sont souvent transverses et touchent plusieurs métiers et de nombreuses dimensions : architecture d’entreprise et du Système d’Information, métiers aussi bien que l’organisation. Souvent en lien direct avec la transformation de l’entreprise, ils impliquent généralement pour les chefs de projets de soulever des questionnements différents des projets classiques et d’appréhender aussi bien les enjeux métiers que les impacts techniques. C’est ce qui passionne Philippine, consultante et CDP sur un projet Data chez Projexion. Elle nous partage dans cette interview ses retours d’expérience dans le cadre de la mise en place d’un projet de Cloud Data Platform dans le secteur Retail.
Pourrais-tu nous présenter le contexte et les objectifs de ce projet de Plateforme de données ?
Notre client, un groupe de vente par correspondance, avait identifié que les métiers, supply en tête, perdaient énormément de temps à consolider les données. L’outil mis en place précédemment ne couvrait qu’une partie de l’offre et n’était pas utilisé uniformément par les différents pays. Les normes entre les services variaient, chacun réalisait des extractions et travaillait sur des fichiers à côté… Même une fois consolidées, il était difficile de comparer des données par manque d’homogénéisation. En effet les services métiers s’appuyaient sur l’outil de Business Intelligence sans maîtriser les définitions et processus métiers associés : la référence était alors l’outil sans remise en cause de l’existant. Les axes d’analyse utilisés différaient entre les utilisateurs, multipliant les dashboards et les demandes. L’objectif final était parfois perdu de vue ! Ces difficultés éloignaient les utilisateurs de leur métier qui est avant tout de réagir vite selon l’évolution du marché ou d’adapter l’offre et les stocks selon les KPI. L’objectif du projet de Cloud Data Platform était ainsi d’homogénéiser les pratiques entre les différentes Business Units, de centraliser et partager ensuite cette donnée fiable, au service de la Business Intelligence, mais pas seulement. En effet, le souhait était de faire grandir la culture Data et son appropriation dans l’organisation : les opérationnels ont aussi vocation à pouvoir créer leurs tableaux de bord à partir des données à disposition dans la plateforme.
Pour la métaphore, c’est en quelque sorte un buffet de données qualifiées et fiables dans lequel chacun peut se servir, pour se construire son propre menu d’indicateurs.
C’était également l’opportunité de mettre en place une gouvernance de la donnée en termes de rôles, de processus, de standardisation et de définition de la donnée et des indicateurs. Il n’existait pas auparavant de rôles de Data Owners et de Data Stewards par exemple. Ainsi, le projet a été initié à partir d’un constat sur la data visualisation – le besoin de se concentrer sur l’analyse plus que la construction des KPI – et est remonté sur la mise en place d’une plateforme de gestion de données transversales, et d’une stratégie de gouvernance de données dans l’organisation.
Comment s’est organisé ce projet de DCP autour des différents prismes de la donnée ?
L’entreprise a structuré différentes briques organisationnelles pour accompagner le projet de Data Cloud Platform. La Data Factory regroupe des profils plutôt techniques comme des data engineers qui vont développer et alimenter la plateforme au niveau de l’intégration de données et des flux. Cela implique de standardiser les échanges, de rendre la donnée disponible, d’automatiser au maximum les process et de gérer le monitoring.
Un flux qui ne fonctionne pas ou une erreur lors de l’intégration a directement des impacts sur toute la chaîne de la donnée dans la plateforme !
Le Data Office est composé d’un architecte Data et d’un Data Manager. L’architecte Data pilote le Data Office et va être garant de la modélisation de la donnée, des tables et des choix de modèles selon les besoins métier. Le Data Manager va accompagner la démarche sur la durée comme par exemple autour du glossaire métier. La 3ème brique organisationnelle est la Data Analytics qui rassemble des Data Analysts. Ils définissent la stratégie autour du self BI : les rôles métiers, les BI Champions qui vont créer les dashboards… Ils s’occupent aussi directement du développement des dashboards suivant les besoins métiers et animent la démarche. Selon l’expression de besoins, ils sont force de proposition sur la conception et challengent les métiers sur l’usage final. Nous nous sommes, en effet, rendu compte que les premiers tableaux étaient trop complexes, et qu’il fallait pouvoir se détacher des formats existants précédemment pour mieux répondre à l’usage métier réel.
Et en termes de briques techniques autour de ce projet de data management platform ?
La brique centrale est la Google Cloud Platform (GCP) qui se compose de plusieurs couches. La cible est de disposer d’un Data Lake avec les données brutes et natives, un Data Lakehouse avec des données plus structurées, une Data Refinery avec les données agrégées et transformées. Cette dernière a vocation à enrichir la donnée et à réaliser les calculs. Ensuite, Le Data Lab est, quant à lui, plutôt un bac à sable pour mener les tests. Le Data Access est la partie finale dans laquelle les utilisateurs peuvent accéder à la donnée. Celle-ci doit alors être structurée et « découpée » par cas d’usage pour faciliter l’appropriation par les métiers. Elle est complétée par la brique de Data Consumption qui met à disposition les tableaux de bord et la Self BI.
Nous avons pris conscience durant le projet qu’il existait une dette importante. Certains pays n’utilisaient pas le Data Hub historique. Pour toute une partie des données, impossible de savoir si elles étaient qualitatives ! Il a fallu recetter étape par étape.
Quelle a été ta mission dans ce projet de cloud data platform, et comment celle-ci a évolué dans la durée ?
Je suis arrivée en tant que chef de projet Data dans une équipe de consultants externes assez diversifiée et majoritairement en distanciel. Le sponsor s’était rendu compte de la nécessité de structurer le projet et d’améliorer la communication : il y avait en effet un déficit en termes de méthodologie de gestion de projet. Les services métiers manquaient de visibilité sur l’avancée du projet. Depuis le kick-off plus d’un an auparavant, ils n’avaient plus de nouvelles ! Tout cela entraînait un paysage assez complexe auquel il fallait apporter de la rigueur et un peu de management. Mon premier rôle a ainsi été de mettre en place une nouvelle gouvernance avec un daily tous les matins, des comités projets et des instances de pilotage. Cela impliquait aussi d’assurer que les bons interlocuteurs soient dans les bonnes réunions pour être efficace ! De manière plus classique, en tant que chef de projet, j’ai aussi géré le budget, le planning, les instances, UAT, les livraisons… En termes de pilotage de projet, nous avons dû nous adapter et gérer des spécificités locales suivant les pays : process différents, culture différente, dette technique et organisation différentes également.
Piloter un projet Data transversal et critique pour l’entreprise implique des compétences solides de gestion de projet en plus d’experts techniques et data au sein de l’équipe.
Après quelques mois, l’entreprise a recruté un Head of Data et fait évoluer l’équipe. J’ai alors basculé en chef de projet métier, rattaché à la brique Data Analytics. Je collectais les besoins et je m’assurais de l’alignement avec les métiers en mode BUILD aussi bien que RUN. Pour embarquer, nous devions montrer que le projet avançait et impliquer les métiers ! Avec la livraison et la mise à disposition de deux dashboards, j’ai accompagné la formation, la communication autour du projet et également l’analyse des usages réels une fois en production. Avec le Head Of Data, nous suivions aussi la stabilisation de la plateforme GCP : causes des écarts, soucis rencontrés, vérification de service régulier (VSR)…
Dans ce type de projet, il faut aussi affronter des facteurs exogènes comme dans ce retour d’expérience une cyberattaque. Un projet ne se déroule jamais exactement comme prévu : le CdP doit pouvoir s’adapter aux impondérables !
Quels conseils et points d’attention partagerais-tu à des entreprises se lançant dans des projets Data similaires ?
Cela paraît évident, mais il ne faut pas négliger la phase préliminaire, surtout dans le cadre d’un projet international. S’accorder sur les définitions, les process métiers et les analyses d’écarts entre pays en amont du déploiement est essentiel. Cela limite les découvertes de spécificités et de contraintes durant le projet qui peuvent remettre en cause des pans importants du projet. Toujours dans cette phase préliminaire, définir la cible, le Core Model auquel tous les pays se rattachent et la trajectoire pour l’atteindre assure que tous soient alignés. C’est un gage d’efficacité par la suite. Il est ainsi possible, si nécessaire, de définir des trajectoires variables suivant les pays en connaissance de cause. Le risque est sinon d’avoir des métiers qui n’utilisent tout simplement pas l’outil. Cet alignement touche aussi l’architecture data. Que va-t-on conserver ou non ? Qu’est-ce qu’on décommissionne, quand et comment ? Quelle est l’architecture SI cible à court, moyen et long terme selon les pays ? Quelle est la dette technique et au niveau de la qualité des données ? Les responsables doivent s’assurer de consolider la documentation existante : schémas d’architecture à jour, diagrammes de processus métiers, règles fonctionnelles au sein des flux…
Étudier le niveau de maturité des métiers vis-à-vis de la donnée et des processus, permet de les inciter à prendre du recul sur les expressions de besoins. C’est aussi le socle pour définir comment les accompagner au mieux : adapter le discours, sensibiliser à la data et à la gestion de projets et mener une démarche de Change.
Expliquer aux métiers à quoi sert un glossaire métier, pourquoi on mène le projet selon ces étapes leur permet d’être plus à l’aise avec la méthodologie et le cadre du projet. En étant ensuite plus fluide dans les échanges, c’est tout le déroulé du projet qui est accéléré !
Pour finir, bien appréhender les différences entre Business Intelligence et Data Visualisation est important. La Data Visualisation est un facilitateur pour interpréter les chiffres rapidement et disposer d’une vue simplifiée des KPI tandis que la BI englobe l’aide à la prise de décisions. Lors du cadrage, il faut prendre du recul et s’aligner sur la cible et l’usage final. Cela implique également d’identifier les acteurs avec le niveau de maturité suffisant dans l’entreprise pour valider le choix technologique, à partir des inputs métiers.
Qu’est-ce qui t’a en particulier intéressé dans ce projet de Data Platform et plus généralement dans le conseil autour de la data ?
Dans ce projet spécifiquement, j’ai grandi sur le savoir-être au travers de la dimension managériale. J’ai réalisé que c’était loin d’être évident suivant les profils et que cela nécessitait de la méthode. Plus généralement sur les projets data, je me suis rendu compte au travers de mes expériences que la Data est un monde à part ! En termes de savoir-faire, le chef de projet Data doit à la fois disposer d’un bagage méthodologie classique et également avoir une compréhension des enjeux plus techniques. C’est très enrichissant. Pour finir, dès qu’on touche à la Data Visualisation, notre travail a un impact immédiat et réel. Des décisions sont prises directement à partir des données et des indicateurs que nous mettons à disposition. Prendre conscience de cela met en relief l’importance de la gouvernance et de la qualité des données… et donc de notre rôle !
Projexion est un cabinet de conseil en organisation et en gestion de projets Data dont la vocation est d’accompagner les entreprises dans leur transformation. La complémentarité entre nos consultants permet de couvrir toutes les dimensions de la data : architecture, projet, change, formation…
Soyez averti(e) de nos prochains évènements et publications via LinkedIn !