La gestion d'un projet ERP est souvent comparée à la construction d'un navire en pleine mer : il faut maintenir le cap stratégique tout en ajustant les voiles face aux vents changeants des besoins métiers. Dans ce contexte, la maitrise du budget ne peut plus se limiter à une simple surveillance comptable à postériori. Elle doit devenir un outil de navigation prédictif.
Traditionnellement, les projets ERP suivaient une approche linéaire, dite en "cascade". On définissait un budget global, on réalisait une longue phase d'analyse, puis de paramétrage, pour enfin livrer le produit fini. Ce modèle a montré ses limites: les dérives budgétaires n'étaient constatées qu'en fin de parcours, souvent trop tard pour être corrigées. Aujourd'hui, l'agilité s'impose, transformant le suivi budgétaire en une structure tridimensionnelle où se croisent les domaines fonctionnels, les cycles de production et désormais, la temporalité des sprints.
Voici la méthodologie que j’utilise pour structurer, saisir et piloter le budget de mes projets, en s'appuyant sur une architecture de données rigoureuses et des outils de pilotages visuels simples.
I. La fondation stratégique : La segmentation par domaines fonctionnels
Tout commence par une déconstruction analytique du périmètre. Un projet ERP n'est pas une entité monolithique, mais une collection de modules interdépendants. La première étape consiste donc à effectuer une découpe "top-down" basée sur les domaines fonctionnels.
Cette segmentation permet d'attribuer un budget " grosse maille » dès la signature du contrat ou de la commande initiale. En effet, la quantité globale de jours à dispatcher est une donnée contractuelle. Le rôle du chef de projet est de ventiler cette enveloppe globale pour donner une réalité opérationnelle au contrat.
On définit ainsi des codes de domaines :
- A00 – Comptabilité Générale : Le socle financier.
- B00 – Comptabilité Clients (O2C) : Les flux de revenus.
- C00 – Comptabilité Fournisseurs (P2P) : Les flux de dépenses.
- D00 – Comptabilité Bancaire et Trésorerie : La gestion des flux de liquidités.
- E00 – Gestion des Stocks et Logistique : La chaîne opérationnelle.
- Etc …
Chaque domaine se voit attribuer une part du budget total. Cette répartition initiale, utile, sert uniquement à établir une estimation de charge, elle est également cruciale pour responsabiliser les consultants experts sur leur périmètre propre.
Si la Comptabilité Générale dispose de 40 jours, le consultant sait qu'il doit orchestrer ses interventions dans cette limite, sous peine de devoir solliciter un arbitrage budgétaire auprès du comité projet.
II. La Dimension temporelle : L'intégration des sprints
Contrairement à l'ancienne méthode séquentielle, le projet ERP contemporain adopte le rythme des Sprints. Un sprint est une itération courte, généralement de deux à quatre semaines, visant à livrer une portion fonctionnelle de l'ERP prête à être testée.
L'introduction du sprint dans le budget change radicalement la façon dont on envisage la consommation des jours. On n'alloue plus seulement du budget au domaine fonctionnel (ex: à la "Comptabilité Générale") de façon abstraite sur toute la durée du projet, on alloue du budget au Sprint 1 du domaine Comptabilité Générale.
Cette approche permet de morceler le risque. Si un domaine s'avère plus complexe que prévu, la dérive sera identifiée dès la fin du premier sprint, et non six mois plus tard. Le budget devient ainsi dynamique : il est consommé par vagues successives, permettant une réallocation entre les sprints si certaines fonctionnalités s'avèrent plus simples ou plus complexes que prévu initialement. C'est cette notion de sprint qui définit désormais la structure même de la codification budgétaire, car elle impose une vision temporelle de l'en-cours.
Il ne faut cependant pas confondre la budgétisation (en terme de jours de travail) d’un domaine fonctionnel avec le planning du projet, ni même avec le planning des sprints du domaine fonctionnel. Un sprint peut impliquer un nombre variable de ressources qui consommeront un nombre variable de jours de travail.
III. Le cycle de production : De l’analyse au démarrage
À l’intérieur de chaque domaine fonctionnel et pour chaque sprint, la méthodologie impose le respect d’un cycle de production standardisé. Ce cycle est le garant de la qualité technique et fonctionnelle. Selon la complexité, ce cycle peut être court (mise en place avec un paramétrage standard) ou long (mise en place de fonctionnalités spécifiques à développer).
Pour chaque domaine, on décompose le travail en phases codifiées, créant ainsi le troisième niveau de notre structure budgétaire.
Sprint avec cycle de production long:
- 100 – Analyse : Compréhension des besoins et rédaction des processus cibles.
- 200 – Présentation Maquettes : Validation intermédiaire avec les utilisateurs clés.
- 300 – Paramétrage : Configuration des fonctionnalités standards de l'ERP.
- 400 – Développement : Création de fonctionnalités spécifiques ou d'interfaces (les "spécifiques").
- 500 – Tests et Recette : Vérification de la conformité de la solution.
- 600 – Formation : Transfert de compétences aux utilisateurs finaux.
- 700 – Assistance au démarrage : Accompagnement critique lors de la mise en production.
Sprint avec cycle de production court:
- 100 – Analyse : Compréhension des besoins et rédaction des processus cibles.
- 200 – Présentation Maquettes : Validation intermédiaire avec les utilisateurs clés.
- 300 – Paramétrage : Configuration des fonctionnalités standards de l'ERP.
- 500 – Tests et Recette : Vérification de la conformité de la solution.
- 600 – Formation : Transfert de compétences aux utilisateurs finaux.
- 700 – Assistance au démarrage : Accompagnement critique lors de la mise en production.
💡La reprise de données n’est pas une phase d’un sprint pour un domaine fonctionnel, elle est à considérer comme un projet dans le projet. Un budget secondaire avec ses propres domaines fonctionnels, ses propres sprints et ses propres phases sont à définir.
Exemple de phases du sous-projet de reprise de données:
- Analyse des données source
- Maquettage de l’extraction de données
- Reprise de données
- Tests et contrôles
En attribuant un budget en jours à chaque phase de chaque domaine et à chaque sprint, on obtient une précision chirurgicale. On peut ainsi dire : "Le domaine A00 dispose de 3 sprints de 5 jours chacun".
Le fait de numéroter chaque phase par 3 caractères, permet de définir plus de détails aux cycles, si nécessaire. Par exemple, la phase d’analyse pourrait être divisée en:
- 110, Ateliers de recueil des besoins,
- 120, rédaction des documents d’analyse,
- 130, relecture et restitution au client
Ce détail complexifie l’affectation et la réallocation budgétaire, mais aussi la saisie des temps de la part de l’équipe projet.
IV. La codification analytique : Le langage commun du projet
Pour que ce système fonctionne, il faut un identifiant unique capable de lier le budget et les temps passés pour calculer l'encours. C’est le rôle du “Code budget concaténé”.
Le code est formé par l’union du code domaine, du code sprint et du code phase. Par exemple : A00-S1-100.
- A00 : Comptabilité Générale.
- S1 : Sprint numéro 1.
- 100 : Phase d'analyse.
Cette clé unique est le pivot de tout le système. Elle permet d'imputer chaque heure de travail à une cellule budgétaire précise. Plus le projet est complexe, plus les codes peuvent être précis, notamment pour les développements spécifiques où des sous-codes peuvent être créés pour isoler chaque demande de modification logicielle.
V. Méthodologie de saisie du budget : Le référentiel "Écritures Compta. Budget"
Il est important de noter que, malgré l’absence d’un logiciel de gestion de projet spécialisé ou d’un outil de suivi de budget, il est possible de faire son suivi sur Excel.
Excel: “les pros”:
La flexibilité d'Excel permet de bâtir un système sur mesure, souvent plus agile et mieux adapté aux réalités d'un déploiement ERP. Cette infrastructure de substitution repose sur trois piliers documentaires fondamentaux :
- Une feuille dédiée à la saisie initiale du budget qui valorise les codes budgétaires,
- Une feuille de recueil des temps passés pour capturer la réalité du terrain,
- Une feuille de dashboard de suivi de l'encours qui assure la réconciliation automatique et visuelle des données.
Cette architecture transforme un simple tableur en un véritable centre de pilotage décisionnel.
Excel: “les contres”:
Pour les gros projets comportant beaucoup de jours de mise en place, de ressources, de sprints, de domaines fonctionnels, un simple tableur peut vite devenir lourd à manipuler et la perte de données peut être irréparable.
Mon expérience personnelle me permet de dire que des projets de 1000 jours d’implémentation, répartis sur le travail de 10 personnes, découpés en 10 domaines fonctionnels et 3 sprints chacun, sont la limite à ne pas franchir avec un simple fichier Excel.
La phase de saisie initiale du budget est le moment où l'on définit les règles du jeu. Cette opération s'effectue dans une feuille Excel nommée "Écritures Compta. Budget".
Le fonctionnement technique du SOMME.SI.ENS
L'enjeu ici n'est pas de simplement taper des chiffres dans des cases, mais de construire une base de données budgétaire. Chaque allocation de budget est une écriture avec une date, un domaine, un sprint, une phase et une quantité de jours.
Pour consolider ces données dans un tableau de bord, on utilise la puissance de la fonction Excel SOMME.SI.ENS (ou SUMIFS). Cette fonction permet d'additionner les jours constituant le budget en fonction de plusieurs critères simultanés.
- Formule type : =SOMME.SI.ENS(Colonne_Jours; Colonne_Domaine; "A00"; Colonne_Sprint; "S1"; Colonne_Phase; "100").
- Formule type : =SOMME.SI.ENS(Colonne_Jours; Colonne_Domaine; "A00"; Colonne_Sprint; "S1"; Colonne_Phase; "100").
Cette méthode présente un avantage majeur : la traçabilité. Si le budget d'un domaine augmente suite à un avenant, de même qu’une réaffectation d’un morceau de budget à un autre code budget qui serait nécessaire, on ne modifie pas le chiffre existant. On ajoute une nouvelle ligne d'écriture budgétaire avec la date du jour et la quantité de jours (en augmentation ou en diminution).
Le SOMME.SI.ENS cumulera automatiquement l'ancien et le nouveau budget, permettant ainsi de garder un historique complet des décisions financières du projet. On peut ainsi savoir à quelle date un budget a été augmenté ou réduit.
VI. La réalité du terrain : Saisie des temps et imputations
Une fois le budget défini et saisi, le projet entre dans sa phase d'exécution. La fiabilité du suivi repose alors sur la qualité de la saisie des temps par les collaborateurs (consultants, développeurs, chefs de projet). Cette donnée est collectée dans la feuille "Temps réels".
L'imputation sur Code Budget
Le collaborateur n'écrit pas "J'ai travaillé sur la compta". Il sélectionne, idéalement via une liste déroulante, le “Code Budget Concaténé” (ex: B00-S2-200 pour le paramétrage de la compta client au Sprint 2).
L'imputation se fait généralement en heures, qui sont ensuite converties en jours dans le système (ex: 7h = 1 jour). La précision de cette étape est fondamentale. Si un consultant passe 4 heures sur une analyse et 3 heures sur du paramétrage, il doit éclater son temps sur les deux codes correspondants. L’expérience dicte que les ressources les plus expérimentées sont aussi celles qui passent d’un projet à l’autre durant une même journée de travail, il est donc crucial de pouvoir tracer les heures passées sur le projet.
C'est cette rigueur d'imputation qui permet de confronter le "consommé" au "budgété". Sans un code budget strict, le suivi se perd dans des approximations sémantiques qui rendent l'analyse des écarts impossible. Cette feuille de temps réel devient le journal de bord quotidien de la santé du projet.
VII. Le Dashboard visuel : Piloter l'encours par l'image
La phase ultime de la méthodologie est la restitution de l'information. La feuille "En cours par Domaine et Phase" centralise les calculs, mais c'est le Dashboard Visuel qui permet la prise de décision. Le but est de transformer des colonnes de chiffres en indicateurs de performance (KPI) immédiatement compréhensibles.
1. Le thermomètre de consommation par domaine
J’utilise des barres de progression verticales pour illustrer le reste à consommer par la différence visuelle entre la hauteur totale d'un bloc (budget alloué) et sa partie colorée (consommé réel), permettant d'identifier immédiatement les marges restantes. En observant la profondeur de l'axe Z, on repère si le budget d'un domaine s'épuise trop tôt dans l'enchainement des sprints par rapport aux phases encore à accomplir.
Functional domain on phase
2. La matrice "Phase vs Sprint" (Heatmap)
Ce tableau permet de voir où se concentre l'effort. On y affiche le ratio Consommé / Budget par phase. Si on s'aperçoit que la phase "Analyse" (100) est déjà à 95% de consommation au milieu du Sprint 1, le dashboard alerte visuellement sur un risque de dépassement pour les phases suivantes de paramétrage.
Phases on one Functional domain
3. L'Analyse du reste à faire (RAF)
C'est l'indicateur le plus précieux. Le dashboard calcule la différence entre le budget alloué et le consommé réel. Mais il intègre aussi une saisie manuelle du consultant : le "Reste à Faire estimé".
- Si Budget - Consommé > RAF : Le projet est bénéficiaire, nous dégageons de la marge.
- Si Budget - Consommé < RAF : Nous sommes en situation de perte latente.
Visuellement, cela se traduit par un graphique d'atterrissage (Forecast) qui montre la trajectoire probable du budget à la fin du projet. Si la courbe d'atterrissage dépasse le plafond budgétaire, le chef de projet dispose d'une preuve factuelle pour entamer des discussions sur le périmètre ou les ressources.
Pour conclure cet article, j’aimerais préciser que cette méthodologie, bien que robuste, puisque je l’utilise depuis quelques années, n'est pas une finalité en soi. Elle constitue le socle fondamental permettant de mesurer l'encours de manière fiable, mais elle reste largement perfectionnable et évolutive.
Ce modèle peut être affiné pour s'adapter aux profils des intervenants. Par exemple, certaines ressources spécialisées sont contractuellement ou techniquement associées à une seule et unique phase (comme les développeurs purs ou les formateurs). Pour ces profils, on peut imaginer une simplification de la saisie des temps : une interface où le code budget est prérempli, limitant ainsi le risque d'erreur et augmentant l'adhésion des équipes à l'outil de pointage.
Par souci de clarté, je n'ai décrit que la structure de base. Dans une gestion de projet industrielle, le découpage des développements spécifiques gagne à être relié directement aux User Stories (US) et aux Tasks présents dans l'outil de gestion de tickets du projet (comme Azure DevOps ou Jira). L'étape suivante consisterait à créer un pont entre votre fichier Excel et le backlog technique pour assurer une cohérence parfaite entre l'avancement fonctionnel et la consommation budgétaire.
Enfin, un thème majeur n'a été qu'effleuré: la facturation. C'est pourtant le juge de paix de la rentabilité. Confronter l'encours réel (ce qui a été produit) avec la facturation (ce qui a été reconnu par le client) est l'exercice ultime du chef de projet. Cette comparaison permet d'anticiper des situations critiques, comme le "travail non encore facturé" (WIP) trop élevé ou, à l'inverse, des avances sur facturation qui masquent un retard de production.
Je traiterai de ces sujets avancés (intégration DevOps, automatisation de la saisie et réconciliation facturation/encours), dans mes prochains articles.
En bref, dans un monde où les projets ERP sont réputés pour leur complexité et leurs dérives, il est nécessaire de trouver une approche de pilotage fiable. Ce pilotage garantit que chaque heure passée par les consultants est une pierre ajoutée de manière ordonnée à l'édifice, dans le respect de la rentabilité de l'entreprise et de la satisfaction du client final. La maitrise du budget n'est plus alors une contrainte, mais le moteur même du succès du déploiement.
Fichier Excel d'exemple