Au-delà de la question stratégique, cela s’explique aussi par l’importance des budgets engagés. Un projet Business Intelligence n’est pas le énième lot d’une application spécifique utilisée par tel ou tel département, ni la montée de version d’un logiciel lambda. C’est un gros projet qui touche tout le monde ou presque, et un budget lourd pour l’entreprise. Autrement dit : il ne faut pas se rater.
Pourtant, l’ampleur d’un tel projet laisse la place à de nombreuses possibilités d’erreur. Du fait de son étalement dans le temps et de sa large portée à travers l’entreprise, un projet Business Intelligence fourmille d’opportunités d’échec, tant en termes de décisions que de façons de faire, et ceci à n’importe quelle étape.
L’esprit
ironique de ce billet fait écho à mon billet de mars 2012 sur la
thématique du tableau-Excel-trop-ambitieux-et-finalement-inexploitable (“Comment rendre un tableau inutile ?”).
Et tout comme dans ce billet-là, mon point de vue est résolument
opérationnel : il y a aussi des manières de compromettre un projet BI
depuis une Direction SI mais ce n’est pas mon domaine donc je n’en
parlerai pas ici !
Petit tour d’horizon des ingrédients d’un échec...
1. Rater l’implication des experts métier
Associer des experts métier (non-informaticiens) à un projet Business Intelligence est une grande idée. Leur place dans la maîtrise d’ouvrage est tout à fait légitime. Et comme ces gens ont une connaissance étroite des réalités de l’entreprise, leur intervention est une garantie de pertinence pour le projet.
Et en prime, faire appel à eux crée un ressort pour l’adoption du futur outil par la population entière de l’entreprise, dans la mesure où ces personnes ont en général un statut de prescripteurs.
Cela dit, il y a trois excellentes manières de se fourvoyer dans la manière de faire appel à ces experts métier.
D’abord, ne pas les associer dès le début du projet Business Intelligence. Par exemple, il suffit de les ignorer dans la phase de réflexion de pré-projet, de ne pas les inviter aux présentations de fournisseurs potentiels ou, bien sûr, de ne pas les associer à la décision d'achat logiciel.
Ensuite, en plus de ne les impliquer dans le projet qu’à partir de sa mise en œuvre, une bonne idée est de les cantonner à un job de paramétrage. Et surtout ne pas faire appel aux ressources les plus riches qu’ils pourraient mettre au bénéfice du projet : leur expertise métier, précisément.
Enfin, pour peu que le logiciel retenu soit un “outil d'informaticien” (et c’est souvent le cas des logiciels de Business Intelligence pour les grandes entreprises), faire perdre du temps aux experts métier en les poussant à apprendre à se servir du logiciel, dans un joyeux mélange entre maîtrise d’ouvrage et maîtrise d’oeuvre. Cette manipulation par des non-informaticiens a de grandes chances de ne pas donner grand chose : au mieux elle aura un résultat vaguement probant mais leur aura demandé dix fois plus de temps qu’elle n’en aurait demandé à des informaticiens. Sans parler de risques de (dé)motivation. Bref, ce sera un beau gâchis de ressources.
2. Choisir le mauvais outil
Un grand classique des erreurs de choix logiciel en entreprise : ne pas sélectionner le logiciel que le besoin recommanderait mais en choisir un autre pour des raisons de coût ou, pire, pour des motivations personnelles liées à tel ou tel décideur. Pour peu que ces raisons aillent à l’encontre des besoins de l’entreprise, on a là un superbe gage d’échec : l’inadéquation du logiciel.
Un exemple d’inadéquation parmi d’autres : les questions de temps de réponse. Elles ne se posent pas dans telle entreprise, mais peuvent être très problématiques dans telle autre. Si ces questions posent problème, cela peut être décelé très tôt dans le cours du projet ; suffisamment tôt pour faire machine arrière. Mais on peut délibérément ignorer ce point-là :, c’est un bon moyen d’aller dans le mur.
Autre exemple. En terme d'ergonomie, certains logiciels sont loin d'être à la pointe des tendances de l'informatique décisionnelle, et encore plus loin des attentes légitimes de l'utilisateur final. Celui-ci est habitué depuis le début des années 2000 à ce que l'accès à l'information soit intuitif, et l’essor des interfaces tactiles au tournant des années 2010 va encore plus loin dans ce sens. Choisir un logiciel qui aurait une génération de retard sur ces questions est un excellent moyen de saper la future adoption de l’outil par l’utilisateur moyen.
3. Survaloriser ce que fera l’outil de Business Intelligence
Business “Intelligence”. Cette appellation aujourd’hui consacrée, conjuguée à l’ampleur dont on parlait plus haut et aux sommes en jeu, donne facilement lieu à l’erreur de compréhension suivante : l'illusion d'acheter de l'intelligence.
Il suffit aux promoteurs du projet de ne pas avoir de discours rappelant explicitement que l’intelligence est d’abord dans le cerveau des personnes. Ils laisseront alors s’insinuer cette fallacieuse idée : « avant, la stupidité gangrenait l’entreprise, mais désormais un logiciel venu d’ailleurs apportera une bienfaisante intelligence. » La qualité de l’accueil réservé à l’outil devrait en pâtir.
Autre erreur, corollaire de la précédente : l'illusion que l’outil permettra d'automatiser totalement les travaux de traitement statistique. À la manière de ce que la robotique a permis dans l'industrie, on peut glisser implicitement dans un projet Business Intelligence l’ambition de délégitimer certains métiers du traitement de données, voire de se passer des gens qui les exercent. Dans la mesure où le besoin d’information chiffrée - tant en analyse qu’en synthèse - est protéiforme et changeant, cette ambition est illusoire. Y croire est un bon moyen de mettre en péril la pertinence d’un outil de Business Intelligence.
4. Penser l’avenir avec les principes du passé
À l'heure du dynamisme et de l'interactivité des flux d'information, certains logiciels proposent une vision figée de l'information. Piloter une entreprise semblerait consister simplement à consulter des rapports l’un après l’autre, sujet après sujet, jour après jour. L’outil de Business Intelligence proposera alors des flux de données à sens unique, des rapports statiques et des vérités gravées dans le marbre.
Travailler avec un tel outil est un très bon moyen de scléroser son système d’information décisionnelle. Et de croire que, à force d’essayer d’améliorer la bougie, on finira bien par arriver à l’électricité.
5. Démultiplier le nombre d'intermédiaires
Un grand classique des projets en général et des projets SI en particulier : solliciter un grand nombre d'intervenants sur des sujets qui ne le méritent pas forcément.
Requérir de multiples niveaux de validation sur le moindre point de détail, réunir de nombreuses personnes pour parler d’éléments déjà validés, etc. Outre le coût pour l'entreprise de l’ampleur de ces mobilisations, cela permet aussi de brouiller les cartes et de ralentir l'avancée du projet.
La question est particulièrement cruciale en Business Intelligence puisqu’on parle de projets, comme on l’a mentionné plus haut, qui impliquent un grand nombre de directions, départements, services, voire l’entreprise entière. On a donc là un ressort très puissant pour perdre beaucoup de temps et beaucoup d’énergie.
6. Ne pas désigner de réel leader
Corollaire du point précédent : si le niveau hiérarchique partagé par toutes les parties prenantes est la Direction Générale, il suffit que celle-ci s’appuie sur l’idée qu’elle a aussi plein d’autres choses à faire (ce qui est toujours le cas) pour ne pas soutenir suffisamment le projet. L’idée est de s’affranchir d’un réel appui en haut lieu - DG en personne ou chef de projet ayant une réelle autorité.
On peut trouver ici une belle garantie d’échec : c’est la porte ouverte aux jeux de pouvoir et aux tentatives d’influence entre les directions des parties prenantes. Au mieux, le projet donnera naissance à un outil malformé, peu pertinent, éventuellement pertinent pour quelques uns mais finalement peu utile pour le plus grand nombre. Au pire il prendra beaucoup de retard voire sera abandonné un jour ou l’autre.
7. Surjouer la carte des anglicismes
Nombre de logiciels disponibles sur le marché de la Business Intelligence regorgent de dénominations anglaises. Un quelconque requêteur va porter un nom du genre Power Advanced Query Designer, un outil de travail sur hypercube va s’appeler X-dimension Analysis Handler, et le module d’affichage de résultat s’appellera Report Viewer. Bon, cela ne renvoie jamais qu’à des outils à la main des techniciens.
Mais la frontière avec l’espace de l’utilisateur final est très fine : une fois qu’on aura construit les reports, on appellera les tableaux de bords des dashboards, les graphiques seront des charts, etc.
Le propos n’est pas ici d’arbitrer entre tendances anglophiles et anglophobes, mais simplement de retenir cette option : truffer un outil de termes issus d’une langue qui n’est pas la langue courante de l’utilisateur final est un excellent moyen de nuire à son appropriation !
8. Ne pas nommer le nouvel outil
Évoquons un instant la différence qu’il y a entre ces deux éléments :
- le logiciel est le produit vendu par l’éditeur ;
- l’application est le résultat de l’intégration du logiciel dans le Système d’Information de l’entreprise. Cette intégration peut être légère (bureautique ou softwares simples) ou complexe (pour un ERP par exemple).
Lors de l’intégration d’un outil complexe, un usage répandu consiste à choisir pour l’application un nom différent de celui du logiciel sous-jacent.
D’où cette idée simple : ne pas le faire !
Cela permet de freiner l'identification de l'outil par ses utilisateurs, d’autant que la Business Intelligence, par définition, ne touche pas au coeur de métier et se prête donc moins facilement à une appropriation spontanée par le plus grand nombre.
À défaut de dénomination maison, c’est probablement le nom du logiciel qui s’imposera. Pour peu que celui-ci ait une certaine notoriété publique - ne serait-ce que dans la population qui travaille en entreprise -, l’absence de nom dédié permettra aussi que l’application Business Intelligence soit perçue comme “un outil de plus” et, qui plus est, “la même que dans plein d’entreprises”.
Le must : laisser s’imposer un nom (celui du logiciel ou un autre) qui ressemble au nom d’une autre application existant déjà dans l’entreprise. Le risque de confusion est immense...
Aucun commentaire:
Enregistrer un commentaire