Au coeur d'une plateforme DATA
Contexte
Une équipe OCTO est missionnée chez notre client pour construire de bout en bout une solution de traçabilité pour ses produits. Le projet s’inscrit dans un vaste programme sur la traçabilité suivi par la direction avec de nombreuses initiatives lancées en parallèle.
L’enjeu est de taille pour l’entreprise qui se voit contrainte par des directives réglementaires de ne plus utiliser certains composants dans la fabrication de ses produits tout en maintenant l'optimisation de sa chaîne de production.
La solution a pour objectif final de tracer les produits (articles) depuis la matière première qui le compose jusqu’à sa mise à disposition sur le lieu de vente, en passant par les étapes de fabrication et de gestion des stocks. L’idée étant d’arrêter le produit le plus tôt possible en cas d’anomalie et de valoriser le coût financier.
La solution est articulée autour de 2 sujets :
Construire un datamart contenant tout le cycle de vie des articles
Développer une plateforme de traçabilité exploitant le datamart.
La solution est destinée aux clients internes chargés de surveiller la chaîne de production et la qualité des produits.
Notre client décide de lancer un MVP sur 3 ans avant de valider la pertinence de ses choix sur le long terme.
Le but de l’article
Il s’agit avant tout de vous partager un retour d’expérience (méthodologique, organisationnel, culturel, technique, data) sur la mise en œuvre d’une plateforme data de traçabilité chez un acteur mondial du luxe.
Les difficultés rencontrées et les solutions mises en place
Nos apprentissages.
Je pense qu’il est parfois bon de prendre du recul et de vous livrer nos apprentissages qui seront à la fois bénéfiques :
aux équipes octos (product owners, tech leads, développeurs, delivery managers) s’ils se retrouvent dans la même situation (projet à forte dominante data, créer un référentiel provenant de différents ERP’s, organisation agile d’une équipe dans un écosystème qui travaille en cycle en V,..)
ou à nos clients qui souhaitent mettre en place le même type de projet avec un datamart et/ou une solution de traçabilité.
Mon arrivée
J’arrive dans un moment critique du projet en septembre 2022 où l’équipe tente par tous les moyens de livrer de la valeur à notre client qui de son côté ne constate pas d’amélioration significative sur la réalisation de la solution. De plus, il ne dispose pas de visibilité quant aux échéances qu’il s’est engagé à tenir auprès de sa hiérarchie.
L’architecture du projet
Pour tracer les données, il faut récupérer une partie des informations brutes qui proviennent de différentes sources, les transformer et les intégrer dans un datamart. Celles-çi pourront être requêtées par la suite via un outil de dataviz ou dans une solution développée spécifiquement.
Des ERP versent des centaines de millions de données sur snowflake. II s’agit d’une plateforme Data Cloud proposée sous la forme d’un Saas. Nous avons à charge de prendre ces données, de les transformer pour les mettre dans un datamart. Une base de données Graph fournie par un service AWS, nous permet de requêter des données sur un front.
Snowflake : Il s’agit d’une Data Warehouse proposée sous la forme d’un Saas (logiciel en tant que service) . Cela signifie que l’utilisateur n’a pas besoin de choisir, d’installer, de configurer ou de gérer de hardware, ni d’installer, de configurer ou de gérer de logiciel.
La maintenance, la gestion et la configuration sont entièrement prises en charge par Snowflake. Tous les composants sont exécutés sur une infrastructure de Cloud public. Les calculs sont effectués sur des instances virtuelles, et le stockage de données est assuré par le service de stockage de Snowflake.
Dbt : permet aux utilisateurs de définir leurs modèles de données à l’aide de requêtes SQL, puis d’utiliser ces modèles afin de générer un code SQL optimisé qui peut être exécuté sur un entrepôt de données ou un autre système de stockage de données. L’infrastructure de données est maintenable et évolutive, elle peut être facilement mise à jour et étendue au fil du temps.
Outre la génération de code SQL, dbt propose également un certain nombre de fonctionnalités qui facilitent le travail avec les données. Ces fonctionnalités incluent la possibilité de gérer les dépendances entre les modèles de données, d’exécuter des tests pour garantir leur intégrité et de suivre l’évolution des données pour comprendre comment elles ont été transformées au fil du temps.
Opcon : est un orchestrateur. La solution permet de planifier et d'ordonnancer l'ensemble des tâches et jobs techniques ou applicatifs, ainsi que les processus les plus complexes et critiques.
Datamart : Le datamart est un ensemble de données ciblées, organisées, regroupées et agrégées pour répondre à un besoin spécifique à un métier ou un domaine donné. Il est donc destiné à être interrogé sur un panel de données restreint à son domaine fonctionnel, selon des paramètres qui auront été définis à l’avance lors de sa conception.
Base de données graph : Une base de données orientée graphe est une base de données orientée objet utilisant la théorie des graphes, donc avec des nœuds et des arcs, permettant de représenter et stocker les données.
Requête Gremlins : Les données du graphe dans Amazon Neptune utilisent un langage de requête appelé Gremlins.
Les principales étapes pour construire le Datamart
Voici les 5 principales étapes qui nous ont permis de construire le datamart et de structurer la donnée pour l’exposer au front par la suite.
Les filtres métiers permettent de définir avec les experts des ERP concernés, les informations spécifiques qui doivent être remontées dans le datamart pour pouvoir les exploiter par la suite. Il ne s’agit pas de prendre l’ensemble des informations de chacun des ERP’s pour alimenter le datamart.
Les difficultés rencontrées et la mise en place de solutions
Je vous propose de voir la suite de l’article sous la forme des difficultés rencontrées et des solutions que nous avons pu mettre en place. Toutes ne sont pas liées à la mise en place d’un projet de data.
L’architecture du projet
Problèmes
- Une architecture complexe
Dans le cadre d’un MVP (minimum viable product), l’architecture proposée par les architectes de notre client est beaucoup trop riche pour tester nos premières features malgré nos recommandations qui était de faire plus simple et d’enrichir pas à pas l’architecture avec les premiers feedbacks des utilisateurs. La volonté de notre client est d’avoir une vision à long terme et de ne pas modifier l’architecture pas à pas. Il mise sur de multiples besoins métiers avec une croissance de ses utilisateurs finaux.
Vous l’aurez compris, l’approche MVP devrait permettre de tester la faisabilité du produit et l’appétence des utilisateurs sur une courte période, 6 mois auraient dû suffire pour valider la pertinence des hypothèses. Or le client se fixe 3 ans !
- Un POC qui ne reflète pas la réalité
Avant de partir “bille en tête”, l’équipe et le client décident de réaliser un POC (Proof Of Concept) afin de valider les principes d'architecture auprès des différents experts. Le POC valide l’architecture définie mais le périmètre testé ne reflète pas la complexité du projet et l’équipe va rencontrer plusieurs problèmes par la suite.
Solutions
Abandonner la base graph vers un outil dataviz du marché.
Utiliser Power BI qui était utilisé au sein de l’éco-système de notre client.
Utiliser un projet Power BI similaire au nôtre et enrichir les données existantes via le datamart.
Faire appel à renfort d’expertise sur la base graph pour valider notre modèle de données et avoir des pistes d’optimisation des requêtes.
L’architecture n’a malheureusement pas pu être remise en cause malgré les propositions que nous avions faites avec l’équipe car le projet était déjà fortement engagé et notre client souhaitait tester de nouvelles technologies qui lui semblaient prometteuses pour ses futurs projets. Pour autant, Il aurait été intéressant de définir l’architecture pas à pas avec les connaissances que nous avions à l'époque et les cas d’utilisation décrits. L’idée étant de ne pas engager trop d’investissements et d'efforts de part et d'autre. Nous aurions pu tester uniquement le datamart pour construire le modèle de donnée par exemple et le connecter à un outil dataviz du marché pour vérifier l’appétence des utilisateurs.
Je vous renvoie à l’article “Quand le changement est constant, l’architecture devient une discipline essentielle” de Wassel ALAZHAR, Damien HECQUET qui traite de ce point en proposant “une approche pragmatique qui nous offre des options face aux différentes incertitudes, plutôt qu’une série de contraintes qui nous infligent des solutions figées et complexes”.
Gains
- Pas de gain immédiat mais nous avons montré qu’il y avait des solutions possibles pour répondre au besoin de notre client.
Data et gouvernance de la donnée
Problèmes
- Une vision transverse de la donnée tronquée
L’équipe réalise une grande première car elle agrège des millions d’informations issues de différents systèmes et crée un référentiel unique qui n’existait pas auparavant. Vous l’aurez compris, la donnée est au cœur de notre projet et c’est là toute la difficulté.
Personne n’a de vision transverse de la donnée pour appréhender les règles de gestion :
Les experts métiers et des ERP concernés sont très compétents mais ils sont peu nombreux, extrêmement sollicités et donc peu disponibles.
Chaque expert a une bonne visibilité sur son périmètre mais n’a pas une vision d’ensemble des données qui traverse la chaîne de valeur.
Les experts ne sont pas toujours d’accord sur la meilleure façon d’aller récupérer la données pour répondre à la règle de gestion.
L’équipe n’a pas de jeux de données pour valider ses développements
L’équipe perd un temps précieux pour valider les données. Elle doit comparer une à une ce qu’elle présente dans le datamart (recette technique notamment) et les éléments sources de chacun des systèmes. Et même quand le contrat d’interface a été finalisé nous avons dû comparer le front avec les données du datamart et ceux des ERP’s.
- Des règles métiers plus complexes que prévues
Personne ne s’est assuré à un moment dans le projet qu’il y avait une cohérence entre les données des différents systèmes et les règles de gestion décrites. L’équipe réalise des filtres issus des règles de gestion pour ne mettre à disposition que ce qui est utile pour le front mais nous nous apercevons avec le temps que personne ne valide ces filtres et par ailleurs, le métier changent d’avis (une assistance à maîtrise d’ouvrage AMOA fait le lien entre le métier et nous) ou ne regarde pas dans les bonnes tables pour récupérer les données dont il a besoin. Cela crée beaucoup d’incompréhension de part et d'autre, de dépense d’énergie pour stabiliser les features.
Solutions
Nous avons proposé de :
Rencontrer les différents experts pour leur présenter notre solution (modèle de données, environnement, front, architecture) et les attendus afin qu’ils comprennent mieux notre demande.
Bâtir plusieurs jeux de données qui reflétaient le cycle de vie des articles (matières premières, stock de matières premières, création du produit, stock entrepôt et mise en boutique).
Clarifier les règles de gestion et le vocabulaire utilisé pour valider notre compréhension du besoin.
Organiser des points de RDV réguliers et un planning de tests afin de valider ensemble les requêtes effectuées et les résultats pour pallier à l’absence de gouvernance de la donnée.
Gains
Une meilleure compréhension avec l’ensemble des acteurs pour structurer la data,
Une plus grande réactivité au regard des problèmes rencontrés,
La répétabilité des tests avec un jeu de données co-construit avec les experts métiers.
Organisation équipe
Problèmes
- Une organisation d’équipe qui n’est pas adaptée au contexte
Pour tenir les délais, l'équipe décide de paralléliser ses développements et le temps que les développeurs back finalisent leurs travaux, les développeurs front avancent sur des données mockées. Mais nous le savons tous, ce qui coûte en temps c’est l’intégration de bout en bout. Et nous n’avons pas échappé à cette règle, l’équipe a mis beaucoup d’énergie à obtenir un contrat d'interface opérationnel.
Solutions
- Intégrer un développeur full stack
A la base nous cherchions un développeur front et l’équipe m’a convaincu de l’intérêt d’intégrer un développeur full stack qui pourrait :
Passer d’un sujet back ou front en fonction des besoins de notre client et apporter de la souplesse au dispositif d’équipe
Avoir une vision de bout en bout du code et faire le lien entre les développeurs back et front
Cette décision a été très structurante dans nos futurs développements. Là où nous n’arrivions pas à maintenir le contrat d'interface, le développeur full stack l'a repris et l’a mis à jour. Il nous a permis d’afficher l’ensemble des données sur le front que nous n'arrivions pas à réaliser auparavant.
L’équipe a décidé de prendre du recul et du temps pour elle pour présenter tout le processus de développement et faire du mob programming afin que chacun ait une bonne vision des impacts back et front.
Le développeur full stack a aussi créé du liant entre les développeurs backs qui manquaient de temps pour échanger ensemble.
Gains
Un contrat d’interface opérationnel,
Une meilleure fluidité du delivery entre les équipes de développements back et front,
Une plus grande souplesse de l’équipe dans la prise en compte des demandes du client.
Écosystème de notre delivery
Problèmes
- L’écosystème riche de notre client
Nous sommes une équipe agile mais qui vit dans une organisation silotée avec un mode projet en cycle en V. Que cela implique t-il ? L’équipe n’a pas la main sur son infrastructure. La moindre demande fait l’objet d’ouverture de tickets et de nombreux échanges pour justifier de son intérêt.
L’équipe Octo n’avait pas forcément un énorme vécu dans ce type d’organisation et s'est vu confrontée à plusieurs problèmes :
La mise en place d’une architecture et le lancement d’un projet doivent être validés par un Comité d’Architecture (COMAR), ce qui a pris un mois et demi et qui neuf mois après le lancement du projet étaient encore sujet à quelques discussions.
La mise en place de l'infrastructure pour démarrer le projet a elle aussi pris environ un mois et demi.
L’accès aux données pour commencer à les traiter a pris plusieurs mois.
La projection qui avait été initialement faite pour réaliser le projet était déjà fortement impactée par les éléments communiqués ci-dessus.
Les problèmes d’organisation et de mode de fonctionnement rencontrés par l’équipe ne sont pas liés spécifiquement à la nature du projet DATA que nous avons co-construit avec lui mais ils sont assez importants et impactants pour le présenter dans cet article.
Solutions
Pour faciliter notre delivery
Créer des liens avec vos interlocuteurs,
Identifier les différents acteurs opérationnels incontournables qui seront vous débloquer la situation,
N’hésitez pas à escalader à votre client les difficultés que vous rencontrez et les solutions que vous avez déjà mis en place.
Gains
Une accélération dans la prise en compte de nos demandes.
Un développeur Octo au sein des équipes snowflake nous a aidé à gagner en efficacité, à analyser et résoudre des problèmes en amont du datamart.
Nos apprentissages
- Rétablir la confiance de notre client
Le sujet n’est pas lié à la spécificité d’un projet DATA mais sans confiance vous ne faites rien encore plus quand vous êtes le dos au mur.
Il n’y a pas de baguette magique pour établir la confiance d’une équipe ou d’un client. Mais après des années à piloter des projets, j’ai acquis quelques croyances qui sont chevillées au corps.
Soyez transparent et factuel avec votre client, dites lui la situation telle qu’elle est tout en lui proposant des recommandations.
Informez-le des difficultés que vous allez rencontrer tout en proposant des solutions de remédiation,
Faites des points d’étapes réguliers pour lui donner de la visibilité,
Organisez des rencontres avec l’équipe pour partager,
Revoyez le périmètre du projet en apportant pas à pas de la valeur.
Selon ces principes, je lui ai exposé la difficulté de rétablir la réconciliation nécessaire des données entre le back et le front et que d’autres problèmes pourraient apparaître au fur et à mesure de la mise en œuvre du projet. tout comme la gouvernance de la data et la nécessité de construire des jeux de données.
Pour que la confiance se rétablisse, il faut que vous puissiez montrer un changement entre une situation à date et une situation cible, ce qui vous permet d’échanger plus sereinement avec toutes les parties prenantes.
- Connaissance du métier/data et des enjeux liés à la traçabilité
La gouvernance de la DATA est un sujet central pour coordonner les différents acteurs et s'assurer que la chaîne de valeur soit complète.
La disponibilité des experts métiers est primordiale, les identifier et s’assurer de leur présence dans les différents ateliers est essentiel. Sans eux le projet avance au ralenti.
Les données doivent être validées au plus tôt avec les règles de gestion pour s'assurer qu'elles sont réalisables et connues des différents responsables des ERP => Cohérence des données.
La montée en compétences de l’équipe sur ce type de projet peut être importante, ne la négligez pas.
La compréhension du métier et la construction du modèle de données ne doivent pas être sous-estimées, à la fois pour appréhender la complexité métier mais également pour répondre au mieux aux exigences fonctionnelles du client.
La DATA est le cœur du métier de notre client, il sera difficile de customiser un outil du marché pour répondre à l'ensemble de ses exigences
Le travail effectué nous a montré les manques soit sur le processus métier soit sur les données qui ne sont pas disponibles à date. Ce travail nous a permis d'échanger sur la valeur métier des données, rapportée au coût d'acquisition.
Le souhait de notre client était de réaliser une plateforme assez générique pour traiter tous ses métiers. Notre expérience sur le MVP nous a permis de voir les limites d'une plateforme multi-métiers, car celle-ci devra prendre en compte les spécificités de chacun des métiers. Nous proposons donc de décliner la plateforme afin de l'adapter aux caractéristiques des différents métiers.
- Organisation
Je retiens que dans certains cas notamment avec un fort enjeux data / back il ne vaut mieux pas intégrer les équipes front avant d’avoir stabilisé le back pour diminuer les allers-retours successifs sur le contrat d’interface où alors intégrer des développeurs full-stack. Il n’y a pas de bonne méthode. En tout cas, dans notre contexte, cela aurait été judicieux. Et je peux comprendre la frustration d’un client de ne pas voir tout de suite à quoi peut ressembler la solution.
N’hésitez pas à prendre du temps avec l’équipe pour vous projeter et regarder ce qu’il est possible de faire.
- Techniques
La performance des données est un élément majeur (traitement de centaines de millions de données). L'architecture qui doit être mise en œuvre doit prendre en compte cette composante avec l'optimisation des requêtes.
L'architecture doit être évolutive et scalable au regard des use-cases fournies par le métier. Dans le cadre de notre MVP, un outil de dataviz du marché connecté au datamart pouvait répondre aux besoins initiaux.
Elle doit être adaptée en fonction des besoins notamment sur un MVP. Vous n’avez pas besoin de construire l’architecture cible au début de votre projet.
L’équipe a acquis des compétences solides sur des composants techniques comme snowflake, la base graph et les requêtes gremlins qui lui servira par la suite sur des projets similaires et des recommandations que nous pourrions faire à nos clients qui sont confrontés au même problème.
- Connaissance de l’écosystème de votre client
La validation d'une architecture et le déploiement d'une infrastructure peuvent nécessiter un temps long au sein de certains de nos clients et constituent un point de passage obligé pour la réalisation du projet. Le planning de mise en œuvre doit en tenir compte pour ne pas se trouver impacté sur les features à réaliser.
La synchronisation avec les équipes de votre client doit parfois être renforcée dans la mesure où vous n’avez pas la main sur l'infrastructure globale du projet.
A partir du moment où l’on vous explique que dans le processus de delivery vous aurez un comité d’architecture, des CAB, une gestion de tickets pour déployer votre infrastructure, vous savez qu’il faudra du temps pour poser les premières briques de votre projet. En tout cas ne négligez pas le contexte
- La réversibilité
Lister l’ensemble des thématiques que vous devez transférer pour que l’équipe reprenne l’application en toute autonomie.
Définissez un indicateur de suivi assez simple à mettre en œuvre à partager avec les parties prenantes.
Planifier une série d'ateliers pour que la montée en compétence se fasse de façon progressive.
Accompagner l’équipe qui reprend l’application dans toutes les phases critiques du projet (recette, mise en production, post mise en production)
Définissez une période post Mise En Production qui vous permettra d’accompagner l’équipe sur des cas concrets afin qu’elle se sente de plus en plus à l’aise avec l’application concernée.
N’attendez pas le dernier moment pour faire la réversibilité. Si vous pouvez la commencer avant la mise en production, c’est idéal.