Implémentation d’outils de consolidation et de reporting : la documentation au service de la gestion des risques

Quand la direction d’un groupe fait le choix de recourir à un progiciel de consolidation et de reporting, elle s’engage dans un projet lourd et impliquant. L’implémentation d’un tel outil ne se fait pas en quelques jours et sa bonne adaptation aux problématiques de l’entreprise exige l’attention de chacun. La direction financière, la direction des systèmes d’informations voire les futurs utilisateurs au sein des filiales doivent être sensibilisés à la démarche. Le projet, de sa définition à sa conclusion, ne se déroule pas sans risques. Du non-respect des délais annoncés à la négligence des spécifications techniques et fonctionnelles fixées en amont, les dangers sont nombreux et susceptibles d’augmenter l’enveloppe budgétaire allouée à l’implémentation du progiciel. Prêter une attention soutenue à chacun des documents produits permet de juguler ces risques.

Le risque contractuel en amont du projet : définition des besoins et de la réponse

Le lancement d’un projet passe inévitablement par une phase préparatoire. Cette première étape doit conduire à qualifier les besoins et justifier la volonté d’y satisfaire. En d’autres termes, il s’agit de définir précisément ce que sera le projet. Dans cette perspective, l’étude d’opportunité doit valider le besoin exprimé et la demande d’évolution des utilisateurs. Elle conduit à l’élaboration d’une note de cadrage. Quant à l’étude de faisabilité, elle met à jour les points faibles du projet et identifie les résultats attendus. Une fois aboutie, elle devient le dossier de faisabilité. Ce dernier, comme les autres documents, aura valeur contractuelle dès le prestataire sélectionné pour assister la maîtrise d’ouvrage (MOA) dans la réalisation de son projet.

La phase préparatoire aboutit à la rédaction d’un cahier des charges. La formulation précise et réfléchie de celui-ci est une étape essentielle à ne pas négliger. Définir de manière détaillée et contextualisée ses besoins, c’est amorcer le choix du progiciel. Quand la MOA choisira de recourir à un consultant pour l’assister dans l’implémentation de cet outil, le cahier des charges sera le premier support d’échanges avec les candidats à la mission de conseil. Un éventuel appel d’offres reposera sur la diffusion du cahier des charges.

Les offres reçues prendront la forme de lettres de mission. Chaque potentiel consultant formalisera sa réponse aux besoins du client via ce document qui détaille l’objet de la mission de conseil proposée, sa durée, son prix et, surtout, les rôles de chacun. Le prestataire retenu, qui devient la MOE (maitre d’œuvre), doit délimiter les contours de son intervention. Or celle-ci repose sur la communication régulière de données. Sans œufs, pas d’omelette, sans données supports, pas d’outil implémenté… Pour tenir les délais souhaités par la MOA et acceptés par la MOE, chaque partie doit accepter ses obligations et les responsabilités qui en découlent. Les définir précisément dans la lettre de mission permet de limiter les risques de dépassement des délais et couvre, du point de vue juridique, l’ensemble des partie prenantes au projet.

Le risque matériel : la pérennité des données

Le plus grand risque dans la conversion d’un outil à un autre – autrement dit dans le passage d’une solution artisanale à un progiciel – tient à la pérennité des données. Gérer ce risque, c’est prévoir des processus d‘identification, de classification et de quantification des données. Le moindre élément susceptible d’engendrer une difficulté doit être repéré et son traitement anticipé. Plusieurs documents permettent de limiter ces dangers :

• le Plan de management des risques, autrement dit un document préparé par la MOA qui prévoit les risques pour estimer les impacts et créer des plans d’intervention susceptibles d’en enrayer le développement. Ce Plan de management des risques définit les scénarios des pires hypothèses, estime leur probabilité et esquisse les réponses à envisager. Il peut aller jusqu’à affecter un budget à leurs résolutions.
• le Registre des situations dangereuses, soit le journal des risques continuellement mis à jour et qui rend compte de leur gestion complète (identification, évaluation, traitement et suivi). Ce registre permet d’impliquer fortement les parties au projet et de les sensibiliser à l’anticipation d’éventuelles erreurs.

Outre ces documents propres à la gestion du risque dans le projet, les rapports d’installation et, plus globalement, le livre de bord projet, viennent compléter la couverture des risques matériels liés à l’implémentation de l’outil.

Le risque humain : organisation puis acceptation du nouvel outil

La documentation et les livrables constituent un outil essentiel de communication et de dialogue entre les membres de l’équipe projet et les intervenants extérieurs (membre des instances de pilotage, chefs de projet, utilisateurs, etc.). Identifier les devoirs de chacun est une chose, mettre en œuvre les responsabilités liées en est une autre. Implémenter un outil que bon nombre d’interlocuteurs devront ensuite faire leur s’inscrit dans un contexte humain fort. Le projet doit permettre la cohabitation harmonieuse de problématiques issues de différentes directions et susciter une réponse convergente. Rien d’évident à cela. La MOE est là pour favoriser cette rencontre et elle produit des documents à cette fin. Les manuels de paramétrage et de consolidation doivent ainsi recueillir l’adhésion de tous. En rédigeant le premier, la MOE organise le bon usage du progiciel implémenté. La MOA doit pouvoir décider de telle ou telle évolution des mois après l’intervention du consultant et, pour ce faire, se référer à ce manuel de paramétrage. Celui-ci n’est donc en aucun cas un document produit dans l’ombre de la MOE. Il doit être formalisé de manière à être accepté et facilement utilisé par la MOA.

Autre production liée, celle du manuel de consolidation doit être l’occasion de mettre tout le monde d’accord sur les règles de consolidation qui sont appliquées au sein du groupe. Autant dire qu’il ne peut être rédigé sans la concertation de tous. Le risque que la documentation doit ici permettre d’enrayer tient, in fine, à la bonne acceptation du nouvel outil mis en place. Un outil mal expliqué, à l’implémentation laborieuse, risque de ne pas être adopté par les équipes qui devront pourtant l’utiliser quotidiennement. Fixer par écrit et formaliser les règles après les avoir élaborés de concert sont autant d’étapes à ne pas négliger.

Le rôle de la documentation va plus loin. Apprendre à anticiper le risque et formaliser cette anticipation permet de créer une expertise dans la gestion du risque. D’un projet à un autre, d’un outil à implémenter à un autre, les différents acteurs créent une expérience et alimentent une expertise qui leur sera utile pour l’avenir. Enrichir la base de connaissances sur les difficultés rencontrées, organiser leur traçabilité, conserver la mémoire des actions engagées et des résultats obtenus permet le transfert des savoir-faire. La documentation constituée est là pour en attester. Elle permet d’améliorer continuellement la maîtrise du risque, qui devient, progressivement, un projet dans le projet.

Benjamin Mauviot
Associé – Consultant – Expert-comptable