Mise en place d'une équipe Data - Partie 1 : Data Anarchy

Dans le paysage commercial actuel, de plus en plus guidé par les données, un département data est devenu essentiel pour permettre à une entreprise de prendre des décisions éclairées et de rester compétitive. L'élaboration d'une stratégie et d'une culture data permet d'optimiser les choix stratégiques et opérationnels, tout en se prémunissant contre les baisses d'activité, les investissements non pertinents, les coûts cachés et les pertes financières.

Les organisations qui ne parviennent pas à utiliser efficacement leur patrimoine de données risquent de perdre en compétitivité. En revanche, celles qui en tirent parti pour comprendre les tendances du marché, les besoins des clients et les critères essentiels de performance de leur domaine d'activité peuvent prendre l'avantage plus facilement. Bien que la valorisation des données devienne de plus en plus cruciale, nous verrons par la suite que ce processus est plus complexe et plus long qu'on pourrait le croire.

Le concept de Data Anarchy

Définition de l'anarchie dans le contexte data :

On peut qualifier la situation précédant la mise en place d'une équipe data de "data anarchy". Bien que ce terme puisse sembler connoté négativement, il n'est pas ici péjoratif. L'anarchie est un concept qui promeut une société sans autorité gouvernementale ou hiérarchie coercitive. Dans une société anarchique, l'ordre est censé émerger spontanément à partir de la coopération volontaire des individus plutôt que d'être imposé par une autorité centralisée.

Transposée au contexte professionnel et à la gestion des données, cette définition neutre nous permet de comprendre qu'une organisation qui construit la gestion des données sans une équipe Data dédiée peut arriver à un résultat analytique fonctionnel, mais souvent peu optimisé.

Les caractéristiques de la Data Anarchy :

Dans un contexte de Data Anarchy, on observe généralement :

• Des données en silos : les informations sont éparpillées dans différentes applications (CRM, ERP…) non connectées entre elles.
• Une transmission des données par fichiers : le partage de données se fait souvent via des fichiers, avec une prédominance des tableurs (Excel).
• Un manque d'historisation : les données ne sont pas conservées dans le temps, et sans stratégie de versioning.
• Des capacités d'analyse limitées : les outils utilisés sont souvent basiques comparés aux solutions modernes du marché.
• Une difficulté de réconciliation des données : les données provenant de différents silos sont difficiles à combiner sans un effort important.

Les limites de la Data Anarchy :

Bien que fonctionnelle, cette approche présente des limites de plus en plus évidentes face à l'évolution constante des technologies et des besoins en analyse de données. Les organisations qui restent à un niveau basique de gestion des données auront de plus en plus de mal à suivre l'avancée technologique et stratégique des solutions modernes en data.

L'héritage technologique : un écosystème complexe à appréhender

Le Legacy, le poids du passé :

À l'heure actuelle, de nombreuses organisations mettant en œuvre un projet data partent d'un existant, appelé "Legacy" dans notre jargon. Ce patrimoine de données, de code et d'outils s'est constitué au fil des années, souvent sans stratégie data élaborée, hormis pour les start-ups récentes.

Bien que des solutions comme SAP et Business Objects soient présentes dans les grands groupes depuis longtemps, leur ticket d'entrée élevé et leur gamme de produits moins optimisée que les fournisseurs cloud actuels (Google Cloud, AWS, Microsoft Azure) les rendent maintenant moins attractives sur le marché.

La construction du Legacy :

Ce Legacy est construit par les différents collaborateurs au fil du temps. Ce système d'information, bien que fonctionnel, montre généralement des faiblesses, des signes d'aléas de gestion et de qualité inhérents à tout projet développé sans expertise spécifique en data.

De plus, le domaine de la "data" / "big data" étant relativement récent, avec une popularisation au cours de la dernière décennie, les systèmes d'information actuels ont un besoin important de modernisation. Pour chercher à comprendre plus facilement ce type de situation, voici un exemple fictif d’une construction de Legacy. C’est une évolution graduelle de solutions qui finissent par donner un agrégat peu optimisé d’outils de gestion des flux de données.

Use case : construction du Legacy chez TechnoRetail

TechnoRetail est une chaîne de magasins d'électronique fondée il y a 25 ans. Au fil des années, l'entreprise a grandi et s'est adaptée aux évolutions technologiques, mais sans jamais mettre en place une véritable stratégie data centralisée. Voici comment s'est construit leur Legacy :

1. Les débuts (1998-2005)
   • Utilisation de fichiers Excel pour gérer les stocks et les ventes
   • Base de données Access pour le fichier client
   • Rapports mensuels générés manuellement
2. Première modernisation (2006-2010)
   • Mise en place d'un ERP basique pour la gestion des stocks et de la comptabilité
   • Création d'une base de données SQL Server pour centraliser les données clients
   • Développement de scripts VBA pour automatiser certains rapports
3. Expansion et diversification (2011-2015)
   • Lancement d'un site e-commerce avec sa propre base de données MySQL
   • Adoption d'un CRM pour la gestion de la relation client
   • Création de tableaux de bord sur Excel connectés aux différentes sources de données
4. Tentatives d'amélioration (2016-2020)
   • Mise en place d'un data warehouse rudimentaire sur SQL Server
   • Adoption de Power BI pour la création de tableaux de bord plus avancés
   • Développement de scripts Python pour l'extraction et le traitement de données
5. Situation actuelle
   • Multitude de systèmes non connectés (ERP, CRM, e-commerce, points de vente)
   • Données dispersées dans différentes bases (SQL Server, MySQL, fichiers plats) et certaines saisies manuellement. Par exemple, des interventions manuelles sur les données du catalogue (les tarifs, les dates de disponibilité, etc.) peuvent générer des erreurs et des incohérences dans les systèmes.
   • Processus d'ETL partiellement automatisés mais peu fiables
   • Tableaux de bord Power BI alimentés manuellement pour la plupart
   • Absence de gouvernance des données et de documentation centralisée

Cette construction progressive du Legacy, sans vision data globale, a conduit à un système d'information complexe, fragmenté et difficile à maintenir. L'arrivée d'une équipe data dédiée sera cruciale pour moderniser et optimiser cette infrastructure.

La découverte des leviers d'amélioration :

L'arrivée d'une équipe data révèle généralement l'étendue des possibilités d'optimisation dans la gestion et la valorisation des informations existantes. Cette phase de découverte met en lumière de nombreux axes d'amélioration jusqu'alors insoupçonnés. En effet, sans formation, expérience, spécialisation ou expertise spécifique, les collaborateurs n'étaient pas familiarisés avec les principes fondamentaux du domaine data.

La nécessité d'une équipe Data dédiée :

Face à ces limites, de plus en plus de directions font appel à des experts data pour monter une solution intégrant toutes les bonnes pratiques de développement pour la gestion des données. Cela induit, au départ du projet, une forte centralisation des données autour d'une équipe réduite.

Composition d'une équipe Data :

Une équipe data type se compose généralement de plusieurs profils aux rôles complémentaires :

• Head of Data : Responsable de la stratégie globale et de la gestion de l'équipe.
• Profils techniques (Data Architect / Data Engineer / Cloud DevOps) : Chargés de l'architecture et de l'intégration des données.
• Profils analystes (Data Analyst / Data Scientist) : Responsables de la valorisation d'informations utiles à partir des données.
• Profil gouvernance (Data Steward / Analytics Engineer) : Garant de la qualité, de la conformité et de la documentation des données.

La phase de recrutement est le socle du projet. Ce sont les fondations qui vont supporter tout le travail à effectuer pour remplir les objectifs d'un projet data. C'est le facteur humain qui va déterminer les choix stratégiques de développement du produit data et son avancée opérationnelle.

Ceci dit, la mise en place d'une équipe Data présente plusieurs défis qui doivent être bien pris en compte en amont, car "gouverner, c'est prévoir".

Les défis de la mise en place d'une équipe Data :

Voici les principaux enjeux auxquels sont confrontés les projets en data :

• Le recrutement : trouver des profils qualifiés peut s'avérer difficile et chronophage.
• La qualité de la donnée : les données existantes peuvent présenter des incohérences ou des erreurs. C'est LE chantier à mettre en avant dans le projet, souvent l'investissement le plus difficile mais le plus essentiel pour pouvoir valoriser les données.
• La vitesse de mise en place : le processus nécessite un investissement important en temps et en ressources. Notamment, l'acculturation de tous les collaborateurs est à prioriser au plus tôt pendant le projet.
• L'évolutivité : il faut concevoir une architecture capable d'évoluer avec les besoins de l'organisation. Avec la Modern Data Stack, il est plus facile de rendre indépendantes les briques les unes des autres. On peut les remplacer ou les améliorer sans tout devoir refondre. Il est indispensable de garder ses outils les plus indépendants les uns des autres lors des phases de développement.
• Les coûts : les profils Data sont généralement coûteux, et l'infrastructure nécessaire peut représenter un investissement conséquent.

La mise en place d'une équipe Data dédiée est donc une étape cruciale pour moderniser l'approche de la gestion des données. Dans la deuxième partie, nous explorerons le concept de "Data Monarchy" et verrons comment l'équipe Data peut contribuer à développer et harmoniser le système d'information de l'organisation en tenant un rôle clef.