Les projets décisionnels sont-ils des projets à risques ? Oui, comme tous les projets système d’information : les risques sont liés au projet lui-même, aux outils, à l’organisation, aux compétences et à la maîtrise du changement. Cet article présente, pour ces quatre domaines, les bonnes pratiques qui permettent d’éviter ces écueils.
Le décisionnel fait partie des outils informatiques dont l’intérêt n’est plus à démontrer. Les métiers comme les décideurs ont adopté des pratiques de management basées sur des indicateurs, et les entreprises ont investi massivement pour automatiser la production de rapports et de tableaux de bord. Malgré tout, les projets décisionnels n’ont pas toujours tenu leurs promesses. Certaines entreprises se trouvent ainsi engluées dans des projets sans fin, d’autres produisent des informations et indicateurs en décalage plus ou moins flagrant avec les besoins métiers.
Beaucoup ont mis en place des solutions très lourdes, souvent poussées par les éditeurs, et qui ne peuvent évoluer pour s’adapter aux nouveaux besoins. Toutes ces organisations se retrouvent dans une situation paradoxale : les applications décisionnelles sont sous-utilisées, les utilisateurs insatisfaits, mais les coûts de maintenance et d’exploitation ne cessent de grimper. Conséquence : la Business Intelligence (BI) devient source de tensions et d’incompréhensions et les bénéfices escomptés passent à la trappe. Pour éviter de tomber dans ces pièges, il faut être conscient de la complexité des projets décisionnels et des nombreux paramètres à prendre en compte.
À l’heure actuelle, les enjeux de l’informatique décisionnelle ne sont plus de bâtir des infocentres qui respectent le modèle d’architecture classique (extraction des données, stockage dans des entrepôts de données, création de datamarts, etc.), mais de s’assurer que cette architecture va pouvoir répondre aux nouveaux besoins, comme la BI en temps réel ou l’intégration de nouvelles sources de données à un coût minimum.
La BI traditionnelle, industrialisée, est très structurée. Aux côtés de ces applications, on voit apparaître de plus en plus de demandes occasionnelles pour consommer des indicateurs, comme la réalisation de benchmarks ou d’évaluations par rapport à la concurrence. Dans une optique de reporting quotidien, ces besoins n’ont pas vraiment de sens : il s’agit de démarches plus ponctuelles. Pour Réda Gomery, directeur BI et EPM chez Micropole Univers, « il existe aujourd’hui trois niveaux de BI et de reporting dans les entreprises, des niveaux qui sont amenés à cohabiter et non à se concurrencer : le reporting opérationnel, avec par exemple des indicateurs d’alerte et de non-conformité, le reporting portant sur l’analyse et la prise de décision, et enfin les tableaux de bord (scorecards) destinés au pilotage, à la simulation et aux prévisions ». Cette évolution des besoins et des usages est venue accroître la complexité déjà importante des projets décisionnels. Il est d’autant plus nécessaire aujourd’hui d’identifier les risques associés à ces projets et les bonnes pratiques permettant d’en conserver la maîtrise.
Les contours d’un projet-type
Un projet décisionnel classique se déroule en moyenne sur six mois. Il débute par une étude d’opportunité préliminaire, avec un premier niveau de cahier des charges et une évaluation de la faisabilité et des risques. Viennent ensuite les phases de mise en œuvre classique, avec tout d’abord la conception et l’analyse, puis la modélisation détaillée, la construction de la solution et ensuite les étapes de déploiement. La première phase est en général réduite au minimum du fait de la durée relativement courte des projets. Elle est très peu industrialisée. Il est nécessaire d’y passer plus de temps et de la structurer afin de sécuriser les projets. Néanmoins, cette phase ne doit pas non plus s’étaler sur plusieurs mois : si elle dépasse la durée classique des projets, cela montre que le projet en lui-même a été mal abordé ou mal formulé.
Les stratégies de déploiement dépendent de l’organisation de l’entreprise. Une des questions fréquemment posées à ce stade est celle d’un déploiement centralisé ou en local. Une plate-forme décisionnelle centralisée permet de maîtriser les coûts et les compétences, elle offre une certaine transversalité, mais parfois au détriment des spécificités locales. Inversement, quand le choix est fait d’applications décisionnelles locales, celles-ci sont souvent complétées par d’autres applications décisionnelles au niveau du groupe.
Les facteurs de risque peuvent être répartis en plusieurs catégories : les risques liés à la gestion du projet lui-même, les risques liés aux outils, les risques liés à l’organisation et à la gestion des compétences et enfin les risques liés à la conduite du changement.
A. Les risques sur le projet
Les entreprises ont le choix entre plusieurs modes de mise en œuvre : cycles courts (prototypes puis industrialisation), méthodes agiles ou démarches plus classiques. Dans tous les cas, il faut capitaliser sur les expériences passées et adapter la démarche projet au contexte.
1. La capacité à appréhender les besoins et usages des utilisateurs
Lors des phases d’analyse, il peut y avoir tendance à démultiplier les besoins. Les entreprises risquent alors de se retrouver avec un périmètre fonctionnel trop ambitieux, mêlant par exemple finance et achats. Il faut alors mettre en place des centaines d’indicateurs et de rapports, ce qui est bien trop long. Il est préférable de partir sur une démarche progressive et pragmatique, avec une cible de départ bien délimitée.
2. Le nombre d’utilisateurs
Parfois, dès la première itération, les entreprises souhaitent un déploiement très large. Les solutions décisionnelles nécessitent pourtant des cycles d’adhésion et de maturité, et, là encore, il est préférable de démarrer progressivement, pour ajuster petit à petit la conduite du changement, plutôt que de déployer la solution d’un bloc au risque de susciter un rejet massif chez les utilisateurs.
3. La méconnaissance des besoins
Les outils décisionnels ne permettent pas de structurer le besoin, à l’exception de certaines solutions d’EPM (Enterprise Performance Management) déjà préparamétrées et packagées. Des exigences fonctionnelles peu ou mal définies peuvent donc compromettre un projet. En outre, certaines offres prépackagées ont été développées pour un pays ou une législation spécifique et ne sont pas toujours adaptées aux besoins du marché local.
4. La mauvaise couverture des usages
Des indicateurs et tableaux de bord peuvent être utilisés de différentes façons. Il ne faut donc pas figer les usages, mais autant que possible les rendre dynamiques.
5. La mauvaise appréhension de l’agilité demandée par le métier
Les besoins des métiers évoluent rapidement, la demande d’agilité étant souvent essentielle : dans de tels contextes, une plate-forme décisionnelle qui stagne est alors un indice de décalage avec le cycle d’évolution des métiers.
6. Omettre la phase d’ajustement
Lorsqu’un projet BI est lancé pour la première fois, une phase d’ajustement est souvent nécessaire afin de faire évoluer les règles de gestion, pour différentes raisons : il peut s’agir, par exemple, d’améliorer la qualité des données ou de fournir des informations encore plus pertinentes. Il faut avoir conscience qu’un système décisionnel n’est pas figé et peut évoluer dès ses premières itérations. Ces ajustements peuvent être gérés de manière très variable en fonction du périmètre du projet, par exemple en en faisant un lot à part ou en prolongeant le projet de quelques mois.
7. Négliger la courbe d’apprentissage des utilisateurs
Une certaine maturité par rapport aux outils techniques est nécessaire. Il faut évaluer la capacité des différents profils d’utilisateurs à s’approprier l’outil, et aménager ensuite le temps pour permettre cet apprentissage.
B. Les risques liés aux outils
Après une vague de consolidation importante, qui a consacré les grands éditeurs de plates-formes, le marché du décisionnel voit aujourd’hui se développer d’autres types d’offres, ciblées, flexibles et davantage destinées aux besoins ponctuels et à l’opérationnel.
1. Un choix d’outils prédéterminé
Il arrive fréquemment que des entreprises entament un projet décisionnel en partant sur un outil présélectionné, par exemple quand la solution est fournie dans un package, quand un éditeur ou un intégrateur les pousse, ou encore quand un concurrent s’est équipé de la solution en question. Elles ne prennent alors pas le temps d’effectuer des benchmarks et de comparer différents outils. Le risque est alors de se retrouver avec une solution en décalage avec les besoins de l’entreprise. En outre, acquérir un outil qui s’avère au final mal adapté voire obsolète engendre des coûts.
2. Vouloir utiliser les outils existants à tout prix
La plupart des entreprises possèdent déjà des plates-formes décisionnelles et peuvent être tentées de réutiliser celles-ci à chaque nouveau besoin de BI. Cependant, la capitalisation sur les outils déjà en place n’est pas toujours la stratégie la plus pertinente. En effet, les besoins évoluent, et certaines de ces nouvelles demandes n’entrent pas dans le périmètre des projets traditionnels, avec leurs démarches très lourdes.
3. Un environnement informatique encore peu stabilisé
Il est fortement déconseillé de mettre en place des outils décisionnels quand le système d’information opérationnel est en chantier, car cela a un impact direct sur la qualité des données. De la même façon, une refonte du système opérationnel peut avoir un impact fort sur les systèmes d’information décisionnels existants.
4. Sous-évaluer les charges connexes
Les applications décisionnelles ont besoin d’un certain historique afin de permettre d’effectuer des analyses sur les données. Souvent, la reprise de cet historique a tendance a être sous-estimée. Très tôt dans le projet, il faut savoir si cette reprise est faisable ou pas.
5. Une faible connaissance du stock de données disponible
Il est important de qualifier au préalable la qualité des données disponibles, et cela dès que les besoins sont identifiés. Cette qualification doit non seulement porter sur la qualité technique, mais doit aussi se baser sur les besoins des utilisateurs.
6. Des architectures trop contraignantes
Parfois, il s’avère que les architectures existantes sont trop contraignantes, par exemple quand il n’existe qu’un seul entrepôt de données, quand une démarche très structurée est imposée pour la mise en place des référentiels ou quand l’entreprise a mis en place des règles trop strictes. Il faut alors permettre une certaine flexibilité pour faciliter le projet décisionnel.
C. Les risques liés à l’organisation et aux compétences
Les projets décisionnels touchent souvent un grand nombre d’utilisateurs dans l’entreprise. Il convient donc de faire particulièrement attention au choix des différents intervenants du projet et de mettre en place une organisation équilibrée et solide, capable d’arbitrer efficacement quand c’est nécessaire.
1. De compétences internes lacunaires
Il est nécessaire d’assigner au projet des personnes possédant une connaissance tactique, qui savent où sont les données, comment on y accède ou comment on les modélise. Ces personnes doivent avoir une double compétence, à la fois sur le volet système d’information et sur le volet maîtrise d’ouvrage. Il est par ailleurs essentiel de préserver un équilibre entre les tâches internes et celles qui sont déléguées afin de garder la maîtrise : réduire les ressources en interne est très risqué, et il faut maintenir un certain équilibre par rapport aux intégrateurs.
2. Des compétences externes insuffisantes
Certains prestataires ont des compétences nombreuses et poussées sur toute la gamme d’outils, tandis que, pour d’autres, ce n’est pas le cas. Cela induit alors une dépendance et potentiellement des coûts plus importants pour l’entreprise.
3. Des divergences de points de vue et de politique interne
Les projets décisionnels sont des projets transverses qui imposent parfois un fonctionnement collaboratif. Cela peut accentuer les rivalités qui peuvent exister. Il est important d’intégrer ce paramètre humain, pas toujours clairement mis sur la table. Pour pallier les divergences, le rôle du parrain est très important. Il doit tempérer les demandes trop fortes et savoir utiliser le cas échéant les tiers extérieurs (consultants, sociétés de conseil) pour faire passer des avis « neutres » et éviter les guerres internes.
4. Une démultiplication des intervenants
Un trop grand nombre d’intervenants se traduit par une surmobilisation, avec des réunions à répétition. Tout cela est facteur de coût pour l’entreprise. Il est donc important de doser les efforts.
5. La faible implication d’une partie prenante
Un projet décisionnel ne concerne pas que l’informatique, ou que les utilisateurs. Maîtrise d’ouvrage comme maîtrise d’œuvre doivent être activement impliquées tout au long du projet.
6. Des délais de réalisation non maîtrisés
Dans les projets décisionnels, il n’y a pas toujours vraiment un début et une fin, les demandes pouvant tomber sans cesse. Pour éviter les dérives, il est donc d’autant plus important de se mettre dans un vrai mode projet, en déclarant une date de début et une date de fin. Il faut bien dimensionner le délai de réalisation du projet : en moyenne, il faut six mois. Les projets décisionnels ajoutent une charge supplémentaire à de nombreux acteurs (contrôle de gestion, informatique, etc.) : il faut donc faire particulièrement attention à la date de lancement, notamment pour éviter qu’elle coïncide avec les périodes de clôture pour les projets en finance, et il faut tenir compte des périodes de congés. Le délai retenu ne doit pas être trop court ou trop ambitieux.
Les acteurs d’un projet
Les représentants des utilisateurs/la maîtrise d’ouvrage (MOA) : ils sont chargés de collecter et de qualifier les besoins, mais aussi d’interroger les utilisateurs sur ces besoins et d’en évaluer la faisabilité. La maîtrise d’ouvrage peut être transverse ou spécialisée, comme une MOA sur la finance par exemple. La maîtrise d’œuvre (MOE) : elle est chargée de qualifier techniquement la solution à mettre en place. Elle doit également s’assurer de la cohérence de la solution avec le reste du système d’information et l’architecture mise en place.
Le « sponsor » : un projet décisionnel a besoin d’un vrai parrain, possédant une vision claire du projet et de ses objectifs. Le parrain est celui qui assure l’arbitrage entre les différentes priorités et la conciliation entre les différents points de vue. Le parrain doit être à un niveau assez élevé de l’organisation, sans quoi il aura du mal à jouer son rôle d’arbitre. Les prestataires : ils fournissent les compétences et l’expertise nécessaires au projet. Ils permettent également d’absorber tout ou partie des charges liées à la mise en œuvre.
Les éditeurs de solutions décisionnelles : ce sont eux qui vont fournir les outils sélectionnés. Ils doivent apporter le support nécessaire, tant lors du projet que lors de la phase d’exploitation. Ils doivent également fournir à leurs clients une visibilité sur l’évolution de leur solution.
Démarches projets : les grandes tendances
Les méthodes agiles : ces démarches sont très exigeantes en termes de capacités et de compétences, il faut souvent des profils multicasquettes. Il faut également un minimum d’industrialisation, notamment au niveau des tests. Quelques mois, voire une ou deux années, sont généralement nécessaires pour installer durablement une méthode agile et la maîtriser.
Les centres de compétences : la logique des centres de compétences s’accentue dans les entreprises. Néanmoins, dans certaines organisations, les centres mis en place deviennent des centres purement technologiques et monoproduits. La tendance est, actuellement, de s’orienter davantage vers des centres capables de mener des études, regroupant des compétences diversifiées, tant techniques que métiers.
L’externalisation et l’offshore : ce choix est envisageable quand il s’agit de tâches très industrialisées, par exemple quand il faut générer des milliers de rapports. Néanmoins, il faut garder à l’esprit que les projets décisionnels nécessitent une certaine proximité entre les acteurs.
L’évolution du marché des offres décisionnelles
Les solutions de gestion de la performance d’entreprise (Enterprise Performance Management – EPM) sont des offres très packagées, fortement paramétrables, mais les architectures associées sont fortement dépendantes des outils. Aujourd’hui, les entreprises constatent que ces solutions ne sont pas autosuffisantes et qu’il faut notamment un pivot pour collecter les données en amont. De la même façon, en aval, il est souvent nécessaire de mettre en place une application de reporting supplémentaire.
Outre les grandes plates-formes décisionnelles et des offres packagées, on voit donc apparaître de nouveaux types d’offres sur le marché, ciblant les nouveaux besoins : aux côtés des applications d’élaboration budgétaire et d’EPM, on trouve par exemple des solutions ciblant l’analyse des coûts et de la rentabilité, en s’appuyant sur des méthodologies de type ABC (par exemple : PCM de SAP). D’autres solutions ciblent davantage le pilotage de fonctions et de processus métiers, dans un cadre plus opérationnel (eXcentive, Tagetik, Qlikview…). Enfin, le datamining est de plus en plus appliqué aux entrepôts de données, pour effectuer par exemple des segmentations sur les données ou analyser des corrélations.
Les risques liés à la maîtrise du changement
La conduite du changement est d’autant plus importante quand il y a eu par le passé des expériences négatives avec l’informatique décisionnelle. Il faut en particulier faire attention aux risques suivants :
1. Une faible communication sur les enjeux
L’ensemble des acteurs et des utilisateurs n’ont pas forcément cette vision en tête. Par conséquent, ils peuvent avoir des demandes diverses et variées, pas forcément en phase avec les grands enjeux et les délais prévus pour le projet.
2. Une faible analyse des conséquences pour les utilisateurs
Tous les utilisateurs ne réagissent pas de la même façon face à un outil informatique : même si l’outil doit être le plus intuitif possible, il faut quand même prévoir une formation. Les utilisateurs ont souvent beaucoup de questions sur les indicateurs, pour savoir ce qu’ils vont montrer et comment ils vont être calculés : les outils ne donnent pas ces réponses, il faut donc une structure de relais réactive auprès des utilisateurs, capable de répondre rapidement à leurs questions. En outre, quand les utilisateurs commencent à utiliser la solution, ils deviennent de plus en plus exigeants : il faut prévoir un accompagnement à ce niveau, car sinon les demandes risquent d’alourdir le projet.
3. Un plan de communication mal ajusté
Au moment où l’on essaie de vendre le projet, les solutions décisionnelles sont souvent présentées comme des solutions miracles. Une telle entrée en matière risque de susciter la déception, voire l’incompréhension, par exemple si un décideur demande une information et qu’on lui répond qu’elle n’est pas dans la plate-forme. Il est donc important de bien penser le plan de communication, afin de vulgariser les concepts et de sensibiliser les utilisateurs, sans en faire trop ni trop peu.
4. Une prise en compte insuffisante des habitudes de pilotage
Les utilisateurs ont déjà des habitudes, et parfois le décisionnel peut leur apparaître comme une régression car les applications seront moins agiles ou moins réactives qu’Excel par exemple. Il faut donc regarder comment ils travaillent pour proposer une solution qui ne soit pas trop en écart par rapport à cet existant.