Utiliser la modélisation du Data Warehouse pour construire son prévisionnel

Accueil » Blog Modellis sur le pilotage de la performance » Prévisions » Processus d'élaboration budgétaire » Utiliser la modélisation du Data Warehouse pour construire son prévisionnel

Utiliser la modélisation du Data Warehouse pour construire son prévisionnel

Data Warehouse et Simulation prévisionnelle

L’intérêt de capitaliser sur son Data Warehouse

Si on part du principe que les indicateurs suivis à la sortie d’un data warehouse sont bien ceux qui permettent de piloter l’entreprise dans sa globalité et dans sa diversité alors les outils d’élaboration budgétaire et de simulation doivent reprendre en grande partie sinon en totalité la structure et les métadonnées (metadata) utilisées.

Un indicateur de haut niveau va correspondre à l’agrégation et à la combinaison d’informations élémentaires selon différents axes d’analyse, les dimensions.

Ces indicateurs vont être stockées dans une table de faits entourés de ces différentes dimensions.

On va retrouver des données élémentaires préalablement retraitées (transformées) pour une cohérence d’ensemble des différentes sources (multiples ERP, HR ou CRM voire fichiers Excel).

On va pouvoir y retrouver des données prévisionnelles à côté du réel une fois ces informations remontées dans les systèmes amonts et réinjectées dans le data warehouse.

C’est ici que le bât blesse.

Les problèmes non résolus

S’il était possible de gérer facilement pour des utilisateurs des modifications directement dans le data warehouse pour modifier certains items pour leurs besoins de simulation (exemples saisir de nouveaux employés pour la simulation de la masse salariale ou des investissements potentiels) et de modifier à la volée des paramètres, des hypothèses, dans les formules de calcul tout serait pour le mieux dans le meilleur des mondes.

Mais par nature un data warehouse n’est pas une zone où l’on laisse les utilisateurs saisirent.

Pourquoi ?

Retour sur l’origine du concept de Data Warehouse

Pour expliquer cela il faut remonter à l’origine de la solution que constitue un data warehouse et par construction aux problèmes qu’il a résolus.

Le besoin primaire a toujours été de proposer une vue consolidée et transverse des différentes informations présentes dans les systèmes en un endroit centralisé, sécurisé et harmonisé où il serait facile d’aller puiser une réponse à ses besoins.

Ceci y compris sur des données qui auraient évolué dans le temps (pensez au changement d’adresse du siège social d’une société).

Data Warehouse overview (Wikipedia)

Data Warehouse overview (Wikipedia)

L’ère de la rareté

Or il fut un temps où les capacités de stockage et la puissance de calculs n’étaient pas aussi incroyables que celles d’aujourd’hui.

Lorsque l’on a une volumétrie importante et qu’une requête doit parcourir la base pour agréger une information cela peut prendre un certain temps. Pire encore vous avez souvent besoin de faire référence à un agrégat pour par exemple calculer un ratio.

La puissance de calcul étant ce qu’elle était, différentes solutions virent le jour en proposant de pré-calculer ces agrégats et de les stocker.

Bien évidemment toute solution a ses revers mais au moins il n’y avait plus de requêtes passées directement sur l’outil transactionnel (et bien évidemment au même moment pour tout le monde) qui engendrait une gêne considérable pour ceux qui étaient en train de saisir.

Qui plus est le data warehouse et ses déclinaisons en datamarts permettaient de ne plus lancer une requête mammouth dont le résultat serait inexorablement stocké dans un fichier Excel / Lotus ou une base Access / Paradox.

D’où une meilleure cohérence attendue dans les discussions autour des indicateurs.

Pourquoi Excel continue à dominer le monde de l’analyse

Pourtant un département va résister encore et toujours à ce diktat de la cohérence : le contrôle de gestion. Il y en a d’autres mais c’est probablement dans celui-ci que les plus grands spécialistes du tableur sont logés.

On peut avancer plusieurs explications comme la volonté de garder la main sur les traitements ou la peur d’être un jour démuni lors d’une panne informatique, mais je crois que la raison principale est de pouvoir saisir et voir en temps réel le résultat.

Et là ce n’est pas possible dans un data warehouse classique.

Les bases  NoSQL à la rescousse

Pourtant aujourd’hui la technologie a bien évolué.

En un clic sur internet vous avez accès en quelques millisecondes à des informations autrement plus volumineuses que celles stockées dans un data warehouse.

Qui plus est, il est possible de saisir dans beaucoup de cas car les données sont structurées « à plat » sans spécialement de calculs d’agrégats stockés, tout se faisant à la volée.

Enfin les possibilités offertes par les bases de données NoSQL (document, clés-valeurs,…) permettent de faire évoluer le schéma en fonction des données.

On voit bien ici les perspectives d’autant que le coût du stockage tend vers zéro.

Vers des possibilités infinies

Maintenant si on prend un peu de recul ceci ouvre la voie à de nombreuses possibilités

A partir du moment où un KPI est calculé, cela signifie que l’on a identifié les sources et les règles de transformation y compris donc les business rules. De la même façon les dimensions nous renseignent sur les besoins en matière d’analyse.

Si à côté de la donnée réelle (par opposition à prévisionnelle) ainsi calculée on avait la possibilité d’avoir un champ pour exactement la même notion (par exemple chiffre d’affaires ou nombre de commandes) avec plusieurs versions (budget, forecast Q1,… simulation personnelle) et la faculté de répartir cette donnée en utilisant différentes possibilités d’allocations (même poids que l’année dernière, à part égale sur l’axe temps, en fonction du nombre de PCs, … ) alors on aurait la possibilité théoriquement de fusionner un outil budgétaire et d’analyse avec le data warehouse.

En fait cela semble plus que possible techniquement.

Des questions qui surgissent

Néanmoins il y a un sujet de modélisation qui n’est pas trivial du tout et qui pose plusieurs questions.

Comment déterminer les inducteurs pour les allocations en dehors de l’axe temps ? Et c’est là que l’analyse statistique des données (plus précisément des corrélations entre-elles) peut vraiment se révéler utile.

En fait on se rapproche de problématiques d’économétrie et de la résolution simultanée de plusieurs équations.

Comment permettre la création d’une règle d’allocation en fonction des paramètres ainsi déterminés ? Une fois déterminé les équations encore faut-il proposer une solution permettant de jouer sur les variables, celles-ci pouvant être des données pures ou des hypothèses, des coefficients.

Pour l’instant je n’ai vu aucune solution permettant de résoudre dans une seule application les deux problématiques simultanément et de façon dynamique.

HTAP ou l’avenir du décisionnel et du transactionnel

Mais cela va changer avec l’arrivée des bases de données de nouvelle génération capables de gérer simultanément des tâches transactionnelles et analytiques.

Le Gartner les a baptisées du nom de Hybrid Transactional/Analytical Processing (HTAP) . On trouve dans cette catégorie des bases encore confidentielles comme MemSQL, VoltDB , NuoDB qui ouvrent la voie vers des terres inconnues

Elles seront probablement rejointes par celles proposées par les éditeurs établis.

Plus récemment la distibution Cloudera est rentrée dans cette catégorie et on peut considérer que SAP HANA est également dans cette mouvance.

L’évolution sera plus technique que fonctionnelle…dans un premier temps

La technologie peut révolutionner les besoins et ce sera sûrement le cas à terme avec ces solutions.

On se retournera et on se demandera comment on a pu avoir un data warehouse séparé des solutions transactionnelles, comment on a pu accepter des décalages en matière de disponibilité de l’information.

On aura probablement des corrélations entre valeurs qui seront découvertes directement par la machine et ses algorithmes, ouvrant la voie à des analyses et des offres insoupçonnées

Mais fondamentalement, les besoins de pilotage et les analyses de performance ne bougeront pas tant que ça.

Les KPI et axes d’analyse modélisés au travers des dimensions correspondent déjà à ce que les entreprises souhaitent mesurer aujourd’hui.

Donc dans un premier temps le besoin sera de pouvoir saisir dans des modèles calculatoires et par là-même simuler une évolution en fonction d’hypothèses et d’inducteurs.

Ceci signifie qu’à court terme les entreprises vont se pencher de façon pragmatique sur ce besoin tout en s’appuyant sur les indicateurs et les dimensions qui fonctionnellement sont déjà définis.

About the Author:

Valéry Feugeas
Valéry Feugeas, Associé Fondateur de Modellis, est passionné par les nouvelles technologies et leurs applications au travail et dans la vie quotidienne. Précédemment Valéry a exercé différents métiers dans le domaine de la Vente, de l'IT et du Contrôle de Gestion.

Leave A Comment