Une PME ne rate pas souvent un déploiement ERP par manque de logiciel. Elle le rate parce qu’elle essaie de mettre de l’ordre avant d’avoir décidé ce que veut dire “ordre”.
Si le processus n’est pas clair, le système ne fera qu’aller plus vite.
La thèse est simple : avant de configurer Odoo, il faut clarifier les processus, les responsables, les données et les exceptions. Sinon, l’entreprise risque de numériser des désaccords encore ouverts au lieu de les résoudre. Cela complique le démarrage, mais cela rend aussi la base fragile quand l’équipe grandit ou quand les personnes changent.
La scène réelle : quand chaque service pense avoir raison
Imaginez une PME de 25 personnes qui vend par téléphone, prépare les commandes depuis l’entrepôt et achète auprès de plusieurs fournisseurs. Le directeur voit des retards. Les ventes disent que l’entrepôt confirme trop tard. L’entrepôt dit que les ventes promettent sans vérifier le stock. Les achats disent que les demandes changent à la dernière minute. Et la comptabilité, au milieu, essaie de rapprocher des factures avec des bons de livraison incomplets.
C’est souvent à ce moment-là que l’on regarde Odoo comme un interrupteur. Mais Odoo ne décide pas à la place de l’entreprise. Il oblige simplement à formaliser des décisions qui devraient déjà exister : qui crée la commande, qui la valide, quand le stock est réservé, que se passe-t-il s’il manque une référence et quelle donnée fait foi quand deux écrans racontent deux choses différentes.
La documentation officielle d’Odoo précise que les applications et les modules ont des dépendances, que l’ajout ou la suppression d’apps peut affecter d’autres applications, et qu’il faut tester les changements dans une base dupliquée avant de les appliquer. Elle rappelle aussi que l’administrateur de la base doit comprendre le fonctionnement de l’entreprise. En pratique, cela veut dire qu’implanter n’est pas “installer un outil” ; c’est redessiner une manière de travailler. (odoo.com)
Les décisions à fermer avant d’ouvrir la configuration
Quatre questions méritent d’être tranchées avant de toucher un module.
1. Qui décide de quoi. Un organigramme ne suffit pas. Il faut définir qui valide les remises, qui autorise les achats urgents, qui corrige un bon de livraison et qui peut modifier une fiche produit. Si ce n’est pas écrit, le système ne fait qu’amplifier l’ambiguïté.
2. Quelles données font référence. Dans beaucoup d’entreprises, un même client apparaît sous des noms proches, la même référence produit change selon le canal et les unités sont comprises différemment entre ventes et entrepôt. Avant d’implanter, il faut décider quel champ prévaut : référence interne, code fournisseur, unité de vente ou conditionnement. Le but n’est pas la pureté ; c’est d’éviter trois vérités pour la même opération.
3. Quelles exceptions existent vraiment. Toute entreprise dit avoir des “cas particuliers”. La plupart sont surtout des processus mal définis. Mais certaines exceptions sont réelles : commandes urgentes, livraisons partielles, clients avec tarifs propres, retours à contrôle technique ou achats soumis à validation. Si elles ne sont pas séparées du flux standard, elles contaminent tout le process.
4. Quelle mesure prouve l’amélioration. Implanter sans métrique, c’est décorer. Avant de commencer, mieux vaut choisir trois signaux simples : le temps entre commande et confirmation, le pourcentage de commandes corrigées manuellement et le nombre d’incidents interservices par semaine. Si l’on ne peut pas mesurer, personne ne pourra démontrer si le changement fonctionne.
L’erreur inconfortable : personnaliser trop tôt
C’est là que surgit la décision inconfortable. Beaucoup d’implémentations s’accélèrent en demandant des personnalisations trop tôt. Le raisonnement paraît pratique : “si le système ne colle pas, on l’adapte”. Mais souvent, le problème n’est pas le système ; c’est que l’entreprise n’a pas encore décrit son vrai processus.
Odoo permet de personnaliser des champs, des vues, des automatismes, des rapports et des règles d’approbation via Studio, et sa documentation explique que cela a aussi des implications sur le plan et le modèle de données. La tentation est d’utiliser cette flexibilité pour masquer des trous d’organisation. Pourtant, plus on personnalise tôt sans critères, plus il devient difficile de distinguer ce qui relevait du désordre technique et ce qui relevait du désordre humain. (odoo.com)
Une bonne règle est la suivante : standardiser d’abord ce qui devrait déjà être identique pour tous ; adapter ensuite seulement ce qui différencie réellement l’entreprise. Sinon, l’ERP devient le miroir des anciennes habitudes, pas une amélioration.
Mini-cas : moins d’écrans, plus de conversations utiles
Une PME avec entrepôt et ventes téléphoniques est arrivée à l’implantation avec un problème classique : chaque service avait son fichier Excel favori. Les ventes voulaient promettre vite, les achats voulaient se protéger, l’entrepôt voulait éviter les urgences et la comptabilité voulait facturer sans courir après les papiers.
L’équipe n’a pas commencé par configurer des modules. Elle a commencé par dresser trois listes : décisions, exceptions et données critiques. Elle a découvert que le vrai goulot d’étranglement n’était pas la commande elle-même, mais la validation du stock réservé et l’approbation des urgences. Elle a aussi vu que deux types de clients avaient besoin de règles différentes, mais que 80 % du business pouvait suivre un flux standard.
Le changement le plus utile n’a pas été “plus d’automatisation”. Il a été d’arrêter de discuter chaque cas comme s’il était inédit. À partir de là, l’implantation a mesuré moins de corrections manuelles, moins d’appels internes et plus de commandes confirmées du premier coup.
Ce qu’une entreprise ferait cette semaine pour bien lancer le projet
D’abord, tracer le parcours réel d’une commande, de son arrivée jusqu’à son paiement, avec le nom des personnes qui touchent chaque étape.
Ensuite, lister dix exceptions fréquentes et distinguer celles qui sont légitimes de celles qui sont seulement les symptômes d’un désordre.
Enfin, choisir trois indicateurs de départ et un responsable par indicateur. Non pour surveiller les gens, mais pour savoir si l’implantation remet de l’ordre dans l’exploitation ou si elle déplace simplement le problème ailleurs.
La question inconfortable est la suivante : si vous implantiez Odoo demain, quelle décision resterait sans propriétaire ? Chez Codefuente, c’est souvent par là que l’on commence, parce qu’un logiciel ne fonctionne vraiment que lorsque l’entreprise sait déjà comment elle veut opérer.