Article

Cahier des charges ERP et "Proof of concept" : entre complémentarité et agilité

A l’heure de la digitalisation des entreprises, 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 opérationnels. 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 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 toujours compatible avec les exigences des directions générales en termes de rapidité et d’agilité pour le projet ? 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 en quelques mois et que les environnements économiques sont pour le moins volatils. C’est ainsi que le concept du POC « Proof of concept » a semblé ê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 ?

Bien définir l'orientation des directions métiers avant le cahier des charges ERP :

La mise en place d’un ERP permet de fédérer les utilisateurs autour de processus opérationnels 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 mais 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 directions générales…

Le cahier des charges ERP doit adopter un nouveau format qui lui permette de prendre vraiment 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étiers dans le cadre d’un projet ERP suivant 3 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 :

Le cahier des charges ERP et la couverture fonctionnelle

Si ce regroupement des demandes fonctionnelles est important pour créer les bonnes conditions à un projet piloté par les enjeux, le cahier des charges ERP permet toujours d’apprécier les différences de couverture fonctionnelle entre les différentes solutions comparées et favorise l’adoption de 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 pas forcément comme on l’a toujours fait dans les cahiers des charges. Une approche plus innovante 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.

Les avantages du POC "Proof of Concept"

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 le choix de la bonne solution 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 à le 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 Proof of Concept consiste à 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 impliqués dans le choix qui peuvent mieux comparer les ERP et mieux apprécier comment les utilisateurs finaux les utiliseront…

Evidemment, 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 2 solutions finalistes de l’appel d’offres pour les comparer plus en détail. Evidemment, si le cahier des charges ERP présente déjà les fonctionnalités selon les processus clés et que les échantillons de données ont déjà été préparés, la réalisation du POC en sera grandement facilitée.

En tant qu’intégrateur expert des ERP Microsoft Dynamics 365 et SAP S/4 HANA, nous réalisons régulièrement des Proof of Concept entre ces 2 solutions qui se retrouvent souvent comme les 2 finalistes des appels d’offres ERP.

Le cahier des charges ERP doit enfin 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.

Comment définir le Total Cost of Ownership de votre projet ERP ?

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/4 HANA, 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 les gains attendus et le ROI (Retour sur investissement) ?

La détermination des gains et du ROI (Retour sur Investissement) attendus est effectivement déterminante pour que l’approche financière soit complète. On investit dans un projet ERP pour qu’il soutienne le développement de l’entreprise et renforce la capacité à générer des améliorations significatives ainsi que des avantages compétitifs.

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 2 ERP tels que Microsoft Dynamics 365 ou SAP S/4 HANA qui met en évidence que les gains cumulés dépassent les coûts au bout d’environ 4 ans…

En synthèse : cahier des charges ERP et "Proof of Concept" sont tous 2 indispensables

A l’heure des ERP 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 rédigeant un cahier des charges ERP prévoyant la réalisation d’un Proof of Concept sur les 2 solutions finalistes, vous êtes certain de démarrer votre projet ERP sur de bonnes bases…

Intégrer les 2 étapes du cahier des charges et du POC ne doit pas être synonyme de projets longs. C'est pourquoi nous vous proposons l’étude comparative ERP de TVH Consulting sur les ERP Microsoft Dynamics 365 et SAP S/4 HANA qui peut vous permettre de gagner du temps et de réduire les principaux risques liés au choix grâce à des éléments factuels différenciants : adéquation fonctionnelle, adéquation opérationnelle, adéquation technique, stratégie de mise en œuvre et de déploiement, équipes et charges internes/externes, planning, effort de conduite du changement, cibles de TCO & ROI, etc.

Autre Articles