Heny SELMI, BI Manager chez Mantu Group – Data Science Consultant chez Mantu-Amaris Consulting, Tunis
Quant à la mise en œuvre d’une stratégie Data, elle est rarement statique, et ce quel que soit le secteur d’activité. Généralement, un directeur des données (CDO) est chargé de veiller à ce que cette stratégie s’adapte de façon dynamique, en réponse à la pression concurrentielle et aux mutations de la stratégie d’ensemble de la société.
Source unique SSOT, Interprétations multiple MVOT
Dans un premier stade de la stratégie data, il est important de distinguer l’information et la donnée d’une part, et l’architecture de l’information et l’architecture des données d’autre part.
Selon Peter Drucker, l’information se définit comme suit : « des données dotées d’une pertinence et d’un objectif ». En effet, les données brutes, comme les taux de fidélisation des clients, les chiffres des ventes et les coûts des fournitures, sont d’une utilité réduite tant qu’elles n’ont pas été contextualisées, croisées avec d’autres données ou transformées en informations susceptibles d’orienter le processus de prise de décision. Par contre, des données comme les taux de vente, replacés dans une perspective historique ou dans le contexte analytique comparatif, prennent soudain du sens – ils sont à la hausse ou à la baisse par rapport à certaines références ou en réponse à un besoin métier particulier.
Au sein des entreprises, l’architecture des données définit la façon dont les données sont captées, stockées, transformées, distribuées et exploitées. Elle englobe les règles qui régissent les formats structurés. L’architecture de l’information régit les opérations et les règles de conversion des données en informations exploitables. Plus particulièrement, il revient à l’architecture des données, d’alimenter les outils de l’architecture de l’information en données brutes quotidiennes, relatives au besoin d’un secteur d’activité ou un département précis. Ces données seront ensuite intégrées et analysées de manière à faire apparaître les relations entre les différents indicateurs de performance mis en jeu.
Dans ce contexte, pas mal d’entreprise ont déjà tenté d’élaborer des architectures de données et d’informations fortement centralisées et orientées vers le contrôle, via les outils de MDM (Master Data Management). Mais, ces approches restent toujours verticales dans le sens où elles ne fournissent pas un cadre approprié à une stratégie data étalée permettant de couvrir tous les enjeux internes et externes. D’ailleurs, si elles trouvent leur utilité dans la standardisation des données de l’entreprise, elles peuvent faire obstacle à la flexibilité, rendant ainsi plus complexe l’adaptation des besoins de l’entreprise, ou leur conversion, en une information à même de trouver son application stratégique.
D’où, la nécessité d’adopter de manière rapide, une approche data plus souple et réaliste de l’architecture de données et de l’information consistant à recourir à la fois à une source unique de vérité (SSOT, Single Source of Truth) et à des interprétations multiples (MVOT, Multiple Versions of the Truth).
La source unique est mieux adaptée aux données proprement dites, et est assurée par l’entreposage de données (le Data Warehouse au sens BI, le Data Lake au sens Big Data). Quant aux interprétations multiples, elles seront réservées aux décideurs, en tenant compte de la nature de leurs métiers ou secteurs d’activités. Ainsi, le développement d’une stratégie data selon une approche défensive-offensive nécessite des architectures data et informations flexibles autorisant simultanément une source unique de vérité et des versions multiples.
En effet, la SSOT est un référentiel cohérent, souvent virtuel et localisé dans le cloud, contenant généralement une copie, faisant autorité, de toutes les données essentielles, telles que les informations relatives à la clientèle, aux fournisseurs, aux produits, aux projets en cours, aux recruteurs, aux HR, etc.
Par ailleurs, l’absence de SSOT peut conduire au chaos : quand les données d’une entreprise provenaient de plus qu’une source, dans lesquelles étaient enregistrées les mêmes informations d’un fournisseur ; mais dont le contenu était légèrement différent dans chacune des sources, par exemple dans une source un fournisseur était identifié sous le nom Abcd, dans une autre, il était nommé Abcd Inc. ; et une troisième source on le dénommait ABCD Group. De même, une multinationale vient de changer sa marque du groupe en MM Group, sachant que MM était le nom d’une de ses filiales de consulting, et étant donné qu’elle regroupe actuellement plusieurs filiales à savoir MMconsulting, MMR&D, etc., elle risque désormais d’avoir plusieurs nouveaux modules dans ses différentes applications ERP, et par conséquences plusieurs noms, identifiants, trigrammes… dans ses différentes sources de données.
L’être humain sait bien décoder ce type de problème, mais les systèmes informatiques ne seront pas capables de démêler ce type d’incidents. Cependant, disposer d’un entrepôt de données ou d’un lac de données est la pierre angulaire du référentiel SSOT.
Car, mise à part les finalités d’analyse, d’historisation, de centralisation et de support pour les processus de prise de décision, avoir un entrepôt de données permet également de construire une source unique de vérité, afin d’éviter de multiples interprétations. En effet, centraliser toutes les données opérationnelles des départements clefs, notamment Administration, Finance, Business, HR, Recrutement, Marketing, etc., offrira deux aspects complémentaires et cruciaux pour assurer une stratégie Data : le contrôle via le respect des dictionnaires de données et la présence de l’ensemble des KPIs dans l’entrepôt de données, ainsi que la flexibilité, grâce à la possibilité de construire un catalogue d’indicateurs en lien avec la même source de vérité.
Ainsi, le nombre d’heures de travail peut être interprété différemment entre les HR, les équipes Recrutement et les N+1… L’ETC (Estimate to Completion) pourra exprimer, d’une part la somme des coûts restant de chacun des membres de l’équipe qui travaille sur un projet précis, et d’autre part peut indiquer la productivité et les retards possibles de livraison… et les exemples sont divers. C’est à partir de la source unique que sont élaborées les interprétations multiples de la vérité. Ces dernières résultent généralement des transformations, pour des besoins spécifiques à l’entreprise, des données en informations pertinences et porteuses d’objectif métier. Ainsi, à mesure que les différentes équipes, au sein des différentes gouvernances et des services, traitent, cataloguent et rendent compte des données, elles élaborent des versions distinctes, maitrisées, de la vérité, qui, lorsqu’elles sont sollicitées, seront capables de fournir des réponses cohérentes, adaptées aux besoins préétablis des différents groupes de consommateurs de data.
Selon Peter Drucker, l’information se définit comme suit : « des données dotées d’une pertinence et d’un objectif ». En effet, les données brutes, comme les taux de fidélisation des clients, les chiffres des ventes et les coûts des fournitures, sont d’une utilité réduite tant qu’elles n’ont pas été contextualisées, croisées avec d’autres données ou transformées en informations susceptibles d’orienter le processus de prise de décision. Par contre, des données comme les taux de vente, replacés dans une perspective historique ou dans le contexte analytique comparatif, prennent soudain du sens – ils sont à la hausse ou à la baisse par rapport à certaines références ou en réponse à un besoin métier particulier.
Au sein des entreprises, l’architecture des données définit la façon dont les données sont captées, stockées, transformées, distribuées et exploitées. Elle englobe les règles qui régissent les formats structurés. L’architecture de l’information régit les opérations et les règles de conversion des données en informations exploitables. Plus particulièrement, il revient à l’architecture des données, d’alimenter les outils de l’architecture de l’information en données brutes quotidiennes, relatives au besoin d’un secteur d’activité ou un département précis. Ces données seront ensuite intégrées et analysées de manière à faire apparaître les relations entre les différents indicateurs de performance mis en jeu.
Dans ce contexte, pas mal d’entreprise ont déjà tenté d’élaborer des architectures de données et d’informations fortement centralisées et orientées vers le contrôle, via les outils de MDM (Master Data Management). Mais, ces approches restent toujours verticales dans le sens où elles ne fournissent pas un cadre approprié à une stratégie data étalée permettant de couvrir tous les enjeux internes et externes. D’ailleurs, si elles trouvent leur utilité dans la standardisation des données de l’entreprise, elles peuvent faire obstacle à la flexibilité, rendant ainsi plus complexe l’adaptation des besoins de l’entreprise, ou leur conversion, en une information à même de trouver son application stratégique.
D’où, la nécessité d’adopter de manière rapide, une approche data plus souple et réaliste de l’architecture de données et de l’information consistant à recourir à la fois à une source unique de vérité (SSOT, Single Source of Truth) et à des interprétations multiples (MVOT, Multiple Versions of the Truth).
La source unique est mieux adaptée aux données proprement dites, et est assurée par l’entreposage de données (le Data Warehouse au sens BI, le Data Lake au sens Big Data). Quant aux interprétations multiples, elles seront réservées aux décideurs, en tenant compte de la nature de leurs métiers ou secteurs d’activités. Ainsi, le développement d’une stratégie data selon une approche défensive-offensive nécessite des architectures data et informations flexibles autorisant simultanément une source unique de vérité et des versions multiples.
En effet, la SSOT est un référentiel cohérent, souvent virtuel et localisé dans le cloud, contenant généralement une copie, faisant autorité, de toutes les données essentielles, telles que les informations relatives à la clientèle, aux fournisseurs, aux produits, aux projets en cours, aux recruteurs, aux HR, etc.
Par ailleurs, l’absence de SSOT peut conduire au chaos : quand les données d’une entreprise provenaient de plus qu’une source, dans lesquelles étaient enregistrées les mêmes informations d’un fournisseur ; mais dont le contenu était légèrement différent dans chacune des sources, par exemple dans une source un fournisseur était identifié sous le nom Abcd, dans une autre, il était nommé Abcd Inc. ; et une troisième source on le dénommait ABCD Group. De même, une multinationale vient de changer sa marque du groupe en MM Group, sachant que MM était le nom d’une de ses filiales de consulting, et étant donné qu’elle regroupe actuellement plusieurs filiales à savoir MMconsulting, MMR&D, etc., elle risque désormais d’avoir plusieurs nouveaux modules dans ses différentes applications ERP, et par conséquences plusieurs noms, identifiants, trigrammes… dans ses différentes sources de données.
L’être humain sait bien décoder ce type de problème, mais les systèmes informatiques ne seront pas capables de démêler ce type d’incidents. Cependant, disposer d’un entrepôt de données ou d’un lac de données est la pierre angulaire du référentiel SSOT.
Car, mise à part les finalités d’analyse, d’historisation, de centralisation et de support pour les processus de prise de décision, avoir un entrepôt de données permet également de construire une source unique de vérité, afin d’éviter de multiples interprétations. En effet, centraliser toutes les données opérationnelles des départements clefs, notamment Administration, Finance, Business, HR, Recrutement, Marketing, etc., offrira deux aspects complémentaires et cruciaux pour assurer une stratégie Data : le contrôle via le respect des dictionnaires de données et la présence de l’ensemble des KPIs dans l’entrepôt de données, ainsi que la flexibilité, grâce à la possibilité de construire un catalogue d’indicateurs en lien avec la même source de vérité.
Ainsi, le nombre d’heures de travail peut être interprété différemment entre les HR, les équipes Recrutement et les N+1… L’ETC (Estimate to Completion) pourra exprimer, d’une part la somme des coûts restant de chacun des membres de l’équipe qui travaille sur un projet précis, et d’autre part peut indiquer la productivité et les retards possibles de livraison… et les exemples sont divers. C’est à partir de la source unique que sont élaborées les interprétations multiples de la vérité. Ces dernières résultent généralement des transformations, pour des besoins spécifiques à l’entreprise, des données en informations pertinences et porteuses d’objectif métier. Ainsi, à mesure que les différentes équipes, au sein des différentes gouvernances et des services, traitent, cataloguent et rendent compte des données, elles élaborent des versions distinctes, maitrisées, de la vérité, qui, lorsqu’elles sont sollicitées, seront capables de fournir des réponses cohérentes, adaptées aux besoins préétablis des différents groupes de consommateurs de data.
Entrepôt de données ou Lac de données pour assurer un équilibre SSOT-MVOT
Il y a quelques années à peine, les limites de la technologie rendaient difficiles la construction d’une architecture de données SSOT-MVOT capable de venir en appui à une stratégie data solide. Alors, les sociétés migraient du modèle relationnel de data vers les entrepôts de données, en adoptant les stratégies de Business Intelligence visant à mettre des perspectives orientant la data vers le processus de prise de décision.
Le but principal étant d’assurer l’historisation, la centralisation et l’analyse de la donnée opérationnelle, les finalités du modèle Data Warehouse portent aussi sur l’optimisation du temps de réponse quand les utilisateurs finaux interrogeaient des quantités colossales de données.
Ainsi, même en tenant compte des problèmes de volumétrie de données, le Data Warehouse restera toujours l’une des meilleures solutions garantissant un bon équilibre SSOT-MVOT, à condition que les données traitées soient principalement structurées, peu importe leurs sources : ERP, CRM, Base de données, etc.
Cependant, il sera à noter que moins de 1% des données non structurées sont analysées ou simplement prise en compte lors de la prise de décision, selon une étude réalisée par Harvard University en 2018 auprès d’entreprises américaines.
Alors, pour répondre aux besoins des entreprises mettant en jeu cette nature de données, il est impératif d’avoir recours à une architecture moins coûteuse, plus agile et évolutive. En effet, le Data Lake pourra être l’équivalent du modèle data warehouse du point de vue de ses objectifs, mais peut encore stocker des quantités virtuellement illimitées de données, structurées, semi-structurées ou non structurées. : des contenus textuels, des fichiers Web, des fichiers Images, des séquences vidéo, des signaux, etc.
En général, les lacs de données constituent la plateforme idéale pour l’architecture SSOT-MVOT. Un lac de données peut héberger la source unique, extraire, stocker, et fournir l’accès aux données de la plus petite granularité, descendant jusqu’au niveau des transactions individuelles. Et il accepte l’agrégation de données SSOT dans des configurations pour ainsi dire illimitées, sous la forme de MVOT hébergées également dans le lac.
Les entrepôts de données gardent toujours leur utilité : ils stockent les données des applications de production qui exigent une sécurité renforcée et des contrôles d’accès, ce que peu de lacs de données peuvent offrir, à cause du caractère open-source des écosystèmes Big Data. Nombre de sociétés ont à leur disposition tout à la fois des lacs de données et des entrepôts, et même si la part croissante des données est hébergées dans les lacs, l’entrepôt restera indispensable pour assurer la SSOT-MVOT.
Le but principal étant d’assurer l’historisation, la centralisation et l’analyse de la donnée opérationnelle, les finalités du modèle Data Warehouse portent aussi sur l’optimisation du temps de réponse quand les utilisateurs finaux interrogeaient des quantités colossales de données.
Ainsi, même en tenant compte des problèmes de volumétrie de données, le Data Warehouse restera toujours l’une des meilleures solutions garantissant un bon équilibre SSOT-MVOT, à condition que les données traitées soient principalement structurées, peu importe leurs sources : ERP, CRM, Base de données, etc.
Cependant, il sera à noter que moins de 1% des données non structurées sont analysées ou simplement prise en compte lors de la prise de décision, selon une étude réalisée par Harvard University en 2018 auprès d’entreprises américaines.
Alors, pour répondre aux besoins des entreprises mettant en jeu cette nature de données, il est impératif d’avoir recours à une architecture moins coûteuse, plus agile et évolutive. En effet, le Data Lake pourra être l’équivalent du modèle data warehouse du point de vue de ses objectifs, mais peut encore stocker des quantités virtuellement illimitées de données, structurées, semi-structurées ou non structurées. : des contenus textuels, des fichiers Web, des fichiers Images, des séquences vidéo, des signaux, etc.
En général, les lacs de données constituent la plateforme idéale pour l’architecture SSOT-MVOT. Un lac de données peut héberger la source unique, extraire, stocker, et fournir l’accès aux données de la plus petite granularité, descendant jusqu’au niveau des transactions individuelles. Et il accepte l’agrégation de données SSOT dans des configurations pour ainsi dire illimitées, sous la forme de MVOT hébergées également dans le lac.
Les entrepôts de données gardent toujours leur utilité : ils stockent les données des applications de production qui exigent une sécurité renforcée et des contrôles d’accès, ce que peu de lacs de données peuvent offrir, à cause du caractère open-source des écosystèmes Big Data. Nombre de sociétés ont à leur disposition tout à la fois des lacs de données et des entrepôts, et même si la part croissante des données est hébergées dans les lacs, l’entrepôt restera indispensable pour assurer la SSOT-MVOT.