Pourquoi tant d’implémentations ERP reviennent aux tableurs

Le symptôme : les tableurs reviennent sans bruit

Le lancement s’est bien passé. Le système fonctionne, les accès sont créés, la formation a eu lieu. Puis, quelques mois plus tard, un premier fichier réapparaît : un export « juste pour vérifier », un suivi parallèle « en attendant », un tableau de bord refait à la main parce que celui du système « ne donne pas les bons chiffres ».

Rien n’a planté. Personne n’a décidé d’abandonner l’ERP. Mais peu à peu, le vrai travail se refait en dehors du système, et l’investissement ne rapporte plus ce qu’il devait rapporter.

Un ERP n’échoue pas d’un coup. Il est contourné, un fichier à la fois.

Cinq causes qui reviennent

1. Le modèle opérationnel n’a jamais été conçu

Le projet a commencé par la configuration. Personne n’a d’abord défini qui fait quoi, à quelle étape, avec quelles règles d’approbation. Le système reproduit alors l’ambiguïté existante, et chaque équipe comble les trous à sa façon.

2. Le système est configuré par défaut, pas par processus

Les paramètres standards sont pensés pour une entreprise moyenne qui n’existe pas. Quand les écrans ne correspondent pas à la façon réelle de travailler, les utilisateurs reviennent à l’outil qui, lui, épouse leur réalité.

3. Les données migrées n’inspirent pas confiance

Une importation massive sans contrôles de rapprochement laisse des doublons, des soldes faux et des stocks incohérents. Il suffit de quelques erreurs visibles pour que les équipes recommencent à tout vérifier… dans un tableur.

4. La formation est générique

Une démonstration de toutes les fonctions à tout le monde ne prépare personne à son propre travail. Chaque rôle a besoin de savoir faire ses tâches, dans son ordre, avec ses cas particuliers.

5. Personne n’est propriétaire après le lancement

Le projet se termine, l’équipe de projet se disperse, et les petites demandes d’ajustement s’accumulent sans réponse. Faute de gouvernance, le système se fige pendant que l’entreprise continue d’évoluer.

Les signaux d’alerte

Ces signes apparaissent généralement bien avant que le retour aux tableurs soit visible :

• Des exports réguliers vers Excel pour « retravailler » les données.
• Des réunions où chacun arrive avec ses propres chiffres.
• Des saisies faites en double, dans le système et ailleurs.
• Des demandes d’ajustement qui restent sans propriétaire.
• De nouveaux employés formés par leurs collègues à contourner le système.

Comment l’éviter

La réponse n’est pas un meilleur logiciel. C’est l’ordre dans lequel on fait les choses.

1. Concevoir avant de configurer. Cartographier les processus réels, décider des rôles, des étapes et des règles, puis seulement configurer.
2. Valider les données avant le lancement. Migration d’essai, contrôles de rapprochement et validation par les personnes qui connaissent les chiffres.
3. Former par rôle. Des parcours de formation construits autour des tâches de chaque équipe, avec leurs propres exemples.
4. Nommer un propriétaire. Une personne responsable du système, des indicateurs d’adoption et une revue régulière des demandes.
5. Mesurer l’adoption, pas seulement le lancement. Suivre l’usage réel dans les semaines et les mois qui suivent, et corriger tôt.

En résumé

Les implémentations qui durent ne sont pas celles qui ont le plus de fonctionnalités, mais celles où le modèle opérationnel a été pensé d’abord, où les données inspirent confiance et où quelqu’un continue de s’en occuper après le lancement. C’est la démarche que nous suivons, en trois phases : diagnostic, implémentation et adoption, puis amélioration continue. Voir notre méthode d’implémentation Odoo.