Le business case est un outil précieux pour tout décideur informatique. Instrument clé dans le dialogue avec les métiers, le business case facilite la prise de décision et aide à aligner les investissements informatiques avec les objectifs de l’entreprise.
Le business case, ou étude de cas, permet d’évaluer une proposition de changement. Dans la gestion des systèmes d’information, il est utilisé pour évaluer des projets ou des programmes regroupant un ensemble cohérent de projets. Il est élaboré, la plupart du temps, en amont de ceux-çi, mais il peut aussi s’avérer utile pour analyser un projet en cours.
Son rôle est double : d’une part, le business case sert à estimer la valeur métier de l’investissement envisagé. D’autre part, il aide à justifier cet investissement auprès des décideurs métiers. Il s’agit donc d’un outil très précieux pour tout manager informatique, facilitant la prise de décision en matière d’investissement IT et contribuant au dialogue avec les métiers.
Le business case réduit les risques associés aux projets IT en permettant de vérifier en amont un certain nombre d’éléments : alignement de l’investissement avec la stratégie de l’entreprise, cohérence par rapport à l’architecture existante, valeur pour les métiers ou encore faisabilité du projet. Nous présentons dans cet article dix bonnes pratiques pour faciliter la conception d’un business case.
1. Adapter le business case à la complexité du projet
La construction d’un business case ne suit pas un schéma figé, même si un certain nombre d’éléments doivent nécessairement y figurer, comme l’estimation des coûts, des bénéfices et des risques. Le niveau d’analyse requis dépend du projet envisagé, de sa taille et des enjeux fixés. Plus l’investissement est stratégique et sensible pour l’entreprise, plus il est nécessaire de détailler le business case. Sa finalité est également un paramètre à prendre en compte. Le niveau de complexité de l’étude ne sera pas le même :
- s’il s’agit de comparer différentes opportunités de projets entre elles ;
- s’il faut identifier des sources de valeur dans un projet à caractère obligatoire, comme les projets d’ordre réglementaire ;
- ou encore s’il faut décider de l’abandon ou de la poursuite d’un projet existant.
2. Identifier la raison du changement
La première question à se poser en construisant un business case est la suivante : pour quelle raison opère-t-on un changement ? Il est fondamental d’identifier et de décrire précisément le problème à traiter, l’opportunité à étudier, ou tout autre élément permettant d’identifier le motif du changement.
Ces moteurs du changement peuvent être internes à l’entreprise, par exemple un dysfonctionnement dans un processus clé ou un outil en inadéquation avec les besoins des utilisateurs, nuisant à leur productivité. Ces motifs peuvent également être externes, comme une nouvelle contrainte réglementaire ou l’entrée sur un nouveau marché. Si plusieurs facteurs peuvent coexister, il est important de bien identifier la motivation principale. Aligner trop de raisons dénote un projet mal positionné, qui a toutes les chances de rater sa cible.
3. Examiner les autres options
En dehors de cas très spécifiques, le business case étudié n’est qu’une façon parmi d’autres de répondre à un enjeu identifié par l’entreprise. Dans tous les cas, il existe au moins une autre option : ne rien faire. Poser la question du statu quo apporte un éclairage complémentaire, nécessaire pour qu’il y ait choix. Il s’agit, dans ce cas, de se demander ce qui se passe si l’on décide de laisser la situation telle quelle : comment les choses peuvent-elles évoluer, quels seraient le coût et les conséquences si l’entreprise optait pour l’inaction ?
Bien souvent, il existe plusieurs solutions différentes à la problématique du business case. Il est souhaitable, au moins, d’identifier ces autres options, au mieux, de les évaluer elles aussi à travers des business cases, afin de permettre une comparaison sur les mêmes bases.
4. Définir un langage commun
Une incompréhension entre les différents acteurs d’un projet, en particulier entre la maîtrise d’ouvrage et la maîtrise d’œuvre, est un facteur d’échec connu. Pour éviter cet écueil, il est souhaitable d’établir, dès la conception du business case, un vocabulaire commun, afin de s’assurer que tout le monde parle bien le même langage.
Une définition simple, précise et sans ambiguïté, des concepts clés du projet et un lexique incluant le vocabulaire spécifique du domaine étudié sont très utiles, en particulier dans les projets impliquant plusieurs domaines fonctionnels ou métiers. Ce langage commun est d’autant plus nécessaire quand le business case est utilisé comme outil de dialogue avec les métiers.
5. Bien délimiter le périmètre du projet à analyser
Pour que le business case soit pertinent, il est primordial de délimiter aussi précisément que possible le périmètre de l’investissement envisagé. La valeur du business case sera estimée en tenant compte de ce périmètre : celui-ci doit donc être établi en fonction des bénéfices attendus. Si ceux-ci interviennent au niveau d’un programme regroupant plusieurs projets interdépendants, il faut se placer au niveau du programme.
Ensuite, il importe de définir, avec les demandeurs du projet, quel est l’objectif à atteindre, puis d’établir la liste des actions permettant d’atteindre cet objectif et leurs conséquences. Cette liste d’actions doit être cohérente, structurée et limitée dans le temps.
En outre, un projet informatique ne se limite pas aux actions concernant le système d’information : d’autres types d’actions pouvant être nécessaires pour atteindre les bénéfices attendus. Il s’agit par exemple de la conduite du changement ou d’actions de formation. Celles-ci doivent être incluses dans le périmètre du projet.
Enfin, il est indispensable de prendre en compte non seulement les conséquences positives (bénéfices), mais aussi les éventuelles conséquences négatives du projet pour en estimer correctement la valeur.
6. Estimer les coûts de manière exhaustive
L’une des phases délicates lors de l’analyse d’un business case est l’estimation des coûts. Souvent, cette estimation s’appuie sur l’analyse de projets passés ou, lorsque c’est possible, sur des benchmarks. Même si l’estimation demeure une approximation plus ou moins fine, cette phase est néanmoins incontournable pour évaluer l’investissement étudié.
Il faut prendre en compte le coût de toutes les actions permettant d’atteindre l’objectif souhaité, que celles-ci soient d’ordre informatique ou pas. Tous les coûts doivent être estimés sur la même base (monnaie en valeur constante ou courante, coûts hors taxes déductibles ou pas, etc.). Il est utile de distinguer les coûts liés à l’investissement initial (« le ticket d’entrée ») des coûts récurrents liés à l’exploitation et à la maintenance.
Dans certains cas, le projet permet de supprimer des coûts existants, comme des frais de maintenance d’une application que le projet vise à remplacer. Ces coûts « évités » doivent aussi être identifiés. En revanche, il faudra veiller à ne les comptabiliser qu’une fois, soit dans l’estimation des coûts, soit dans l’estimation des bénéfices.
Les coûts peuvent être difficiles à chiffrer, notamment quand les business cases sont établis très en amont des projets, quand certains paramètres sont encore flous (nombre d’utilisateurs, ressources nécessaires à l’exploitation…). Il faut alors indiquer le degré de précision de l’estimation.
7. Présenter des bénéfices clairs et mesurables
L’identification des bénéfices est une partie essentielle du business case. Des bénéfices décrits et présentés de manière claire sont un facteur clé pour susciter l’adhésion des différents acteurs concernés par le projet. Un projet informatique touche à la fois le métier et l’IT : il est utile de couvrir ces deux aspects dans l’analyse des bénéfices pour obtenir un consensus le plus large possible. Parmi les principaux bénéfices métier figurent :
- les gains de productivité ou d’agilité ;
- l’amélioration de la qualité des produits ;
- la réduction des risques ;
- la conformité réglementaire ;
- la satisfaction des clients.
Du côté informatique, les bénéfices peuvent apparaître à différents niveaux :
- sécurité ;
- facilité d’exploitation ;
- disponibilité et performance des applications ;
- architecture ;
- pérennisation d’un actif informatique ;
- etc.
Identifier les bénéfices ne suffit pas, il faut également définir comment les évaluer et les prioriser. Le business case sera d’autant plus solide qu’il prévoira des indicateurs et métriques permettant de quantifier et de mesurer les bénéfices. Ces indicateurs devront être validés par les différents responsables opérationnels concernés.
Il faut en particulier identifier les bénéfices avec un résultat économique, afin de chiffrer les gains financiers possibles : hausse du chiffre d’affaires, gains en équivalents temps plein (ETP) et autres économies récurrentes (non comptabilisées dans les coûts évités). Des indicateurs d’ordre non financier peuvent fournir une appréciation plus complète de l’ensemble des bénéfices : indices de satisfaction client, taux de disponibilité, etc. Enfin, quand il s’agit de bénéfices intangibles, difficilement mesurables, il est utile de leur attribuer une note afin d’évaluer leur effet pour l’entreprise.
Il est important de noter que les conséquences d’un projet ne sont pas obligatoirement toutes positives, un investissement pouvant avoir un effet négatif dans certains domaines. Les éventuels effets négatifs doivent aussi être pris en compte.Une fois ces éléments établis, il est possible de hiérarchiser les bénéfices pour identifier les plus importants.
8. Évaluer les risques
Tout projet comporte des risques : repérer ceux-ci dès la prise de décision évite certaines déconvenues. L’estimation des risques fait partie intégrante du business case. Les méthodes classiques d’évaluation des risques déterminent généralement le niveau de
risque encouru en se basant sur la probabilité et l’effet potentiel de chaque facteur de risque. Plus un projet est stratégique, plus l’analyse des risques doit être fine. Le risque d’ensemble du projet se compose du risque lié à l’exécution du projet (risque de dérapage du projet) et du risque lié à la réalisation des bénéfices (risque de ne pas atteindre les objectifs attendus).
Le risque d’exécution s’évalue en analysant tous les facteurs de risques liés à l’exécution du projet, depuis la définition des exigences jusqu’à l’implication des acteurs, en passant par l’intégration avec l’existant, le pilotage du projet ou la sécurité.
Le risque lié à la réalisation des bénéfices concerne plus particulièrement les bénéfices d’ordre économique. De manière standard, les risques les plus importants sont associés aux projets visant à accroître le chiffre d’affaires. Les facteurs de risque, dans ce domaine, proviennent de l’environnement économique et réglementaire, des clients, des concurrents, des acteurs internes, des partenaires et des fournisseurs.
9. Démontrer la valeur du projet
De manière classique, la valeur d’un projet est évaluée en comparant le coût du projet à ce qu’il peut rapporter. Différents indicateurs financiers sont utilisés pour estimer cette valeur, notamment la valeur actualisée nette (VAN), la période de recouvrement (payback period) et le fameux retour sur investissement (RSI). La VAN se base sur une estimation actualisée des flux de trésorerie relatifs au projet pour analyser ce que rapporte celui-ci. La période de recouvrement indique le délai à partir duquel l’investissement effectué pour le projet est remboursé par les revenus générés.
Enfin, le RSI, ou ROI (Return On Investment), indique la rentabilité de l’investissement en comparant la valeur générée par le projet avec l’investissement initial. Ces indicateurs partagent tous le même défaut : ils sont limités au domaine financier. Lorsque les bénéfices intangibles occupent une place importante dans un projet, il est primordial de faire apparaître ces bénéfices au même niveau que le RSI. Une autre difficulté consiste à déterminer sur quelle période évaluer le RSI, certains projets ne démontrant une valeur financière que sur le moyen, voire le long terme.
10. Mettre en place un suivi dans le temps
Le business case joue un rôle important lors des étapes précédant le lancement d’un projet. Il est également utile une fois les projets lancés. La mise en place d’un processus de suivi et de validation du business case facilite le dialogue entre les différents intervenants d’un projet. à chaque étape, il est pertinent de refaire valider le business case par les acteurs impliqués, que ce soit pour s’assurer que tout le monde reste en phase avec les objectifs du projet ou pour prendre en compte une évolution de ces finalités en cours de route.
| Business case : les dix meilleures pratiques | ||
| Meilleures pratiques | Pourquoi ? | |
| 1 | Adapter le business case à la complexité du projet | La construction d’un business case ne suit pas un schéma figé. |
| 2 | Identifier la raison du changement | Pour identifier et décrire précisément le problème à traiter. |
| 3 | Examiner les autres options | Le business case étudié n’est qu’une façon parmi d’autres de répondre à un enjeu identifié par l’entreprise. |
| 4 | Définir un langage commun | Une incompréhension entre les différents acteurs d’un projet, en particulier entre la maîtrise d’ouvrage et la maîtrise d’œuvre, est un facteur d’échec connu. |
| 5 | Bien délimiter le périmètre du projet à analyser | La valeur du business case sera estimée en fonction de ce périmètre. |
| 6 | Estimer les coûts de manière exhaustive | Cette phase est incontournable pour estimer la valeur de l’investissement étudié. |
| 7 | Présenter des bénéfices clairs et mesurables | Susciter l’adhésion des différents acteurs concernés par le projet. |
| 8 | Évaluer les risques | Tout projet comporte des risques : identifier ceux-ci dès la prise de décision évite certaines déconvenues. |
| 9 | Démontrer la valeur du projet | Lorsque les bénéfices intangibles occupent une place importante dans un projet, il faut les faire apparaître. |
| 10 | Mettre en place un suivi dans le temps | Faciliter le dialogue entre les différents intervenants d’un projet. |
| Source : Digitalonomics. | ||