A quoi sert l’expression de besoin dans le choix d’une solution FP&A

L’approche métier du processus

L’expression de besoin de la part des clients (ou de leur AMOA) est le point de départ du projet. 

En effet, une solution FP&A est en général assez modulable pour être efficace dans tous les secteurs d’activité et pour toute taille d’entreprise. 

Le « besoin » est par exemple la façon dont on calcule la prévision de masse salariale ou de chiffre d’affaires, le logiciel d’où extraire les données du réalisé à charger ou encore la façon dont sont restitués les indicateurs de performance opérationnels.

Il ne s’agit pas d’une description de feuilles Excel (qu’on confond souvent avec les règles de gestion qu’elles contiennent) mais l’approche métier du processus.

Les solutions FP&A

Rappelons tout d’abord aussi ce que sont les solutions FP&A (financial planning and analysis), appelées aussi EPM (enterprise performance management), elles permettent de construire collaborativement des budgets ou des prévisions et d’intégrer le réalisé (financier ou non) des systèmes opérationnels afin de les comparer et de les analyser. 

Techniquement, elles contiennent des fonctionnalités de saisie, de calcul, de chargement de données, de reporting et de gestion de processus.

Dit autrement, ce sont les solutions phares du contrôle de gestion pour le pilotage des performances, dont l’usage se généralise, le plus souvent aux côtés des tableurs utilisés pour des traitements plus locaux, personnels et ponctuels.

La mise en œuvre d’un outil tel que Workday Adaptive Planning, suit une méthodologie précise s’appuyant sur une philosophie agile. 

Cette activité, qu’on l’appelle MOE, intégration ou paramétrage, est le rôle des sociétés de conseil qui répondent au mieux aux besoins de leurs clients compte tenu des possibilités des outils.

L’étude du besoin 

Au cours du projet, le besoin sera bien entendu analysé en détail pendant des ateliers, puis sera souvent ajusté à partir des premiers prototypes pour être pleinement couvert à l’issue du projet. Il n’est pas rare qu’un projet commence avec une expression de besoin représenté par quelques feuilles Excel. 

Nous avons beaucoup d’exemples de projets de ce type qui ont été des succès. 

Dans ce cas, pourquoi rédiger un cahier des charges plus formalisé ? Quels sont les avantages ?

I – Valider le succès du projet

Ce projet consiste à couvrir le besoin, et le rôle de l’intégrateur est d’y parvenir avec la solution technique retenue. 

Si le besoin n’est pas formalisé, comment vérifier que la solution est en adéquation avec celui-ci ? C’est donc une référence de départ incontournable. 

Bien sûr, d’autres aspects seront traités pendant le projet et il est préférable pour chaque partie d’avoir la souplesse nécessaire pour faire évoluer le périmètre initial, mais plus il sera détaillé et plus le point de comparaison sera incontestable.

II – Formaliser et valider en interne un ensemble de paramètres

Il permet de formaliser et valider en interne le vocabulaire, les règles de gestion, les acteurs, les étapes du processus, mais aussi le planning ou les ressources. En effet, il ne faut pas confondre l’outil qui va traiter le processus et le processus en lui-même. La meilleure pratique consiste d’abord à obtenir une validation interne des détails aussi fin que possible, avant de tenter une mise en œuvre technique. 

En général, les projets qui s’étalent en longueur sont ceux dont les processus et les règles de gestion n’avaient pas encore été définis en amont de la mise en œuvre (en tenant compte des possibilités et des limites des outils).

III – Obtenir un engagement commercial ferme des intégrateurs.

Le périmètre du projet étant parfaitement défini, on réduit le risque d’un surcoût lié à une « zone grise » d’incompréhension, un malentendu, un périmètre à étendre car non inclus dans celui d’origine, ou une marge d’incertitude incluse le prix au forfait. 

Quand faut-il formaliser le besoin détaillé ? 

Le faire en amont du projet permet d’en tirer tous les bénéfices ci-dessus. Le faire au cours du projet, par domaine fonctionnel, est aussi une possibilité, même si cela présente deux conséquences 

1 – La perte de l’avantage de l’engagement de l’intégrateur sur le détail 

2- Cela peut présenter un risque en termes de planning si les ateliers internes prennent plus de temps que prévu.

Le dérapage d’un projet est rarement dû à une charge supérieure à ce qui était prévu dans la réalisation pour un besoin donné. Si elle intervient, c’est que ce besoin avait mal été cerné au départ, qu’il évolue constamment ou que les hypothèses s’avèrent fausses. 

En matière de progiciel paramétrable tel qu’un outil FP&A, l’intégrateur se doit de connaître les possibilités de l’outil et de prévoir le temps de réalisation. Mais si le besoin est flou, s’il vient à évoluer fortement, ou s’il devient incompatible avec les possibilités de l’outil, le rééquilibrage peut entraîner des délais et des coûts supplémentaires.