Pourquoi les utilisateurs reviennent à Excel après une mise en production ERP

Six mois après la mise en production, quelqu’un de la finance partage un tableur en réunion. Il contient la vraie marge par client, parce que « le rapport de l’ERP n’est pas juste ». Les ventes ont leur propre liste de prix dans Excel. L’entrepôt tient un inventaire parallèle. Personne n’a décidé d’abandonner le nouveau système. C’est arrivé, contournement après contournement.

C’est l’une des façons les plus courantes dont un projet ERP déçoit sans que personne ne l’appelle un échec. Gartner prévoit que d’ici 2027, plus de 70% des initiatives ERP récemment mises en œuvre ne rempliront pas pleinement les objectifs de leur business case d’origine, et relie ces échecs à l’écart entre ce que les utilisateurs attendaient et ce qui a été livré. [1] Les tableurs qui reviennent sont souvent le premier signe visible de cet écart.

Pourquoi les tableurs reviennent

Le système ne répond pas à la question que les gens posent vraiment

Les utilisateurs reviennent rarement à Excel parce qu’ils l’aiment. Ils y reviennent parce qu’ils ont besoin d’une réponse que le système ne donne pas facilement : une vue de marge, une vue de planification, une liste filtrée comme ils pensent. Si le rapport dont ils ont besoin n’a jamais été construit, ou demande 10 clics, un tableur gagne.

Les données ne sont pas crues

Un prix faux, un chiffre de stock qui ne correspond pas à l’étagère, et la confiance chute vite. Dès que les utilisateurs croient que les données sont fausses, ils gardent leur propre version « pour être sûrs ». Deux versions de la vérité garantissent ensuite que l’ERP a l’air faux plus souvent.

La formation a couvert les écrans, pas le travail

La plupart des formations de mise en production montrent comment créer une commande ou comptabiliser une facture. Elles couvrent rarement les cas inhabituels qui font une grande part du travail réel : la livraison partielle, l’exception de prix, le client aux conditions particulières. Quand ces cas arrivent et que personne ne sait les traiter dans le système, les utilisateurs improvisent en dehors.

Les utilisateurs clés sont retournés à leur quotidien

Pendant le projet, les utilisateurs clés étaient le pont entre le métier et le système. Après la mise en production, ils sont souvent rappelés à plein temps dans les opérations, et les questions n’ont plus d’endroit où aller.

Personne ne possède les processus après le projet

L’équipe projet se dissout. Le partenaire passe à autre chose. De petits problèmes de configuration qui prendraient une heure à corriger restent ouverts pendant des mois, parce que personne n’est responsable de les collecter et de les prioriser.

Les signaux à surveiller

• Des exports vers Excel lancés chaque jour ou chaque semaine, par les mêmes personnes.
• Des rapports présentés en réunion de direction qui ne viennent pas de l’ERP.
• Des utilisateurs qui demandent « où est-ce que je trouve… » pour des choses couvertes en formation.
• Des corrections manuelles en clôture de mois qui se répètent chaque mois.
• Des changements de données maîtres faits par qui en a besoin, sans responsable clair.

Comment regagner les utilisateurs

1. Découvrez à quoi sert chaque tableur. Traitez chaque tableur parallèle comme un besoin. Demandez quelle question il répond, et si l’ERP pourrait y répondre avec un rapport, une vue ou un petit changement de configuration.
2. Corrigez d’abord les problèmes de confiance. Nettoyez les données dont les gens se plaignent le plus, et rendez visible que vous l’avez fait. Commencez par les prix, le stock et les données clients.
3. Formez sur des scénarios, pas sur des écrans. De courtes sessions sur les vraies exceptions que chaque équipe traite. Enregistrez-les pour que les nouveaux collaborateurs puissent s’en servir plus tard.
4. Donnez aux utilisateurs un endroit où poser leurs questions. Un canal de support de premier niveau clair, avec des réponses rapides, empêche les contournements de devenir des habitudes.
5. Nommez un responsable de processus par domaine. Quelqu’un en finance, ventes, achats et opérations qui décide comment le processus fonctionne dans le système et approuve les changements.
6. Collectez et corrigez les petits problèmes en continu. Une liste d’amélioration mensuelle, priorisée avec le métier, fait plus pour l’adoption qu’un grand projet de phase deux un an plus tard.
7. Retirez les tableurs délibérément. Une fois que l’ERP répond à la question, convenez d’une date après laquelle le tableur n’est plus utilisé en réunion.

L’adoption est un travail d’après mise en production

Aucune de ces mesures ne porte sur le logiciel. Elles portent sur les mois qui suivent la mise en production : support, qualité des données, formation et responsabilité. C’est aussi la période que la plupart des budgets et des plans de projet couvrent le moins. Si le projet s’est terminé à la mise en production, personne ne travaille sur l’adoption.

Deux choses aident le plus. Un architecte d’applications métier qui peut regarder les tableurs parallèles, voir ce que le système devrait faire, et le faire corriger. Et un support quotidien stable qui garde les données propres et répond vite aux questions des utilisateurs, pour que le système reste l’endroit le plus simple où faire le travail.

L’essentiel

Les utilisateurs reviennent à Excel quand l’ERP est plus difficile à croire, plus difficile à utiliser ou plus lent à répondre qu’un tableur. Remettez les données en ordre, répondez aux vraies questions, soutenez les utilisateurs après la mise en production et donnez un responsable à chaque processus. Les tableurs perdront alors la discussion d’eux-mêmes.

Sources

1. Gartner, « What IT Leaders Must Do to Avoid Disappointing ERP Initiatives »