Dans le contexte dynamique des fusions et acquisitions, les entreprises se retrouvent confrontĂ©es Ă  d’importants dĂ©fis de convergence, notamment au niveau des systèmes d’information. Le choix stratĂ©gique d’un ERP ou d’un CRM cible est crucial et peut s’Ă©tendre sur plusieurs annĂ©es. Pourtant, la nĂ©cessitĂ© de disposer de rapports de gestion consolidĂ©s est immĂ©diate et impĂ©rative. Au niveau du groupe, le besoin de reporting de gestion est plus pressant, et il est rarement envisageable d’attendre la fin de la convergence pour disposer de tableaux de bords consolidĂ©s Ă  l’Ă©chelle d’un groupe.

Et, dĂ©tail qui a son importance, l’Ă©laboration de ces tableaux de bord nĂ©cessite la consolidation de donnĂ©es fines, pas la consolidation de donnĂ©es agrĂ©gĂ©es ! J’insiste sur ce point car c’est la raison pour laquelle la plateforme de donnĂ©es entre en jeu.

La nĂ©cessitĂ© d’une consolidation efficace

Dans ce cadre complexe, la Modern Data Stack Ă©merge comme la solution idĂ©ale pour une consolidation rapide et efficace des donnĂ©es entre les diffĂ©rentes entitĂ©s. Chaque entitĂ© a son SI, sans doute dĂ©jĂ  une BI en place. Selon le besoin, on souhaite s’accrocher Ă  la BI de l’entitĂ© ou directement aux donnĂ©es sources du SI.

Les plateformes data nouvelles gĂ©nĂ©rations permettent de connecter des systèmes d’information hĂ©tĂ©rogènes sans nĂ©cessiter leur convergence immĂ©diate. Imaginez une entreprise sur GCP BigQuery et une autre sur Snowflake ; il est très facile de mettre en place un partage de donnĂ©es sĂ©curisĂ© (eg : External Stage snowflake permettent de lire des buckets GCP dans le cas d’import, ou d’Ă©crire dans le cas d’un export, le tout très simplement, et sans problĂ©matique de volumĂ©trie ou de performance).

La pratique de l’ELT dans un Datawarehouse Cloud est gage de productivitĂ© et d’agilitĂ© dans un groupe en pleine construction. C’est la promesse des Modern Data Stack, synonyme de vĂ©locitĂ© tant dans les dĂ©veloppements que dans les traitements, de transparence au travers de processus qualitĂ©s contrĂ´lĂ©s avec du Devops

En somme, les technologies modernes permettent de faire vite et bien, et d’envisager plus loin.

Bien, mais non suffisant !

L’importance de la modĂ©lisation dĂ©cisionnelle

MĂŞme avec les meilleures technologies et les meilleurs Cloud Data Warehouse, le succès de ces projets tient pour beaucoup Ă  des efforts de modĂ©lisation particuliers pour concrĂ©tiser dans les donnĂ©es le mouvement de convergence. La modĂ©lisation multi-dimensionnelle a pour vertu de dĂ©coupler le Data Warehouse des modèles de donnĂ©es source pour aboutir Ă  une modĂ©lisation par « objets d’entreprise ». Ces objets, pour des sociĂ©tĂ©s d’activitĂ©s similaires, ne changeront pas. Une commande est une commande, un contrat est un contrat. Que ce soit stockĂ© dans 3 tables dans le système A et dans 1 table dans le système B n’a pas d’impact. J’illustre ce principe par un exemple de datawarehouse d’entreprise dans le cadre de fusions/acquisitions.

Un cas concret : La dimension client dans une fusion

Prenons l’exemple de la consolidation des donnĂ©es clients. En crĂ©ant une dimension client unique Ă  partir des rĂ©fĂ©rentiels de chaque sociĂ©tĂ©, nous pouvons dĂ©doublonner les informations sur des critères comme le SIRET, permettant ainsi des analyses prĂ©cises tant au niveau consolidĂ© que par entitĂ©.

Cas d’une dimension :

  • table dwh_dim_client__societeB => c’est mon rĂ©fĂ©rentiel de client societe B
  • table dwh_dim_client__societeA => c’est mon rĂ©fĂ©rentiel de client societe A

=> Je vais crĂ©er une dimension client qui est l’union des 2

Illustration DBT d’union de dimensions


Cas d’un fait :

  • une facture, un relevĂ© d’heure, donc un fait, est reliĂ© Ă  sa dimension source, pas Ă  sa dimension consolidĂ©e. Cela permet une analyse de la source quoi qu’il advienne. Pour la cible, voir le point suivant

Mise en place de dimensions chapeau :

  • A partir de tous mes client__* je constitue un dimension dwh_dim_client_unique rĂ©fĂ©rencĂ©e dans chacune des dimensions sources. Je la dĂ©doublonne sur le siret et le tour est jouĂ©.
  • En clair, cela permet des rapprochements autant du point de vue consolidĂ© groupe, qu’Ă  la source sur la consolidation entitĂ©.
Illustration DBT de la dimension chapeau

Ces dimensions chapeaux permettent Ă©galement d’harmoniser des donnĂ©es mĂ©tiers ( statut d’une commande, type de contrat, etc… )

Illustration DBT d’harmonisation de dimensions

L’outil DBT permet ce parfait dĂ©coupage entre donnĂ©es sources et agrĂ©gation sur des rĂ©fĂ©rentiels fusionnĂ©s.

NB : en BI, on a parfois du mal Ă  discerner si un objet doit ĂŞtre une dimension ou un fait. Dans le cadre d’une convergence oĂą les donnĂ©es viennent de plusieurs SI, la dissociation devient plus Ă©vidente :

  • dimension : on cherche Ă  crĂ©er des dimensions chapeau, des regroupements (exemple des clients, des familles de contrats)
  • fait : on les cumule, car un fait n’est Ă©mis que par un système (lors du switch, on bascule sur l’autre système, mais pas question de regroupements)

Suivi de la convergence

Il est Ă©galement crucial de suivre la convergence des systèmes au fur et Ă  mesure des migrations. La Modern Data Stack permet de maintenir la cohĂ©rence des donnĂ©es pour toutes les entitĂ©s, qu’elles aient migrĂ© vers le nouveau système ou non, grâce Ă  des dimensions chapeau efficaces qui reflètent les Ă©tats avant et après migration.

Sujet tout aussi intĂ©ressant : raccorder un ensemble de donnĂ©es hĂ©tĂ©rogènes est une chose, s’assurer de la cohĂ©rence des donnĂ©es au fur et Ă  mesure que la convergence se concrĂ©tise en est une autre.

En clair, pour un objet donnĂ©, il y a un avant et un après, mais tous les objets ne convergent pas au mĂŞme moment. Par exemple, vous ne migrez pas toutes les agences d’une entitĂ© vers un nouvel ERP au mĂŞme moment, il va y avoir des agences pilotes, etc… et Ă©ventuellement des lots de migration.

Dans ce mouvement, la plateforme data se doit d’assurer la cohĂ©rence des chiffres, que ce soit pour les agences qui n’ont pas migrĂ© comme pour les agences qui ont migrĂ©. Pour cela, une gymnastique de correspondance va ĂŞtre mise en place, notamment la notion de dimension chapeau, pour par exemple avoir dans le cadre d’une agence : l’agence avant migration, l’agence après migration, et dans une dimension chapeau une seule agence.

Conclusion

L’efficacitĂ© de la Modern Data Stack dans le cadre de fusions et acquisitions ne rĂ©side pas seulement dans sa capacitĂ© Ă  gĂ©rer de grands volumes de donnĂ©es ou Ă  intĂ©grer des technologies de pointe, mais Ă©galement dans son approche stratĂ©gique de la modĂ©lisation et de la gestion de la donnĂ©e.

L’objectif de cet article n’était pas d’expliquer pourquoi des groupes en pleine structuration ont un besoin crucial de data, mais comment les technologies actuelles, alliées à un savoir-faire de modélisation décisionnel, formaient le dispositif idéal pour répondre à ce besoin.

La Modern Data Stack répond parfaitement à ces enjeux.

#datamanagement #fusionsacquisitions #moderndatastack #faitesbrillervosdonnees #effidic