Causes d'échecs du projet Business Intelligence

Réussir son échec en 10 leçons

Le guide officiel pour un projet décisionnel parfaitement raté

La conduite du projet de tableaux de bord est une opération délicate. La moindre erreur peut en compromettre définitivement la réussite. J'ai ici répertorié dix des principales causes d'échec des projets de Business Intelligence. Comme pour un plat de champignons, où un seul malencontreusement ramassé sans précaution, suffit à rendre toxique le repas, point besoin de cumuler les causes d'échec. En règle générale, une seule suffit.

1. L'outil 2. Les utilisateurs 3. Les besoins 4. La Direction 5. La méthode 6. La stratégie 7. Les indicateurs 8. Les données 9. Les informations 10. La resposabilité À Télécharger À lire

Échec projet BI

1. Commencer par choisir l'outil

Lors du lancement d’un nouveau projet, il arrive encore bien trop souvent que l’on choisisse les outils AVANT d’avoir identifier ce que l’on devait faire. Paradoxalement, le choix de la solution précède alors l'étude des besoins !

Pourquoi un tel comportement ?
- Est-ce un travers de certains informaticiens responsables du projet, accordant exclusivement leur attention à l'aspect technique, et peu enclins à comprendre les besoins purement fonctionnels ?
- Est-ce sous la pression des éditeurs ? Les opérations marketing des éditeurs sont justement jugées comme réussies dès lors que le produit promu devient un phénomène de mode. Ce qui d’ailleurs n’enlève rien aux qualités intrinsèques du produit, là n’est pas la question.

Simplement choisir l’outil avant d’identifier précisément le besoin et la démarche pour y répondre est une erreur aussi classique que dramatique.

2. Ne pas solliciter les utilisateurs, de toute façon, ils ne comprennent jamais rien !

L'étude des besoins n'est pas qu'une formalité et ne peut se résumer à un document qui, s'il n'est pas sommaire, est en tout cas vide de sens. Dans bien des cas, cette « étude » traite les questions technologiques sans trop s’attarder sur les aspects purement fonctionnels. En résultat, il ne reflète que fort peu les souhaits des utilisateurs !

Pourtant, ce sont les « utilisateurs » qui par principe connaissent bien « l’usage ». Ce sont eux qui « utiliseront » le produit et jugeront ainsi son « utilité ».

La bonne approche est donc de réaliser des enquêtes précises, non pas pour faire « comme si » on écoutait les utilisateurs tout en pensant à autre chose, mais bien pour « collecter » des informations primordiales sur l’usage et le besoin du point de vue du terrain.

La recherche du progrès ne peut se passer de ces indispensables informations pour définir la pertinence de « l’utilité » à réaliser.

3. Étudier précisément les besoins ? Pourquoi faire ! On a choisi un progiciel configurable !

En effet, avec un outil configurable on peut par définition "tout faire". Au fur et à mesure, on rajoutera les fonctionnalités jugées nécessaires. Voici une excellente recette pour construire une belle usine à gaz !

Bien des utilisateurs des premiers ERP, et des suivants d’ailleurs, ont cru possible de totalement re-développer l’image de l’entreprise dans le progiciel d’ERP, à l’aide d’un outil de script pas vraiment conçu pour cela.

Ce sont des coûts et des coûts, des retards et des retards, pour parvenir à la fameuse usine à gaz et ses comportements erratiques, et donc inexplicables et insolvables. Pour éviter d’arriver à cette extrémité, il vaut mieux rechercher l’optimal entre les plus de l’entreprise et les plus de l’outil, c’est-à-dire consentir à des concessions

4. Ne pas impliquer la direction. On se contentera de lui présenter les factures !

La direction peut être un appui bien utile pour convaincre les potentats locaux, et vaincre ainsi les résistances des projets transversaux. Aussi chaleureuse que soit l’ambiance en apparence, une entreprise est un terrain de lutte de pouvoir. Le chef de projet ne tarde pas trop à en prendre conscience.

Mais encore faut-il que la direction souhaite vous épauler, et donc s’engager ! S'engager, c'est aussi prendre part à la responsabilité du projet.

Être responsable, c'est étymologiquement avoir à répondre des conséquences de ses actes, et notamment de ses échecs ! des conséquences de ses actes, et notamment des échecs !

5. Une méthode ? Voyons, c'est dépassé ! Aujourd'hui seuls l'expérimentation et l'empirisme le plus complet importent !

Ou comment réaliser un projet fort loin, et des spécifications initiales, et des besoins réels des utilisateurs.

Les compétences d’un bon chef de projet sont multiples. L’une de celle-ci concerne la parfaite maîtrise des méthodes de conduite de projet et des outils associés. L’usage d’une méthode parfaitement maîtrisée est absolument indispensable pour assurer un déroulement entre les ridelles du raisonnable.

Une deuxième compétence, celle qui fera de lui justement un bon chef de projet, c’est de ne pas non plus se transformer en rigoriste de l’usage de la méthode. Le bon chef de projet est doté de bon sens, et sait adapter ses outils aux besoins.

6. Pourquoi s'intéresser à la stratégie de l'entreprise ? Tout le monde sait bien ce que performance veut dire !

Lors du lancement du projet, tout le monde est d'accord sur ses enjeux stratégiques. Pourtant, on ne résiste pas à toujours placer complulsivement les mêmes indicateurs, le plus souvent de coûts et de productivité, fort loin de la stratégie choisie.

C’est aussi parce que trouver les bons indicateurs de performance exige un effort et une réflexion de fond pour remonter effectivement aux besoins stratégiques. Il est tellement plus facile de faire comme d’habitude sans se poser de questions.

7. Réfléchir sur le choix des indicateurs ? Ne perdons pas de temps ! J'ai trouvé un bon bouquin avec les listes d'indicateurs types de la profession !

Et en plus, elles ont du succès ces listes ! Mais attention, il n'y a rien de plus personnel qu'un indicateur ! N'oublions pas que l'on ne pilote que ce que l'on mesure. Ces indicateurs au mieux ne servent à rien, et au pire sont contre-productifs.

Suivre un indicateur de performance, qui n’a rien à voir avec les objectifs stratégiques et donc la performance attendue, c’est équivalent à s’efforcer d’avancer en ramant sur le sable.

8. Nettoyer les données, dites-vous ? Mais voyons, Monsieur, notre informatique de production fonctionne correctement et sans erreur !

La gestion qualité des données est l’un des enjeux de survie des systèmes d'information actuels. Il n'y a aucune commune mesure entre la qualité attendue de données utilisées pour la décision et les besoins de production.

C’est d’ailleurs la principale cause de dépassement des budgets de constitution d’un Data Warehouse. Les coûts de nettoyage et de mise en forme des données dépassent systématiquement le budget prévu toujours trop étriqué. Le même problème est aujourd’hui amplifié avec le Big Data.

9. De toute façon, on va placer TOUTES les informations dans un Data Warehouse. Les utilisateurs sauront bien trouver leur bonheur !

On sait bâtir des bases de données qui dépassent largement plusieurs dizaines de péta octets. Considérons simplement un « petit » Data Warehouse qui utilise le tera-octet comme unité de mesure.

Qu’est-ce qu’un tera-octet ?
C’est à peu près 300 millions de pages A4 bien remplies de données. Imaginez-vous, avant de prendre une décision, de devoir chercher l'information essentielle au sein d'une telle pile de feuillets ! Il s’agit en effet de bien conduire le projet data warehouse, de soigner l’étape de modélisation des données, et d’organiser intelligemment la base de données.

Négliger cette phase du projet est une dérive connue de longue date de la structuration des data warehouse. Et ce ne sera pas les outils de modélisation, de recherche de corrélation ou de datamining qui viendront corriger vos erreurs de structure de la base de données.

10. On ne va pas définir précisément les rôles et les responsabilités ! Nous formons une bonne équipe que diable !

Cette définition préalable est souvent bâclée. Et, en cas de problème majeur, on passe alors plus de temps à se rejeter la responsabilité qu'à chercher à le solutionner ensemble.

Savoir qui fait quoi, et donc qui répond de quoi, est une étape fondamentale à tout projet, quel que soit son thème ou son envergure. Si on évite cette phase du projet, en cas de dérive, la chasse au coupable est alors ouverte. Voir notamment les sessions de « blamestorming » évoquées ici.

À télécharger

Réussir son échec en 10 leçons
Ce dossier est en accès libre.
Vous pouvez le télécharger et le distribuer si vous le souhaitez, mais sans le modifier.

Lecture recommandée

Les nouveaux tableaux de bord des managers
Le projet Business Intelligence clés en main
6^ème édition Eyrolles
Ouvrage de référence auprès des managers, consultants, chefs de projets décisionnels, formateurs, enseignants
495 pages
Long Seller francophone du management, 40.000 exemplaires vendus