Vous préparez un projet ERP mais vos besoins ne sont pas encore totalement cadrés ?

Hecatis accompagne les PME industrielles en AMOA pour cartographier les processus, formaliser les besoins et préparer la consultation des intégrateurs.

Échanger sur votre projet ERP

Pourquoi le cahier des charges est une étape clé d’un projet ERP ?

Lorsqu’une entreprise commence à envisager le remplacement ou la mise en place d’un ERP, le premier réflexe est souvent de regarder les solutions disponibles. Odoo, Sage, SAP, Microsoft Dynamics ou encore des logiciels plus spécialisés : les démonstrations commencent, les fonctionnalités s’enchaînent et chaque solution semble capable de répondre à une grande partie des besoins.

Mais une question devrait être posée avant toutes les autres : De quoi l’entreprise a-t-elle réellement besoin ?

C’est précisément le rôle du cahier des charges ERP. Il doit permettre de formaliser ce que le futur système devra résoudre, mais surtout dans quel environnement il devra fonctionner. Dans une PME industrielle, un ERP touche rarement un seul service. Il peut concerner :

• les ventes et les devis ;

• les achats ;

• la gestion des stocks ;

• la production ;

• le MRP et les approvisionnements ;

• la qualité ;

• la traçabilité ;

• la logistique ;

• la facturation ;

• voire les échanges avec un WMS, un MES ou d’autres logiciels métier.

Le projet ne consiste donc pas simplement à installer un nouvel outil. Il consiste à faire fonctionner ensemble des processus qui traversent plusieurs services. Et c’est là qu’un cadrage insuffisant peut rapidement devenir coûteux.

L’erreur fréquente : commencer le cahier des charges par les fonctionnalités

On rencontre régulièrement des cahiers des charges qui ressemblent à ceci : Gestion commerciale- Gestion des stocks- Gestion de production- Achats- Facturation - Reporting

Sur le papier, tout est là. Dans la réalité, ces quelques lignes ne disent presque rien du fonctionnement de l’entreprise. Prenons simplement la gestion des stocks.

Deux entreprises qui demandent toutes les deux « une gestion des stocks » peuvent avoir des besoins radicalement différents. L’une veut connaître le stock disponible dans un entrepôt unique. L’autre doit gérer plusieurs emplacements, des lots, des numéros de série, des dates de péremption, des réservations de matières pour la production et une traçabilité complète des mouvements. La fonctionnalité porte le même nom. Le besoin métier, lui, n’a rien à voir. Un bon cahier des charges ERP doit donc descendre suffisamment dans le fonctionnement réel de l'entreprise pour éviter que chacun interprète une même demande à sa manière.

1. Commencer par cartographier les processus existants

Avant de rédiger les spécifications du futur ERP, il faut comprendre comment l’entreprise fonctionne aujourd’hui. Et pas uniquement comment elle est censée fonctionner. Il existe souvent une différence importante entre la procédure officielle et ce qui se passe réellement sur le terrain. Un devis peut par exemple être créé dans l’ERP, repris dans un fichier Excel pour préparer la production, transmis par mail à l’atelier puis ressaisi dans un autre système avant la facturation. Vu depuis la direction, il existe peut-être déjà un ERP. Vu depuis les équipes, le processus repose en réalité sur quatre outils et plusieurs ressaisies manuelles. Le cadrage doit donc suivre les flux réels :

devis → commande → approvisionnement → production → stock → expédition → facturation

Pour chaque étape, il est utile d'identifier :

• qui intervient ;

• quelles informations sont utilisées ;

• dans quel outil elles se trouvent ;

• quelles données sont créées ou modifiées ;

• où apparaissent les ressaisies ;

• quelles validations sont nécessaires ;

• où se produisent les erreurs ou les pertes de temps.

Cette cartographie fournit la base du futur cahier des charges ERP industriel.

2. Identifier les irritants avant de définir la solution

Un projet ERP est rarement lancé simplement parce qu’une entreprise souhaite « se digitaliser ». Il existe généralement des irritants très concrets derrière le projet.

Par exemple :

• impossible d’obtenir un stock fiable rapidement ;

• trop de fichiers Excel parallèles ;

• informations différentes selon les services ;

• données saisies plusieurs fois ;

• difficultés à suivre l’avancement des ordres de fabrication ;

• manque de traçabilité ;

• délais de préparation difficiles à anticiper ;

• reporting construit manuellement ;

• ERP historique devenu trop rigide ;

• dépendance à quelques collaborateurs qui savent « comment ça marche ».

Ces irritants doivent apparaître dans le cadrage. Mais il faut aller un peu plus loin que leur simple constat. Si les équipes ressaisissent une information dans Excel, par exemple, la bonne question n’est pas : « Comment supprimer Excel ? »

Il faut d’abord comprendre : « Pourquoi les équipes ont-elles besoin d’Excel alors qu’un ERP existe déjà ? » Très souvent, le fichier parallèle n’est pas le problème. Il est le symptôme d’un processus mal couvert.

3. Transformer les besoins métier en exigences fonctionnelles

Une fois les processus et les irritants identifiés, il devient possible de formaliser les attentes du futur ERP. L’objectif est de passer d’un besoin assez vague comme : « Nous voulons améliorer la gestion de production. » à des besoins beaucoup plus exploitables :

Le responsable de production doit pouvoir visualiser les ordres de fabrication en cours et leur état d’avancement. Les consommations de matières doivent être rattachées aux ordres de fabrication concernés. Une rupture potentielle de composant doit pouvoir être détectée avant le lancement de la production.

Les données nécessaires au suivi de production doivent être accessibles sans ressaisie dans un fichier parallèle. Cette précision facilite énormément les échanges avec les intégrateurs ERP.

Elle permet également de distinguer ce qui relève :

• d’une fonctionnalité standard ;

• d’un paramétrage ;

• d’un développement spécifique ;

• d’une interface avec un autre outil ;

• ou parfois simplement d’une évolution du processus interne.

Et cette dernière possibilité est souvent oubliée. Tous les problèmes métier ne nécessitent pas un développement informatique.

4. Décrire les flux de données et les interfaces

Un ERP fonctionne rarement seul. Dans une entreprise industrielle, il peut devoir échanger avec :

• un MES ;

• un WMS ;

• un logiciel de CAO ;

• des machines ;

• un système d’étiquetage ;

• des solutions RFID ou code-barres ;

• un logiciel comptable ;

• une plateforme e-commerce ;

• un CRM ;

• ou des applications métier spécifiques.

Le cahier des charges ERP doit donc préciser les informations qui doivent circuler entre ces différents systèmes. Pour chaque interface, il faut notamment se demander :

• quelle donnée doit être transmise ?

• par quel système est-elle créée ?

• quel système doit devenir la référence ?

• à quel moment doit-elle être synchronisée ?

• l’échange doit-il être instantané ou périodique ?

• que se passe-t-il lorsqu’une donnée est modifiée ?

L’enjeu est simple : éviter de reconstruire, autour du nouvel ERP, les mêmes silos que ceux que l’on cherchait justement à supprimer.

5. Définir une source de vérité pour chaque donnée

Produit, client, fournisseur, nomenclature, stock, prix, ordre de fabrication… Lorsqu’une même information existe dans plusieurs systèmes, une question essentielle doit être tranchée : quel outil fait foi ?

Prenons une référence produit présente dans l’ERP, le WMS et un fichier Excel. Si sa désignation ou ses caractéristiques changent, où la modification doit-elle être réalisée ? Et comment est-elle ensuite transmise aux autres systèmes ? Sans règle claire, les équipes finissent rapidement avec plusieurs versions d’une même information. Le cahier des charges doit donc également préciser les règles de gouvernance des données. Dans beaucoup de projets ERP, cette question est au moins aussi importante que le choix des fonctionnalités.

6. Prioriser les besoins : tout n’a pas la même importance

Un cahier des charges ERP peut rapidement devenir très long. Le risque est alors de mettre au même niveau une exigence critique pour l’activité et une fonctionnalité simplement confortable. Une méthode simple consiste à distinguer : 

• Les besoins indispensables Sans eux, la solution ne permet pas de faire fonctionner correctement le processus.
• Les besoins importants Ils améliorent significativement l’efficacité mais peuvent éventuellement être traités dans une deuxième phase.
• Les besoins complémentaires Ils apportent du confort ou des optimisations supplémentaires.

Cette priorisation devient particulièrement utile lors de la consultation des intégrateurs. Elle permet de différencier : « la solution ne répond pas à notre processus critique » de : « cette fonctionnalité pourrait être agréable à avoir ». Ce n’est évidemment pas la même chose.

7. Prévoir les volumes, contraintes et cas particuliers

Un projet ERP ne doit pas être conçu uniquement autour du processus « quand tout se passe bien ». Ce sont souvent les exceptions qui compliquent réellement le système. Le cahier des charges peut donc préciser :

• nombre d’utilisateurs ;

• nombre de sites ou d’entrepôts ;

• volume de commandes ;

• nombre de références ;

• volumes de données historiques ;

• gestion multi-sociétés ;

• droits d’accès ;

• exigences de traçabilité ;

• contraintes réglementaires ;

• scénarios particuliers ;

• besoins mobiles ou atelier.

Un processus industriel qui fonctionne dans 90 % des situations mais oblige les équipes à contourner l’ERP dans les 10 % restants finit souvent par recréer… un nouveau fichier Excel.

8. Ne pas oublier la reprise des données

La question arrive parfois très tard dans le projet : « Et toutes nos anciennes données, on en fait quoi ? » Elle devrait pourtant être abordée dès le cahier des charges. Il faut identifier :

• les données à reprendre ;

• leur format actuel ;

• leur qualité ;

• les doublons éventuels ;

• leur historique ;

• les informations réellement utiles dans le futur ERP.

Changer d’ERP peut être l’occasion de repartir sur une base plus propre. Importer plusieurs années de données incohérentes dans un nouvel outil permet surtout d’obtenir… un nouvel outil rempli de données incohérentes.

9. Définir comment les intégrateurs seront comparés

L’un des grands intérêts d’un cahier des charges bien structuré est de permettre de comparer plusieurs réponses sur une base commune. Sans cadrage précis, chaque intégrateur peut proposer une vision différente du projet. L’un inclura certaines prestations. L’autre les considérera comme optionnelles. Un troisième supposera qu’une fonctionnalité standard suffit là où un développement sera finalement nécessaire. Le prix seul devient alors très difficile à comparer. Le cahier des charges doit permettre d’évaluer notamment :

• la couverture fonctionnelle ;

• les écarts par rapport aux besoins ;

• les développements spécifiques ;

• les interfaces nécessaires ;

• la méthodologie projet ;

• la reprise de données ;

• la formation ;

• l’accompagnement au démarrage ;

• les délais ;

• le budget global.

L’objectif n’est donc pas uniquement d’obtenir plusieurs devis. Il est d’obtenir plusieurs propositions réellement comparables.

Cahier des charges ERP : exemple de structure

Il n’existe pas un modèle de cahier des charges ERP valable pour toutes les entreprises. Pour une PME industrielle, une structure peut néanmoins s’organiser autour des éléments suivants :

1. présentation de l’entreprise et du contexte ;

2. objectifs du projet ERP ;

3. périmètre concerné ;

4. organisation et utilisateurs ;

5. cartographie des processus actuels ;

6. difficultés et irritants identifiés ;

7. processus cibles ;

8. besoins fonctionnels ;

9. données et règles de gestion ;

10. interfaces avec les autres systèmes ;

11. contraintes techniques ;

12. reprise de données ;

13. besoins de reporting ;

14. exigences de sécurité et droits utilisateurs ;

15. accompagnement et formation ;

16. planning envisagé ;

17. critères de sélection de la solution et de l’intégrateur.

Mais la structure du document est finalement secondaire. Ce qui compte, c’est la qualité du travail réalisé avant de l’écrire.

Quel est le rôle de l’AMOA dans la rédaction d’un cahier des charges ERP ?

L’Assistance à Maîtrise d’Ouvrage (AMOA) intervient justement du côté de l’entreprise qui porte le projet. Son rôle n’est pas de vendre un logiciel.

Elle aide l’entreprise à :

• comprendre et formaliser ses processus ;

• recueillir les besoins des différents métiers ;

• identifier les priorités ;

• construire les spécifications ;

• préparer la consultation ;

• analyser les réponses des intégrateurs ;

• puis accompagner le projet jusqu’au déploiement.

Cette indépendance est particulièrement importante au moment du cadrage. Un intégrateur connaît parfaitement la solution qu’il propose. L’entreprise, elle, doit d’abord être capable d’exprimer précisément ce qu’elle attend de cette solution.

Chez Hecatis, l’accompagnement AMOA repose notamment sur une connaissance opérationnelle des flux industriels : production, stock, MRP, logistique et systèmes d’information associés. L’objectif est donc de partir du fonctionnement métier de l’entreprise avant de déterminer comment l’ERP devra y répondre.

Vous préparez un projet ERP ?

Hecatis accompagne les PME industrielles en AMOA et pilotage de projets ERP, indépendamment des éditeurs et des intégrateurs.

De la cartographie des processus à la rédaction des spécifications, puis au choix de l’intégrateur, au déploiement et à la recette, Hecatis intervient comme chef de projet côté client afin de défendre les besoins métier de l’entreprise tout au long du projet.

Vous avez un projet ERP en réflexion ? Échangeons d’abord sur vos processus et vos besoins.

👉 Prendre rendez-vous avec Hecatis

À propos de l'auteur

Julien Jouan

Fondateur d'Hecatis

Hecatis est un cabinet de conseil basé à Rouen qui accompagne les TPE et PME industrielles et logistiques dans l'optimisation puis la digitalisation de leurs processus (Lean Management, cartographie VSM, MES, WMS, traçabilité RFID et code-barres). Il intervient directement sur le terrain, de l'analyse des processus jusqu'au déploiement des outils de suivi de production. 📩 contact@hecatis.fr — Profil LinkedIn