Projets ERP, la formation des utilisateurs décide de l'adoption de Business Central

Dans un projet ERP, la formation arrive presque toujours en fin de planning. À ce moment, le budget est entamé et l'équipe projet n'a plus qu'un objectif: tenir la date de démarrage. C'est pourtant la formation qui décide si le système sera adopté ou subi. Business Central ne se limite pas à de nouveaux écrans. Il impose des processus, une discipline de saisie et une logique de paramétrage que l'utilisateur doit comprendre pour ne pas la contourner.

Un comptable qui ignore pourquoi le "Groupe compta. marché" d'un client détermine ses écritures finira par le renseigner au hasard. Reproduite par quelques dizaines de personnes, cette approximation suffit à priver l'implémentation d'une bonne partie de sa valeur. Parmi les sept principaux risques d'un projet ERP, ce quatrième est sans doute celui qu'on sacrifie le plus facilement.

Manifestations et symptômes sur le terrain

Le scénario se répète d'un projet à l'autre avec une régularité presque mécanique. Dans les premiers jours qui suivent le démarrage, le support reçoit en masse des questions élémentaires: comment retrouver une commande, comment corriger une facture déjà validée, pourquoi tel champ refuse la saisie. Puis l'urgence retombe, et un problème plus discret prend le relais.

Au bout de quelques semaines, les erreurs apparaissent dans les données: fiches article incomplètes, clients créés en double, axes analytiques mal affectés. La première clôture mensuelle sert souvent de révélateur, quand les écarts empêchent de boucler les comptes dans les délais habituels.

Viennent ensuite les contournements. Un tableur réapparaît pour suivre ce que l'on ne sait pas obtenir dans le système, un circuit parallèle s'installe et personne ne le signale. La productivité reste en retrait bien après la période d'adaptation normale, et une phrase revient dans les services: "avant, c'était plus simple". Il serait commode d'y voir de la mauvaise volonté. Une partie des reproches vise un paramétrage réellement perfectible, l'autre traduit une maîtrise incomplète de l'outil. C'est justement ce tri qu'une organisation mal formée ne sait plus faire.

Impact financier, opérationnel et humain

Le coût ne s'arrête pas au démarrage. Sur le plan opérationnel, la dégradation des données se fait sans bruit: champs obligatoires remplis avec la première valeur venue, conventions de codification ignorées, référentiels qui se polluent fiche après fiche. Six mois plus tard, les tableaux de bord affichent des chiffres auxquels plus personne ne croit, et la direction revient à ses extractions manuelles.

La facture financière, elle, arrive plus tard. Il faut prolonger le support, refaire des formations et corriger des données à la main. Il n'est pas rare non plus de retoucher le paramétrage pour compenser une méconnaissance plutôt que pour répondre à un vrai besoin. Ces journées de régie, rarement prévues au contrat initial, pèsent lourd dans le bilan du projet.

Reste le coût humain, le plus durable. Des utilisateurs livrés à eux-mêmes face à un outil mal maîtrisé en gardent une méfiance tenace, envers le système comme envers ceux qui l'ont choisi. Cette défiance réapparaît à chaque mise à jour, à chaque nouvelle fonctionnalité, à chaque projet suivant.

Analyse des causes racines et erreurs de gouvernance

La première cause est budgétaire. Dans le chiffrage, la formation est une ligne parmi d'autres, et souvent la première rognée quand le projet dérape. On la considère comme un coût, rarement comme ce qui conditionne le retour sur investissement.

Le calendrier aggrave la situation. Tout se joue dans une fenêtre étroite, et parfois trop tôt: une formation donnée trois mois avant le démarrage est en grande partie oubliée le jour venu. Une compétence s'acquiert par la répétition, et la répétition ne commence réellement qu'au moment où l'utilisateur traite ses propres dossiers.

Le contenu pose un autre problème. Conçu par l'intégrateur, il décrit l'outil page par page, souvent sur la société de démonstration CRONUS. L'utilisateur apprend où cliquer, sans voir comment ses propres articles, ses clients et ses cas particuliers s'inscrivent dans ce qu'on lui montre.

Enfin, la pédagogie reste uniforme. Une salle, un vidéoprojecteur et un support de cent pages conviennent à certains profils et en laissent d'autres de côté. Un magasinier n'apprend pas comme un contrôleur de gestion.

Plan d'action, mesures préventives et correction

La formation se pilote comme un chantier à part entière, avec un budget, un responsable et des jalons. Elle se déroule en plusieurs temps: une formation initiale placée au plus près du démarrage, des sessions pour les absents, puis un accompagnement pendant les semaines suivantes.

Le levier le plus efficace reste celui des utilisateurs clés. Formés tôt et associés aux recettes, ils connaissent à la fois leur métier et le paramétrage retenu. Ce sont eux qui forment ensuite leurs collègues, avec le vocabulaire et les exemples de leur service. Les recettes elles-mêmes sont d'ailleurs une formation qui ne dit pas son nom, à condition de les mener dans un environnement de test (sandbox) alimenté par une copie des données réelles, et non dans la société de démonstration.

Les formats doivent varier: ateliers sur cas réels, courtes vidéos par processus, fiches réflexes d'une page, coaching individuel pour les postes sensibles. Des profils et des pages adaptés à chaque rôle allègent aussi l'apprentissage, puisque chacun ne voit que ce qui le concerne.

Après le démarrage, le dispositif doit se renforcer au lieu de disparaître. Cela passe par un support étoffé pendant les premières semaines, une permanence ouverte aux questions qu'on n'ose pas poser et un point d'étape après la première clôture. La maîtrise, enfin, se mesure. Quelques contrôles réguliers sur les fiches incomplètes ou les doublons indiquent mieux qu'un questionnaire de satisfaction où porter le prochain effort de formation.

Conclusion

Beaucoup d'entreprises investissent peu dans la formation, parfois pas du tout. Elles ont tort. Après avoir financé des licences, des mois de paramétrage et une reprise de données, elles laissent sans protection la seule condition qui rend tout cela rentable: l'usage réel du système. Chaque lacune de formation laisse aux employés une possibilité de ne pas adopter l'outil, de le contourner ou de l'utiliser à moitié. Au bout de quelques mois, ces choix individuels finissent par constituer le mode de fonctionnement de l'entreprise.

Il serait tentant de confier cette responsabilité à l'intégrateur. Ce n'est pas réaliste. L'intégrateur forme au démarrage, mais il ne peut pas descendre au niveau de détail de chaque poste ni suivre la façon dont les pratiques évoluent service par service. Surtout, il n'a pas la main sur ce qui fragilise le plus la connaissance: le mouvement du personnel. Des collaborateurs partent, d'autres arrivent, et chaque départ emporte une part du savoir-faire acquis pendant le projet. Croire que l'intégrateur conserve cette connaissance pour le compte de son client relève de l'illusion.

La maîtrise de Business Central doit donc devenir un actif interne, au même titre que le système lui-même. Cela suppose des utilisateurs clés reconnus dans leur rôle, des modes opératoires tenus à jour et un parcours d'intégration pour chaque nouvel arrivant. Une entreprise qui ne prend pas ce relais ne perd pas son ERP du jour au lendemain. Elle le perd peu à peu, à chaque départ.