suite :

Si ce que j'ai dit plus haut n'est pas tout à fait exact, SVP donné votre opinion...

Donc ma question, je suis sur un projet ou je dois concevoir un entrepôt de donnée , problème il m'est impossible pour des raisons interne de faire le recueil des besoins aussi bizarre que cela puisse paraître mais il faut faire avec :(. Seul solution qui s'offre donc à moi, modéliser un dwh en 3FN représentative à l'entreprise et qui est évolutive ( on appelle aussi ca une base de donnée idéale d'apres ce que j'ai lu). Ensuite quand le recueil des besoins pourra se faire, création de different datamart.
Est une solution plausible d'après vous?

Merci.

Effectivement le but d'un DW est de répondre à des besoins utilisateurs sans quoi l'intérêt du DW et sont ROI ne seront que très faible. L'approche la plus favorable serait departir d'un périmètre fonctionnel restraint, de proposer aux utilisateurs concernés des indicateurs à valeur ajoutée liés à ce périmètre et d'en décliner un modèle d'analyse pour implémenter un premier Datamart.
L'avantage serait d'éviter de s'embarquer dans une durée projet importante (effet tunel) et d'obtenir tout de même une validation des utilisateurs sans passer par une phase d'expression des besoins.

Bonjour ,

Je pense que vous avez déjà la réponse à votre dernière question dans les retours des différents intervenants. Plus exactement , vu que vous avez pas la main sur les besoins , une approche mitigé me seemble de mise , et la mise en place d'un datamart pour un sujet fonctionnel important/sympa me semble la marche à suivre la plus adéquate par rapport à votre situation. Bien entendu , vous aurez besoin de qqn avec des connaissances métier sur ce domaine , vous pouvez vous rapporter à vos propres connaissances si vous êtes seul.

par ailleurs , en dehors de ces 2 écoles , la réalité sur le terrain est souvent loin de tout ça, donc détachez vous un peu de la théorie et essayez de regarder les choses point de vue utilisateur.

Bon Courage ,

Stefan Caracas
Pôle Décisionnel
MAS

Si ,

Au fait , voici la réalité du terrain (mon exp ) :

Vision itérative : moins d'efforts pour convaincre , résultats visibles rapidement , et propagation du décisionnel par séquence métier. Avantages : côut réduit dans un premier temps , visibilité accrue , effort réduit , rapproché métier / client final donc adhésion des utilisateurs à portée. Désavantages : maîtrise du processus itératif difficile entre les X projets et les N prestataires qui changent tout le temps , le savoir ne se capitalise pas , et la consolidation risque de se faire dans la douleur. Pour ne pas parler des chiffres , chaque département aura les siens , et le temps gagné par le décisionnel se perdra dans des disputes interminables sur qui a le bon chiffre , pourquoi , comment etc.

Vision fédératrice : plein d'efforts pour rassembler le tout dans un ensemble cohérent et non redundant , des sacrifices sur les besoins spécifiques au profit de la transversalité et la cohérence . Avantages : bc moins de 'casse-remplace' , vision stratégique et capitalisante , enfin , on sait ou on va. Mais?. attention , ces projets de longue haleine riquent de louper l'essentiel , càd les besoins utilisateurs qui ont évolué depuis le départ. L'effet tunnel ... pas d'adhésion utilisateurs , ROI d'un projet décisionnel = 0, vous venez de jeter une grosse somme d'argent et plein d'efforts par la fenetre.

Enfin , personnellement , je ne trouve pas les 2 approches satisfaisantes à 100% du réel , c'est toujours du cas par cas , et un mix étudié entre les 2 écoles me semble plus adéquat dans une bonne partie des projets.

Seule conclusion : gardez bien les yeux sur les besoins utilisateur , car sans leur adhésion tout projet décisionnel est voué à l'echec. Poser les bonnes questions dans les ateliers bésoins : que voulez vous aujourd'hui? demain? dans 6 mois? ce serait quoi l'idéal selon vous?. Ensuite , n'oubliez pas que l'itératif aboutit aussi à un DW fédérateur un jour. Mieux vaut prévénir que guérir. Soyez tacticien et stratège à la fois. Donner de son mieux pour chaque projet , mais ne pas oublier , et défendre , le fait que ce sera juste une brique dans un ensemble.

Le problème majeur est que, non seulement aucune des deux approches n'est parfaitement satisfaisante... mais aussi une solution de 'juste milieu' qui prendrait un peu de chaque côté n'est pas réellement jouable à grande échelle.

On sait que la majeure partie des coûts et des risques d'un SID est liée au développement des services de collecte et d'intégration (SCI). Développer une petite collection de data marts indépendants (sans entrepôt de données commun) équivaut à développer autant de chaînes d'acquisition de données qu'il y a de data marts. Cette approche peut parfaitement convenir pour une application ponctuelle, mais elle n'est pas soutenable à grande échelle.

A l'opposé, développer un entrepôt de données commun, conforme à un modèle d'intégration en 3FN en l'absence de demande fonctionnelle équivaut à faire un projet d'infrastructure (on dit aussi un 'socle technique décisionnel' dans certaines entreprises) sans maîtrise d'ouvrage. On est tenté d'y 'pousser' des données pour la seule raison qu'on sait les produire et sans savoir quel sera leur usage. L'inconvénient majeur de ces 'socles', c'est qu'ils n'ont pas de sponsor efficace du côté des métiers, et que l'équipe informatique qui les prend en charge cumule (de fait) les rôles de maîtrise d'oeuvre et de maîtrise d'ouvrage en attendant le client.

L'idéal (qui se réalise quelquefois), c'est d'avoir d'un côté un projet décisionnel 'pionnier', dont le périmètre correspondrait parfaitement à la thématique d'un data mart, et de l'autre une direction informatique qui, pour faire face à ce besoin, impose en douceur un choix d'architecture à deux niveaux, l'alimentation du data mart passant par un SCI conçu pour être partageable et comprenant un entrepôt de données. Cet entrepôt est alors modélisé en 3FN (modèle d'intégration) mais son périmètre est délimité de manière à alimenter le ou les data marts déjà spécifiés, et rien d'autre. Par la suite, d'autres projets (et partant d'autres data marts) viennent se greffer sur le DWH. Tant qu'on respecte la 3FN, c'est-à-dire tant qu'on résiste à la tentation de dénormaliser le data warehouse pour permettre à des requêtes (OLAP ou autres) de l'attaquer en direct sans passer par un data mart, l'extension du périmètre par incréments (sans casser l'existant) est théoriquement possible.

Mais là aussi, cela ne fonctionne qu'avec des directions de projets qui jouent le jeu, dans des structures où la mutualisation inter-projets n'est pas uen simple vue de l'esprit, et moyennant une certaine suite dans les idées en matière de management du DWH. L'un des pré-requis est aussi l'adhésion à un cadre méthodologique garantissant que les concepts de DM et de DWH soient bien perçus comme correspondant à des composants fonctionnels distincts et à des règles de modélisation différentes (et non à des considérations de volume). Dans certains grands comptes, on en a pris conscience car, sous des dénominations diverses, j'ai vu apparaître au sein de certaines DSI des cellules chargées, en quelque sorte, de l'urbanisme des projets de BI.