Decideo - Actualités sur le Big Data, Business Intelligence, Data Science
Recherche avancée

Abonnez-vous gratuitement à Decideo !
Decideo
 


Référentiel de pilotage : utopie ou nécessité accrue ...


Rédigé par Toufic-Pascal NACCACHE le 25 Octobre 2006

Après deux décennies de mise en place de solutions décisionnelles souvent menée par fonction (syndrome du silo), les utilisateurs revoient et auditent leur plate-forme existante avec un objectif de fluidifier l'accès et le partage de l'information. Ils souhaitent rendre l'existant cohérent, efficace et dynamique autour d'un référentiel commun orienté pilotage.



Référentiel de pilotage : utopie ou nécessité accrue ...
Selon une étude récente du Forrester Research, une majorité des grands comptes dispose en moyenne de 5 à 15 applications séparées de reporting et d’analyse. Des soucis de cohérence des données sont souvent rencontrés entre différents entrepôts de données, applications BI et BPM.

Le manque de cohérence au niveau de la gestion des dimensions de pilotage peut être embarrassant pour certains managers présentant en réunion des rapports avec des résultats conflictuels. Ceci est source de perte de temps et d‘énergie humaine à des fins de comparaison et mise en cohérence (exemple de rapprochement des reportings financier et non financiers).

Ne pas lancer une réflexion transverse au niveau de l’entreprise pour une mise en commun des dimensions de pilotage (catégories et nomenclature Clients, Produits, Fournisseurs, Centres de Coûts et Centres des Profits …) ressemble à une mise en place d’une application financière sans une adoption d’un plan de comptes commun.

L’approche traditionnelle demandant aux collaborateurs de la Direction Informatique de régler le problème n’a jamais été efficace car un reporting précis et fiable d’une entreprise nécessite une collaboration continuelle et détaillée entre les fonctions et la DI. La Finance et les fonctions utilisant des rapports spécifiques et personnalisés (comme le Marketing/Vente) ne sont pas organisées et préparées, par manque de ressource, pour mener ce travail de mise en cohérence au niveau de l’entreprise.

Souvent la réponse est « nous avons ceci dans SAP ou dans notre ERP et donc c’est déjà fait …». Les applications ERP disposent bien des niveaux élémentaires des objets de gestion (client, article, fournisseur et autres …) mais ne disposent pas d’un module dédié et avancé pour la gestion et le partage des dimensions de pilotage communes à toutes les fonctions de l’entreprise (Vente, Marketing, Finance, Achat, RH …).

La réponse préconisée à cette problématique est de disposer d’un environnement commun à toutes les fonctions gérant le référentiel de pilotage (objets et dimensions de pilotage). Les différentes applications de reporting et d’analyse utilisées par les différentes fonctions s’appuieront sur cet environnement pour assurer la fiabilité et la cohérence de leurs résultats.

Ceci permet d’éviter et économiser le lancement de projets pharaoniques d’entrepôt commun car la clé de réussite est dans la donnée de référence (le code ADN de l’information de pilotage).


Toufic-Pascal NACCACHE
Associé fondateur du cabinet de conseil IENA Consulting spécialisé dans le pilotage de la performance
contact : tpnaccache@iena-consulting.com
Autres articles




Commentaires

1.Posté par Bruley le 25/10/2006 10:01
Bonjour,

La solution que vous recommandez conduit à faire perdurer les silos qui sont dans la durée plus coûteux qu’un entrepôt de données commun (Cf. rapport des analystes : Gartner, Forrester, …). Or si l’on ne remet pas en cause ces silos, ils vont encore plus se multiplier pour supporter les nouveaux besoins décisionnels comme ceux relatifs à la BI (Real Time BI, Operational BI, Pervasive BI), sans parler de la couverture de nouvelles approches transverses comme celles liées aux problématiques de fraude, de gestion des garanties, etc…

Donc, je souscris à vos propos sur l’importance de la donnée de référence, mais pas à votre vision caricaturale de l’entrepôt de données d’entreprise. Ce qui est pharaonique c’est le coût des silos !

http://www.teradata.com/t/page/41788/index.html

2.Posté par Francois Mazaud le 27/10/2006 14:24
Il me semble que l'approche que vous préconisez s'illustre bien à travers les applications BI mises en oeuvre avec SAP BW. On y trouve un référentiel commun, contre lequel viennent s'adosser les structures de stockage de données et de reporting.

Ce référentie agit sur la mise en cohérence technique (facilitant le partage d'un domaine fonctionel à l'autre), il conduit aussi à la mise en cohérence des règles de gestion (en incitant à clarifier des définitions des indicateurs, des axes organisationnels, à identifier les flux propriétaires de la donnée...).

Je pense comme vous qu'il peut permettre de construire un Reporting d'entreprise à moindre coût qu'une approche "pure" Datawarehouse; parceque, même si les silos doivent être mise en cohérence malgré tout, on ne le fait qu'au coup-par-coup, et avec une meilleure visibilité (car on travaille par écart par rapport aux cohérences déja en évidence). On se concentre donc sur les jonctions indispensables, alors que l'approche "pur Datawarehouse" incite à investir au préalable dans un modèle global cohérent, bien plus couteux.

Concernant l'objection de M.Bruley (les silos se multiplient à long terme), je constate qu'au contraire l'articulation autour du référentiel commun permet de monter rapidement des structures virtuelles entre silos exsitants.

3.Posté par Abdou ELOMARI le 30/10/2006 02:00
Bonjour,
Je comprends que le débat Inmon-Kimball fait toujours couler de l'encre. Il s'agit biensur des auteurs des deux approches les plus communes de mise en place de solutions décisionnelles.
Tout le monde est d'accord que l'approche en silo est catastrophique à long terme, cependant la question comment procéder pour régler ce problème se pose toujours :
Devons-nous créer un entreprise data warehouse (Inmon) ce qui risque de prendre des mois et des mois avant de disposer d'un modèle commune à l'entreprise ou encore passer en revue tous les silos en place pour essayer d'en dégager tous ce qui est commun tant au niveau des faits que les dimensions afin de mettre en place l'architecture en bus ( dimension et fait conformes) de kimball.
Je préconise plutot la deuxième approche parcequ'elle permet d'avoir des résultats plus ou moins rapide, sans être obligé d'avoir un consensus global sur le modèle de l'entreprise (EDW)... Cependant, il faut bien noter que plusieurs divergences peuvent surgir quant il sera question de bien définir tout ce qui est conforme de ce qui ne l'est pas !
Par ailleurs, tout dépend de la nature, la taille, la concurrence et le statut de l'entreprise : Les compagnie privées ne peuvent se permettre d'attendre 1 an avant d'avoir un modèle de données de l'entreprise (EDM), car la concurrence fait rage et les résultats doivent être au rendez-vous. Par contre et même si les entreprises publiques sont tenues à présenter les résultats à des régies de réglementation et d'améliorer le services rendus, elles peuvent encore se permettre de mettre en place un EDM... c'est d'ailleurs un des champs de bataille de Inmon avec son GIF ( Government Information Factory).

Voila !
http://www.dwfacile.com

4.Posté par Patrick De Freine le 06/12/2006 17:42
Un système décisionnel ne se limite pas aux dimensions et même si celles-ci sont un facteur de cohérence essentiel des usages. Dans le monde idéal et un peu dogmatique de Mr Naccache (dont le sens de la formule n'est pas de facto gage de pertinence), un voile pudique semble être jeté sur les autres informations partagées par les utilisateurs de domaines différents et qui participent à la cohérence : croisement de métriques en provenance de plusieurs domaines fonctionnels, règles de gestion pour calculs d'agrégats et autres indicateurs plus ou moins sophistiqués.

De plus, la coordination fonctionnelle d'une architecture distribuée a également un coût, des limites et des incompatibilités et avec en plus la nécessité de prendre en compte le temps réel dans les applications décisionnelles modernes.

Un exemple : quel est le rôle des dimensions dans l'indicateur "solde moyen créditeur", lorsqu'il s'agit de prendre en "compte" comme dénominateur le nombre de jours de la période ou le nombre de jours créditeurs de la période ? Dans l'approche décrite, qui est porteur de la cohérence de la règle de calcul ?

Twitter
Rss
LinkedIn
Facebook
Apple Podcast
App Store
Google Play Store
 
Toute reproduction interdite.
Copyright © Decideo OÜ

Contact
     
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit, des pages publiées sur ce site, faite sans l'autorisation de l'éditeur est illicite et constitue une contrefaçon.