Projet BI Où sont les utilisateurs ?

Le projet Business Intelligence 4/5

4ème volet Recommandations 2 et 3 pour un projet Business Intelligence suite :

2 Après la réforme du ROI, combattre l’esprit de systématisation me semble un point tout aussi important.
Encore aujourd’hui, de nombreux projets Business Intelligence privilégient la quantité à la qualité. L’objectif étant de profiter de l’accroissement exponentiel de la capacité des systèmes de stockage pour engranger un maximum de données. Cette approche systématique part sûrement d’un bon sentiment, n’en doutons pas, "Plus j’en mets, plus ils ont de chance de trouver leur bonheur” semblent nous dire les concepteurs. Malheureusement elle conduit généralement à un système proposant de bien piètres performances. Toutes les données ne sont pas porteuses de sens. L’énergie utilisée pour ce long et fastidieux travail est définitivement consommée. Elle ne sera plus au service du traitement des besoins précis des utilisateurs.

Remarque : Dans tous les cas il est hautement recommandé d’abandonner l’idée de projet “définitif” lorsque l’on parle de Business Intelligence. Il ne sera pas possible, et ce quels que soient les moyens consentis, de régler la question en une passe unique. Il est préférable de considérer le projet Business Intelligence comme un processus et d’avancer par stades successifs. Chacun des stades correspondant à un projet plus léger et ainsi plus “palpable”, exprimant précisément les besoins d’un groupe d’utilisateurs et s’intégrant étroitement avec l’existant.

3 Dernier point : Centrer la réalisation sur les besoins des utilisateurs tombe sous le sens. C’est d’ailleurs un peu la clé du projet. Mais il ne s’agit pas, comme les vieux de la vieille pourraient le suggérer, de se contenter de procéder à une étude des besoins bien figée avant d’entreprendre le projet proprement dit. C’est dans une dynamique stimulant les aspects participatifs ou coopératifs, comme vous préférez, que se déroulera le projet.

Plus facile à dire qu’à faire ? Je ne vous le fais pas dire. Les modes de gestion de projet participatif joignant utilisateurs et concepteurs/réalisateurs sont en fait les seuls envisageables pour ce type de projet. Mais les modes participatifs sont bien plus difficiles à gérer que les modes traditionnels où les utilisateurs ne découvrent le bébé qu'au moment de la recette. Au titre des difficultés à surmonter, notons qu'utilisateurs et réalisateurs ne partagent pas les mêmes enjeux et contraintes. Les chargés de la réalisation sont tenus par des exigences de budget et de délais. Pas si facile. D'autant plus lorsqu'une obligation de résultats un peu draconnienne ou en tout cas mal ficelée laisse planer le spectre du tribunal. De leur côté, les utilisateurs sont bien souvent reticents à s'engager. Il est bien plus facile de rejeter quelque chose dont on a été tenu à l'écart que de s'engager pour contribuer à la réussite. En fait, c'est bien dès les prémisses du projet que commence l'accompagnement du changement. ( Je reviendrais sur ce thème au terme de cette série.)

En aparté, le schéma classique du système Business Intelligence ici mériterait d’être entièrement repris. En effet, ce schéma reflète beaucoup trop la prédominence de la technique sur les besoins propres du décideur en situation. Il faudrait le redéfinir en plaçant le poste utilisateur comme élément central de la réflexion, au barycentre des préoccupations. J’y penserai. En attendant, je développe ces points à propos de la conduite de projet, ici et dans ce livre.