Un projet ERP échoue rarement pour des raisons techniques. Il échoue parce que les processus n’avaient pas été arbitrés, parce que les données reprises étaient fausses, ou parce que personne n’avait prévu le temps de formation.
Ce que nous prenons en charge
Expression du besoin
Avant de comparer des solutions, il faut savoir ce que l’on veut couvrir. Nous formalisons le périmètre fonctionnel — achats, ventes, stocks, production, comptabilité, paie, maintenance, qualité — et surtout les règles de gestion propres à l’entreprise : celles qui ne se paramètrent pas d’un clic et qui décideront du coût réel du projet.
Aide au choix
Nous construisons la grille de comparaison, organisons les démonstrations sur vos propres cas et non sur ceux de l’éditeur, et instruisons les questions qui coûtent cher plus tard : capacité d’évolution, coût des développements spécifiques, conditions de support, et — point systématiquement négligé — la réversibilité, c’est-à-dire votre capacité à récupérer vos données dans un format exploitable si vous changez de solution.
Nous ne revendons aucune licence et ne percevons aucune commission d’apport d’affaires. C’est la condition pour que la recommandation ait une valeur.
Conception et paramétrage
Traduction des processus retenus en paramétrage : plan analytique, nomenclatures, circuits de validation, droits d’accès, documents et états. Chaque arbitrage est tracé avec sa justification — c’est ce document qui permettra, deux ans plus tard, de comprendre pourquoi le système se comporte comme il le fait.
Reprise des données
C’est la phase qui fait dérailler le plus de projets, parce qu’elle révèle l’état réel des données existantes : doublons de tiers, articles obsolètes jamais désactivés, stocks théoriques sans rapport avec le stock physique, historiques incomplets. Nous traitons la reprise comme un chantier à part entière, avec un périmètre décidé — tout reprendre est rarement le bon choix — et une réconciliation contrôlée avant bascule.
Recette, formation, bascule
Jeux d’essai construits sur des cas réels, recette conduite par les utilisateurs eux-mêmes, formation par métier plutôt que par module, documentation courte accessible depuis le poste de travail, et un dispositif de soutien renforcé sur les premières semaines d’exploitation.
Les cinq erreurs que nous voyons le plus souvent
| Erreur | Conséquence | Ce qui l’évite |
|---|---|---|
| Choisir l’outil avant d’avoir décidé les processus | Le paramétrage arbitre à la place de la direction | Cartographie et arbitrages en amont |
| Reprendre l’intégralité de l’historique | On importe les erreurs du système précédent | Périmètre de reprise décidé et nettoyage préalable |
| Multiplier les développements spécifiques | Coût de possession et blocage aux montées de version | Justifier chaque spécifique, adapter le processus quand c’est possible |
| Sous-dimensionner la formation | Contournements par tableur dès le deuxième mois | Formation par métier et soutien après bascule |
| Ne pas prévoir la réversibilité | Dépendance durable à un éditeur | Conditions d’export négociées avant signature |
ERP et exigences normatives
Aucune norme ISO n’impose de progiciel. Elles imposent en revanche de maîtriser l’information documentée et de pouvoir démontrer ce que l’on affirme. Un système d’information bien conçu produit naturellement ce qu’un auditeur demande : traçabilité, enregistrement des non-conformités, suivi des actions correctives, maîtrise des versions, gestion des habilitations.
Mal conçu, il produit l’effet inverse : des chiffres que personne ne sait justifier et une reconstitution manuelle avant chaque audit. Lorsqu’une démarche de certification et un projet ERP sont menés dans la même période, nous recommandons de les articuler explicitement plutôt que de les laisser se croiser.
Questions fréquentes
Faut-il un ERP quand on est une PME ?
Pas systématiquement. Le déclencheur n’est pas la taille mais la perte de maîtrise : quand le stock théorique ne correspond plus au stock réel, quand la même donnée est ressaisie dans trois outils, quand la clôture demande des semaines. Tant que ces signaux sont absents, une organisation bien tenue autour d’outils simples peut suffire.
Solution en ligne ou installée chez nous ?
Les deux modèles se défendent. Ce qui compte davantage que l’hébergement : la localisation des données et le cadre juridique applicable, les engagements de disponibilité et de sauvegarde, les conditions de sortie du contrat et le format d’export des données. Ces points se négocient avant la signature, jamais après.
Combien de temps dure un projet ?
Cela dépend du périmètre et de la qualité des données de départ, bien plus que du logiciel retenu. Le poste le plus souvent sous-estimé n’est pas le paramétrage : c’est la reprise des données et la disponibilité réelle des utilisateurs clés, qui continuent d’exercer leur métier pendant le projet.
Intervenez-vous après la mise en service ?
Oui. Les premières semaines d’exploitation révèlent des écarts que la recette n’avait pas montrés. Nous prévoyons un dispositif de soutien puis un bilan à quelques mois, qui débouche souvent sur des ajustements de paramétrage et un complément de formation.
Avant d’engager un projet. Un diagnostic court permet de vérifier que le besoin est bien un besoin d’outil — dans une partie des cas, le problème est d’organisation et un ERP ne le résoudrait pas. Nous écrire.