Business Case – Pratiques Courantes et Recommandations

Faire le bon choix

Dans l’entreprise et plus encore dans sa DSI, le Business Case règne en maître pour décider du lancement des projets. Mais de quoi parle-t-on exactement ? Cet article propose de faire un point sur l’usage des Business Cases dans le monde de l’IT, sur la base d’une analyse des retours d’expérience dans 5 grands comptes du monde de la finance, et d’esquisser quelques règles simples d’évolution des pratiques.

Business Cases et prises de décision

Business Case : voilà qui évoque immédiatement une feuille Excel à remplir pour l’obtention du feu vert d’un Comité de décideurs. Il met en jeu des acteurs multiples (Finances, IT, métiers) et aboutit à l’autorisation de lancement d’un projet.

Mais quelles sont les pratiques des grandes entreprises dans ce domaine ?

Estimation des projets

L’objectif du Business Case est essentiellement de challenger les hypothèses des projets et à éviter le lancement de ceux qui sont insuffisamment préparés. De ce point de vue, son utilité est immense.

A la base de la constitution des business cases se trouvent les estimations des gains et dépenses liées au projet. Classiquement, les financiers exigent – notamment pour des raisons de gestion budgétaire – des « certitudes » dans ce domaine. Dans les faits, les hypothèses les plus pessimistes en matière de réalisation de gains sont prudemment retenues. La prise en compte de scénarios permet dans une certaine mesure d’établir des variantes de réalisation, mais ne doit pas être confondue avec les incertitudes d’évaluation d’un projet. Les pratiques analysées incluent la prise en compte d’hypothèses basse, moyenne et haute¹, d’autres une simple moyenne sur 2 hypothèses.

Il convient ici de noter que les ROI négatifs, notamment pour des projets qui ouvriront de nouveaux horizons, peuvent être acceptables : la logique financière intransigeante s’arrête là où l’entrepreneur commence son œuvre. Dans ce cas, le mode dérogatoire – officieux ou officiel – pallie les insuffisances ou l’excès de rigueur des modèles imposés.

¹ Le plus souvent PERT : pondéré  1 fois l’hypothèse basse, 1 fois l’hypothèse haute, 4 fois l’hypothèse moyenne ; additionner le tout, diviser par 4 et vous avez l’estimation à retenir (facile mais adapté ? c’est une autre question). 

L’approche des options réelles

La question des décisions stratégiques portant sur des projets à enjeux importants fait l’objet d’applications multiples, par exemple dans le domaine des travaux publics et de la production pharmaceutique, sous l’appellation « valorisation des options réelles ».

Cette approche conduit à suivre la probabilité de réalisation d’hypothèse lors du déroulement du projet et à exercer ou non la levée d’une option (décision d’engager des investissements, de les arrêter en limitant alors les pertes à la valeur de l’option). La flexibilité induite par ce type de raisonnement est un atout important, tout comme les analyses qui accompagnent sa mise en œuvre (approfondissement des hypothèses de réalisation des gains).

Cependant, la diffusion de l’emploi des options réelles pour les projets IT est inexistante (dans le périmètre analysé ici et probablement dans une majorité d’entreprises).

La gestion des engagements

La traçabilité de l’usage des budgets et des résultats qui en découlent fait l’objet d’exigences grandissantes de la part des dirigeants. D’où la pression mise actuellement sur l’engagement des acteurs à réaliser les résultats liés aux hypothèses dans la durée (typiquement 5 à 7 ans).

Les projets (et les périodes prévues de recueil des bénéfices) durent longtemps, les managers « circulent » vite, ce qui les rend assez « dociles » sur le plan des engagements. Mais cette « docilité » a pour corollaire une attitude de « qui vivra verra », qui n’est pas satisfaisante et rend difficile l’analyse de référentiels de Business Cases dans la durée.

Quelques pistes d’évolution possibles des pratiques :

  • Dissocier la question d’actualisation financière des problématiques relevant exclusivement des projets (ne pas hésiter à utiliser un modèle de ROI simplifié).
  • Éviter de traiter de façon unique les projets sur le plan de la durée du Business Case et des exigences de ROI (les classer selon leur « vocation » stratégique).
  • Clarifier le rôle des acteurs et lier leurs objectifs aux résultats des projets, dans la durée.
  • Pour les projets qui en valent la peine, à fort impact et faible prévisibilité, du fait des marchés considérés ou des technologies mises en œuvre :
    – Se placer dans une logique d’options ;
    – Effectuer un suivi rapproché des hypothèses ;
    – Ne pas de décider avant l’heure ;
    – Se mettre en position d’engager des moyens rapidement.
  • Eviter les situations ou l’estimation est réalisée par un « expert » individuel.
  • Exiger systématiquement des estimations pour des hypothèses haute, moyenne et basse, quand les enjeux sont importants
  • Traiter des risques via le coût des mesures de gestion qu’ils entraînent (et écarter le procédé consistant à utiliser un taux d’actualisation pour « risque »).

Auteur : Jean-Pierre Le Sellin

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *