La vision détaillée des coûts des projets ERP est indispensable à l’heure des personnalisations excessives, des dépassements de délais et de budgets. D’où l’intérêt d’utiliser une grille pour introduire plus de transparence. Les projets ERP mobilisent d’importants budgets, d’autant que le coût moyen d’implémentation reste élevé.
Pour une entreprise américaine, cela peut atteindre 4,1 millions de dollars. Les coûts sont d’ailleurs souvent augmentés par les besoins de personnalisation. Sur ce terrain, les entreprises ne se privent pas : quasiment toutes adaptent leur ERP. D’après Panorama Consulting, plus de la moitié des entreprises américaines ont modifié leurs solutions de façon significative (équivalent à plus de 25 % du code) et seulement une sur dix effectue une personnalisation mineure (équivalente à moins de 10 % du code). Cette possibilité de personnaliser intervient d’ailleurs dans le choix d’équipement : un tiers des utilisateurs la placent parmi leurs critères de choix, selon le cabinet américain Mint Jutras.
En France, le niveau de personnalisation a été mesuré par le CXP, qui a publié, le 10 mars 2016, son ERP Survey 2016, en amont des salons Solutions 2016 et ERP 2016 qui se tiendront à Paris en septembre prochain. Selon cette analyse, 27 % des entreprises ont personnalisé plus de 25 % leurs solutions. « Dans près de 40 % des cas, la part de développements spécifiques est inférieure à 10 %, le développement des solutions métiers contribue de plus en plus à les limiter », note Patrick Rahali, analyste en charge des études ERP au CXP.
Des effets pervers de la personnalisation excessive
La personnalisation introduit plusieurs effets de plus en plus pervers à mesure que son degré s’accroît. Ainsi, il faut prendre en compte les coûts liés à la formation technique des développeurs internes et/ou externes, aux consultants fonctionnels et techniques, à l’acquisition des codes source et des documentations techniques et aux mises à niveau des modifications avec les nouvelles versions de l’ERP. « La mise en place d’interfaces et la reprise des données, qui dépend de leur quantité mais aussi de leur qualité, sont souvent sous-estimées », rappelle Isabelle Saint Martin, chef de marché ERP chez Sage.
Il est donc préférable de limiter la personnalisation au maximum, en suivant les principes suivants :
- Accepter le fait qu’un ERP soit personnalisé.
- Choisir le bon progiciel après une étude des besoins, et non celui qui est le plus vendu ou utilisé par les concurrents.
- Anticiper l’évolution du système : si l’on se contente d’automatiser des processus, un fort degré de personnalisation sera nécessaire.
- Bien définir la gouvernance du projet pour contrôler la pertinence de toute demande de personnalisation.
- Utiliser toutes les possibilités des outils de configuration.
- Ne pas considérer qu’un ERP doit tout traiter pour tout le monde.
C’est en effet important pour maîtriser les coûts. Outre le fait de minimiser la personnalisation, le contrôle des coûts repose sur trois principes, selon Isabelle Saint-Martin : « D’abord, concevoir la refonte de son système par les enjeux. Il convient de mettre en perspective les besoins court terme et moyen-long terme en fonction des objectifs et des contraintes de l’entreprise, en étant honnête avec soi-même en termes de ressources. » Le second principe consiste à privilégier autant que possible les solutions standard : « Chercher à éviter les développements spécifiques est un objectif classique dans ce type de projet. Les entreprises peuvent aussi voir dans la mise en place d’un ERP une opportunité pour simplifier leurs processus », commente Isabelle Saint-Martin. Enfin, ajoute-t-elle : « Il faut également veiller à fiabiliser le référentiel et les données, de manière à rationaliser, assainir et anticiper la qualité future des données. »
Toujours des dépassements de délais et de budgets
Même si les coûts sont maîtrisés, les projets ERP, comme la plupart des projets IT, souffrent de dépassements de délais et de budgets. L’étude CXP révèle que les deux-tiers des projets ERP connaissent des dépassements de budgets. Certes, cela peut se justifier par une évolution du périmètre à couvrir (dans un cas sur cinq) ou parce que le dépassement est relativement tolérable (moins de 20 % du budget dans 12 % des cas). De même, l’étude révèle que les dépassements de délais sont, eux aussi, très fréquents : seulement un projet sur quatre ne connaît pas de tels dépassements. Pour un sur dix, le dépassement de délai excède un an…
Cette maîtrise des coûts doit être anticipée, d’autant que les entreprises vont poursuivre leur renouvellement de parc d’ERP : une solution sur deux a été mise en œuvre avant 2009 dont 18 % avant 2000, selon l’étude CXP. Aux États-Unis, l’ancienneté moyenne d’un ERP, dans les petites et moyennes entreprises, s’élève à 7,5 ans, selon Aberdeen Group. Outre le vieillissement du parc, plusieurs raisons justifient l’upgrade d’un ERP : bénéficier de nouvelles fonctionnalités, résoudre les problèmes de compatibilité, moderniser l’interface utilisateur ou doper les performances.
Les coûts d’un projet ERP peuvent ainsi se décomposer en trois grandes familles (voir tableau) :
- Les coûts liés au logiciel : droits d’usage, support et maintenance, coûts de fonctionnement, prestataires.
- Les coûts d’intégration : mise en œuvre, formation, direction de projet, prestataires.
- Les coûts d’accompagnement : schéma directeur, mise en œuvre, gestion du changement.
| Coûts liés au logiciel | Coûts d’intégration | Coûts d’accompagnement |
Droits d’usage
|
Mise en œuvre de la solution
|
Schéma directeur
|
Support
|
Formation
|
Mise en œuvre du projet
|
Coûts de fonctionnement
|
Direction de projet
|
Appropriation
|
Ressources et prestataires
|
Ressources et prestataires
|
Conduite du changement
|
| Source : Sage, Best Practices Systèmes d’Information. | ||
Migration d’un ERP : les étapes clés
- Étudier les adaptations spécifiques de l’ancien système et décider, au cas par cas, si un tel niveau de personnalisation est toujours nécessaire. Certaines fonctionnalités peuvent être intégrées dans la nouvelle version, les procédures et modes opératoires peuvent être revus à cette occasion.
- Être capable d’arbitrer afin de définir rapidement une solution en cas de refonte ou de rationalisation des processus.
- Limiter les adaptations spécifiques et privilégier le « standard » afin de faciliter les prochaines migrations et d’éviter les dépassements (budget/délais).
- Se rapprocher du modèle de données standard qui s’appuie généralement sur des normes et nomenclatures métier.
- Identifier les données et les classer par typologie (statiques, techniques et dynamiques).
- Étudier les transactions, les historiques, les statistiques et sélectionner le mode opératoire de reprise de données en fonction du contexte de l’entreprise (périmètre, format et volume des données, outil de reprise).
- Affecter des règles claires de retraitement et d’archivage des données.
- Ne pas sous-estimer les actions à prévoir concernant la BI, les reportings, les interfaces et la gestion des droits ; la charge liée aux tests (et le coût potentiel engendré par des tests incomplets) ; la charge liée aux reprises de données et les évolutions probables des besoins.
- Déterminer les plans de sécurité (back up, plan de retour en arrière, etc.). •
Source : TVH Consulting.