Découvrez quelles sont les bonnes pratiques et les erreurs à éviter lors de la rédaction du cahier des charges de votre projet d’ERP.

1. Webinar
ERP: 7 points clés pour un cahier des charges réussi

2. ERP: 7 points clés pour un cahier des
charges réussi
 Fondation sur laquelle le projet va reposer.
 Il va permettre le choix de la solution
 Il va servir de fil conducteur pendant la durée du projet.
 Incomplet ou irréaliste : danger
 Lors de ce webinar, vous découvrirez quelles sont les bonnes pratiques et
les erreurs à éviter lors de la rédaction du cahier des charges de votre
projet d’ERP.

3. Qui sommes-nous ?
 Éditeur de solutions Open Source ERP, CRM, RH et BPM de nouvelle
génération
 Cloud et mobile, la suite d’applications d’Axelor couvre les principaux
besoins d’une entreprise
 Notre promesse :
 S’adapter en temps réel à la croissance et à l’évolution des
entreprises, avec de simples paramétrages et sans
développements spécifiques
 Axelor partage les valeurs et la vision de l’Open Source, avec des
logiciels 100% libres

4. 1- Ne pas perdre de vue les objectifs
d’un cahier des charges

5. Objectif Principal
 Il est important de bien cerner les objectifs d’un cahier des charges
 L’objectif principal : choisir la solution la mieux adaptée à vos besoins
Le bon produit, pour un prix et un délai donné

6. Ne pas confondre cahier des
charges et spécifications détaillées
 Pour simplifier, le cahier des charges répond à la question
 “De quel ERP ai-je besoin pour répondre à mes besoins ?”
 Il ne faut pas confondre avec les spécifications détaillées qui est l’étape
qui se déroule après le choix d’un ERP
 Les spécifications détaillées permettent de répondre à la question
 “Comment l’ERP va répondre à mes besoins ?”

7. Document de référence
 Sert de document de référence tout le long du projet
 Point de départ pour les spécifications détaillées
 Le cahier des charges est également un document contractuel. Il servira
de référence en cas de litige.
 Même quand on signe pour un projet au forfait, tout ce qui n’est pas écrit
sur le cahier des charges ne peut pas être implicite, et ça ne protège pas le
client en cas de problème.

8. Document de référence
 Evitez de commencer par choisir un prestataire puis de lui faire
rédiger le cahier des charges.
 Par contre il peut être intéressant de se faire accompagner par un
consultant externe qui aura de l’expérience dans la gestion de
projets ERP.
Fortement recommandé de passer par
un cahier des charges

9. 2- Le contexte de l’entreprise

10. Le contexte
 Décrire l’entreprise, ses produits, sa stratégie…
 Expliquer pourquoi on souhaite se doter d’un ERP
 Essayer de définir des objectifs : ex. indicateurs pertinents sur l’activité de
l’entreprise

11. 3- Les processus actuels de l’entreprise

12. Les processus
 Point important : l’analyse des processus de l’entreprise.
 Il faut chercher à les décrire clairement, tels qu’ils sont vraiment.
 Nécessité de les classifier
 Impossible de tout prendre en compte
 Il convient donc d’interviewer les utilisateurs, et l’équipe projet.
Ne pas oublier certains détails qui ont de l’importance

13. Les processus
Les éléments à analyser
 Les différents flux
 Leur destination, leur origine.
 La forme de ces flux (oral, informatique, papier)
 Les outils utilisés
 Les points d’amélioration
 Les problèmes, dysfonctionnements rencontrés
 Ce qu’il vous manque actuellement
 Ce qui fonctionne bien actuellement, ce qui est indispensable.

14. Les processus
 3 questions à se poser pour décrire un processus.
 T-1 : le comptable
 T0 : création de la facture
 T1 : quand la commande est validée
 Pas de « Comment » à cette étape : spécifications détaillées
Les 3 Q
Qui, Quoi, Quand

18. 4- La description des besoins

19. Les besoins de l’entreprise
 Le cahier des charges doit comporter les besoins et problématiques de tous
les services.
 Impliquer l’ensemble des services dans le projet, organiser des réunions
entre les différents services pour échanger et analyser les différents flux
et processus.
 Avoir un point de vue global au niveau de l’entreprise permet parfois de
mieux les appréhender, plutôt que de faire une analyse entièrement
cloisonnée.
RISQUE
Si des besoins n’ont pas été prévus lors du cahier des charges et lors de la
phase de spécifications, et ils vont entraîner de nouveaux développements qui
vont prendre du temps et être coûteux.

20. Les besoins de l’entreprise
Description des besoins de l’entreprise
 Ce que devra comporter le prochain ERP et ce qui sera exclu.
Il s’agit de lister et de regrouper les fonctions attendues par modules
 Des templates existent mais ils sont formatés
 Vous pouvez prioriser les besoins selon leur importance

21. Les besoins de l’entreprise
Description des besoins de l’entreprise
 Donner des exemples, des cas concrets.
 ex : données en entrée, données en sorties.
 Des cas pratiques (comment on gère son stock, sa production…)
 Pas d’approche idéale : détailler le plus clairement possible les processus.
A EVITER
Trop détailler un besoin simple.
A l’inverse, ne pas passer vite sur des besoins assez complexes.

24. Les besoins de l’entreprise
 Vous pouvez formuler des questions ouvertes sur les problématiques de
l’entreprise.
 Comment gérer des stocks multi-entrepôts ?
 Comment effectuer le calcul des besoins de production ?
 Comment gérer les remises saisonnières sur nos produits ?
 L’éditeur ou l’intégrateur devra alors signifier s’il est en mesure de répondre
à ces besoins.

25. 5- Le SI existant

26. Le SI existant
Phase d’audit
 Logiciels
 Fonctions
 Versions
 Matériel
 Infrastructures (serveurs, réseaux…)
 Accès distants (vpn…)
 Débits et connexion internet
 Ordinateurs (système d’exploitation, processeur, ram, espace disque
disponible…)
 Terminaux de saisie (écrans tactiles, PDA…)

27. Le SI existant
Réfléchir à la rationalisation du SI

28. 6- Les contraintes du projet

29. Les contraintes
 Les problématiques d’interfaçage avec le reste du SI
 Quelles données seront synchronisées, avec quels modules…
 Spécifications détaillées fonctionnelles des interfaces
 Le contexte particulier de l’entreprise :
 Multi-sociétés,
 Obligations légales particulières…
 Archivage/traçabilité

31. Les contraintes
 La Migration
 Aborder toutes les problématiques de reprise de l’existant.
 Imports
 Quels types de données ? Quelle antériorité ?
 Continuité de service
Ne pas négliger le coût de la migration

32. Les contraintes
D’autres aspects à prendre en compte concernant l’exploitation de l’ERP
 Le nombre de licences voulu
 Les droits d’accès
 Les modalités de formation
 Le type de documentation attendue
 Les aspects légaux

33. 7- Conduite du projet

34. Conduite du projet
Détailler le déploiement de l’ERP
 Installation (récupération données, sauvegarde…)
 Modalités de démarrage
 Service attendu
 Evolution de l’ERP (comment il est mis à jour, degré de paramétrage…).
 Le rétroplanning souhaité.

35. Conduite du projet
Implémentation en plusieurs temps
 Plusieurs livraisons au sein d’un même lot (développements itératifs)
 Par lot : plus précis car mises en production successives
 Inconvénients :
 Processus à moitié dans le nouveau système, à moitié dans l’ancien.
 Nécessite une migration entre les lots
S’en rendre compte au milieu du projet risque d’allonger fortement les temps
d’implémentation et d’engendrer des coûts supplémentaires.

37. MERCI
Anthony Ferrari
a.ferrari@axelor.com