Simplifiez et optimisez la logistique de votre entreprise.
Un ERP, pour Enterprise Resource Planning, est un progiciel de gestion intégré. Il rassemble dans un même environnement plusieurs fonctions de l’entreprise : ventes, achats, stocks, comptabilité, production, projets, ressources humaines ou service après-vente. Les données sont généralement partagées entre les modules, ce qui limite les ressaisies et facilite le suivi des opérations.
Pour une PME, le choix ne consiste pas seulement à comparer des écrans ou des tarifs par utilisateur. Il engage les processus de travail, la qualité des données, les habitudes des équipes et parfois les relations avec les clients ou les fournisseurs. Un outil mal adapté peut ajouter des tâches, multiplier les contournements et rendre les informations moins fiables qu’auparavant.
La bonne démarche commence donc par les besoins opérationnels. Il faut déterminer ce que l’ERP doit améliorer, ce qui relève d’une exigence réglementaire, ce qui peut être traité plus tard et ce qui ne doit pas être automatisé. Le logiciel vient ensuite répondre à un fonctionnement cible clairement décrit.
Avant de rédiger le cahier des charges, il est utile de cartographier les principaux flux. Cette étape révèle souvent que les difficultés attribuées à l’outil proviennent en réalité de règles imprécises, de fichiers multiples ou de responsabilités mal définies.
Pour chaque processus, décrivez la situation actuelle avec des éléments concrets :
Un schéma simple suffit souvent. Pour une commande client, il peut faire apparaître la demande de prix, la création du devis, la validation commerciale, la réservation du stock, la livraison, la facturation et le suivi du règlement. L’objectif n’est pas de décrire chaque cas particulier, mais de repérer les points qui consomment du temps ou créent un risque.
Il faut ensuite distinguer trois niveaux : le processus à conserver, celui à simplifier et celui à revoir avant toute informatisation. Configurer un ERP pour reproduire une mauvaise pratique peut rendre cette mauvaise pratique plus rapide, mais pas plus pertinente.
Un cahier des charges utile ne se limite pas à une liste de modules. Il traduit les besoins de la PME en situations vérifiables. Chaque exigence devrait indiquer le processus concerné, le résultat attendu, les utilisateurs concernés et le niveau de priorité.
Une structure en six parties peut servir de base :
Chaque besoin doit être classé, par exemple, en exigence obligatoire, besoin important ou amélioration souhaitable. Cette hiérarchisation évite de disqualifier une solution sur un détail secondaire alors qu’elle répond correctement au cœur de l’activité.
Préférez les formulations testables. La phrase le stock doit être fiable est trop vague. Une exigence plus précise pourrait être : un responsable doit pouvoir consulter le stock disponible par dépôt, distinguer les quantités réservées et enregistrer un inventaire avec traçabilité des corrections. La démonstration pourra alors confirmer ou infirmer le besoin.
Le périmètre dépend de l’activité. Une entreprise de négoce ne formulera pas les mêmes priorités qu’un atelier de fabrication ou qu’un prestataire qui facture au temps passé. Il est préférable de partir des flux critiques plutôt que de rechercher le plus grand nombre de fonctionnalités.
| Processus | Questions à poser | Points de vigilance |
|---|---|---|
| Ventes | Comment sont créés les devis, commandes et factures ? | Tarifs, remises, acomptes, conditions de paiement et transformation des documents |
| Achats | Comment les besoins sont-ils déclenchés et validés ? | Seuils de réapprovisionnement, fournisseurs multiples et rapprochement des factures |
| Stocks | Quelles quantités faut-il connaître et à quel niveau de détail ? | Lots, numéros de série, emplacements, réservations et inventaires |
| Production ou projets | Comment suivre les ressources, délais et coûts ? | Nomenclatures, temps passés, ordres de fabrication ou budgets |
| Finance | Quelles données doivent être transmises à la comptabilité ? | Journaux, TVA, analytique, contrôles et export vers le cabinet comptable |
Les fonctions de reporting doivent également être examinées. Un tableau de bord séduisant ne garantit pas une information utile. Vérifiez l’origine des indicateurs, leur fréquence de mise à jour, les filtres disponibles et les droits d’accès. Un taux de marge, par exemple, n’a de sens que si les coûts pris en compte sont définis et alimentés de façon régulière.
Après une première sélection, demandez une démonstration construite à partir de vos scénarios. Une présentation générique montre surtout les fonctions préparées par l’éditeur ou l’intégrateur. Elle permet rarement de vérifier l’adéquation avec les opérations quotidiennes.
Préparez cinq à dix scénarios représentatifs, comprenant au moins un cas normal et un cas d’exception. Vous pouvez demander la création d’un client, l’émission d’un devis avec remise, la transformation en commande, la réservation d’un article, la livraison partielle, l’émission d’un avoir et la consultation de la marge. Pour une activité de production, ajoutez une modification de nomenclature, une rupture de composant et une reprise après non-conformité.
Utilisez une grille pondérée. Attribuez à chaque critère un poids selon son importance, puis une note commune à chaque solution. Les critères peuvent inclure :
La note finale ne doit pas remplacer l’analyse. Elle sert à rendre les arbitrages visibles. Un candidat peut obtenir un résultat élevé tout en présentant un risque majeur sur la migration des données ou sur l’administration quotidienne. Ces réserves doivent être consignées séparément.
Le budget ERP comprend davantage que l’abonnement ou l’achat initial. Il faut distinguer les coûts certains, les coûts estimatifs et les coûts susceptibles d’apparaître après le démarrage.
Le coût total peut inclure :
Demandez une présentation séparée des coûts récurrents et ponctuels. Vérifiez aussi les conditions de révision tarifaire, la facturation des environnements de test, les limites d’API, le nombre de sociétés ou de sites inclus et les prestations facturées à la demande.
Pour comparer plusieurs offres, établissez un scénario financier commun sur une période définie. Une offre moins chère à l’achat peut devenir plus coûteuse si elle exige de nombreux développements ou une administration complexe. À l’inverse, une solution plus complète n’est pas forcément pertinente si ses fonctions ne sont pas utilisées.
Un ERP centralise des informations commerciales, financières, sociales et parfois personnelles. La sécurité doit donc être examinée avant la signature, et non après l’installation.
Les questions à poser portent notamment sur l’hébergement, les sauvegardes, le chiffrement, la gestion des incidents, la séparation des environnements de test et de production, ainsi que la localisation des données. Il faut également vérifier les modalités de restitution des données dans un format exploitable en cas de changement de solution.
La gestion des habilitations mérite une attention particulière. Un utilisateur ne devrait accéder qu’aux informations nécessaires à sa fonction. Examinez les rôles, les restrictions par site ou société, les validations, la journalisation des actions et la possibilité de désactiver rapidement un compte.
Pour les données à caractère personnel, le Règlement général sur la protection des données s’applique selon les traitements réalisés. La Commission nationale de l’informatique et des libertés recommande notamment de limiter les accès, de définir des durées de conservation et de documenter les responsabilités. Le contrat doit préciser les rôles respectifs du responsable de traitement et du sous-traitant lorsque le prestataire traite des données pour le compte de la PME.
Les règles comptables et fiscales doivent aussi être clarifiées avec un professionnel compétent. Le logiciel peut faciliter les contrôles et la conservation des pièces, mais il ne détermine pas à lui seul la règle applicable à une situation particulière.
Un ERP se déploie rarement correctement par une bascule précipitée de tous les modules. Une approche progressive réduit le risque et facilite l’apprentissage. Commencez par un périmètre prioritaire, avec des données maîtrisées et des indicateurs de réussite définis à l’avance.
La gouvernance doit préciser les responsabilités. Un sponsor décide des arbitrages, un chef de projet coordonne les travaux, les référents métiers valident les règles et les utilisateurs testent les scénarios. Sans disponibilité interne, les décisions sont reportées et les paramétrages risquent de refléter des hypothèses plutôt que le fonctionnement réel.
Prévoyez les étapes suivantes :
La formation doit partir des tâches réelles, non d’une visite exhaustive des menus. Une fiche courte sur la création d’une commande ou la correction d’un stock est souvent plus utile qu’un support général trop dense. Identifiez aussi les utilisateurs capables d’aider leurs collègues après le démarrage.
Choisir sur la seule réputation du logiciel. Une solution connue peut être mal adaptée à la taille, au secteur ou au niveau de maturité de la PME. Seuls les scénarios de travail permettent de vérifier l’adéquation.
Vouloir tout personnaliser. Un développement spécifique peut être justifié lorsqu’il répond à une différenciation réelle ou à une contrainte réglementaire. Il augmente cependant le coût, la dépendance au prestataire et la difficulté des mises à jour. Avant de demander une adaptation, examinez la possibilité de modifier le processus ou d’utiliser une fonction standard.
Négliger la qualité des données. Des clients en double, des articles mal codifiés ou des unités incohérentes produiront des résultats erronés dans un outil plus intégré. La migration doit comporter des règles de nettoyage, des contrôles et une validation par les métiers.
Sous-estimer les interfaces. Une connexion annoncée comme possible n’est pas nécessairement disponible sans développement. Demandez quelles données circulent, dans quel sens, à quelle fréquence et comment les erreurs sont signalées.
Confondre démonstration et engagement contractuel. Les fonctions présentées doivent être reprises dans les documents contractuels, avec le périmètre, les livrables, les délais, les critères de recette et les responsabilités.
Oublier l’après-démarrage. Les premières semaines font apparaître des questions et des ajustements. Prévoyez un canal de support, un délai de réponse, un responsable interne et un budget d’amélioration. Un ERP doit rester administrable lorsque le projet initial est terminé.
Non. Un démarrage ciblé sur les flux les plus critiques est souvent plus lisible. Le périmètre doit toutefois être cohérent : déployer les ventes sans prévoir le lien avec les stocks ou la facturation peut créer de nouvelles ruptures d’information.
Il n’existe pas de réponse universelle. Comparez les exigences de disponibilité, de connexion, de sécurité, d’administration, de personnalisation et de réversibilité. La décision doit tenir compte des compétences internes et des contraintes propres à l’activité.
La qualité de l’analyse compte davantage que le nombre. Une présélection de quelques solutions réellement compatibles avec le cahier des charges permet généralement d’organiser des démonstrations approfondies sans disperser les équipes.
La direction arbitre généralement le budget et le niveau de risque, mais la validation doit associer les utilisateurs clés, la fonction financière, la personne chargée des systèmes et, si nécessaire, un professionnel compétent pour les sujets comptables, juridiques ou liés à la protection des données.
Aucune partie de ce site ne peut être reproduite sans autorisation écrite © adequate.fr.