Article initialement publié le 28/06/2018 et mis à jour le 06/10/2021.
A l’heure où l’édition 2021 du Salons Solutions ferme ses portes et que chaque visiteur repart avec de nouvelles idées pour son ERP, il était essentiel de mettre à jour cet article sur les bonnes pratiques pour établir son cahier des charges ERP. La digitalisation des entreprises n’a eu de cesse de s’accélérer depuis plusieurs années et la pression sur les systèmes d’information et ses différents applicatifs n’a jamais été aussi forte ! Direction générale et DSI cherchent en permanence à s’adapter aux évolutions de leur écosystème et cela impacte très rapidement les processus métier.
Dans ce contexte, le choix de l’ERP qui prendra en charge toutes les opérations de manière intégrée est extrêmement engageant, il faut donc soigner son processus de sélection et notamment l’étape traditionnelle de rédaction du cahier des charges avant le comparatif ERP en tant que tel. Il serait en effet trop risqué de faire reposer sa décision sur des démonstrations séduisantes plutôt que sur la vérification de la capacité de la solution retenue à structurer les évolutions attendues des business models de l’entreprise afin de soutenir efficacement sa stratégie de développement.
Pour cela, rédiger un cahier des charges ERP apparaît souvent comme indispensable mais son délai de réalisation est-il encore compatible avec les exigences des directions générales en termes de rapidité et d’agilité ? En effet, DSI et DG s’accordent aujourd’hui sur le fait que les approches « quick-win » doivent être privilégiées. Construire le cahier des charges parfait pendant plusieurs mois n’a plus aucun sens alors que les besoins évoluent aujourd’hui plus rapidement et que les environnements économiques sont pour le moins volatils. C’est ainsi que le concept du POC « Proof of concept » semble être une approche plus innovante que le cahier des charges ERP, mais dans ce cas, qui fait quoi concrètement ? Et comment retrouver davantage d’agilité dans la création du cahier des charges ?
Avant le cahier des charges ERP : bien définir l’orientation des directions métiers
La mise en place d’un ERP permet de fédérer les utilisateurs autour de processus métier intégrés et devient ainsi un élément prépondérant dans la culture d’entreprise. L’implication des directions métiers dans la préparation du cahier des charges est donc essentielle. En revanche, nos expériences de déploiement de projets ERP nous montrent que l’approche classique de lister les fonctionnalités attendues en les regroupant par domaines de gestion est insuffisante voire même désormais inadaptée au-regard des exigences de rapidité et d’agilité des entreprises…
Le cahier des charges ERP doit désormais adopter un nouveau format qui lui permette de prendre de la hauteur avec une approche plus stratégique autour des exigences exprimées par les directions métiers. Ces derniers doivent évidemment transmettre leurs orientations, leurs axes d’amélioration et les modifications organisationnelles nécessaires mais dans le but d’identifier les véritables enjeux et objectifs liés à la mise en place de l’ERP. Un projet ERP réussi est un projet porté par les métiers et piloté selon les objectifs stratégiques.
Voici ci-dessous un exemple de « radar » regroupant les orientations fonctionnelles exprimées par les directions métier dans le cadre d’un projet ERP suivant trois critères de priorisation propres à l’entreprise : « Je dois », « Je veux » et « Je peux » faisant apparaître où se trouvent les gains attendus… Ce regroupement pourra servir de base aux travaux pour constituer le cahier des charges :

Profitez de tous les conseils de nos experts ERP basés sur plus de 15 ans de retours d’expériences et posez les bases de la réussite de votre projet dès l’étape du cahier des charges :

La couverture fonctionnelle dans le cahier des charges ERP
Si ce regroupement des fonctionnalités est important pour créer les bonnes conditions à un projet piloté par les enjeux, le cahier des charges ERP permet d’en apprécier les différences parmi les différentes solutions comparées et favorise des critères de choix objectifs et pertinents. C’est pour cela que la recherche d’agilité ne doit pas écarter la formalisation des besoins fonctionnels mais une approche plus innovante pour leur formalisation pourrait être intéressante comme nous allons le voir…
L’entreprise doit appréhender la recherche de sa solution ERP, cœur de son système d’information, par une approche orientée métier et privilégier des solutions spécialisées pour son secteur d’activité. C’est pourquoi, il faut passer en revue les macro-processus clés en se concentrant sur ses particularités et les mentionner clairement dans le cahier des charges. Idéalement, les fonctionnalités souhaitées doivent d’ailleurs être organisées selon les processus clés en mentionnant les gains attendus, plutôt que sous forme d’une liste de besoins qui fait souvent tomber dans l’écueil de la « liste au père Noël ». Cela évite aux entreprises et intégrateurs de travailler sur des cahiers des charges ERP où il est difficile de distinguer les fonctionnalités liées à des objectifs stratégiques de celles issues des « demandes partisanes » avec tous les risques que cela fait courir sur l’identification des éventuels développements spécifiques qui seraient nécessaires et l’anticipation des charges associées pour éviter les mauvaises surprises budgétaires en cours de route. La synergie avec l’intégrateur ERP qui sera retenu au final se construit dès l’étape du cahier des charges.
Le POC « Proof of Concept » et ses avantages
Comme nous le disions précédemment, les directions générales privilégient désormais des approches plus agiles pour raccourcir les délais des projets ERP. C’est ainsi que le concept du POC ou « Proof of Concept » a progressivement pris de l’ampleur dans les méthodes comparatives car si le cahier des charges permet de bien structurer la démarche de sélection, le POC permet quant à lui de valider la capacité de l’entreprise et du partenaire intégrateur à mener à bien le projet !
A partir d’une grille contenant les besoins essentiels et des principaux objectifs fixés au projet ERP, l’intégrateur pourra réaliser une étude préalable et commencer à maquetter pour que la projection de l’entreprise dans la solution permette une adoption et un choix plus pertinent que s’il avait fallu attendre la finalisation du cahier des charges. En effet, le POC permet de réaliser une « maquette » à partir des données réelles de l’entreprise pour que les démonstrations des solutions soient beaucoup plus concrètes en étant réalisées à la fois sur les processus clés et les données réelles de l’entreprise. Cela rassure les responsables métiers qui peuvent mieux comparer les ERP et mieux apprécier comment les utilisateurs finaux les utiliseront avant de faire leur choix…
Évidemment, la réalisation d’un POC est consommatrice de temps pour l’entreprise comme pour les intégrateurs. Il n’est donc pas raisonnable d’envisager de la réaliser avec toutes les solutions ERP consultées, il faut plutôt privilégier de le faire sur les solutions finalistes de l’appel d’offres. Pour cela, le cahier des charges ERP doit idéalement présenter les fonctionnalités selon les processus clés et intégrer des échantillons de données pour faciliter la réalisation des Proof of concept.
En tant qu’intégrateur expert des ERP Microsoft Dynamics 365 et SAP S/4HANA, nous réalisons régulièrement des Proof of Concept entre ces deux solutions, vous pouvez d’ailleurs télécharger notre comparatif détaillé pour en savoir plus :

IL est enfin nécessaire de prévoir toute la dimension financière : TCO et ROI
Si le Proof of Concept fait en sorte que les démonstrations des solutions ERP soient plus concrètes pour les directions métiers, il reste encore à bien évaluer leurs coûts et c’est un point essentiel du cahier des charges ERP.
Comment définir le Total Cost of Ownership ?
En ce qui concerne l’évaluation des coûts des différentes solutions ERP, l’approche idéale est évidemment d’analyser le coût total de possession (Total Cost of Ownership – TCO) en se basant sur la période d’amortissement estimée de 8 à 10 ans qui reflète la durée de vie réelle d’un ERP en entreprise.
Vous trouverez ci-dessous un exemple de modélisation du comparatif des coûts annuels entre 2 solutions ERP telles que Microsoft Dynamics 365 ou SAP S/4HANA, en phase projet et en phase maintenance qui permet d’identifier à quel moment les gains annuels dépassent les coûts engagés.

Comment définir le ROI (Retour sur investissement) ?
La détermination des gains et du ROI attendus est effectivement déterminante pour que l’approche financière soit complète. On investit dans un ERP pour qu’il soutienne le développement de l’entreprise en créant des avantages compétitifs durables. Il faut pour cela identifier dans le cahier des charges ou la préparation du POC les processus qui seront directement impactés par la mise en œuvre du nouvel ERP et évaluer les bénéfices à atteindre :
- Des bénéfices quantitatifs : fiabiliser les temps de production, réduire la durée des cycles de commande et délais de livraison, accélérer le traitement des réclamations clients, améliorer les prévisions et notamment la visibilité des stocks par exemple, diminuer les coûts de fonctionnement informatique, etc.
- Des bénéfices qualitatifs : réduire la durée des prises de décisions opérationnelles, augmenter le taux de satisfaction des clients, respecter les objectifs de taux de services, accélérer les temps de clôture mensuelle, améliorer la productivité des salariés, etc.
Vous trouverez ci-dessous un nouvel exemple de comparaison du ROI dans le cadre de la mise en place de deux ERP tels que Microsoft Dynamics 365 ou SAP S/4HANA qui met en évidence que les gains cumulés dépassent les coûts au bout d’environ quatre ans…

Cahier des charges ERP et « Proof of Concept » sont donc tous deux indispensables
A l’heure de la généralisation des solutions dans le Cloud et de la recherche d’agilité permanente, il est plus que jamais important d’adopter une approche innovante pour votre processus de sélection d’un ERP en conservant la présence de la direction générale dans le pilotage du projet. En rédigeant un cahier des charges prévoyant la réalisation d’un Proof of Concept sur les solutions finalistes, vous êtes certain de démarrer votre projet sur de bonnes bases…