L’idée, en créant un datamart, est de donner une réponse précise à une question précise. Une telle vocation implique, pour ce service décisionnel, une grande flexibilité d’usage. Aussi, consolider ces datamarts au travers d’un datawarehouse centralisé comporte le risque de perdre cette agilité. En effet, le but est alors de répondre en priorité à des questions transversales à toute l’entreprise. Ce qui passe par le dessin d’un modèle de données unique pour tous les indicateurs stratégiques. D’où le danger d’une impression de rigidité pour les services départementaux qui disposaient d’un datamart au modèle de données totalement adapté à leurs requêtes. “Si une entreprise pense que la consolidation peut diminuer notablement sa flexibilité, je lui conseille de ne pas le faire”, estime même Lou Agosta, analyste au Giga Group, en visant plus particulièrement les utilisateurs du secteur de la distribution, dont l’organisation est très centralisée. D’autant qu’étant lui-même une couche logicielle supplémentaire, le datawarehouse ne peut qu’ajouter en complexité.“L’agilité réside dans la conception de l’architecture, ajoute Henri Villedieu, de CSC. Si l’on opte pour un système d’information centralisé, il faut veiller à ce que ce système ne soit pas perçu par les utilisateurs finals comme étant trop éloigné de leurs besoins et que, après sa mise en place, ce système soit peu utilisé.”
Consolider par itération motive les utilisateurs
Il est donc préférable, si possible, de procéder à la consolidation des datamarts par itération. Cette méthode évite aux projets d’entrepôts de données d’entrer dans la catégorie des “projets tunnels”, dans laquelle, jadis, on les rangeait spontanément. Elle permet d’apporter des résultats concrets aux utilisateurs, et donc de les garder motivés le temps nécessaire à l’installation du datawarehouse. Autre problématique : en cas de mauvaise définition d’un modèle, il est aussi plus aisé ?” et moins onéreux ?” de changer d’orientation un datamart utilisé par un service départemental qu’un entrepôt de données centralisé. Dans ce cas, en effet, la tâche relève quasiment de la mission impossible. “Si, dans le datawarehouse, cinquante tables concernent le marketing et que l’on veut modifier le modèle de ces données, seules ces cinquante tables seront totalement impactées. Même si elles sont reliées à d’autres données”, estime quant à lui Jacques Milman, architecte des systèmes décisionnels chez IBM France. Ce qui implique également de conserver au moins des partitions métier au sein des grands entrepôts. Il faut également réfléchir à la possibilité de laisser quelques datamarts isolés du système d’information. “Si l’on prend le cas du ” yield management “, un petit entrepôt pour le calcul de prévisions donnant satisfaction doit être conservé. Sa consolidation n’apportera aucun bénéfice”, explique Henri Villedieu.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
