Forums, dernières contributions
Mise en place d'un Système Décisionnel et APRES? |
Forums, dernières contributions
Mise en place d'un Système Décisionnel et APRES? Philippe Nieuwbourg
2 jours !? Ce serait un miracle !
Aucun entrepôt de données ou système décisionnel ne peut être opérationnel et pleinement utilisé en 2 jours par l'ensemble des utilisateurs. Tout d'abord ce n'est pas un problème informatique, mais une question de contenu et d'attentes : - qu'attendent les utilisateurs d'un tel système, va-t-il répondre à des questions qu'ils se posent de manière urgente.. - que contient l'entrepôt de données, est-il bien organisé, les utilisateurs ont-ils facilement accès aux données, peuvent-ils avoir confiance dans ces données, leur accès est-il facile ? Voilà quelques unes des questions à se poser pour faciliter l'adoption d'un système décisionnel par les utilisateurs. Joël Da Costa
Bonjour Jos,
Il est très difficile de répondre, à mon avis de manière formelle a votre question. En tout cas une chose est claire, je pense que deux jours de formation pour un utilisateur "lambda" ne sont pas suffisant pour obtenir un "power user" complètement autonome et capable de créer des tableaux de bord complexe. Ceci ne s'acquiert qu'avec de l'expérience et beaucoup de réalisations. Ensuite, et c'est un avis basé sur mes expériences passée, le succès du déploiement d'un système décisionnel en ad-hoc query, ne sera possible qu'en sélectionnant pour un premier lot une petite quantité d'utilisateurs clés, possédant une forte compétence métier, et surtout qui sont réellement motivé par la perspective de devenir autonomes vis-à-vis de leurs données. Il faudra ensuite s'appuyer sur ces utilisateurs clé pour promouvoir l'outil de query ad-hoc auprès des autres utilisateurs une fois que l'utilisateur clé aura réellement pris en main l'outil. Celui-ci servant de relai notamment lors des formations pour les autres utilisateurs. En effet déployer dès le départ sur un grand nombre d'utilisateurs (tous pas forcément motivés par l'idée de réaliser soit même son infocentre) mène a la mort assurée du système et ce pour deux raisons : - Le plus difficile dans un infocentre est de comprendre la demande utilisateur, le plus souvent il ne sait pas lui même ce qu'il souhaite réellement obtenir. Le laisser seul face à un outil ne va pas aider en ce sujet. Le fait de formuler sa demande par écrit (dans le cadre d'un infocentre) aide souvent a clarifier la situation. - La deuxième raison est moins avouable (et elle résulte encore d'expériences passées), l'utilisateur préfèrera toujours faire endosser la faute de résultats ou de chiffres faux à l'informatique, et continuera donc a formuler ses demandes auprès de l'infocentre.... C'est notamment pour ces deux raisons que je continue de dire que la réussite du déploiement d'un système d'ad-hoc query ne sera possible qu'en ciblant très finement le premier lot d'utilisateurs, et la durée de déploiement (je parle de déploiement auprès des users, pas de déploiement technique) n'est pas de deux jours mais bel et bien de plusieurs mois... (mon expérience perso 4 à 8 mois). Cordialement, Joël Da Costa Advanced Schema chanthou
Bonjour Jos,
La question que vous soulevez là est en effet cruciale dans les projets Décisionnel. Je pense donc qu'à ce sujet, il faut prévoire dès le départ la partie TMA (Tierce Maintenance Applicative) du Datawarehouse avec soin. En effet, selon moi 75% de la vie d'un projet Décisionnel se déroule essentiellement en dehors de la première mise en route, c'est pour cela qu'il faut que le système mis en place soit un système très ouvert et adaptable. Pour cela, je conseille souvent à mes clients de réserver une partie des charges de travail à l'aspect purement technique, car cela reste tout de même de l'informatique, afin de régler une bonne fois pour toute les problème du styles "je ne peux pas ajoute ce process car ..." ou "il me faut 50 jours pour ajouter un paramètre ...". Cela semble évident mais beaucoup néglige cet aspect ainsi on est souvent au stade "artisanal" chez certains clients. D'autre part, des réunions régulières avec les Maîtrise d'Ouvrages doivent être plannifier, aussi courtes soit-elles, car la mise à jour d'un entrepot de données exige que tous les acteurs, liés de près ou de loin, soient informer des modifications. Croyez moi, cela permet d'anticiper beaucoup de problèmes. En espérant que cela vous apportera quelques éléments de réponses satisfaisantes. Chanthou Joël Da Costa
Bonjour Jos,
En effet ma précédente réponse n'abordais pas ce sujet. Je rejoit Chanthou sur ce point, un datawarehouse ne survivra que si celui-ci arrive a évoluer avec les systèmes d'informations en amont. En effet, les alimentations marchent toujours très bien le jour de la livraison, mais que va t-il se passer le jour où l'ERP source ou le système transactionnel source va être ammené a evoluer, tant au niveau technique (ajout de tables, modifications des tables etc....) qu'au niveau fonctionnel. Par expérience, la restitution et le datawarehouse sont toujours la cinquième roue du carrosse, les analyses d'impact sur les changements oublient toujours le datawarehouse et on se rends compte des changements "quand ça pète". La bonne démarche est en effet selon moi la mise en place d'un administrateur datawarehouse (ou d'un équipe administration datawarehouse suivant l'envergure du projet) qui va maintenir la partie alimentation. Cependant cet administrateur ne pourra être proactif a la seule condition que celui-ci soit impliqué au départ de chaque projet du système source, et ce pour prévenir dès le départ les changements qui pourraient impacter le datawarehouse. Et il faut en effet pour chaque projet prévoir dans son budget la partie maintenance du datawarehouse, car celui-ci doit être ammené a évoluer au même titre que le système source. Cordialement, Joël Da Costa |