Un projet décisionnel ne se conduit pas à l aveugle. Attention à certains écueils comme un périmètre fonctionnel trop ambitieux, un système d information opérationnel en refonte ou un faible accompagnement des utilisateurs. Recommandations pour boucler au mieux son déploiement.
Les projets de Business Intelligence ont la cote. Pour autant, leur succès n'est pas garanti. Comme tout projet en entreprise, ils débouchent parfois sur des échecs. Les raisons sont multiples : faible évolutivité, mauvaise prise en compte des besoins et des usages, logiciels inadaptés...
Définir des ambitions réalistes
Pour réduire les risques de naufrage d'un projet décisionnel, plusieurs facteurs doivent être pris en compte. Première catégorie de facteurs : les besoins et les usages.
« Un projet BI c'est avant tout une réponse à des besoins utilisateur. C'est avoir la capacité à identifier et formaliser ces besoins. Un facteur de risque qu'on rencontre dans certaines grandes organisations, c'est la tendance à démultiplier le besoin. Dès les premières itérations, le projet BI va adresser toutes les fonctions avec un catalogue de centaines d'indicateurs » déclare Reda Gomery, directeur du pôle BI chez Micropole-Univers.
Conséquences fréquentes de ces errements : longueur des cycles sur les phases d'études préliminaires (jusqu'à plusieurs mois), des fichiers de tableur trop lourds pour recenser tous les indicateurs et, au final, des difficultés à mettre en place le projet en raison de sa faible faisabilité.
Il est donc préférable de s'engager dans une démarche progressive et pragmatique : « Il faut voir grand et commencer petit » résume ainsi Reda Gomery.
Débuter avec un nombre d'utilisateurs maîtrisable
Les solutions décisionnelles nécessitent des cycles de maturation et se déploient, par conséquent, de manière progressive dans l'entreprise. L'ouverture graduelle à un nombre croissant d'utilisateurs est un facteur clé d'adhésion.
Outre la maîtrise du déploiement, il est également indispensable de bien cerner les besoins réels et d'opter pour une couverture des usages adaptée au contexte (par exemple la fréquence de publication des tableaux de bord).
« L'entreprise a conscience que la BI va apporter des réponses, mais elle ignore qu'elles sont précisément ces réponses. Tant que le besoin n'est pas maîtrisé, il est préférable de différer le lancement de son projet » met en garde l'expert de Micropole-Univers.
Autres éléments à tenir compte : l'évolution des métiers et les capacités d'apprentissage des utilisateurs (appropriation de l'outil et des indicateurs). Chaque entreprise, en fonction de son activité, de sa concurrence et d'un certain nombre de facteurs, est soumise à un certain rythme d'évolution de ses besoins métier. Un système décisionnel devra ainsi se caler sur ce cycle pour proposer de nouveaux indicateurs ou tableaux de bord.
Attention aux choix des outils
Le choix des solutions logicielles ne doit pas précéder l'analyse du besoin. Pourtant, les entreprises tombent parfois dans ce travers.
« Ce choix anticipé qui n'est pas basé sur un besoin et qui n'a pas fait l'objet d'un benchmark pourrait déboucher sur un décalage avec les besoins réels. Cela semble du bon sens, mais l'expérience prouve que les organisations commettent parfois cette erreur, par exemple parce que la solution était dans un package ou était utilisée par un concurrent du secteur » explique Fakhreddine Amara, consultant chez Micropole-Univers.
Autre maladresse sur le plan technique : la volonté à tout prix de capitaliser sur des solutions existantes du système d'information. Cette obstination peut présenter un risque, en particulier compte tenu de l'évolution des besoins. L'existant doit donc être également évalué sur la base des besoins futurs.
« Imaginer que la solution en place n'est pas pertinente et compléter le portefeuille en termes d'outils avec une application plus légère, satellite, n'est pas absurde. C'est même aujourd'hui la tendance. Une solution d'entreprise plus un logiciel plus léger adressant des besoins plus ponctuels, jetables, est une architecture qui a du sens » souligne Fakhreddine Amara.
Insérer le décisionnel dans un SI stable
Mettre en place une solution de BI dans un système d'information opérationnel en pleine mutation est un facteur possible d'échec du projet. De même, les DSI ne doivent pas négliger les impacts d'une évolution du SI (un nouvel ERP par exemple) sur un système décisionnel déjà déployé.
« Les entreprises qui s'engagent dans des refontes en oubliant qu'il y a un décisionnel derrière ou en ne tenant pas suffisamment compte de cette problématique sont généralement surprises du coût induit pour réaligner le décisionnel et des problèmes occasionnés, notamment en termes de qualité de données » prévient le consultant.
Autres risques relevés par le cabinet de conseil : la sous-évaluation des charges connexes (reprise de l'historique), la faible connaissance du stock de données (qualité de données : les informations existent-elles dans le système opérationnel ? Et si oui, avec quelle profondeur d'historique ?), et le choix d'une architecture trop contraignante (exemple : un seul datawarehouse pour tous les besoins).
