un

ERP dans ma PME

Jules RÉMY
Toutes les marques citées dans cet ouvrage sont des marques déposées par leurs propriétaires respectifs.
© La Ronde des Vivetières, 2016
Édité par « La Ronde des Vivetières », Pruillé (Maine-et-Loire, France)
http://pro.LaRondeDesVivetieres.com
« Toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement de l’auteur ou de ses ayants
droit ou ayants cause, est illicite » (alinéa 1er de l’article L. 122-4).

À ma femme,
première supportrice de mes ambitions
L’auteur
De formation ingénieur en informatique, Jules Rémy a commencé sa carrière comme
développeur de logiciels de gestion. Après plusieurs années au service d’un grand groupe
international, il décide de passer de l’autre côté du logiciel et d’accompagner les
entreprises utilisatrices de l’informatique, dans la définition de leurs besoins fonctionnels.
Aujourd’hui, Jules Rémy a accompagné plus de 40 projets ERP, essentiellement dans
des PME industrielles. Ses missions se concentrent en amont des besoins : conseiller les
dirigeants, analyser les flux d’information des entreprises ou bien rédiger des cahiers des
charges. Mais il peut également assister les PME dans leur choix et dans la mise en œuvre
de progiciels de gestion. Il a acquis l’essentiel de son expérience en gestion industrielle et
le métier de consultant sur le terrain, c’est-à-dire directement dans les ateliers de
production. Il anime régulièrement des formations de vulgarisation auprès de dirigeants de
PME.
Fort de cette expérience, il nous livre ses outils et sa méthodologie pour piloter un projet
ERP en PME. Il s’appuie sur des exemples réels qui ont marqué son quotidien de
consultant.
Avant-propos
Quel que soit son niveau de maturité, l’entreprise est tôt ou tard confrontée à un projet
informatique. De la PME manufacturière qui franchit le cap de l’industrialisation, à la
société qui renouvelle un système d’information devenu obsolète, l’informatique
accompagne toutes les entreprises dans leur développement.
Mais le choix des bons outils n’est pas simple. La recherche du « logiciel qui répondra
exactement au besoin » est truffée d’embûches et de miroirs aux alouettes. La jungle du
logiciel de gestion rebute souvent les dirigeants. En effet, la taille et la variété de l’offre
nécessitent une veille permanente pour avoir une vision claire du sujet. De plus, les
statistiques nous rappellent sans cesse le nombre d’échecs, les débordements de planning
et les coûts pharaoniques de ces projets. Il est clair que dans les clubs de dirigeants, ou par
le bouche-à-oreille, on entend plus souvent parler d’échecs de projets ERP que de
« Success Stories ». Mais qu’on se rassure tout de suite : sur le nombre total de projets, les
échecs représentent moins de 10 % des cas1.
On parlait au début des années 2000, d’environ 2000 références de logiciels de gestion
pour entreprise en France (tout type de gestion confondue : paie, comptabilité, gestion
commerciale, GPAO, etc.). Depuis ces années, l’offre s’est notablement consolidée, et
continue dans ce sens. Les gros acteurs rachètent les petits, les petits se rachètent entre
eux.
Cet ouvrage s’adresse en premier lieu aux chefs d’entreprises des petites et moyennes
industries (10 à 250 salariés) et aux chargés de projets qui souhaitent entreprendre un
projet ERP. Il n’y a pas de méthodologie miracle qui garantisse à 100 % un bon choix de
logiciel et sa bonne implémentation. Ce livre est là pour attirer votre attention sur les
erreurs commises trop souvent. Il se base sur des cas réels de projets menés par des PME.
Néanmoins, dans un souci de confidentialité, les noms des entreprises et des personnes ont
été transformés.
Ce livre n’est pas un recueil fonctionnel. Il s’agit avant tout d’un guide sur la gestion
des projets ERP. Des techniques et des outils éprouvés vous seront donnés pour tendre
vers une réussite maximale. Mais n’oubliez pas que ces projets sont fortement liés à
l’humain (aspect trop souvent négligé). Il y aura donc toujours des incertitudes et des aléas
à gérer.
Le contenu de ce livre est susceptible d’évoluer au fur et à mesure des remarques qui
nous seront faites, alors n’hésitez pas à nous faire part de votre avis.
Ni l’éditeur ni l’auteur ne peuvent être tenus responsables des résultats de l’application
des méthodes mentionnées dans cet ouvrage. L’auteur et l’éditeur déclarent n’avoir aucun
lien avec les logiciels et sociétés cités dans ce livre. Ce recueil est le fruit d’un travail
accompli en toute indépendance.
L’auteur, Jules RÉMY

[1]
Comprendre l’offre
Spécificités d’un projet ERP en PME
Pourquoi une PME devrait-elle piloter un projet ou un avant-projet ERP différemment
d’une grande société ? Considérant uniquement la méthodologie de gestion de projet, il ne
devrait pas y avoir de différence. Malheureusement, les ressources humaines pour piloter
un projet de plusieurs mois sont plus difficilement mobilisables dans une petite structure
que dans une grande. Il faudra gérer le projet en plus des tâches quotidiennes : « Business
first ! » D’autre part, l’offre pour PME est beaucoup plus packagée. On s’attend donc à ce
que la petite et moyenne entreprise tende vers un fonctionnement plus standard qu’un
grand groupe.
La surcharge d’investissement qu’amène ce genre de projet peut être critique pour la
PME. Les grands groupes choisissent souvent de disposer de ressources de développement
en interne. Il est illusoire en PME d’avoir un ingénieur recruté à plein temps travaillant sur
la mise au point d’un progiciel. La PME devra davantage miser sur un partenariat avec
l’éditeur ou l’intégrateur retenu. D’où l’importance de bien choisir ce partenaire, et de
bien piloter cette relation.
ERP, PGI : définitions
Littéralement, ERP signifie « Enterprise Ressource Planning » - « Planification des
ressources de l’Entreprise ». En français, cela a été adapté en « Progiciel de Gestion
Intégré » (PGI). Ces deux définitions sont très différentes : le terme anglais s’apparente
davantage à l’aspect fonctionnel, alors que le terme français définit une notion
d’architecture de système. Cela dit, de plus en plus, l’acronyme « ERP » supplante son
homologue français. La définition française est pourtant porteuse des valeurs essentielles
de ce type d’outils. L’adjectif « intégré » résume bien le but de beaucoup d’entreprises qui
adoptent un ERP. L’idée est d’avoir le même logiciel de gestion pour piloter tous les
services de l’entreprise, que chaque salarié ait accès aux mêmes données et que l’on évite
les pertes de temps administratives avec des ressaisies dans de multiples programmes
informatiques. On évite aussi que certains services cloisonnent les informations qu’ils
produisent. Du point de vue de la sécurité des données, l’intégration implique aussi une
centralisation des informations sur un serveur. Les procédures de sauvegarde et de PRA2
sont donc plus simples à mettre en œuvre.
Les ERP sont caractérisés par leur modularité. Le client choisit les services qu’il
souhaite intégrer à l’outil. Chaque module d’ERP dispose de fonctions standards qui
seront paramétrées pour coïncider avec le fonctionnement souhaité par l’entreprise. En
complément, le prestataire peut développer des spécifiques pour les fonctions manquantes
à son progiciel. En moyenne, on parle de 80 % de fonctionnalités standard pour 20 % de
spécifiques. Ce chiffre varie selon la typologie de l’entreprise, et la tendance veut qu’en
PME, on évite de s’éloigner de la philosophie d’un outil. Certains éditeurs pour PME ont
même opté pour l’abolition des développements spécifiques.
Les gestionnaires de longue date qui ont connu l’informatique des années 80-90 se
souviennent de l’acronyme GPAO – Gestion de Production Assistée par Ordinateur. À
l’origine, on les distinguait des ERP, car ces outils étaient vraiment spécialisés en suivi de
fabrication (Gestion des ordres de fabrication, lancement, planning, ordonnancement…).
Aujourd’hui, certains éditeurs utilisent les termes ERP et GPAO pour désigner la même
chose ; d’autres cantonnent la GPAO à des ERP simplifiés. Enfin d’autres appellent GPAO
le module de gestion de production des ERP. Peu importe le nom que vous lui donnerez,
l’important c’est de bien s’entendre sur son contenu.
Application… logiciel… progiciel… framework…
Nous sommes entourés de logiciels. Mais leurs appellations diffèrent selon le cadre
d’utilisation. Les tablettes et les smartphones utilisent le terme « applications ». Il s’agit
de programmes informatiques utilisables directement et permettant d’accomplir un
ensemble souvent réduit de fonctions.
Un logiciel est conçu par un développeur. Il doit être installé sur une machine cible
avant d’être exploité. Le logiciel répond à un besoin spécifique défini par l’utilisateur. Son
utilisation peut-être dédiée à un service ou plus large dans les grandes organisations.
Un progiciel (produit-logiciel) est un type de logiciel développé par un éditeur, visant à
standardiser des usages et offrir des programmes génériques. Ce terme, que l’on retrouve
dans l’acronyme « PGI », est toutefois peu utilisé aujourd’hui, les services de l’état
recommandent désormais l’appellation « logiciel standard ».
Certains éditeurs emploient parfois le terme « framework ». Dans ce cas, l’éditeur
développe un moteur générique, indépendant du type de métier de l’entreprise cliente, qui
est repris plus tard par un intégrateur qui en fait un logiciel. Le framework en tant que tel
ne peut rien faire, c’est un ensemble de fonctions et de possibilités qui doivent être mises
en musique par un tiers.
Quel que soit le vocabulaire utilisé, l’organisation et l’offre de service tournent autour
de 3 entités : un éditeur, un intégrateur et le client. L’intégrateur prend en charge
l’installation, le paramétrage, le développement des éléments complémentaires, les tests et
la recette, la formation des utilisateurs et la maintenance de la solution.
De son côté, l’éditeur fait évoluer les versions standard du progiciel (ou du
framework), et donne du support à l’intégrateur. Il peut éventuellement faire office de
support niveau 2 pour l’utilisateur final.
Les intégrateurs sont des sociétés plus ou moins importantes. Les plus grandes d’entre
elles déploient des solutions de plusieurs éditeurs. Derrière ces deux entités – éditeurs et
intégrateurs – plusieurs modèles de partenariat coexistent. (Voir « Segmentation des
acteurs de l’ERP » dans ce chapitre).
Qui a besoin d’un Progiciel de Gestion Intégré ?
Aujourd’hui, il est rare de voir une entreprise industrielle produire ses Bons de
Livraison (BL) à l’arrière du camion sur un facturier en papier carbone. Qu’elles aient une
taille de 10 ou de 249 salariés, la gestion de la PME passe par l’informatique. On entend
souvent dire que Microsoft® Excel® est le premier ERP du monde. Ce constat est bien
réel : entre les tableurs partagés, les traitements programmés en macro-commandes, les
données liées entre plusieurs fichiers, etc., les entreprises ne manquent pas d’imagination.
Mais il arrive un moment ou le « système D » a ses limites : difficultés pour plusieurs
personnes à accéder à la même information en même temps, fichiers trop gros, duplication
des données… L’entreprise se rend compte qu’elle est en train de maintenir un quasi-ERP,
alors que ce n’est pas son métier.
L’institut National de la Statistique et des Études Économiques (INSEE) publie
régulièrement des résultats d’enquêtes réalisées auprès des entreprises françaises. L’étude
menée sur les Technologies de l’Information et de la Communication (TIC) inclut un volet
sur les ERP.
Le pourcentage d’entreprises équipées d’un ERP progresse chaque année (+6 % entre
2009 et 2011, +8 % entre 2011 et 2012). Selon l’institut, un tiers des sociétés de plus de 10
salariés utilise un PGI en France (2014). Encore faut-il distinguer les tailles d’entreprises :
25 % des sociétés de 10 à 19 personnes se servent d’un ERP, 40 % de celles de 20 à 249
personnes et 78 % des plus grandes.3
Ces chiffres montrent l’intérêt grandissant pour ces outils intégrés. Ils font partie du
quotidien de nombreuses entreprises industrielles françaises.
Mais toutes les entreprises ont-elles besoin d’un ERP ? En 2014, les PME n’utilisant pas
d’ERP étaient plus nombreuses que celles qui en utilisaient un. Alors comment font-elles ?
Il faut souligner que l’adoption de progiciels de gestion connaît une forte croissance. Les
réticences contre l’adoption d’un PGI deviennent moins fortes. Sur le terrain, on constate
que les PME qui n’ont pas encore fait le choix d’un ERP se servent quand même de
logiciels de gestion : gestion commerciale (devis, commandes de vente, bons de livraison,
factures), gestion comptable (comptabilité générale ou analytique, trésorerie, règlements,
immobilisations) et gestion de la paie (quand elle n’est pas sous-traitée à un cabinet). Le
tout est organisé autour d’une base clients et parfois d’une base articles. Concernant le
suivi de production et des achats de matières et de sous-traitance, encore beaucoup de
PME pratiquent le tableur et la gestion « papier ».
Posséder un logiciel de gestion commerciale ou exploiter des tableurs comme Excel®
permet déjà aux salariés de partager de l’information et de structurer les flux
informationnels de l’entreprise. C’est un premier pas vers une gestion globale
informatisée.
Les différents types d’utilisateurs
 Dans l’entreprise, on peut segmenter les utilisateurs d’ERP en trois catégories.
Tout d’abord, ceux qui saisissent les données de base : par exemple les opérateurs de
production qui scannent les ordres de fabrication terminés, ou l’administration des ventes
qui effectue des saisies de commandes. On retrouve également les commerciaux qui
renseignent les tarifs de ventes, les achats qui créent les fiches fournisseurs, ou bien les
méthodes qui renseignent les données techniques des articles.
La deuxième catégorie concerne les utilisateurs qui transforment l’information, comme
les agents de planification qui positionne les ordres de fabrication, l’administration des
ventes qui produit des factures à partir des bons de livraison.
Enfin, on retrouve les utilisateurs qui exploitent les données contenues dans l’ERP : la
direction et le management. Ces utilisateurs ont besoin de rapports, tableaux de bord,
statistiques pour suivre l’activité de l’entreprise et la piloter.
Si l’ERP touche tous les organes de l’entreprise, ce sont quasiment tous les salariés qui
sont affectés. Une nuance tout de même en production, où le management peut
délibérément choisir de faire saisir les temps par une tierce personne, les opérateurs
n’ayant donc pas directement accès à l’ERP. Cela dit, ce choix de management n’est pas
toujours fondé, car il existe aujourd’hui des interfaces de saisie en atelier à l’ergonomie
travaillée et efficace.
Enfin, il faut garder à l’esprit que plus le nombre d’utilisateurs de l’ERP est grand, plus
les étapes de validation des données seront importantes. Et la pertinence des statistiques
extraites pour le management sera dépendante de l’exactitude et de l’exhaustivité des
données saisies à la base.
Le paradigme ERP
S’il n’y a qu’une idée à retenir de la définition d’un ERP, c’est le paradigme suivant :
« Un ERP est une suite d’actions (acheter, vendre, fabriquer, expédier…) pour une
quantité d’articles donnée, pour un délai donné ». C’est aussi simple que cela. Les coûts
s’obtiennent par un calcul arithmétique à partir des quantités. Lorsque l’on demande à son
atelier de produire 50 bureaux métalliques, on lui donne un délai. Lorsqu’on sonde les
stocks pour voir si l’on peut honorer une commande client, on regarde le stock à la date
demandée.

« Un verbe, une quantité et un délai. »

Ce paradigme pourrait être enrichi d’une autre valeur essentielle. En effet, il serait injuste
de ne pas parler de la qualité. Toute action de l’entreprise doit être menée pour une qualité
souhaitée. La gestion de la qualité n’est pas l’objet de cet ouvrage.
Couverture fonctionnelle d’un ERP
La couverture fonctionnelle d’un ERP est l’ensemble des modules et des possibilités
proposés à l’intégration. Elle diffère selon les produits et évolue au fil des ans. Les ERP
intègrent de plus en plus de modules utiles à l’entreprise. Certains de ces modules ont
accumulé tellement de fonctions, qu’ils sont maintenant proposés comme des logiciels
indépendants. On peut alors s’écarter de la notion « intégrée » du PGI. On parle alors du
principe « Best of Breed » qui sera abordé plus loin (ERP monolithique ou approche
« Best of Breed » ? au Chapitre 2).
Aujourd’hui, les modules que l’on retrouve généralement en standard dans un ERP pour
PME sont :
La gestion des ventes : permet de gérer la chaîne commerciale en passant par les devis,
la saisie de commandes et l’édition des bons de livraison et des factures. On y trouve
également les fonctions de gestion des tarifs, du prévisionnel, et la gestion des contrats.
La gestion des achats : on y retrouve les fonctions symétriques à la vente (demandes de
prix, gestion tarifaire, commandes, etc.) ainsi que la gestion des réapprovisionnements.
Cela inclut aussi les achats de sous-traitance.
La gestion de la relation client (GRC ou CRM4 en anglais) : permet de gérer les fiches
tiers, et les actions associées (prospection, suivi contact…).
La gestion de la production (GPAO) : cœur de la gestion des entreprises
manufacturière, la GPAO couvre toutes les données techniques (gamme, nomenclature), le
lancement des Ordres de Fabrication (OF) et la planification. On trouve aussi la gestion
des programmes de fabrication, et le suivi de la charge et de la capacité des ateliers.
La gestion des stocks : depuis la réception des matières premières jusqu’à la
préparation des expéditions.
La gestion financière : ce module est destiné aux décideurs. Il s’agit d’un outil de
reporting combinant les informations des autres modules pour en extraire des statistiques.
La gestion comptable, de trésorerie, des amortissements : obligation pour les
entreprises, elle peut également être sous-traitée. La comptabilité peut être générale ou
analytique. Ce module n’est pas toujours présent en standard.
La gestion de la paie : obligation pour les entreprises, elle peut aussi être sous-traitée.
Comme pour la comptabilité, ce module n’est pas toujours présent en standard.
Cette liste des modules fonctionnels n’est pas exhaustive. On pourrait y rajouter la
gestion des points de vente, la gestion d’affaires de plus en plus utilisée, la gestion
électronique de la documentation, la gestion de la qualité, la gestion des ressources
humaines, le décisionnel (BI) ou bien la gestion de la maintenance pour gérer un parc
machines.
Le découpage fonctionnel et l’appellation des modules varient selon l’éditeur. Par
exemple, certains appellent « gestion commerciale » l’ensemble des modules « vente »,
« achat » et « gestion de stock ».
Quoi de neuf dans le monde des ERP ?
Certains modules, comme ceux des ressources humaines, des finances ou de la qualité,
évoluent constamment pour suivre les nouvelles exigences réglementaires auxquelles sont
assujetties les entreprises françaises.
Les ERP pour PME voient également leurs usages tirés par les ERP des grands groupes.
En effet, les innovations des uns finissent souvent par intégrer tous les progiciels du
marché.
Le Workflow
Le « Workflow » fait partie de ces concepts qui intéressent de plus en plus les PME. Il
permet de modéliser un flux de décision ou de diffusion d’information dans l’entreprise.
Par exemple, le passage d’achats pour des montants supérieurs à un seuil devrait passer
dans les mains du responsable des achats. On retrouve aussi souvent le Workflow dans le
processus de création d’articles. En effet, tous les services de l’entreprise contribuent à la
création d’un article : le bureau d’étude pour les données techniques, les commerciaux
pour la politique tarifaire, les achats dans le choix des matières premières, les méthodes
pour l’industrialisation du produit, etc. Dans ce cas de figure, le Workflow permet d’une
part de s’assurer que tous les services ont effectué leurs tâches et d’autre part de faire
circuler l’article à créer entre les personnes concernées.
L’information poussée
Le Workflow est souvent associé à une autre innovation : le mode « Push ». Les ERP
des années 80-90 fonctionnaient selon le principe suivant : celui qui voulait une
information devait aller la chercher. Une information, quelle qu’elle soit, s’obtenait donc
après un certain nombre de clics, et d’exécutions de requêtes. Le mode Push permet aux
utilisateurs de travailler autrement. Un portail d’accueil personnalisé attend chaque
utilisateur après sa connexion. Celui-ci peut d’un seul coup d’œil visualiser le résultat de
ses requêtes principales (ex. : le responsable commercial visualise le CA de la veille, le
réceptionnaire visualise les commandes attendues ce jour). L’intégration du Workflow au
mode Push permet de lister les tâches à réaliser. Pour reprendre les exemples cités
précédemment, le responsable des achats verrait les demandes d’achats à valider. Les
commerciaux verraient les articles en création dont ils doivent saisir les tarifs. Et tout ça
sans aller chercher l’information. Elle est poussée de manière individuelle et personnalisée
à chaque utilisateur.
 Aujourd’hui, les créations de Workflows s’accompagnent parfois d’outils graphiques.
Leur création sous forme de graphe (des boîtes et des flèches) est devenue très
ergonomique.
Les flux intersociétés réciproques
Les croissances externes de PME se sont amplifiées ces dernières années. Il n’est pas
rare de voir une PME de 200 salariés être en réalité composée de 4 ou 5 filiales de
typologies différentes : société commerciale, usines de production, points de vente. Dans
ce cas de figure, le point de vente passe des commandes à la société commerciale qui, elle-
même passe des commandes de production à l’usine de fabrication. Pour répondre à la
charge administrative que représentent les multiples saisies analogues d’informations, la
plupart des ERP proposent maintenant l’automatisation des flux réciproques. Il s’agit de
modéliser une fois pour toutes les flux physiques et financiers entre les sociétés du groupe,
afin de pouvoir générer en un clic toute la séquence d’opérations allers et retours. Prenons
l’exemple d’une société commerciale A qui commande à la société B 100 chaises. A passe
sa commande, B saisit la commande et effectue un accusé de réception. Dans cet exemple,
A et B saisissent tous les 2 la même commande en symétrique. Avec les flux intersociétés
réciproques, la création de la commande chez B est automatisée. C’est un gain de temps
important pour les sociétés qui gèrent beaucoup de commandes internes.
Pour terminer notre exemple, nous avons à l’identique, au moment de la livraison : B
livre A, A réceptionne la marchandise. Avec les flux réciproques, A n’aura pas à ressaisir
le BL de B. Le passage des informations aura été automatisé. Remarque : cela n’empêche
pas la société A de contrôler le BL et de le dénoncer.
La mobilité
Les fonctions liées à la mobilité concernent les commerciaux et le personnel nomade.
L’ERP étant de plus en plus riche en information, il est normal de vouloir y accéder depuis
n’importe quel endroit, y compris en dehors des murs de l’entreprise. Les commerciaux
ont besoin d’accéder aux fonctionnalités et aux données de la CRM : fiches et
portefeuilles clients ou données administratives. Le commercial est le relais de l’entreprise
avec le client. Si le service administratif a des griefs envers un client (retard de paiement
par exemple), le commercial doit avoir l’information lorsqu’il se trouve chez le client. La
mobilité est une préoccupation technique majeure. La multiplication des smartphones et
des tablettes dans les entreprises et l’amélioration des débits des réseaux mobiles ont
favorisé l’émergence de ces besoins fonctionnels. Avec ces outils, le commercial saisit ses
commandes en temps réel ou en mode déconnecté sur sa tablette, le client choisit ses
produits, et signe sa commande sur le même appareil.
Le Cloud Computing
Terme très en vogue, le Cloud Computing devrait apporter de belles innovations aux
ERP. Le mode SaaS (location d’un service hébergé au lieu de l’achat de licences) avait
déjà apporté aux entreprises une nouvelle façon d’appréhender les projets ERP. La
technologie Cloud devrait apporter une finesse supplémentaire dans la gestion des coûts
des progiciels. En effet, l’usage sera au cœur du modèle économique proposé par le
Cloud : « on ne paye que ce que l’on utilise ». D’un point de vue technologique, le Cloud
Computing permettra aussi une adaptation plus rapide des ressources disponibles
(nouveaux utilisateurs, nouveaux modules, augmentation de la taille des données, besoin
de davantage de puissance de calcul, etc.). La mobilité et ses appareils prédestinés que
sont les smartphones et les tablettes se marieront parfaitement avec un ERP hébergé dans
les nuages. À noter qu’une offre Cloud ira de pair avec un modèle économique basé sur la
location de service (SaaS). Néanmoins, aujourd’hui, ce modèle peine toujours à séduire
toutes les PME. Certains dirigeants se posent de nombreuses questions quant à la sécurité
des données et à la fiabilité de la connexion Internet de leur entreprise. L’avenir nous dira
si ces verrous seront levés.
Segmentation des acteurs de l’ERP
Avant de s’intéresser au marché français, regardons le marché mondial. La Figure 1
présente les revenus du top 15 mondial des éditeurs d’ERP. Les conclusions sont
frappantes. L’éditeur SAP® détient la moitié du marché mondial5 en nombre de licences
pour un revenu de 16 milliards de dollars (année 2010). D’autres éditeurs de la liste sont
également très présents dans les grandes entreprises françaises. On ne présente plus
Oracle®, Sage®, Infor®, Microsoft®, Lawson®, ou IFS®. Pourtant, ces acteurs ne sont pas
toujours présents sur le marché de la PME. Attention toutefois au sens que l’on donne à
PME. Il n’est pas le même en Europe et aux États-Unis. Toutes ces grandes firmes n’ont
pas la culture « PME moins de 250 salariés ».
 Figure 1 : revenus du Top 15 mondial des éditeurs (M$)6

En France, le marché est très morcelé. Le top 50 des éditeurs de logiciels nationaux est
partagé entre autres par Cegid®, Prodware®, GFI Informatique®, EBP®, Bodet®, Cogeser®,
Missler®, Proginov®7.
La PME qui cherche un nouvel ERP doit déjà comprendre la typologie des acteurs en
présence. La gestion du projet, et le type de contrat diffèrent légèrement selon le modèle
partenarial envisagé.
Modèle éditeur seul : la PME contracte avec un éditeur de logiciel qui intègre lui-
même sa solution. En France, ces sociétés ont des tailles modestes. Le partenariat est donc
équilibré avec une PME. Attention cependant aux acteurs trop petits (moins de 10
salariés).
Modèle éditeur et intégrateur : le dirigeant de la PME contracte avec un intégrateur
national, qui lui-même est habilité à revendre et à déployer des licences d’un éditeur tiers.
Les intégrateurs ont généralement une taille plus grande que les PME, souvent obtenue par
croissance externe et fusions. C’est le choix de l’éditeur d’opter pour un modèle indirect.
L’histoire nous montre que ce choix de modèle n’est pas irrévocable pour l’éditeur.
Modèle développeur spécifique : fait très rare, mais existant (moins de 3 % des cas
selon Panorama Consulting Group), certaines PME ont fait le choix de développer ou faire
développer un ERP spécifique. Il s’agit de partir d’une feuille blanche et de définir son
besoin. En PME, un projet complet peut ainsi durer 5 ans et comporte des risques très
élevés. Le partenariat avec le développeur doit être infaillible. Ce genre de projet doit être
envisagé seulement si le marché existant ne répond pas au besoin émis.
Modèle open source : encore très peu répandus, les ERP open source ont pourtant une
carte à jouer en PME. Les logiciels sont peu nombreux, mais il existe une multitude de
SSLL8 réparties sur le territoire. Ces sociétés sont généralement de petite taille, du fait de
leur adhésion à la philosophie du monde libre. Ce modèle partenarial est à mi-chemin
entre le développement spécifique et l’intégration.
Pour quel modèle opter ? Plusieurs facteurs entrent en jeu. C’est d’abord le produit, sa
fiabilité, sa pérennité qui doivent guider votre choix. Ensuite vient le modèle : direct ou
indirect. Le rapport de force est plus équilibré avec le modèle éditeur seul. Les demandes
d’évolution du logiciel sont davantage entendues. Un gros client peut même influencer le
développement du standard d’un logiciel.
L’inconvénient c’est que si l’éditeur est petit, rien n’est certain sur son avenir. Pour
preuve, voici 2 exemples réels.
En 2011, l’éditeur français indépendant « Softmatic » (nom fictif) s’est fait racheter par
un éditeur plus gros. Dans un premier temps, les clients installés se sont vus promettre du
support pour 2 années supplémentaires. En réalité, le support était inexistant, le repreneur
essayait juste de placer sa solution à lui. Les utilisateurs, tous des PME, ont dû dans
l’urgence lancer un projet de renouvellement de leur ERP. Certaines PME se sont
regroupées en association pour exiger du repreneur un minimum de service.
Autre cas dramatique : après des choix stratégiques douteux, l’éditeur « LogicéCo »
vend ses actifs à un fonds d’investissement actionnaire de son plus gros client. Les
développeurs sont presque tous licenciés puisque le gros client avait déjà ses propres
ressources internes. Les derniers ingénieurs ne travailleront plus que sur le spécifique de
leur nouveau patron. Les anciens clients de l’éditeur ne font pas partie de la nouvelle
stratégie du fonds d’investissement.
Les intégrateurs sont généralement des structures de taille plus importantes. Mais les
risques de fusion-acquisition sont tout aussi présents. Cela dit, l’intérêt du modèle indirect
est que l’on peut théoriquement changer d’intégrateurs sans changer d’éditeur. Je parle
évidemment de la période préimplantatoire, car c’est beaucoup plus difficile après le choix
de l’intégrateur (surtout en présence de verticaux métiers). Par contre, cela reste vrai avec
le modèle open source, avec lequel vous êtes libre de continuer les développements avec
une autre SSLL (si tant est que les règles de codage et de documentation du code aient été
respectées).
Pour se valoriser, les intégrateurs mettent souvent en avant les certifications obtenues
 auprès des éditeurs. Elles attestent du lien fort entre l’intégrateur et l’éditeur. Mais, il ne
s’agit ni d’un label reconnu ni d’une certification de type ISO.
Le consultant
Tout comme dans l’industrie du bâtiment, un client peut choisir de faire appel à un
conseiller (architecte). Ce n’est pas obligatoire, mais son expérience et sa maîtrise du sujet
vous emmèneront plus loin tout en évitant les sentiers périlleux.
Un consultant intervient soit en tant qu’indépendant, soit en tant que salarié d’une
société. Dans tous les cas, il est important de s’assurer de sa neutralité. En effet, certains
consultants peu scrupuleux obtiennent une commission de la part de l’éditeur qu’ils ont
placé chez leur client. Ils sont donc payés deux fois : une fois par le client pour l’aider
dans son choix, et une fois par l’éditeur par commissionnement. Ces pratiques vont
jusqu’à verser 10 % du prix des licences au consultant.
Le conseil peut se découper en 2 grandes phases. La première phase consiste à
accompagner l’entreprise en amont de la sélection d’un ERP. Il s’agit pour le consultant
d’aider l’entreprise dans la refonte de ses processus, dans la formalisation du besoin, dans
l’analyse et la sélection des offres ou encore dans la relecture du contrat final. Ces étapes
seront détaillées plus loin dans cet ouvrage.
La deuxième grande phase commence après la signature du contrat avec le prestataire
retenu. Le consultant prend sa casquette d’assistant à maîtrise d’ouvrage (AMOA). Il
assiste l’entreprise dans la mise en œuvre de l’ERP choisi. Son regard extérieur à
l’entreprise permet d’éviter les dérives et de valider les choix stratégiques et les options
d’implémentation. Il s’assure aussi de la gestion des risques et de la gestion du
changement. Enfin, il veille sur l’implication de la direction pendant toute la durée du
projet.
Une bonne pratique consiste à sélectionner un consultant qui dispose de compétences et
d’expériences dans votre métier. Il sera plus à même de guider votre entreprise dans
l’organisation des processus le cas échéant. Reste à trouver cette perle rare, à la double
compétence métier et conduite de projet ERP.
Le coût du conseil externe représente en moyenne 10 % du coût total du projet.
Résumé
Pour gérer son activité, une PME a besoin de la même couverture fonctionnelle qu’un grand
groupe, sans toutefois en avoir ni les moyens financiers ni les ressources humaines.
Un ERP permet d’enregistrer l’activité de l’entreprise selon le paradigme « Verbe, Quantité,
Délai ». Après transformation, l’information peut être consolidée en statistiques pour
suivre et piloter l’activité de la société.
Différents modèles partenariaux coexistent : une PME peut contracter auprès d’un éditeur,
d’un intégrateur ou d’un développeur.
La complexité des projets ERP et le manque de ressource interne amènent souvent la
direction des entreprises à se faire accompagner par un consultant expérimenté.

[2]
Notions d’architectures
Composantes du système d’information
Ce chapitre est le plus technique de cet ouvrage. Derrière les architectures de systèmes
d’information (SI) présentées, il aborde les questions que doivent se poser les entreprises
au moment du choix.
De plus en plus de PME, même industrielles, prennent conscience que leur système
d’information est leur premier outil de production. Le SI doit permettre aux PME de
garder souplesse et réactivité. L’ERP tient une place centrale dans l’informatique des
entreprises.
Les ERP pour PME ont une couverture fonctionnelle plus ou moins grande, plus ou
moins packagée. Même si l’ERP peut en être le pivot, il n’est pas l’unique composante
d’un SI. Autour de celui-ci, peuvent graviter un certain nombre d’outils périphériques
spécialisés. A noter que les gros ERP peuvent intégrer ces outils dans leur couverture
fonctionnelle. Voici une liste non exhaustive d’outils connectés aux ERP :
Groupware : il s’agit des outils de travail collaboratif et de communication
(messagerie, calendriers partagés). Ces outils sont souvent connectés aux ERP pour
l’envoi d’e-mail ou la synchronisation des tâches dans les calendriers.
WMS : Warehouse Management System. Ces outils logiciels sont dédiés à la gestion
d’entrepôts. On les trouve surtout dans les entreprises ayant une grande activité logistique.
MES : Manufacturing Execution System. Permet de suivre l’activité des lignes de
production en temps réel. On trouve ces logiciels dans les entreprises ayant une fabrication
continue comme dans l’industrie agroalimentaire par exemple. Le MES peut injecter des
données dans l’ERP.
CRM : Customer Relationship Management (Gestion de la Relation Client ou GRC).
Applicatifs gérant l’activité avec les prospects et les clients (suivi des échanges, suivi
clientèle, aide à la prospection, etc.). La CRM est synchronisée à l’ERP par les identifiants
clients.
GMAO : Gestion de la Maintenance Assistée par Ordinateur. Cet outil permet de suivre
spécifiquement le parc machines, planifier la maintenance préventive, gérer les stocks de
pièces détachées… Il peut échanger les calendriers de disponibilité machines avec un ERP.
GRH : Gestion des Ressources Humaines. Comme son nom l’indique, cet applicatif
permet de gérer les salariés, les congés, les formations, les accréditations, etc. Il
s’interface à l’ERP avec l’identifiant des ressources.
Point de vente : Ces logiciels équipent des magasins et permettent la gestion de la
caisse, d’un stock, de cartes de fidélité, etc.
E-commerce : Ces applicatifs web mettent en vitrine les produits de l’entreprise. Des
passerelles informatiques synchronisent les commandes et les stocks avec un ERP.
Comptabilité, paie : Ces logiciels sont couplés aux ERP par les identifiants clients ou
salariés. L’échange d’information peut se faire dans les deux sens.
ERP monolithique ou approche « Best of Breed » ?
Dans un monde idéal, on pourrait imaginer un ERP à la couverture fonctionnelle si large
et si complète qu’il permettrait de se passer de l’acquisition de tout autre logiciel. Mais
toutes les entreprises n’ont pas les moyens ni les ressources suffisantes pour déployer le
numéro un des ERP : SAP® (qui cela dit n’est pas exempt de défaut). En réalité, on se rend
compte que dans certains cas, un ERP seul ne peut suffire à remplir tous les traitements
informatiques nécessaires à l’entreprise.
En effet, les modules intégrés aux ERP sont souvent moins développés que des logiciels
dédiés correspondants. Par exemple, la CRM intégrée d’un ERP satisfera bon nombre de
PME. Mais si l’entreprise a une forte activité de prospection téléphonique, elle devra opter
pour un logiciel spécialisé en CRM. Se pose alors la question de l’interfaçage entre les
composantes ERP et CRM. Il faut proscrire toute duplication manuelle des comptes
clients. L’informatique permet des synchronisations et des automatismes, il faut en
profiter.
Mais si les deux logiciels sont édités par des éditeurs différents, lequel endossera la
responsabilité de la passerelle de synchronisation ? Cette question est récurrente dans les
projets ERP. On la retrouve aussi dans le cas d’un projet ERP avec une vitrine e-
commerce.
Commence alors une partie de ping-pong dont le client est l’arbitre. Les problèmes de
synchronisation dus à des changements de format d’échange de données sont très
fréquents et sont des pertes de temps et d’énergie pour les PME. La meilleure chose à faire
est d’exiger du partenaire principal (ERP par exemple) qu’il prenne en charge l’intégralité
du projet. Il fera l’interface avec l’autre prestataire en devenant votre guichet unique.
Tous n’accepteront pas. Il s’agit là d’un élément de négociation.
 « Best of Breed » signifie : « prendre le meilleur dans chaque domaine ». Il y a un
domaine où cette approche duale est très commune en PME : celui de la comptabilité. Ce
module en particulier est souvent laissé aux spécialistes de par ses évolutions liées à la
législation. Les logiciels de comptabilité pour PME sont très répandus, et les principes
d’échange se sont standardisés. Le transfert de données entre un ERP et une comptabilité
peut se faire en statique ou en dynamique. En statique, l’ERP, après intervention manuelle,
crée un fichier d’échange contenant les informations de facturation. Puis, toujours
manuellement, depuis la comptabilité, on importe ce fichier d’écritures. Il est aussi
possible dans l’autre sens de remonter les règlements clients. En connexion dynamique,
l’ERP peut échanger directement avec le logiciel de comptabilité et envoyer les données
directement dans sa base de données sans intervention humaine. Ces passerelles
automatiques ont souvent un coût plus important.
L’approche monolithique a l’avantage de rendre la création d’états et de requêtes plus
simple. De même, la maintenance d’un seul outil est plus simple à gérer que celle de
multiples logiciels. Par contre, certains modules de l’ERP peuvent avoir des
fonctionnalités trop basiques (CRM, GMAO). À l’opposé, l’approche « Best of Breed »
apporte des logiciels aux fonctionnalités performantes, mais cela implique une gestion des
synchronisations pour éviter toute ressaisie inutile. Par exemple, le nombre de processus
à synchroniser peut atteindre les 15 dans le cadre d’un échange ERP – WMS.
À ce propos, il faut bien comprendre que le problème de la synchronisation entre
logiciels n’est pas uniquement technique. Prenons l’exemple d’une entreprise disposant
d’un bureau d’étude interne, produisant des plans et des nomenclatures. Il est souvent
demandé aux ERP d’importer ces données techniques issues du logiciel de CAO
(Conception Assistée par Ordinateur). Une fois la question technique de l’import des
données réglée, il faut organiser le processus de modification de ces données. En effet, si
quelqu’un modifie directement la nomenclature importée, les informations ne sont plus
synchrones avec les plans de la CAO. La gestion de versions est devenue caduque. Un
scénario d’utilisation doit être défini précisément dès qu’une passerelle de synchronisation
de données est mise en œuvre. L’idéal étant évidemment d’avoir une passerelle
bidirectionnelle.
ERP généralistes, verticaux et applications métiers
Après avoir opté pour l’approche intégrée ou « Best of Breed », le dirigeant de PME va
être confronté à différents types de positionnement des solutions de gestion.
D’un côté les généralistes qui prétendent pouvoir adapter leur ERP standard à
n’importe quel cas d’entreprise. Certains de ces généralistes se sont spécialisés dans un
métier et ont développé des fonctions spécifiques au-dessus d’ERP généralistes (ex. :
métier du recyclage industriel). On appelle ce genre d’application spécialisée un vertical
 métier. Il s’agit ni plus ni moins d’un ERP généraliste dans lequel l’intégrateur a
développé lui-même des fonctionnalités métiers. Enfin, troisième catégorie, un éditeur
spécialisé dans un métier particulier (exemple : les industries agroalimentaires) développe
et commercialise un ERP dédié à ce métier.
Prenons l’exemple de l’entreprise « Chocolove», une chocolaterie industrielle de 200
salariés. Celle-ci a le choix entre 3 positionnements d’ERP :
des ERP généralistes, car « Chocolove» a les mêmes besoins que n’importe quelle autre
entreprise industrielle,
des verticaux métiers d’intégrateurs spécialisés dans les industries agroalimentaires,
des applicatifs métiers spécialisés dans les industries agroalimentaires.
Les ERP généralistes sont parfois appelés des horizontaux par opposition aux verticaux
qui ont une teinte sectorielle.
Faut-il choisir un ERP propre à son métier ?
Cette question est loin d’admettre une réponse unique et évidente. Premier constat : les
applicatifs métiers d’éditeurs sont souvent plus chers que les généralistes de par une plus
grande intégration des processus métiers et une plus grande richesse fonctionnelle.
Concernant les verticaux implantés sur des généralistes, ils permettent une mise en œuvre
beaucoup plus rapide (le paramétrage est en partie déjà fait) et donc à des coûts moins
élevés qu’un généraliste.
Mais c’est surtout la philosophie de chaque type de logiciel qu’il faut prendre en
compte. Dans le cas d’un généraliste, c’est l’entreprise qui doit tendre vers un
fonctionnement standard. Avec un ERP métier, c’est davantage l’outil qui vient s’adapter
au fonctionnement et à la nature même de l’entreprise. Essayer de coller à des standards
est loin d’être une mauvaise chose en PME. Toutes les entreprises manufacturières
achètent, transforment et vendent des produits. Même avec un ERP généraliste, l’effet
structurant peut être obtenu. De plus, les entreprises évoluent et leurs métiers aussi. Il ne
faudrait pas s’enfermer dans un fonctionnement particulier. D’autre part, il vaut mieux
miser sur un vertical métier que de partir sur un développement spécifique pour combler
des manques fonctionnels.
Répondre à des besoins spécifiques
Les dirigeants estiment parfois que leur entreprise est gérée comme n’importe quelle
autre PME. En s’intéressant aux détails fonctionnels des ERP, ils vont très vite se rendre
compte que certains de leurs besoins relèvent de la spécificité. Par exemple, demander à
son prestataire que l’ERP calcule les « taux de COV émis » n’est pas encore une fonction
standard. Si le logiciel ne dispose pas de cette fonctionnalité, l’éditeur ou l’intégrateur
peut proposer un développement spécifique.
Si le besoin est susceptible d’intéresser d’autres entreprises (comme les « COV émis »),
le prestataire peut proposer de prendre à sa charge une partie des frais de développement.
Sinon, le client devra payer cette nouvelle fonctionnalité. Pour information, un
développeur confirmé est vendu entre 800€ et 1000€ la journée. Si votre liste de
spécifiques est longue, la note risque d’être salée. Sans compter les recettes, les
éventuelles mises au point et corrections de bogues.
Le problème du spécifique c’est qu’il vient se greffer sur un standard qui va évoluer.
Comment faire cohabiter un spécifique pour un client donné avec des fonctions
évolutives destinées à plusieurs entreprises ? Malheureusement, tous les éditeurs ne savent
pas répondre de manière qualitative à cette problématique. La réponse se trouve du côté de
la technologie de développement employée et de l’architecture logicielle. Ces choix sont
faits en amont des développements et sont irrévocables, à moins de redévelopper tout
l’ERP.
En PME, les spécifiques ne doivent être utilisés qu’en dernier recours, ou si l’éditeur
démontre sa maîtrise de ce type de développement. Il reste toujours pour l’entreprise, la
possibilité de maintenir un tableur en marge de l’ERP, en attendant une implémentation de
la fonction désirée. D’ailleurs, certains éditeurs d’ERP refusent catégoriquement de
rentrer dans le jeu des développements spécifiques. Même si ce raisonnement semble
présenter quelques limites, il a l’avantage d’offrir une solution logicielle plus pérenne et
plus fiable dans le temps ; l’éditeur ne maintient alors qu’une seule version de son
progiciel, commune à tous ses clients. Dans ce cas, l’éditeur mise toute l’intégration de
son progiciel sur le paramétrage. Nombreux processus métiers, a priori spécifiques,
trouvent une adaptation à travers un paramétrage adéquat, grâce notamment à l’ajout de
champs personnels dans les tables de la base de données ou par la mise en œuvre de
Workflows.
Un sondage de 2015 (voir ci-après) nous enseigne que dans les deux tiers des projets
ERP, le spécifique a une place mineure. Les projets où plus de 25 % du code source est
modifié ne représentent que 34 % des cas.
 Figure 2 : ratio de développement spécifique dans un ERP9

Exemple d’ERP spécifique

Les ERP spécifiques ne représentent à l’échelle mondiale que 3% des projets. La société
« DNX », spécialisée en chaudronnerie, fait partie de cette minorité. Le PDG, homme de
terrain très proche de la production, avait investi dans un ERP ultra-robuste propriétaire.
Celui-ci a fonctionné 20 ans, sans un seul bogue. Mais le système est devenu obsolète et
les compétences rares. Alors que l’entreprise croît et s’affirme dans son métier, l’ERP
n’évolue plus. L’outil de gestion n’est plus à la hauteur des ambitions de l’entreprise, il est
devenu urgent de changer de système. Rien de plus facile que d’éteindre un vieux serveur,
mais par quoi le remplacer ? Le PDG connaît bien le milieu industriel de sa région et
entend régulièrement d’autres responsables de PME se plaindre du mauvais
fonctionnement de leurs ERP. Il n’est pas dans la nature du dirigeant de DNX de faire
confiance à un éditeur inconnu. Par contre, il a tissé une relation sincère avec le prestataire
informatique historique. De plus, il ne voyait pas comment gérer les particularités de ses
réseaux de ventes avec les outils logiciels du marché. Pour le PDG, tout était clair :
l’avenir de l’informatique de DNX passerait par le prestataire historique. Celui-ci n’est ni
intégrateur ni éditeur d’ERP. Il connaît le matériel, les réseaux, le développement logiciel
autour du Framework .Net® et surtout la gestion industrielle. La page était encore blanche,
le prestataire allait commencer le codage d’un nouvel ERP.
Le projet débuta par la gestion commerciale. La mise au point dura 2 ans. Mais au final,
les processus commerciaux étaient entièrement reproduits. Le logiciel collait comme un
gant à la main. Restait le cas de la gestion de production. Durant ces 2 années, la
planification et le calcul des besoins se faisaient sur Microsoft Excel®, l’ancien ERP ayant
été stoppé. Le prestataire se sentait tout de suite moins à l’aise avec la GP qu’avec la
Gestion Commerciale. Pourtant l’attente des utilisateurs était grande. Il fallait avancer.
Deux verrous étaient à lever. D’une part, il fallait faire monter en puissance le
prestataire sur le thème de la gestion de production. D’autre part, il était nécessaire de
conseiller DNX sur les choix d’implémentation à faire. Un expert fut consulté sur ces deux
sujets : un éditeur d’ERP qui a bien voulu faire part de son expérience et de la dizaine
d’années de R&D qu’il avait à son actif.
Premiers constats de l’expert : la structure des tables doit être revue pour permettre
l’ajout d’une GPAO. Ce travail fut long et complexe. L’expert et les équipes du prestataire
durent entrer dans le détail des tables et des vues qui composent la base de données de
l’ERP. Une fois les fondements en place, le développement de la GPAO pouvait
réellement commencer. Les premières estimations prévoient un échelonnement de ce
travail dantesque sur 4 années.
Opter pour un ERP développé spécifiquement n’est pas une décision légère. Le
sentiment d’avoir un ERP « en chantier » est nettement plus long que dans le cas d’un
ERP du marché.
Un ERP gratuit
Derrière ce titre provocateur se cache une catégorie de logiciels dits « open source » ou
« libres » en français. On les oppose aux logiciels propriétaires. Un ERP open source est
un ERP dont le code source est accessible librement. Il est également modifiable et
redistribuable librement (dans les mêmes conditions que la licence d’origine).
Il est donc possible de télécharger les sources d’ERP comme OpenERP, Compiere,
Neogia, ou ERP5 gratuitement, de les installer, de les modifier, puis d’utiliser le logiciel
sans payer de licence.
En théorie, tout cela est possible et permet un déploiement ERP à moindre coût. En
réalité, une fois l’étape du téléchargement passée, il faut être informaticien pour installer
et configurer les aspects systèmes du logiciel. Ensuite, la modification du code source ne
s’improvise pas. On parle de centaines de milliers de lignes de code (voire 1 million).
Développer sur un ERP open source nécessite une vraie formation et une longue
expérience. C’est un vrai métier, et ce n’est sans doute pas le vôtre.
Par contre, il est tout à fait possible de trouver des partenaires qualifiés pour ces tâches.
L’offre qu’ils vous feront ne mentionnera aucuns frais de licences (sauf s’ils y ajoutent
des composants propriétaires), mais seulement des frais de prestations et de formations.
Les moteurs de base de données sont eux aussi issus du monde libre (ex. : mySQL,
postgreSQL). Les ERP open source sont quasiment tous développés en mode full web et
sont donc utilisables à travers n’importe quel navigateur internet. Ceux-ci proposent des
sites de démonstration en ligne, il est donc possible de se faire une idée avant de contacter
un spécialiste. Sachez enfin que vous êtes libres de changer de prestataire à tout moment
puisque vous disposez du code source de votre ERP même s’il a été modifié. Sauf
négociation contraire, les évolutions apportées pour votre usage seront redistribuées à la
communauté. C’est ainsi que se développent et qu’évoluent les logiciels open source.
Ce n’est pas tant le coût du projet qui fera pencher la balance pour l’open source, car les
adaptations à prévoir sont souvent très nombreuses. Les budgets risquent d’être très
proches d’un projet avec un ERP propriétaire, du moins pour la première année. De plus,
d’un point de vue fonctionnel, il faudra faire attention au module de gestion de production,
souvent très limité dans les ERP open source.
L’open source est avant tout un état d’esprit, une philosophie. Comme pour les logiciels
propriétaires, l’expression du besoin et le choix du bon partenaire technique restent
cruciaux.
Exemple d’un projet open source
Les ERP open source ne sont pas encore très répandus dans les PME françaises. La
méconnaissance de ce marché est principalement liée au manque de visibilité et de
communication des acteurs du libre. Le modèle économique et la philosophie qui en
découlent sont également mal compris ou mal acceptés des industriels. Le manque de
fonctionnalités en gestion de production n’aide pas non plus ces outils à entrer dans les
PMI.
Les exemples sont donc plus fréquents dans les entreprises de service ou de négoce. La
couverture fonctionnelle des ERP libres prend tout son sens dans les organisations où il
n’y a pas de production. Prenons l’exemple de « l’APLP » (Association Pour Les
Professionnels) qui a un fonctionnement proche d’une organisation syndicale. Son activité
consiste à informer les entreprises, à former les salariés, et à initier des projets
collaboratifs. Pour gérer cette activité, l’association a besoin d’un petit ERP (ou d’une
CRM étendue). L’APLP dispose d’un parc machine sous Mac OS®, un choix historique
qui limite les possibilités, car la plupart des ERP du marché s’installent en environnement
Windows® (du moins jusqu’à l’avènement des clients légers). L’aspect multiplateforme
des applications full web open source est donc un argument favorable. L’APLP a pu
comparer des offres de logiciels propriétaires et des offres de logiciels libres. Si les
investissements étaient comparables, l’association devait choisir entre un logiciel livré clef
en main qui a fait ses preuves (licence commerciale) et un outil moins mature qui saurait
s’adapter à toutes ses spécificités (licence open source). Après une étape de
démonstration, l’APLP a finalement opté pour l’offre open source proposée par une
société de service. Les spécificités de l’organisation ont rapidement été analysées et mises
en œuvre dans l’ERP.
Finalement, le modèle économique n’aura pas été différenciant dans ce projet. Les
investissements étaient du même ordre dans les 2 offres commerciales. Seules l’ouverture
du produit, sa richesse fonctionnelle et sa compatibilité technique ont pesé dans la balance.
Client léger, client lourd
Les ERP sont des applications clients-serveur : un parc de postes de travail (les clients)
se connecte à une application et une base de données centralisées sur un (ou plusieurs)
serveur(s). Le serveur est localisé physiquement dans l’entreprise ou externalisé.
Historiquement, l’intelligence de calcul était répartie entre les clients et le serveur. On
parlait alors de clients lourds. Le client lourd nécessite une installation sur chaque
machine utilisatrice, et les calculs font intervenir le processeur et la mémoire du poste de
travail.
L’avènement du web a eu un effet majeur sur les technologies de développement
logiciel. Depuis quelques années, il est possible de mettre au point un applicatif soit sous
forme de client lourd pour une machine cible (compilé en code machine ou interprété),
soit de concevoir ce même applicatif pour être utilisé à travers un navigateur internet.
L’exemple le plus parlant est celui de la messagerie e-mail : vous pouvez utiliser un
logiciel dédié sur votre ordinateur, ou bien consulter vos e-mails sur le site web de votre
hébergeur.
Aujourd’hui, certains ERP proposent ce mode full web. C’est le cas notamment des ERP
open source, mais aussi de certains ERP propriétaires développés avec les technologies
adéquates.
Le navigateur internet devient alors un client léger, c’est-à-dire que toute l’intelligence
de calcul se trouve sur le serveur. La partie cliente n’étant là que pour interfacer l’ERP
avec l’utilisateur (restitution d’un affichage, prise des commandes clavier et souris). Les
clients légers peuvent s’installer sur des machines (ordinateurs, tablettes, smartphones)
moins puissantes que les clients lourds.
L’intérêt majeur du mode léger réside dans la simplicité des mises à jour applicatives.
En effet, puisque tout se passe côté serveur, il n’est pas nécessaire de déployer la nouvelle
version d’un ERP sur le parc client.
Les limites du mode full web concernent davantage l’aspect visuel et ergonomique, qui
se cantonne aux possibilités offertes par un navigateur internet. Mais les technologies web
évoluent vite, et il est maintenant possible de rajouter un peu d’intelligence côté client
(ajax, script). Par exemple, on trouve des applications bureautiques en ligne à l’ergonomie
très proche d’une application lourde. On parle alors de clients légers enrichis (ou clients
riches).
La simplicité de gestion du parc client, la possibilité d’utiliser l’applicatif depuis une
tablette, sont des arguments en faveur de la technologie full web. Par contre, il faut bien
s’assurer que l’ergonomie et les performances de l’application sont au rendez-vous. Cela
dit, c’est souvent la couverture fonctionnelle qui prime sur les aspects convivialités.
Louer son ERP
Les premières licences de logiciel sont apparues avec l’avènement de la micro-
informatique. La licence est un contrat d’utilisation qui ne confère en aucun cas la
propriété du logiciel au client. La licence d’utilisation se calcule généralement par nombre
d’utilisateurs. Elle représente une part des frais de R&D que l’éditeur a eu durant la
conception du produit.
L’explosion des réseaux de télécommunications a poussé les éditeurs à imaginer de
nouveaux services pour leurs clients. Il est maintenant possible pour une entreprise de se
débarrasser complètement de la gestion de l’informatique (plus aucun serveur à gérer) et
des responsabilités qui lui sont liées.
Avec la location, on n’achète plus de licence, l’éditeur est là pour proposer un service.
Ce mode de commercialisation s’appelle le SaaS10 ou Software as a Service (logiciel en
tant que service). Le serveur est hébergé à l’extérieur de l’entreprise. L’hébergeur propose
alors un contrat d’engagement de service. C’est maintenant lui qui est responsable de la
sécurité des données, de la disponibilité et de la continuité du service. La mise à jour des
logiciels et les mises à niveau du matériel se font chez lui.
Toutefois, l’externalisation comporte des risques. Certains dirigeants sont frileux à
l’idée de voir toutes les données sortir de l’entreprise. Mais le plus gros risque n’est pas là.
Il concerne l’accès au service par le réseau de télécommunication. Si la fourniture de
service Internet tombe en panne, l’entreprise perd son accès à son ERP le temps de ladite
panne. L’accès à Internet devient le cordon ombilical de la société. Il est crucial de choisir
les bonnes technologies et les bons services pour garantir une connexion fiable et
constante. C’est pourquoi, il faut privilégier des réseaux de type SDSL, fibre optique ou
ligne dédiée lorsqu’on opte pour un ERP en mode SaaS. Certains hébergeurs proposent
également des services de télécommunications, pour garantir un niveau de service de bout
en bout.
Une autre solution consiste à redonder la connexion à Internet grâce à deux
technologies différentes. Des modems intelligents permettent de basculer sur l’une ou
l’autre des connexions en cas d’indisponibilité du service.
Sur l’aspect financier, il faut bien comprendre la différence fondamentale. Une licence
de logiciel représente un investissement amortissable. Une location de service quant à elle,
se retrouve dans le budget de fonctionnement de l’entreprise. On constate généralement
que le coût des mensualités est calculé à partir d’un amortissement des licences sur 3
années. Avant 3 ans, il est donc plus intéressant financièrement de louer un logiciel. Par
contre sur du long terme, l’investissement de licences est préférable. Ce choix de modèle
économique revient au PDG et au DAF de l’entreprise.
Une offre de location de logiciel comprend une partie hébergement pure (ressources
matérielles et système), et une partie pour l’offre fonctionnelle. Ce genre de prestation est
souvent assorti d’une durée d’engagement allant de 36 à 72 mois. Ceci peut être un
argument de négociation.
Ci-après figure un exemple d’offre pour un ERP en mode hébergé. L’entreprise
« MétaloSAS », 150 salariés et 12M€ de chiffre d’affaire, sous-traitante en tôlerie et
chaudronnerie pour l’aéronautique et le ferroviaire souhaite bénéficier d’une formule
externalisée. Cet exemple ne reprend qu’une partie de l’offre. N’apparaissent pas
notamment les options et la prestation initiale. L’offre prévoit en plus des accès à l’ERP,
un abonnement à un service de communication. Le cordon ombilical de MétaloSAS – sa
connexion Internet – fait partie intégrante de l’offre. En outre, les applications de
bureautique et de messagerie seront elles aussi hébergées par le même prestataire.
L’entreprise MétaloSAS devra donc s’acquitter d’une mensualité de 10k€ pour
permettre à ses 64 utilisateurs d’exploiter l’ERP choisi. Ce coût est loin d’être négligeable,
mais à ce prix, MétaloSAS se désengage de toute responsabilité vis-à-vis de
l’informatique et des télécommunications. La PME n’a par exemple pas besoin d’un
informaticien, ni d’administrer un serveur en interne, ni même de gérer les évolutions
matérielles et logicielles.
Contrat de fourniture
d’applications hébergées (ASP)
Client : MétaloSAS
Durée de l’engagement : 72 mois
Période d’engagement : à partir du 1er janvier 2015

Qté P.U. Prix net

mensuel mensuel

ERP, maintenance incluse, Système Microsoft, Administration, Bureautique, Messagerie, Accès 50 160 € 8000 €
Internet

ERP, maintenance incluse, Système Microsoft, faible utilisation 14 110 € 1540 €

TOTAL 9540€

Figure 3 : extrait d’une offre en mode SaaS

Résumé
L’entreprise a tout intérêt à minimiser les développements spécifiques, car ils demandent une
grande maîtrise dans la gestion des évolutions. La plupart des PME peuvent se limiter à
des fonctions standards.
Il existe des ERP libres (open source). Ce modèle économique ne prévoit pas de coût sur les
licences, mais ces logiciels sont fonctionnellement moins aboutis. L’investissement initial
est souvent comparable à celui des logiciels propriétaires.
L’entreprise a le choix entre investir dans des licences d’utilisation ou louer un ERP sous la
forme d’un service. Tous les éditeurs ne proposent pas cette alternative. Mais il s’agit
d’une tendance qui se généralise.

[3]
Coûts et délais
de mise en œuvre
Notion de TCO (Total Cost of Ownership)
Pour aborder la notion du coût d’un ERP, il est important d’avoir une vue complète de
tous les coûts directs et indirects inhérents à la mise en œuvre et à l’exploitation d’un ERP.
Lorsqu’on vous demande combien vous coûte votre voiture, vous ne donnez pas
uniquement le prix d’achat, vous avancez aussi l’entretien, le carburant, l’usure, etc. Pour
un ERP, c’est la même chose.
Dans le jargon informatique, on parle du « Coût Total de Possession » (TCO ou Total
Cost of Ownership). Le TCO s’applique à toutes les briques du système d’information de
l’entreprise, logicielles comme matérielles.
Prenons un exemple simple. Une petite entreprise a besoin d’un nouvel ordinateur
portable. Pour limiter les dépenses, elle décide d’acheter ce PC dans la grande distribution.
Celui-ci est équipé du système d’exploitation « Windows® 10 édition familiale ». Ayant
des soucis pour l’intégrer au réseau de l’entreprise, il est décidé d’effectuer une mise à
jour vers la version « entreprise » du système d’exploitation.
Bilan :
Le prestataire prend 150€ pour le dépannage
Coût de la licence de mise à jour : 240€
Il faudrait aussi chiffrer l’immobilisation du PC (perte de productivité).
Conclusion, on obtient un coût très supérieur à l’économie initiale faite lors de l’achat.
 À travers cet exemple, on peut comprendre que le véritable coût de possession d’un
ERP va être difficile à mesurer. Ceci est d’autant plus vrai que l’ERP évolue sans cesse
pour accompagner l’entreprise dans son changement. Ce qui est certain, c’est que le TCO
d’un ERP est très loin du simple prix d’achat des licences. La répartition du coût de
possession d’un ERP se répartit11 généralement de la manière suivante :
Licences : 15 à 50%
Matériel : 10 à 20%
Intégration : 35 à 80%
Maintenance : 15 à 25%
Bien entendu, l’aspect licence ne concerne pas les ERP en mode SaaS. Dans ce cas, les
coûts fixes de licences sont transformés en coûts récurrents d’accès au service. La
maintenance fait aussi partie des coûts récurrents et ne s’applique pas au mode SaaS où
elle sera diluée dans la mensualité.
L’intégration reste le plus gros poste du TCO. Il représente à lui seul 1 à 3 fois le prix
des licences et englobera la majeure partie de l’effort interne.
Coûts sur le cycle de vie et ROI
Analysons à présent les coûts durant le cycle de vie d’un projet ERP. Voici une liste non
exhaustive des postes de dépense que l’on retrouve dans le cas d’un ERP installé sur site.
Avant Projet : conseil extérieur, temps passé par les salariés en analyse du besoin et en
réunions.
Mise en œuvre : achat de licences, coût de la formation des utilisateurs, temps passé par
les salariés (analyse, reprise des données, formation, essais, etc.), prestation de
l’intégrateur retenu (analyse, paramétrage, personnalisation, développements spécifiques),
mise à niveau des ordinateurs et serveurs existants, frais de déplacement, de bouche et
d’hébergement du prestataire, achat de matériels divers (douchettes, tablettes, etc.), coût
de l’assistance à maîtrise d’ouvrage (AMOA).
Exploitation : coût du support, de la maintenance, coût des éventuels déplacements sur
site, coûts des mises à jour, formation de nouveaux utilisateurs, remplacement du matériel,
coût d’administration du SI, nouvelles requêtes et nouveaux états, etc.
Les coûts d’exploitation sont récurrents tant que l’application est utilisée. A ce sujet, il
est important de bâtir un tableau des coûts sur les 3 ou 5 premières années d’exploitation
pour comparer des solutions.
Une fois ces coûts connus (même approximativement), il est légitime pour le dirigeant
de se demander quel sera son retour sur investissement (ROI). D’ailleurs, c’est peut-être la
première question qu’il se posera. Mais le ROI est encore plus difficilement maîtrisable
que le TCO. La difficulté vient de la nature même des gains qui peuvent être très
différents. Certes, l’amélioration de la productivité administrative peut se mesurer sur
certains processus, mais la suppression de tâches sans valeur ajoutée n’est pas toujours
chiffrable.
Prenons l’exemple d’une entreprise qui souhaite ajouter une extension à son ERP pour
automatiser la saisie des temps de production. Cette tâche était initialement manuelle, et
effectuée par une personne des services administratifs. L’opération de saisie lui prenait 2 à
3 heures par jour. Avec la nouvelle extension, elle n’y passera plus qu’une demi-heure.
L’investissement logiciel et matériel est de 15k€ (sans compter la maintenance). La
personne chargée de cette tâche gagne 1500€ brut. Après intégration des charges de
l’entreprise, le ROI est atteignable en moins d’un an. Le coût de ce projet est donc pour le
dirigeant une bonne affaire.
Un ROI global sur un projet ERP est presque incalculable. Tout au mieux, il est possible
de mesurer les gains (ou les pertes) sur des processus particuliers. L’idéal est de
commencer avec des indicateurs simples : nombre de devis, de commandes et de BL saisis
par jour, nombre d’OF ouverts à l’instant t, etc. Mais tout n’est pas si facilement
mesurable. L’amélioration (ou la détérioration) des conditions de travail et l’exactitude et
l’exhaustivité des données saisies sont des éléments importants qui relèvent davantage de
la perception.
Mais pourquoi vouloir à tout prix calculer le ROI d’un projet ERP ? Est-ce que
l’investissement dans un ERP est uniquement une opération financière ? Une étude de
200312 nous apprenait que la première préoccupation des dirigeants qui implémentent un
ERP est la mesure de l’activité de leur entreprise et non pas l’amélioration de sa
rentabilité.
Décoder une offre financière
Dans le processus classique d’appel d’offres, l’entreprise reçoit des réponses de
prestataires 3 ou 4 semaines après l’envoi de son cahier des charges. Ces réponses, le plus
souvent exhaustives, comportent un volet financier (sous réserve que le cahier des charges
ait été assez détaillé pour permettre une cotation immédiate).
Chaque prestataire a sa propre façon de présenter le budget du projet ERP. Au-delà de la
forme, ils ont parfois des approches différentes de modèles économiques. Par exemple, les
petits ERP très packagés vont souvent être associés à une licence pour le site industriel, et
non par utilisateur comme il est coutume de le voir. Les synthèses financières peuvent
ainsi varier du simple au double (voire triple) pour le même cahier des charges. Mais il
ne fait pas être dupe, deux prestations équivalentes devraient globalement avoir le même
prix.
L’enveloppe budgétaire proposée dans la réponse au cahier des charges n’est cependant
qu’une première estimation. Après une première rencontre avec l’équipe projet, le
prestataire affinera son offre. Une fois la confiance établie et le besoin correctement
interprété, de nouvelles offres financières seront remises. Idem lors de l’ultime phase de
négociation où de nouvelles moutures budgétaires seront éditées.
Forfait, temps passé et prix catalogue
Une offre rassemble des coûts de différentes natures. Il faut en effet distinguer les étapes
facturées au forfait, de celles facturées au temps passé. A ce sujet, les prestataires ne sont
pas toujours très clairs dans la présentation de leurs offres. Un forfait revient à dire que le
montant de l’étape sera fixe même si le prestataire avait sous-estimé l’ampleur du travail.
Cela peut être le cas pour l’étape d’analyse initiale des processus ou pour celle des
formations. Attention cependant : des formations non prévues initialement (soit à cause de
personnes supplémentaires à former, ou du besoin de refaire une séance identique) seront
souvent considérées hors forfait. Il est important de bien clarifier le contenu des phases
chiffrées au forfait avec le prestataire avant de s’engager.
Les autres étapes sont cotées au temps passé. Le montant, en nombre de jours, donné
par le prestataire n’est qu’une estimation basée sur son expérience. Si le temps nécessaire
à réaliser la tâche est supérieur au temps estimé, celui-ci sera facturé en sus au client.
Toutefois, certains prestataires s’engagent sur ces montants à l’issue de l’étape d’analyse
des processus. D’autres souhaitent ne prendre aucun risque sur une mauvaise estimation,
et ne chiffrent pas certaines étapes dans leur devis. Dans ce cas, la phase sera facturée au
temps constaté (sans aucune estimation préalable). Cela peut être le cas pour l’étape de
reprise des données par exemple.
D’un autre côté, si le client change d’avis ou demande des fonctionnalités
supplémentaires, ce temps non prévu à l’origine sera refacturé. Malheureusement, ce
fonctionnement ne connaît pas de limite, d’où l’intérêt d’avoir un cahier des charges
solide, validé par la direction de l’entreprise cliente, et associé au contrat de prestation.
Enfin, les prix catalogues concernent les achats de matériels ou licences de logiciels.
Leurs tarifs sont uniques et fixés lors de la dernière négociation, après remise commerciale
éventuelle.
Resserrer une offre avant négociation
La concurrence est rude dans le monde des ERP. Dans les phases finales, un prestataire
va devoir se battre contre un ou deux confrères. Cela pousse les éditeurs à resserrer leurs
offres au maximum. Se trouver dans la fourchette budgétaire estimée par le client est
également un enjeu de taille. Il est important de comprendre comment un prestataire arrive
à une offre plus basse que ses premières estimations.
La façon la plus simple est de diminuer les taux journaliers d’intervention du chef de
projet, du formateur ou des consultants. Il s’agit là d’un effort commercial pur et ne
remet pas en cause le contenu de l’offre. Idem sur le prix catalogue des licences : une
remise commerciale peut y être appliquée. Attention : la diminution du montant des
licences n’entraînera pas nécessairement la baisse de la maintenance (pas de double
remise).
Ensuite, le prestataire peut diminuer le nombre de jours de prestation (formation,
paramétrage, reprise des données). Dans ce cas, il faut être très vigilant : comment
justifie-t-il cette diminution ? De même, il peut diminuer la couverture fonctionnelle.
Mais est-on toujours en accord avec le cahier des charges ?
Les clefs de l’étape de négociation seront détaillées dans la partie « Négocier son
contrat » du chapitre 6.
Analyser une synthèse budgétaire
Dans les dernières pages d’une proposition commerciale se trouve généralement une
synthèse des coûts. Voici les principaux coûts que l’on retrouve dans une telle synthèse :
Coûts des licences ERP. Ils sont généralement proportionnels au nombre d’utilisateurs
et au nombre de modules fonctionnels nécessaires.
Coûts des licences tiers. Il s’agit des licences revendues par le prestataire : base de
données, outil de reporting (BI), etc.
Coût de la prestation. Cela inclut le paramétrage, la gestion du projet, l’analyse, le
développement des spécifiques, etc.
Coût de la formation. Souvent éligible aux crédits formation.
Coût de la maintenance annuel. Celle-ci est calculée à partir d’un pourcentage du coût
des licences (généralement entre 16% et 21%). Cela intègre la maintenance corrective et
les montées de version. La plupart de temps (mais les exceptions existent), cela n’intègre
pas les nouvelles fonctions demandées par le client. Par ailleurs, la présence de licences
d’un éditeur tiers impactera le montant de la maintenance annuelle. Notez aussi que le
coût de la maintenance est proportionnel au nombre de développements spécifiques.
À partir de ces éléments de coût, on peut bâtir un tableau d’analyse et calculer des
indicateurs sur cette offre :

Licences ERP A

Licences éditeur tiers B

Prestation C

Formation D

Maintenance annuelle ERP E

Maintenance annuelle
F
éditeurs tiers

% de maintenance E/A ou (E+F)/(A+B)

Ratio Total / Licences (A+B+C+D)/(A+B)

Total sur 1 an T1 = A+B+C+D+E

Total sur 3 ans T3 = T1 + E + E

Figure 4 : tableau d’analyse financière d’une offre

Les licences, la prestation et la formation s’entendent pour l’année 1. Ensuite, chaque

année vous vous acquitterez de la maintenance pour continuer à bénéficier des mises à
jour et corrections de problèmes. Cela n’est pas obligatoire, mais fortement conseillé,
surtout durant les premières années du projet. Ainsi, vous pouvez calculer le coût cumulé
sur 3 ans, en effectuant l’opération « licences + licences tiers + prestation + Formation + 3
x maintenance ». Vous verrez que les offres les plus avantageuses la première année ne le
sont pas toujours après 3 ans ou 5 ans. Une bonne pratique consiste aussi à mesurer le coût
du projet la première année par rapport au poids des licences. Cela permet de mieux
apprécier la valeur ajoutée de la prestation et de comparer les prestataires sur ce point.
Pour comparer les différents montants, il faut déjà s’assurer que les prestataires ont
dimensionné leurs offres avec le même nombre d’utilisateurs. En effet, certains éditeurs
considèrent arbitrairement que vous n’avez pas besoin de tant de licences (ce qui est peut-
être vrai au demeurant). Ils vous proposent alors une offre avec une quantité réduite de
licences, qui sera alors difficilement comparable avec l’offre d’un autre prestataire. Même
si le nombre d’utilisateurs annoncé est estimatif dans un premier temps, vous devez exiger
du prestataire qu’il dimensionne son offre pour le nombre d’utilisateurs stipulé dans votre
cahier des charges. Pour être précis, il faut même distinguer les utilisateurs
« administratifs » qui exploitent plusieurs modules de l’ERP, des terminaux d’ateliers qui
ne seront utilisés que pour le suivi de production.
Nous allons maintenant analyser quelques offres. Nous nous attarderons dans un
premier temps uniquement sur les tableaux de synthèse remis avec les propositions
financières. En effet, il n’est pas rare d’avoir une centaine de pages en amont de ces
synthèses.
 La société PortaTech est un fabricant de portemanteaux de 30 salariés. Elle reçoit et
analyse les 2 offres suivantes :
Offre 1
Licences : 17 400€
Licences tiers : 5 040€
Prestation : 40 490 €
Formation : incluse dans prestation
Maintenance : 4 090 €
Offre 2
Licences : 20 040 €
Licences tiers : 0 €
Prestation : 18 190 €
Formation : 21 800 €
Maintenance : 3 653 €
À partir de ces éléments, PortaTech calcule les indicateurs mentionnés précédemment :
Analyse offre 1
%maintenance : 18.22%
Ratio total/licences : 2.80
Total sur 1 an : 67 020 €
Total sur 3 ans : 75 199 €
Analyse offre 2
%maintenance : 18.22%
Ratio total/licences : 3.00
Total sur 1 an : 63 683 €
Total sur 3 ans : 70 989 €
Les deux offres sont financièrement très proches (avantage pour l’offre 2 sur le moyen
terme). L’écart entre les deux s’explique en réalité par l’utilisation de technologies sous
licence dans le premier cas (licences d’un éditeur tiers pour le système de base de
données). À noter que la première offre ne sépare pas les coûts de formation, et les inclut
dans la prestation. Ce n’est pas grave en soi, mais attention à l’éligibilité d’une prestation
complète auprès des organismes financeurs. Les OPCA participent au financement de la
formation des utilisateurs. Le paramétrage, l’installation et le conseil ne sont pas
subventionnés.
Pour revenir à l’exemple ci-dessus, le choix ne portera vraisemblablement pas sur des
critères financiers. Il faudra analyser le fonctionnel, l’identité des sociétés, leur capacité à
gérer le projet pour sélectionner l’une d’elle (voir « Tableau comparatif des offres » au
chapitre 6).
Pourquoi un ERP coûte-t-il cher ?
Comme vous avez pu le noter dans les exemples précédents, un ERP est un
investissement. Au bout de 3 ans, l’entreprise aura payé 2 500€ par salarié (budget
modeste).
Qu’est-ce qui coûte si cher dans un ERP ?
Tout d’abord les licences. La licence donne le droit d’utiliser le logiciel, mais n’apporte
pas de valeur ajoutée. C’est le modèle économique du logiciel le plus courant. Il est censé
permettre l’amortissement de la R&D de l’éditeur. Un ERP abouti peut représenter un
investissement de plusieurs millions d’euros pour son éditeur.
Derrière les licences viennent les développements spécifiques. Sortir du cadre standard
représente un coût. D’abord sur le développement (il faut payer des développeurs, vendus
800 à 1000 € la journée), puis sur la maintenance. Il faut faire évoluer le spécifique en
même temps que le noyau de l’ERP. La cohérence de l’ensemble doit être sous contrôle.
Comment éviter un investissement trop lourd ?
Le nombre de postes et le nombre de salariés sont les premières variables qui font
grimper la note. Il faut estimer le besoin avec justesse, sachant qu’on parle généralement
de licences par poste et non par utilisateur (sauf en mode SaaS), et surtout d’accès
simultanés. Si 2 personnes utilisent l’ERP à des moments différents, on peut estimer le
besoin à 1 licence. La deuxième variable concerne les spécificités. Validez un à un tous les
spécifiques demandés : est-ce vraiment utile ? Comment puis-je m’en passer ? Pour
répondre à cette épineuse question, évaluez l’investissement à réaliser un spécifique, puis
estimez ce que cela vous coûterait si cette fonction n’était pas implémentée.
Le modèle économique a également une influence sur le coût du projet (open source,
propriétaire). Consultez différents types de prestataires pour en mesurer l’impact.
La prise en charge d’une partie des formations joue aussi en faveur d’une diminution de
l’investissement. Encore faut-il disposer d’un budget formation à hauteur du besoin, ce qui
est rarement le cas.
Évitez les matériels et les systèmes ésotériques si cela n’est pas justifié. Des systèmes de
gestion de bases de données (SGBD) standards pourront toujours être utilisés pour
d’autres applications, évitant ainsi l’achat de nouvelles licences. Attention cependant aux
licences de base de données bon marché, mais destinées à une utilisation exclusive avec
l’ERP.
Enfin, éléments qui n’apparaissent que très rarement dans le corps des offres : les frais
de déplacement, d’hébergement et de bouche peuvent finir par gonfler la note après de 1
an de projet. Mettez-vous bien d’accord avec le prestataire dès la signature du contrat sur
la hauteur et la nature de ces frais.
Tous ces coûts sont annoncés par l’éditeur. Ils peuvent donc être budgétisés. Mais une
des grandes difficultés d’un projet ERP, c’est de prévoir l’effort interne. Ce coût, c’est à
vous de l’estimer. Le pilotage d’un projet de 6 à 12 mois nécessite des aménagements de
postes, voire des recrutements.
Pour que l’éditeur effectue sa prestation, il aura besoin qu’on lui donne de l’information.
Voici, une règle simple pour estimer l’effort interne durant la mise en œuvre. Multipliez le
nombre de jours de prestations annoncé par le prestataire par 1,5. Vous obtiendrez une idée
de l’effort interne. Notez que certains spécialistes conseillent de multiplier par 2 ou même
2,5.
Pour reprendre l’offre 1 vue précédemment, le coût du projet hors licences est de 40 490
€. En prenant un coût moyen de la journée à 850€, on obtient 48 jours. Multiplions ce
résultat par 1.5. L’effort interne sera de 72 jours, soit quasiment 4 mois temps plein. Ce
projet durera vraisemblablement 6 à 8 mois. Le dirigeant doit donc consacrer plus d’une
demi-ressource au projet. Cela doit se prévoir et nécessitera une réorganisation temporaire
des services de l’entreprise.
Cela dit, même en prenant toutes les précautions, il arrive souvent que l’on dépasse le
budget initialement prévu. En cause : développement de spécifiques non prévus,
modification du cahier des charges… Les projets ERP sont très coutumiers du fait, et les
dérives budgétaires ont tendance à s’accentuer au fil des ans. Pour autant, les statistiques
ne sont pas forcément catastrophiques.
 Figure 5 : Dépassement de budget d’un projet ERP13

Panorama Consulting Group recense seulement 24% des projets ayant glissé de plus
25% du budget initial. Certains éditeurs préfèrent donner des estimations hautes, pour ne
pas décevoir les entreprises clientes, au risque d’être au-dessus de la concurrence. Il est
donc possible que le projet se termine en excédent (15% des cas).
La chose importante à se rappeler c’est que les 3/4 des projets se déroulent comme
prévu, ou avec un dépassement budgétaire acceptable.
Délais de mise en œuvre
Piloter un projet ERP, c’est gérer un budget, des ressources, des risques et un planning.
Dans cette partie, nous aborderons les délais de mise en œuvre. Pourquoi la mise en place
d’un projet ERP prend-elle autant de temps ?
Certains dirigeants ont encore la fausse image de l’ERP que l’on installe à partir d’un
CD-ROM, et prêt à l’emploi instantanément. La réalité est tout autre. Pour une PME de
moins de 250 salariés, il faut compter entre 6 mois et 1 an de mise en œuvre (en
moyenne). Il s’agit du délai entre la signature du contrat avec le prestataire choisi, et le
démarrage de l’utilisation effective de l’ERP.
En amont du projet, il se déroule déjà 3 à 4 mois pour clarifier son besoin, choisir un
prestataire et une solution. Ensuite, la négociation, le montage financier peuvent prendre 1
ou 2 mois. Comme pour les budgets, les dépassements de délais existent et sont de plus en
plus courants dans le cadre de projets ERP. PCG (Panorama Consulting Group) nous
enseigne à travers ses statistiques annuelles que les dépassements de délai de 25%
concernent quasiment 1 projet sur 4.

Figure 6 : Dépassement des délais dans un projet14

À quelques exceptions près, il y a corrélation entre les dépassements de temps et les

dépassements de budget. C’est souvent le manque de ressources qui pénalise l’avancement
du projet. La charge est loin d’être négligeable pendant les 6 à 12 mois du déploiement.
Les dirigeants doivent organiser les postes des personnes en charge du projet et des
référents afin qu’ils consacrent le temps nécessaire au projet. Une grande partie des
retards pris par les projets ERP est due à l’interne. Ce manque de temps et de
ressources est essentiellement dû à des problèmes de management.
Prenons l’exemple de la société « Cravate-Corp », 200 salariés répartis sur plusieurs
sites, qui fabrique des cravates de luxes. Le management de cette société est très
pyramidal. Un PDG qui dirige tout, et une poignée de responsables (mais pas nommés
directeurs) gèrent l’opérationnel. C’est seulement lorsque la mise en œuvre du projet ERP
a débuté que le PDG a compris qu’il lui manquait des ressources pour faire avancer le
projet. Après quelques recrutements et réaffectations de postes, le projet pourra se dérouler
comme planifié. Mais la formation des nouvelles recrues a décalé la phase de démarrage
de 6 mois.
Dans les grands groupes, il est d’usage de mettre en place des pénalités de retard en cas
de délai imputable au prestataire. Il est théoriquement possible de faire de même en PME.
 Toutefois, on préfère souvent une relation moins contractuelle sur ce point dans les petites
et moyennes entreprises. Par exemple, certains prestataires SAP© proposent de s’infliger
des pénalités si le retard leur incombe (environ 1000 € la journée de retard). Par contre,
l’inverse est vrai aussi : si le retard est de la faute du client (c’est-à-dire dans la majorité
des cas), c’est lui qui se voit imputer une pénalité de 1000 € par jour. Ils admettent une
tolérance de respect du planning de 1 mois pour le client, et de 2 mois pour eux.
Exemple de projet retardé
Retards et dépassements de budget sont très souvent liés. En voici une parfaite
illustration. Une manufacture de textile souhaite investir dans un ERP. Le projet est
important pour cette PME qui évolue dans un secteur sinistré. La direction charge le
responsable qualité de la gestion du projet ERP. L’entreprise s’attaque au même moment
au passage à la norme ISO 9001. La direction a très rapidement contractualisé avec un
intégrateur d’ERP, mais sans cahier des charges, sans concertation des utilisateurs et sans
processus de sélection rigoureux. Le prestataire est venu installer le progiciel et a effectué
une première série de formations. Le responsable qualité devait piloter 2 projets
stratégiques (ISO et ERP) en même temps, tout en gérant le quotidien. La direction refusa
de détacher une ressource supplémentaire. Trois années après la contractualisation,
l’intégrateur a déjà refait 2 fois les formations de base, tout en ne sachant pas vers quoi il
va.
Cette situation ne sied à personne, ni à l’entreprise, ni à l’intégrateur qui doit positionner
ses ressources compétentes. Avant même le début du paramétrage, le budget était déjà
dépassé. Pour avancer sur ce dossier, l’entreprise va devoir faire appel à un consultant qui
l’aidera à gérer des groupes de travail internes afin de déterminer les meilleures options
d’implémentation. Le coût du conseil ne faisait pas partie non plus du budget initial.
Résumé
Le retour sur investissement (ROI) d’un ERP est difficilement calculable et le coût total de
possession (TCO) n’est pas le simple cumul des prix des licences et du coût de la
prestation.
Pour comparer des offres financières, il faut imposer un format unique de réponse aux
prestataires. Tous les coûts ne sont pas équivalents : forfait, temps passé, location, etc., il
faut comparer ce qui est comparable.
Les ¾ des projets ERP se déroulent dans les délais et le budget estimés, ou avec un
dépassement acceptable d’au maximum 25%.
Les dépassements de délai sont souvent imputables au manque d’organisation et de
disponibilité de la société cliente.
 [4]
Gérer les risques
Pourquoi initier un projet ERP ?
Si vous lisez ce chapitre, c’est que vous avez sans doute l’intention de lancer un projet
ERP. Avant d’aborder la gestion des risques à proprement parler, abordons les motivations
et les freins à l’adoption d’ERP.
Les responsables de PME ont souvent de grandes attentes vis-à-vis des ERP. Ils espèrent
souvent qu’ils soient la solution miracle à leurs problèmes organisationnels. Mais
rappelez-vous qu’un ERP ne résout pas tous les problèmes. Si vous avez des stocks
physiques négatifs et que vous implémentez une gestion de stock informatisée calquée sur
vos processus, et bien vous aurez encore des stocks physiques négatifs.
On dit souvent qu’un projet ERP est structurant. Comme expliqué précédemment, ce
n’est pas le logiciel qui organise les flux. Au contraire, vous devez rationaliser les flux, les
simplifier et surtout les standardiser pour pouvoir utiliser un ERP. Cela évitera ainsi la
gestion erratique des affaires. On peut par exemple empêcher la fabrication d’articles si le
bureau d’étude n’a pas achevé la conception des plans.
Un ERP permet aussi d’améliorer la productivité administrative notamment en
diminuant les ressaisies. Avant l’implémentation d’un ERP, il n’est pas rare de voir des
PME disposer de 3 bases clients : la base de la comptabilité, la base pour les
commerciaux, et quelquefois une base en production. Pour chaque nouveau client, la fiche
d’information est créée 3 fois. Lorsqu’on met en place un ERP, l’unicité de la base permet
un partage des mêmes informations. Dans le cas d’une approche multilogicielle (ERP et
comptabilité séparée), on tâche d’automatiser la synchronisation de ce genre de données.
Ce gain de productivité participe grandement à un retour sur investissement rapide.
Un Progiciel de Gestion Intégré permet aussi de décloisonner les services. Tous les
utilisateurs ont accès à la même information. Des outils comme le « Workflow »
permettent de faciliter le passage de l’information d’un service à l’autre.
Pour le dirigeant ou un responsable de service, un ERP est le moyen d’obtenir
simplement des mesures de l’activité, de la rentabilité et de la qualité dudit service.
L’outil enregistre tout l’historique des transactions de la société. Il est donc possible de
l’interroger sur les évolutions des chiffres d’affaires par DAS (Domaine d’Activité
Stratégique), pour abonder dans le sens d’une diversification ou au contraire vers un
recentrage sur un marché donné.
L’ERP, avec sa composante CRM, est un outil puissant de développement commercial.
En une requête, le responsable commercial peut connaître les clients qui ne commandent
plus chez lui, ou ceux qui au contraire ont été fidélisés. Des systèmes de relance à date
permettent de ne plus oublier d’actions commerciales.
Un ERP est également capable de produire des statistiques intéressantes pour la
négociation avec les fournisseurs. Lister le chiffre d’affaires de fournitures commandées,
ou bien lister toutes les non-conformités de l’année sont des outils simples et très utiles
lors de la revue de contrat annuelle.
Mais un ERP ne fait pas tout. Comme tout outil informatique, il devient pertinent s’il est
utilisé correctement. Pour une exploitation optimale, un bon nombre des salariés doit
effectuer des saisies dans le progiciel (commandes de ventes et d’achat, fiche article, saisie
des temps). Si ces saisies ne sont pas systématiques, ou correctement effectuées, l’ERP
deviendra vite inexploité. L’ergonomie des interfaces hommes-machines joue donc une
importance cruciale. Les saisies d’informations peuvent être en partie sécurisées et
automatisées par l’utilisation de codes à barres.
L’adoption d’un ERP permet de réduire l’utilisation de tableurs. Mais il est fréquent,
surtout dans les premiers temps après la mise en route du progiciel, de voir de vieux
réflexes ressurgir. Si des informations utiles à plusieurs personnes sont localisées en marge
de l’ERP, c’est que la définition des processus dans le progiciel n’est pas correcte. Cette
rétention d’information n’est pas saine pour l’entreprise.
L’unicité de la base de données présente de nombreux avantages. Mais c’est aussi sa
principale vulnérabilité. En effet, la base de données de l’ERP est le centre névralgique de
l’entreprise. Le serveur et le système qui l’hébergent doivent être sécurisés au maximum.
Les menaces sur les données informatiques seront détaillées plus loin dans ce chapitre.
Un ERP n’est pas intelligent. Si on lui donne en entrée des informations fausses ou
erronées (ex : mauvais prix, mauvaise saisie des temps), il ne peut sortir des états
d’analyse corrects. Il en va de même avec des données obsolètes. Il est primordial de
valider les processus de saisie d’informations.
Il est vrai qu’une fois les processus bien structurés, un ERP laissera peu de place à
l’imagination. Il faut faire attention à rester souple, car c’est l’une des principales forces
des PME. Il faut essayer de prévoir l’imprévisible, ou du moins laisser la possibilité de
court-circuiter les processus standards pour être réactifs.
Qu’il s’agisse d’un remplacement ou d’une première mise en œuvre, c’est de vos
motivations que naîtront vos objectifs. Discutez-en avec votre équipe projet.
Renouveler son ERP
Pour certains dirigeants, la question des motivations ne se pose plus. Déjà équipés d’un
ERP depuis 10 ans, ils passent alors dans une phase de renouvellement. C’est toutefois
l’occasion de se reposer les bonnes questions : quels sont mes objectifs, qu’est-ce qui ne
fonctionne pas aujourd’hui, ou au contraire qu’est-ce qui fonctionne et que l’on doit
conserver.
Le PDG de Méca et Cie, sous-traitant mécanique de rang 2 dans l’aéronautique et le
ferroviaire, 160 salariés, assume l’investissement conséquent dans un nouvel ERP :
« notre ERP est le premier outil de production de l’entreprise». Ayant atteint le potentiel
maximum de l’ERP en place, seul un changement de gamme de progiciels pouvait lui
apporter les fonctionnalités qui lui permettront de répondre aux demandes de son
exigeante clientèle.
D’autres entreprises vont vouloir changer d’ERP, car l’actuel avait été déployé sans
réelle réflexion sur les processus, et se trouve du coup mal exploité. Il arrive aussi que
l’entreprise se soit noyée dans les développements spécifiques réalisés au fil des années.
Ce n’est pas le choix de l’outil qui est remis en cause, mais la manière de s’en servir.
Un certain nombre de projets de renouvellement sont également motivés par l’arrêt du
support ou la faillite de l’éditeur. Ce n’est pas un fait rare chez les petits éditeurs. En cas
de rachat de la société, le repreneur s’engage généralement à une continuité du support.
Mais l’histoire a montré que le service n’est pas toujours à la hauteur des attentes. Cela
conduit souvent à des projets de renouvellement menés dans l’urgence.
Pour piloter un projet ERP, il faut avant tout avoir conscience des risques. Les connaître
permet de mieux les gérer. Les principales catégories de risques sont présentées ci-après.
Les risques humains
Les risques humains sont les moins connus et donc les moins anticipés dans les projets
ERP. Pourtant, ils sont plus courants qu’un crash serveur.
L’une des principales menaces liées à l’humain concerne la résistance au changement.
Pour beaucoup de salariés administratifs, l’ERP va devenir le principal outil de travail.
Tout changement d’outil de travail peut être perturbant pour certaines personnes. Ceci est
d’autant plus vrai lors du remplacement d’ERP. De plus, derrière un changement d’outil
informatique, c’est peut-être le rôle d’une personne qui va radicalement évoluer. Il n’est
pas rare de voir des tâches sans valeur ajoutée disparaître après la mise en œuvre d’ERP.
Certains salariés doivent donc être affectés à de nouvelles fonctions.
Il convient d’identifier ces changements majeurs et de communiquer sur le projet avant
le choix de l’ERP. Il est important que chacun comprenne les objectifs et le déroulement
du projet. Également, chaque futur utilisateur doit pouvoir faire part de ses remarques et
exprimer ses besoins auprès de son responsable de service. Dans les organisations les
moins matures en conduite du changement, ou qui ont des craintes sur les compétences
des salariés et leurs évolutions, le mieux est de se faire accompagner par un cabinet-
conseil en ressources humaines. Ils sont là pour diagnostiquer les limites des compétences
et proposer les formations ou les outils adéquats pour accompagner le changement.
La formation sera un moment crucial auquel tous les utilisateurs seront confrontés. Il est
important de ne pas montrer uniquement les principes de fonctionnement du progiciel,
mais surtout comment il faut s’en servir. Le référent informatique de l’entreprise restera
directement ou indirectement toujours à l’écoute des besoins des utilisateurs tout au long
de la vie de l’ERP.
Poste devenu inutile
L’entreprise « Bricompagnie », 50 salariés, travaille dans le négoce d’outils de bricolage
et de jardinage. Elle dispose de 2 plateformes logistiques. L’informatique est le seul outil
de la société. Un projet ERP majeur est mis en route. Le responsable d’exploitation est très
satisfait de son choix, tant au niveau du progiciel que du prestataire sélectionné. La mise
en œuvre s’est déroulée parfaitement durant les 2 premiers mois. Mais 2 événements ont
bien failli faire avorter le projet.
Tout d’abord, le chef de projet côté prestataire, véritable expert métier, démissionne
(c’est son droit). La société en prestation le remplace par un chef de projet qui doit
reprendre la suite au pied levé. Celui-ci n’est pas à hauteur de la tâche, et le projet devient
très compliqué à gérer. Plusieurs responsables de Bricompagnie sont obligés d’annuler
leurs vacances d’été, pour faire avancer le projet.
Le deuxième écueil s’est produit peu de temps après la mise en route du progiciel.
Michelle, salariée de longue date, était vue par ses collègues comme étant la mémoire de
l’entreprise. Elle savait tout des affaires courantes et passées, connaissait les subtilités de
la codification des articles. À moins de 5 ans de la retraite, elle n’a pas jugé bon s’investir
dans le projet ERP. Elle a survolé les formations et préférait ses anciennes méthodes.
Maintenant, dès que ses collègues ont besoin d’une information, ils se tournent vers celle
qui maîtrise l’ERP : une nouvelle secrétaire tout juste diplômée. La salariée de 55 ans s’est
sentie inutile du jour au lendemain. L’équipe de direction a eu beaucoup de mal à rectifier
le tir en redéfinissant le poste de Michelle. Cette mésaventure n’avait pas du tout été
anticipée. Il ne s’agit pas uniquement d’un problème générationnel. Dans cette même
entreprise, de jeunes magasiniers ont aussi exprimé des réticences au changement.
En grève pour refus de flicage
Le deuxième retour d’expérience concerne l’entreprise « AeroTools », PME sous-
traitante d’un grand avionneur européen. Le projet ERP est motivé par le manque de
visibilité de la direction sur l’activité. Leur client principal exige une rationalisation
maximale de la production, mais sans indicateurs pour apprécier la productivité, c’est
difficilement concevable.
 Le projet préimplantatoire se déroule correctement, chaque responsable de service étant
impliqué. Le projet prévoyait une grande nouveauté : la saisie informatisée des temps de
production. Chaque opérateur devra déclarer l’heure de début et de fin de chaque
opération qui lui aura été confiée. Le tout avec douchettes et codes à barres pour éviter les
saisies trop fastidieuses.
Le premier jour de démarrage du module de saisie des temps : grève des opérateurs. Par
l’intermédiaire de leurs délégués syndicaux, ils font savoir qu’ils refusent le « flicage »
des salariés en production. Il leur était inconcevable de devoir saisir les temps de
fabrication.
Situation bloquée, le PDG s’en mêle et a l’idée de demander conseil à son premier
client, de qui vient cette exigence. Le client accepte de venir présenter les raisons et les
objectifs de la mesure des temps aux opérateurs. Lorsque l’avionneur européen a terminé
son explication, tous les salariés ont compris qu’il ne s’agissait pas de flicage individuel,
mais qu’il était question de qualité de service et d’initier une démarche d’amélioration
continue.
PME disposant d’un Comité d’Entreprise
Pour les entreprises de plus de 50 salariés, le Code du travail prévoit que la direction
consulte le Comité d’Entreprise (CE) pour obtenir son avis sur les projets affectant les
outils et l’organisation du travail. La direction doit transmettre un dossier d’impact au CE,
ce dernier disposant d’un mois pour émettre son avis. Le dossier doit être émis avant que
le processus de sélection n’ait été commencé. Si la direction a oublié de mentionner les
risques humains, les syndicats pourront jouer leur rôle d’alerte.
Absence d’équipe projet
Même si l’on ne peut inclure tous les salariés de l’entreprise dans un choix d’ERP, ne
pas les solliciter du tout fait preuve d’une méconnaissance de l’utilisation de ces outils.
Ces logiciels sont complexes, changent le quotidien de nombreux salariés. Leur adoption
est longue et demande un investissement et une volonté de chacun. L’adhésion au projet se
gagne bien avant le choix.
Dans une maroquinerie dédiée au luxe, le PDG lui-même décide du contenu du cahier
des charges, voit seul les prestataires potentiels et fait le choix final en son âme et
conscience. C’est ce qui est arrivé dans cette PME de 250 salariés où le PDG a réalisé
l’avant-projet tout seul, s’épaulant de temps à autre de son responsable de production. Le
choix fait, la mise en œuvre a duré 2 fois plus de temps qu’un projet normal. En effet, le
dirigeant souhaitait faire partie de toutes les réunions, tout en jonglant avec un agenda de
PDG.
Les utilisateurs n’ont donc été mis à profit qu’à partir de la phase d’analyse réalisée par
le prestataire. L’ERP a plus été subi, que porté par les salariés. Au final, même si les délais
ont été anormalement longs, le démarrage s’est fait correctement. Le prestataire aura
toutefois à sa charge d’expliquer le projet, ses tenants et ses aboutissants aux salariés.
Cette tâche aurait dû être portée par une équipe interne de super-utilisateurs.
Phases de conduite du changement humain
Tous ces exemples peuvent être synthétisés par le graphique ci-dessous, représentant
l’évolution du ressenti par les utilisateurs au cours de la vie d’un ERP.

Figure 7 : évolution du ressenti d’un projet ERP

Ces différentes phases peuvent être ressenties en individuel par certaines personnes, ou
être exprimées en collectif.
Déni : « Pourquoi lancer un tel projet ? Je continue à faire comme j’ai toujours fait ! »
Opposition : « Si vous nous imposez le suivi des temps, nous faisons grève ! »
Tristesse : « Il est nul ce logiciel. C’était mieux avant. »
Résignation : « De toute façon, on est obligé d’y passer »
Négociation : « OK, je veux bien exploiter les OF sur l’ERP, mais je ne saisis pas les
temps ! »
Adhésion : « Avec les améliorations, c’est vrai que c’est pas mal en fait ! »
L’enjeu de la gestion des risques humains est de détecter où en est chaque personne pour
pouvoir l’accompagner individuellement jusqu’à l’adhésion au projet.
Les risques financiers
L’investissement dans un ERP n’est jamais neutre, quelle que soit la taille de
l’entreprise. Il faut vraiment le voir comme l’achat d’une machine de production, même si
les dirigeants ont beaucoup moins de mal à signer un chèque pour une machine spéciale
que pour un logiciel. Il est clair que le retour sur investissement est beaucoup plus dur à
calculer pour un logiciel que pour une machine qui produit à une cadence donnée.
Le ticket d’entrée est souvent élevé. On parle de projets en dizaines de milliers d’euros
pour les plus petits ou centaines de milliers d’euros pour les plus grandes PME. Toutefois,
certaines PME de taille modeste ont les mêmes besoins fonctionnels que les grands
groupes. Par exemple, une société de 5 personnes qui fait de la vente multicanal
(téléphone, courrier, fax, mail, site web marchand) d’articles de négoce, aura besoin d’un
ERP intégrant des fonctions avancées d’échange de données. L’investissement sera du
même ordre de grandeur que celui d’une société industrielle de 40 salariés.
Le coût du projet peut être généralement évalué en proportion du chiffre d’affaires de
l’entreprise. En PME, on constate généralement que le coût global du projet (prestation et
effort interne) s’élève à 4-5% du CA. En moyenne, les coûts internes sont équivalents aux
coûts de prestation. Les offres financières des éditeurs et intégrateurs s’élèvent donc à 2-
2.5% du chiffre d’affaires de la société. Ce n’est qu’un indicateur, car les CA varient
beaucoup selon les typologies d’entreprises (négoce pur, fabrication, matière première aux
coûts élevés).
Le risque financier s’étend au-delà de l’investissement initial. Chaque année,
l’entreprise devra s’acquitter des frais de maintenance. Ceux-ci ne sont pas négligeables :
entre 16 et 21% du coût des licences investies la première année. Après 5 ans, les licences
ont donc été payées 2 fois. Cette charge doit être intégrée au budget de fonctionnement.
Certaines entreprises souhaitent lisser le risque financier en passant à la location de
service. Ce n’est pas forcément possible avec tous les ERP, mais les éditeurs y viennent les
uns après les autres. La location remplace uniquement les licences. Les prestations
d’analyse et de paramétrage restent des investissements à part entière. La maintenance est
souvent incluse dans la mensualité. L’entreprise se retrouve donc avec une mensualité
fixe, proportionnelle au nombre d’utilisateurs. Cette mensualité est mise au budget de
fonctionnement.
Dans le monde des ERP, on parle d’un retour sur investissement à 2,5 ans, mais
beaucoup de variables influent sur cette valeur. Le risque financier doit être envisagé
comme n’importe quel investissement de l’entreprise.
Les risques technologiques
Un des critères de choix d’un ERP concerne ses aspects technologiques. Cependant, peu
de dirigeants sont capables de donner une analyse pertinente à ces critères. Seul un
technologue peut juger de l’obsolescence des technologies employées dans un ERP. Il y a
2 niveaux à regarder : la ou les technologies de développements, et le Système de Gestion
de Base de Données (SGBD). Une technologie rare ou trop vieille rendra le logiciel
difficilement récupérable par un repreneur en cas de faillite de l’éditeur. Certains langages
informatiques sont passés de mode. Si l’éditeur ou l’intégrateur éprouve des difficultés à
trouver des développeurs, ce sont ses clients qui en pâtissent.
Concernant le système de gestion de base de données, on recherchera en plus du critère
de pérennité, une capacité d’ouverture et d’interopérabilité. Beaucoup d’applications
d’entreprises exploitent des bases de données. Il y a un intérêt à ne pas disperser les
données dans différents systèmes. De plus, il y a un gain économique à globaliser les
licences clients et serveurs de SGBD.
Risques liés à l’architecture cible
Les choix d’architecture qui seront faits (ERP intégré ou approche « Best of Breed »)
ont des conséquences importantes et comportent certains risques technologiques.
Nous avons déjà mentionné les questions d’échange et de synchronisation de données
dans des approches « Best of Breed ». Le risque est de devenir l’arbitre d’une partie de
tennis de table entre deux éditeurs se rejetant les torts. Mais le choix d’une architecture
intégrée présente aussi un risque majeur sur les données de l’entreprise.
Les risques sur les données de l’entreprise
Votre ERP tout intégré est devenu la pierre angulaire du support de l’information de
votre entreprise. Il contient tout l’historique de la société, les affaires en cours, toute la
base client, etc. Un seul crash serveur et la société cesse de tourner. Un seul crash disque,
et c’est une partie du savoir-faire de la société qui s’envolent.
Après un incident de ce genre, une entreprise organisée déroule un PRA (Plan de
Reprise d’Activité). Il s’agit de retrouver les conditions d’exploitation d’avant incident, le
plus rapidement possible. Pour illustrer ce qu’est un PRA (la construction du PRA n’est
pas l’objet de ce livre), voici ce que prévoit une grande banque internationale en cas
d’indisponibilité de son système d’information : sitôt l’alerte que l’on a affaire à une
grosse panne informatique donnée, des bus sont affrétés pour venir prendre les chargés de
clientèle. Ils sont emmenés sur un site miroir, où chacun trouvera un bureau, un ordinateur,
un téléphone. Pendant le transport, toutes les lignes téléphoniques sont « switchées » vers
le site de secours. Lorsque les chargés de clientèle s’installent à leur poste, ils retrouvent
leur environnement informatique, leurs fichiers et accèdent sans problème au serveur
redondant. En effet, le serveur qui a crashé, était redondé par un deuxième serveur distant.
Pourquoi la banque se paye-t-elle une telle assurance ? Elle a calculé la perte financière
que représentait une interruption de service. Elle ne peut pas se permettre de ne pas
prendre d’opérations financières pendant plus de 15 minutes. D’où la souscription à ce
PRA hors-norme.
En PME, on est bien loin de ces considérations. D’ailleurs, on parle davantage de délai
d’intervention que de délai de rétablissement. L’entreprise signe avec son prestataire
informatique un délai d’intervention en cas de panne du serveur (certaines PME disposent
de leur propre service informatique). On parle généralement d’un délai de 2h à 24h. C’est
de la responsabilité du dirigeant de choisir un délai d’intervention optimal par rapport à
son métier et à l’usage qui est fait de l’informatique dans son entreprise.
Reprenons l’exemple de la société « Bricompagnie ». Une fois le contrat ERP signé, le
dirigeant questionne son prestataire informatique sur ses délais d’intervention.
Considérant sa typologie d’entreprise, celui-ci lui propose 4h ou 8h ouvrées. Le dirigeant
ne sachant quelle option choisir (le coût n’est pas le même évidemment), il choisit de faire
une expérience.
La plateforme logistique de Bricompagnie connaît 2 départs camions chaque jour, un à
midi, l’autre à 17h. Le dirigeant arrive un matin à 8h et coupe le serveur pour simuler une
panne. Aussitôt, le service ADV (administration des ventes) ne peut plus saisir de
nouvelles commandes. Mais les commandes à servir le matin sont arrivées la veille ou la
nuit, et les bons de préparation étaient déjà imprimés. Le remplissage des camions
continue normalement. À midi, tous les camions partent comme prévu. Par contre, en
début d’après-midi, certains opérateurs commençaient à chercher des bons de
préparations. Le dirigeant rétablit le serveur, sans quoi les camions de 17h ne partaient
pas.
Suite à cette expérience, il a été signé un délai d’intervention de 4h, avec stockage de
pièces de rechange pour les composants équipant le serveur.
La procédure de sauvegarde
Les menaces sur les données de l’entreprise ne viennent pas que de l’extérieur
(espionnage industriel, pirates). Dans la majorité des cas de perte de données, c’est bien
une défaillance interne (involontaire ou non) qui est à l’origine de l’incident. Ce n’est pas
l’objet de ce livre que de vous aider à réaliser cette analyse de risques.
Si elle le souhaite (il est également possible de sous-traiter cette responsabilité),
l’entreprise peut gérer elle-même sa propre sauvegarde des données. Ainsi, en cas de
suppression maladroite de certaines informations, il sera possible de repartir avec des
données de la veille (où toute autre échelle de temps).
Pour illustrer la nécessité de sauvegardes journalières, prenons l’exemple de la société
« Stylopub », fabricant d’objets publicitaires. Dès son arrivée dans l’entreprise, le PDG a
mis en place une stratégie de sauvegarde quotidienne sur bandes DAT : une bande par jour
de la semaine, 2 bandes pour les vendredis en alternance. La procédure était
scrupuleusement respectée. Cependant, un incident majeur survint : le disque dur du
serveur fit un crash. Le PDG ne panique pas et appelle son prestataire informatique pour
remonter un nouveau disque. Il pense qu’il vient juste de perdre les données de la matinée,
car il a une sauvegarde de la nuit passée. Une fois l’installation matérielle achevée, le
prestataire demande la bande qui servira à restaurer les données. L’incident devint alors un
drame. La cassette est vierge, ainsi que toutes les autres. Elles n’avaient jamais été
utilisées.
La faille a vite été découverte : la procédure de sauvegarde ne prévoyait pas de test de
récupération des données. Si cela avait été le cas, quelqu’un se serait aperçu que le logiciel
de sauvegarde était paramétré en mode « test », sans écriture réelle sur les bandes.
 Que ce soit un véritable PRA ou une simple procédure de sauvegarde des données, il est
de la responsabilité du dirigeant de s’assurer de la sécurité des données de l’entreprise.
Les risques informationnels
Dans le premier chapitre de cet ouvrage, nous avons énoncé le paradigme de l’ERP :
verbe, quantité, délai. Concernant le verbe (l’action), l’erreur n’est pas ou peu possible.
On sait lors de la saisie des informations si l’on achète, si l’on vend, si l’on expédie, etc.
Par contre, les saisies de chiffres (codes articles, quantités, dates) sont beaucoup plus
sujettes à erreur et aux doublonnages. Sans information qualitative, l’intelligence extraite
de l’ERP sera au mieux une approximation grossière et au pire totalement erronée. La
qualité de l’information de l’entreprise traduit plusieurs choses : des procédures fiables et
maîtrisées, un management transversal efficace et surtout un management réaliste.
La bonne information doit arriver au bon moment. L’entreprise « Tôle et Cie » a pu en
faire les frais. Cette petite industrie tourne en 3x8. La nuit, seuls les opérateurs sont
présents et donc aucun nouveau lancement d’ordre de fabrication n’est effectué. Pourtant,
une liberté est laissée aux opérateurs de commencer de nouvelles productions même si
l’OF n’est pas en statut lancé. Les terminaux de saisie de « Tôle et Cie » permettent de
déclarer les quantités produites et rebutées uniquement sur les OF lancés. Il est donc
impossible aux opérateurs de déclarer la production réalisée sur des OF non lancés
préalablement. Dans ce cas, les ouvriers inscrivent manuellement les informations sur
l’OF papier. L’ERP n’a cependant pas été prévu pour ces écarts de processus. Les
quantités non saisies au moment de la production poseront problèmes à la clôture de l’OF,
à l’expédition des pièces et même jusqu’en comptabilité. On n’est pas loin de la théorie du
chaos : un battement d’aile d’un papillon au Brésil peut déclencher une tornade au Texas15.
La cohérence des données reste une grande vertu pour l’entreprise. Cela commence par
les données de base : les fiches clients et les fiches articles. La base client est la
championne de la multiple saisie. Les PME qui n’ont pas entamé de réflexion sur leur SI
font couramment 2, 3 voire 4 saisies d’un nouveau client. Cela commence par les
commerciaux qui déclarent le compte en premier, dans le cadre d’une visite de
prospection. Si les commerciaux mobiles ont des outils non intégrés au SI de l’entreprise,
il n’est pas rare que l’administration des ventes doive ressaisir les informations du client
pour émettre un devis ou un AR de commande. En bout de chaîne on retrouve le poste de
comptabilité qui dispose lui aussi de ses propres fichiers clients. Enfin, de manière plus
anecdotique, le responsable de production peut avoir sa liste de clients pour l’aider dans le
suivi de la fabrication et la connaissance des exigences particulières.
En plus d’être improductives, les ressaisies sont souvent non intègres. Les données, les
noms, les contacts varient d’un service à l’autre. Les mises à jour ne sont pas faites dans
toutes les listes en même temps. Ce phénomène est courant. L’important est de raisonner
de manière globale à l’entreprise et d’inclure tous les services dans la réflexion d’un
nouvel outil informatique. Les besoins de tous les services seront regroupés dans le cahier
des charges. Ce document se veut fédérateur. Il doit tendre vers une réponse globale aux
problématiques de chaque service, mais il doit aussi rester réaliste.
Le cahier des charges incomplet, ou irréaliste est un facteur de risque pour la réussite du
projet ERP. La société « InnovTech » est même allée plus loin, car elle n’a pas jugé bon
rédiger un cahier des charges. « InnovTech » est une PME de 35 personnes qui connaît
une forte croissance. L’histoire avait commencé 2 ans auparavant avec seulement 5
employés. Les prévisions d’affaires sont bonnes, et le gérant estime que la masse
d’information va également décupler. Le système D, tableurs et fichiers textes, n’est plus
possible. L’étape ERP s’impose. Très vite, le projet est connu sur la place publique, et les
éditeurs se succèdent pour présenter leur solution. L’un des progiciels, et sans doute un
très bon commercial, séduit le patron de la PME. Le contrat est signé dans la foulée.
Quelques mois après, le doute s’installe, puis le responsable de « InnovTech » déclare
l’arrêt de l’implémentation. Motif : le logiciel installé ne correspond pas au besoin. Quel
besoin ? Aucun document n’existe pour le prouver. Innov’Tech mandate un consultant
expert pour montrer que le progiciel ne pourra convenir à la PME. Finalement, l’histoire
se terminera à l’amiable, juste avant la case tribunal. Le logiciel est désinstallé et
« InnovTech » remboursée. Dorénavant, le patron fera toujours appel à un consultant pour
l’aider à exprimer clairement ses besoins.
Les risques informationnels sont souvent mal connus des patrons de PME. Beaucoup
imaginent l’ERP comme un gros bouton qu’il suffit de presser pour qu’il fonctionne à
plein régime. Il n’en est rien. Il est de la responsabilité du dirigeant de prendre les bonnes
décisions pour son entreprise. Il le fait en s’appuyant sur des informations externes (veille
stratégique, marchés, etc.), mais aussi en analysant les données produites en interne. Le
dirigeant doit toujours avoir à l’esprit que des saisies approximatives, des services
cloisonnés, des erreurs de paramétrage au niveau des processus donneront de grosses
approximations de reporting. Le risque de prendre de mauvaises décisions est grand si l’on
ne fait rien pour assurer la qualité et la cohérence des informations transmises à l’ERP. On
est bien là sur un processus d’amélioration continue, qui doit être piloté depuis le haut de
la société.
Synthèses des risques
Toutes les entreprises ne se reconnaîtront pas forcément dans les exemples cités ci-
dessus. Les risques sont liés à la nature même de l’entreprise, à son activité et au type de
management. Ce paragraphe apporte une vision élargie des risques potentiels sur des
projets d’informatisation. À partir de ces éléments, il est recommandé de mener une
véritable analyse de risque. Il s’agit pour chacun des points d’évaluer la probabilité et
l’impact de la menace. Le dirigeant et l’équipe managériale chercheront alors à diminuer
 les risques du projet.
Exemples de risques organisationnels :
Objectifs du projet peu ou pas définis (pas de recul sur ce qui est attendu du projet)
Manque de communication (pas ou peu de diffusion d’information vers les salariés)
Mauvais conseils (le consultant n’a pas les compétences requises, ou alors ses conseils ne
sont pas entendus)
Structure intouchable (le management ne veut pas remettre en cause l’organisation de
l’entreprise)
Exemples de risques informationnels :
Information de l’entreprise incohérente ou non accessible
Non-intégrité de l’information (Saisie multiple de l’information)
Informatisation des dysfonctionnements (des processus incohérents sont supportés par des
outils informatiques)
Cahier des charges incomplet ou irréaliste
Exemples de risques humains :
Projet non porté par le management (le DG est passif et sourd au projet)
Management pyramidal (le DG décide seul de tout)
Résistances au changement
Compétences nécessaires au projet non disponibles
Pas de plan de formation
Exemples de risques technologiques
Choix d’une technologie obsolète
Choix techniques limités ne permettant pas les évolutions futures
Données informatiques non sécurisées
Exemples de risques financiers
Choix d’un modèle économique qui ne correspond pas aux rythmes des rentrées financières
de l’entreprise
Coût du projet disproportionné par rapport à la taille et au chiffre d’affaires de l’entreprise
Banques ne suivent pas
Coûts annuels difficilement absorbables dans le fonctionnement
 [5]
Déroulement d’un projet ERP
Tous les projets ERP sont différents, mais on trouve toujours 4 grandes étapes. Une phase
de réflexion et de sélection, une phase de négociation et de contractualisation, une phase
de mise en œuvre et une phase d’exploitation, jusqu’au remplacement du logiciel.
Du cahier des charges à la sélection
La phase de préprojet – qui peut durer plusieurs mois – est parfois oubliée des
entreprises. Certaines commencent par choisir un prestataire, puis lui font réaliser le cahier
des charges. Peut-on être juge et partie ? Cette étape est justement le moment ou il faut
être ambitieux (les offres budgétaires vous ramèneront vite les pieds sur terre). Il faut voir
loin, et pas seulement pour les 2 ans à venir. On parle en moyenne d’un renouvellement
d’ERP tous les 7 ans. Même si cette moyenne ne veut pas dire grand-chose (l’écart-type
est plutôt grand), la stratégie de la direction doit transparaître dans le cahier des charges.
Analyse des processus existants, schéma cible
Aborder un projet ERP est l’occasion de remettre en cause le fonctionnement de
l’entreprise. Après implémentation, ce sera plus difficile de faire bouger les choses. Il faut
donc prendre le temps, en amont du choix, d’analyser ses processus. Sont-ils clairs et
systématiques ? C’est l’occasion de les améliorer. Au besoin, faites-vous aider par un
consultant extérieur à l’entreprise. Cela permet d’avoir un regard critique sur le
fonctionnement. Celui-ci pourra vous dire ce qui est archaïque et au contraire ce qu’il
faudrait garder. Le consultant produira alors un schéma directeur, aussi appelé schéma
cible. Ce document propose des scénarios de mise en œuvre et d’évolution du système
d’information à un horizon déterminé. Il servira de carte routière au groupe projet qui
mènera l’implémentation de l’ERP pour tendre vers les objectifs fixés. En PME,
l’allotissement des composants du SI est très important. En effet, les ressources limitées ne
permettent pas de mener de front tous les projets du SI en même temps. Le schéma
directeur doit donner un ordonnancement des sous-projets et leur niveau de priorité. Par
exemple, le consultant proposera de commencer par implémenter une nouvelle
comptabilité, puis de fiabiliser la chaîne commerciale (produire des devis et des factures).
La gestion de production viendra dans un 3ème temps, juste avant la gestion de la qualité (2
ans après le démarrage par exemple).
Pour analyser les flux existants, organisez des petits groupes de réflexion (4-5
personnes) sur les sujets qui posent le plus de questions. Croisez les services ; il s’agit de
traiter un sujet précis, mais dans le contexte global de l’entreprise. Il est relativement
fréquent de traiter les sujets de codification des articles (qui ont mal vieillis), de gestion
des temps de production, de gestion de la sous-traitance, du calcul des coûts de
revient, de gestion par affaire, etc. Chaque sujet constitue un levier pour l’entreprise. Il
faut chercher à exploiter au mieux l’offre technologique pour donner de nouveaux outils
de pilotage aux dirigeants.
Cartographie du SI, urbanisation
Si les processus existants sont clairs dans les détails, il peut arriver que la direction
manque d’information à l’échelle macroscopique du SI. Cela se retrouve souvent dans une
organisation Best-of-Breed. Les directions ont parfois du mal à savoir par quel bout
prendre un SI devenu tentaculaire. L’idéal dans ce cas est de faire cartographier le SI
existant par une personne externe à la société, afin d’en sortir une synthèse
macroscopique. L’idée est de pouvoir positionner des modules fonctionnels sur des
composants du SI (exemple : saisie commande dans ERP, site web et GRC, Analyse
commerciale dans un tableur). L’étude cartographique fera ressortir les liens entre les
composants du SI (les synchronisations, les EDI16, les ETL17, etc.)
Des scénarios d’évolution du SI vont être définis en respectant les contraintes, les
ressources et la stratégie de l’entreprise (exemple : suppression de la GRC autonome pour
exploiter celle intégrée à l’ERP). Dans le milieu du conseil en informatique (et des
grandes entreprises), on parle d’urbanisation du système d’information. Ce concept est
inspiré des règles d’urbanisme des villes et permet de formaliser l’organisation et les
évolutions du SI (règles de découpage par zone, canaux d’accès, etc.)
Les scénarios de réingénierie seront validés par la direction. En synthèse, la
cartographie présentera et planifiera les projets de refonte et d’évolution du système
d’information. À ce stade, la précision temporelle n’est guère en dessous du trimestre.
Cet exercice est souvent demandé par les directions de PME suite à un rachat de
sociétés. En effet, cette étude leur permet d’avoir une vision claire de l’organisation du SI
et des projets qui les attendent.
La société « P&Co », fabriquant de calculatrices a connu un démarrage fulgurant. D’une
taille de 20 salariés à sa création, l’entreprise a vite dépassé la centaine, puis des filiales
étrangères sont venues étoffer le groupe. Le SI s’est bâti au fur et à mesure, et souvent
dans la précipitation. L’ERP choisi était devenu obsolète au bout de 2 ans. La direction
commanda alors une cartographie du SI pour déterminer si les fondations seraient assez
solides pour absorber la croissance. Le résultat fut sans appel : la solidité de l’informatique
et des informations de l’entreprise ne tenait qu’à un fil. Le PDG ordonna immédiatement
un grand projet de refonte, encadré par des consultants de renom. L’année suivante,
l’entreprise ouvrit son capital en bourse.
Constituer l’équipe projet
 Dans cette première phase, c’est aussi le moment de constituer l’équipe projet. Cette
équipe pluridisciplinaire aura un rôle important dans la réussite du projet. Chaque service
de l’entreprise doit y être représenté. Chacun devient alors porte-parole de son propre
service, et doit être capable de synthétiser les desiderata de ses collègues, mais aussi de
redescendre vers eux les décisions prises. La prédisposition à la communication est
essentielle dans l’équipe projet. Son but est d’obtenir l’adhésion d’un maximum de
collaborateurs.
L’équipe projet est constituée des membres référents des processus (1 par service) et
d’un chef de projet qui coordonne le planning dans cette phase amont et qui assure la
cohérence de l’expression du besoin. L’équipe a une vision transversale de l’entreprise. On
peut également y trouver un responsable technique (informatique), qui validera les aspects
matériels, infrastructure, hébergement et offre de services. Enfin, la participation
systématique du PDG ou d’un responsable de l’entreprise peut être un plus pour trancher
et prendre des décisions rapidement. La présence d’un décideur sera tôt ou tard requise
dans le processus de sélection. Pour conclure, le PDG constitue l’équipe projet en fonction
des remontées d’information qu’il souhaite avoir.
Voguer vers son objectif
L’équipage constitué, le capitaine désigné, encore faut-il savoir où l’on va, et surtout
connaître les étapes intermédiaires pour y arriver. Pour certains projets de renouvellement
d’ERP, le but est simple : on souhaite se retrouver à isopérimètre du système actuel dans
un an, puis implémenter telles nouvelles fonctions les années suivantes. Il est plus facile
de définir un tracé, lorsqu’on a déjà fait un voyage. Pour les entreprises qui n’ont jamais
entrepris de projet d’informatisation de type ERP, il est préférable de s’entourer d’un
consultant et de passer par l’étape Schéma directeur décrite plus tôt dans ce chapitre.
Celui-ci, par son expérience, saura guider la PME vers son objectif. Attention, il faut bien
lire « vers » et non pas « jusqu’à son objectif ». L’organisation idéale (schéma cible) est
souvent trop coûteuse à obtenir. Le retour sur investissement ne sera pas au rendez-vous.
Ce n’est pas sans rappeler le Paradoxe de la flèche de Zénon18. « Lorsque le vaillant
Achille décoche sa flèche, celle-ci passe récursivement par la moitié de la distance qu’il
reste à parcourir, et semble ne jamais atteindre sa cible. »
Le SI d’une entreprise est une flèche. Plus les développements avancent, plus ils coûtent
cher. Vraisemblablement, une autre flèche sera décochée avant que la précédente ait atteint
sa cible. La nouvelle flèche visera une cible encore plus lointaine.
Rédaction du cahier des charges
Le cahier des charges (CDC) est une formalisation écrite du projet d’informatisation qui
doit permettre de sonder des prestataires. L’objectif premier est d’avoir un document assez
complet pour que les éditeurs puissent rendre une proposition technique et financière. Le
 deuxième but pour l’entreprise, est de garder une ligne directrice tout au long de la vie du
projet. Ce document peut aussi devenir contractuel. Il doit donc être soigné, car il servira
de référence en cas de litige.
Le chapitre 6 présentera en détail la composition d’un tel document. Pour le rédiger,
l’entreprise a le choix : soit elle détache un salarié compétent pour le faire, soit elle recrute
un consultant externe. Le regard externe et critique est souvent une bonne chose en amont
du projet. Le risque avec les ressources internes est de vite tomber dans un cahier des
charges irréaliste. Le consultant est là pour cadrer le besoin et le rendre plausible.
La démarche pour aboutir à la rédaction d’un CDC commence par un audit. Cette
première étape, aussi appelée diagnostic interne (le terme audit peut avoir une connotation
négative pour certains salariés), permet au rédacteur de rencontrer les utilisateurs et
l’équipe projet. Cela ne doit pas leur demander trop de préparation, ils doivent rester
spontanés. Cela évite de tomber dans les cas particuliers. Le risque à trop préparer un audit
est de rester sur des processus théoriques. Ce que l’auditeur doit appréhender c’est
comment l’entreprise fonctionne réellement et non pas comment elle aurait dû fonctionner.
Les interviews se font généralement en individuel ou à 2 si les personnes font partie du
même service. Éventuellement, le chef de projet peut assister à toutes les auditions. Les
réflexions éventuelles intra-service ont eu lieu au préalable.
Les questions à aborder avec chaque service sont simples. On commence avec les
processus actuels de traitement de l’information (comme pour le travail de schéma
directeur). L’idée est de positionner chaque service comme un maillon d’une chaîne :
Quel service et/ou personne vous envoie de l’information ? Sous quelle forme (papier,
informatique, oralement) ?
Vers quel service et/ou personne envoyez-vous de l’information ? Sous quelle forme ?
Comment traitez-vous l’information ? Avec quels outils ?
Chaque personne ou groupe de personnes interviewé illustrera ses propos en montrant
ses outils logiciels, ou des états papier. L’auditeur doit veiller à ce que tous les processus
de gestion principaux aient été abordés.
Le deuxième axe des entretiens aborde le besoin. Sur la base de l’existant, l’auditeur
demande à chaque personne d’expliciter :
Les manques dans les outils ou dans les informations ;
Les souhaits en nouveaux outils, fonctions informatisées ;
Les dysfonctionnements constatés dans les circuits d’information ;
Les outils et fonctions à garder absolument.
 À l’auditeur de séparer le bon grain de l’ivraie. Les référents interviewés n’ont pas de
limites, et ne doivent pas s’en donner à ce stade. Le consultant doit trier les besoins
effectifs, de ceux utopiques. Il faudra également donner un terme aux éléments plausibles.
Tel besoin est-il immédiat, ou n’y a-t-il pas d’autres priorités avant celui-ci ? L’auditeur ne
doit pas forcément restituer sa synthèse immédiatement. L’idée est surtout de capter les
besoins, pas de partir dans des dialogues sans fin sur l’utilité d’une fonction. L’échange
entre le rédacteur et les référents se fera surtout après la première version du cahier des
charges.
Il arrive souvent, notamment dans le cas d’entreprises familiales, que les salariés n’aient
connu qu’une seule expérience professionnelle. L’entreprise actuelle est donc leur unique
référence en matière de gestion et de traitement de l’information. Difficile dans ce cas
d’être critique et d’imaginer de nouveaux besoins qui pourraient tirer leur entreprise vers
le haut. L’auditeur doit alors être force de proposition, et, d’après sa connaissance
conjointe de la maturité de l’entreprise et de l’offre sur le marché, suggérer les besoins
fonctionnels adéquats.
Le rédacteur du cahier des charges doit surtout faire attention aux moyens disponibles
dans l’entreprise lors de la mise en œuvre de l’ERP. Si la taille des ressources est critique,
que le dirigeant ne veut pas ou ne peut pas allouer le temps nécessaire, que la capacité à
gérer les gros projets n’est pas certaine, il faudra définir des lots dans le cahier des charges
(tel qu’on peut aussi le retrouver dans le schéma directeur). Seule une connaissance
technico-fonctionnelle pointue permet de découper un projet ERP en lots. Cette étape peut
néanmoins être effectuée avec le prestataire au début de la mise en œuvre. Ainsi, au lieu
de prévoir un déploiement unique en 6 mois consécutifs, le cahier des charges pourrait
proposer à l’intégrateur de découper le travail en 2 lots sur les 2 prochaines années.
La première version du cahier des charges doit ensuite être relue et validée par
l’ensemble des acteurs de l’équipe projet. Comme précisé plus haut, le cahier des charges
pourra être référencé dans le contrat avec l’intégrateur. Il est important d’avoir une
validation unanime.
Avant de finaliser le cahier des charges, il est recommandé de prendre du recul sur le
besoin exprimé en soulignant les points discriminants. Il s’agit de passer en revue tous les
besoins exprimés par les différents services de l’entreprise et de déterminer unanimement
quelles sont les fonctions incontournables. L’erreur à ne pas commettre est évidemment de
juger toutes les fonctions discriminantes. Il faudra bien faire des choix et des compromis.
On parle des « must to have » et des « nice to have » : ce qu’il est impératif d’avoir et ce
qu’il serait bien d’avoir. Un prestataire qui ne pourrait pas répondre à une fonction
discriminante part avec un sérieux handicap. Cela remet en cause sa place dans la liste des
sélectionnés.
 Liste de prestataires et appel d’offres
Lorsqu’il est achevé, le cahier des charges va être envoyé à une liste de prestataires
préalablement choisis. Là encore, le consultant a un rôle de veilleur et peut vous apporter
des références de solutions correspondant à votre projet. À ce stade, on cherchera par
exemple des solutions qui ont déjà été implémentées dans des sociétés proches d’un point
de vue taille, métier ou typologie de production. Vous obtiendrez des noms de solutions et
des avis en vous informant auprès des clubs ou associations de dirigeants, de confrères, de
fournisseurs ou de clients. Vous pouvez aussi visiter les salons19 spécialisés sur la
thématique des ERP.
Il peut arriver dans certains cas qu’un prestataire pourtant qualifié refuse de répondre à
votre cahier des charges. La raison peut être d’ordre concurrentiel : si le prestataire a
déployé sa solution chez un de vos concurrents directs, ce dernier peut faire pression
auprès de l’éditeur pour qu’il n’installe pas la même solution dans votre entreprise. Dans
d’autres cas, certains prestataires peuvent refuser pour des raisons d’indisponibilité de
leurs ressources ou en justifiant un risque financier trop important.
Le nombre de prestataires à sonder n’est pas limité, mais ce sera autant de réponses à
analyser. Il n’est pas rare d’avoir des réponses d’une centaine de pages. En moyenne, les
entreprises envoient leurs documents à 6 ou 7 prestataires, avec un maximum de 10. En
effet, il peut arriver qu’il faille jouer sur plusieurs tableaux. Une PME de 150 personnes
qui travaillent uniquement avec de grands donneurs d’ordres de l’aviation ou du
ferroviaire en rang 1 ou 2 va devoir investir dans un système d’information performant
répondant aux attentes de ces grands groupes. D’un point de vue fonctionnel, cette PME a
quasiment les mêmes besoins qu’une grande entreprise, sans en avoir toutefois les
moyens. Pour se donner toutes les chances de trouver le bon ERP, la liste de prestataires
devra être composée de solutions pour PME et d’autres ciblant davantage les grands
groupes industriels (éditeurs internationaux).
Pour gagner du temps, les envois de cahier des charges se font par e-mail. Envoyez un
e-mail par prestataire ou bien mettez-les en copie carbone invisible (champ « cci » des e-
mails). En effet, il est préférable qu’un prestataire ne connaisse pas ses concurrents sur un
dossier. Cela évite les alignements de prix et les comparaisons préformatées de la part des
éditeurs, et permet d’avoir plus de latitude lors de la phase de négociation.
Le cahier des charges est envoyé en pièce jointe dans un format classique éditable
(généralement DOC, DOCX, RTF ou ODT, mais pas PDF). Les candidats pourront ainsi
répondre directement dans le document.
Le corps de l’e-mail ne doit pas être négligé. Il s’agit de synthétiser votre démarche et
ses enjeux, de rappeler qui vous êtes, de présenter vos valeurs et ce que vous attendez d’un
prestataire ERP. Si le projet est alloti, mentionnez les lots pour lesquels vous souhaitez
recevoir une cotation.
Voici un modèle de lettre, à remanier selon vos attentes.
Madame, Monsieur,

Notre entreprise cherche à renouveler son ERP. De nouveaux marchés, et une nouvelle stratégie nous amènent à
revoir nos outils. Nous vous sollicitons, car votre produit répond à tout ou partie de nos besoins.
Nous vous prions de bien vouloir répondre aux différentes questions ouvertes présentes dans le document, ainsi que
de compléter les différents tableaux regroupant les fonctionnalités attendues.
De plus, nous vous prions de bien vouloir nous faire parvenir une liste de références dans l’industrie mécanique, de
différentes tailles, et de préciser les modules utilisés.

Merci de mentionner les relations avec des modules tiers qui ne sont pas développés/intégrés par vos services. Nous
demandons également à connaître les technologies de base de données et de développement employées. Les prérequis
matériels et logiciels (systèmes) devront également être mentionnés.
Votre démarche projet sera explicitée dans un document que vous nous enverrez.

Votre réponse est attendue pour le 18 novembre.

En vous remerciant d’avance du temps que vous y consacrerez et de la qualité de votre réponse.

La date limite de réponse doit être mentionnée. Pour les projets de PME, on considère
qu’il faut laisser aux candidats au moins 3 semaines ouvrées, 4 semaines étant le
maximum. Vous pouvez aussi exiger un accusé de réception de votre cahier des charges.
Relancez les sociétés qui n’ont pas renvoyé d’AR après 1 semaine.
Analyse des offres
Dès l’envoi de l’appel d’offres, vous devez commencer à bâtir un tableau comparatif.
Tous les candidats ne vont pas répondre avec la même promptitude, certains vont vous
appeler pour accuser réception et poser quelques questions, d’autres non. Certains vont
vouloir un rapide échange en face à face pour faire connaissance, etc. Tous ces éléments,
ainsi que les dates associées doivent être consignés dans un tableau comparatif. Un
modèle de tableau est proposé dans le chapitre suivant.
Les offres des prestataires vont arriver par e-mail, par courrier ou en main propre (sauf
si vous avez spécifié un processus de réponse particulier). Il s’agit de premières versions
d’offres. Veillez à stocker tous ces fichiers dans une arborescence efficace qui permettra
de suivre les évolutions de versions. Il n’est pas rare d’avoir 3 ou 4 versions d’une réponse
avant signature finale du contrat. Selon les sociétés, il y a 2 à 10 fichiers joints à la
réponse. À ce stade, il est inutile de se concentrer sur tous les documents. Les conditions
générales et particulières liées aux services seront analysées dans les moindres détails plus
tard, si le candidat est retenu pour les phases finales. Les données les plus importantes
dans un premier temps sont la réponse fonctionnelle, l’offre financière et le CV des
sociétés candidates.
Avant même de commencer la phase de démonstration, cette première analyse des offres
peut déjà souligner des écarts importants avec votre projet. Une simple lecture des
réponses permet d’exclure les offres jugées trop éloignées du besoin (qui demanderont
trop de développements spécifiques pour coller au cahier des charges), celles jugées trop
onéreuses (dont le budget est supérieur de 50% à la moyenne des offres reçues) et celles
qui annoncent des délais de mise en œuvre incompatibles avec votre activité (ex. : 2
années de mise en œuvre pour une PME de moins de 100 salariés peuvent être considérées
comme irréalistes).
Ces offres écartées dénotent souvent d’un manque d’intérêt du prestataire pour le
dossier, ou d’une erreur de qualification dans la liste des prestataires sondés.
Démonstrations commerciales
L’idéal est de commencer cette étape avec 5 ou 6 offres. Il s’agit des offres retenues
après avoir écarté celles qui se trouvaient hors sujet. L’objectif de la démonstration
commerciale est dans un premier temps de se familiariser avec la logique et l’ergonomie
de la solution proposée. C’est aussi souvent une première rencontre avec l’équipe
commerciale du prestataire (et parfois avec l’équipe technique). Il est de bon ton d’aborder
toutes les questions laissées en suspens dans la réponse au cahier des charges.
Le scénario de démonstration à ce stade est souvent laissé à l’appréciation des
candidats. Il fera donc ressortir les points forts des progiciels. À vous d’être vigilant en
demandant des précisions sur les points obscurs des offres reçues.
La séance de démonstration commerciale dure entre 2h et une demi-journée. Comme
toutes les étapes, elle est dense et nécessite une grande attention. La quantité
d’information absorbée est très grande. Pour ne pas noyer l’équipe projet, limitez les
démonstrations à 2 par jour.
Questionnez les candidats sur leur société : quand a-t-elle été créée ? Comment est
structuré l’actionnariat ? Quelle est leur taille ? Dans quel sens évolue le chiffre
d’affaires ? Autant de questions qui doivent vous conduire à percevoir les valeurs et la
stratégie du prestataire.
À la fin de chaque séance, le chef de projet recueille l’avis de l’équipe projet lors d’un
débriefing à chaud.
À l’issue des démonstrations commerciales, l’équipe projet, ou du moins ceux qui ont
assisté à ces démonstrations, doivent sélectionner 2 à 3 finalistes (avec un maximum à 4
en cas d’hésitations). Cette liste s’appelle communément la « short list ». Le chef de projet
ou le consultant est tenu de communiquer les résultats à chaque prestataire, sans pour
autant dévoiler le contenu de la liste. Pour les finalistes, la prochaine étape est la
démonstration avec jeu d’essai.
Démonstrations sur jeu d’essai
 Cette deuxième série de démonstrations demande une certaine préparation de la part des
candidats. C’est pourquoi la liste doit être restreinte. Aucun prestataire n’acceptera
d’investir du temps s’il a encore 4 concurrents face à lui. Le délai nécessaire à cette
préparation est environ de 2 et 4 semaines pour les intégrateurs.
Deux types d’éléments doivent être fournis dans le jeu d’essai : des données de
l’entreprise, généralement stockées dans un tableur, et un scénario de démonstration. Le
scénario peut s’appuyer sur les points discriminants mentionnés dans le cahier des
charges. Il s’agit lors des démonstrations de vérifier l’exactitude des réponses au cahier
des charges. À défaut de valider chaque point fonctionnel un par un, le scénario passera au
moins par toutes les fonctions discriminantes. La démonstration sur jeu doit permettre
d’analyser in fine la capacité de chaque prestataire à comprendre le métier de l’entreprise.
Le chef de projet pilote la rédaction du jeu d’essai, ou le réalise complètement lui-
même. Il s’agit de regrouper dans un unique fichier type « tableur », des données de
l’entreprise qui permettront aux prestataires de montrer leurs solutions dans un
environnement parlant à l’équipe projet (on reconnaît ses articles, ses clients, etc.). Les
onglets du tableur servent à séparer les types de données. On trouvera par exemple un
onglet avec les articles, un onglet avec les gammes pour les fabriquer, un autre avec les
nomenclatures, puis des références clients et fournisseurs, des configurateurs d’articles ou
bien des OF.
On choisira des articles typiques de l’activité de la société. La durée des démonstrations
permet de passer en revue plusieurs types d’articles. Il ne faut pas hésiter à leur soumettre
des articles un peu particuliers. Cela dit, il ne faut pas non plus leur proposer uniquement
des cas particuliers.
Une démonstration avec jeu d’essai doit durer au minimum une journée par prestataire.
Ce temps est coûteux pour l’entreprise, car il monopolise plusieurs personnes. Mais
l’enjeu est également important. La solution choisie accompagnera l’entreprise pendant
plusieurs années. Le choix doit être pris en ayant le maximum d’informations.
Certaines PME choisissent de réaliser le jeu d’essai sur 2 jours. La première journée
étant consacrée au noyau gestion commerciale et gestion de production. Le deuxième
aborde les aspects financiers, comptables et services annexes (ressources humaines par
exemple).
Si la participation de l’équipe projet est un problème, organisez un planning de la
journée. La démonstration peut être déroulée dans l’ordre de traitement d’une commande
client, le représentant des commerciaux devra être présent les 2 premières heures, puis les
achats, puis la production, etc. Cela évite de monopoliser des ressources importantes pour
l’entreprise pendant une journée entière. Mais si cela est possible, il est toujours préférable
que l’équipe projet assiste à l’intégralité des démonstrations. C’est justement l’un des
objectifs d’un projet ERP que de décloisonner les services de l’entreprise !
Pendant ces démonstrations, le chef de projet tente de compléter le tableau d’analyse
des offres. S’il lui manque des éléments, il contactera les prestataires candidats
ultérieurement.
À l’heure du choix
Les deux ou trois démonstrations avec jeu d’essai terminées, le chef de projet recueille
une fois de plus les avis des membres de l’équipe projet. Chacun établira son ordre de
préférence, et justifiera son choix par une analyse SWOT (voir le Chapitre 6). Il arrive
fréquemment qu’une solution se détache, voire fasse l’unanimité. Dans ce cas-là, la phase
de négociation va commencer. Attention à ne pas révéler à un candidat qu’il a gagné
l’appel d’offres, car la négociation risque de tourner court. Gardez la concurrence le plus
longtemps possible. Les gestes commerciaux arriveront s’il y a ballottage entre 2
solutions !
Dans les cas où l’hésitation est réelle, reprenez le tableau d’analyse des offres. Pondérez
les valeurs importantes à vos yeux (ex. : références dans un métier similaire, type
d’actionnariat proche de celui de votre société, etc.). À ce stade, une bonne pratique
consiste à visiter un client de chaque prestataire en lice. Profitez de cette visite pour
questionner les utilisateurs sur leur appréciation du logiciel. Parlez de la durée du projet,
des dérives et si vous le pouvez, abordez le sujet des relations avec l’éditeur.
Généralement, les éditeurs vont vous emmener chez des clients « success stories ». Vous
ne verrez donc pas les faiblesses des projets déployés. Le cas idéal est de visiter un client
qui n’a pas été recommandé par le prestataire. Des références de clients peuvent s’obtenir
dans les clubs de dirigeants, par le bouche-à-oreille ou via le consultant en AMOA le cas
échéant.
À ce stade d’avancement, vous pouvez exiger un premier planning de mise en œuvre, et
comparer les finalistes sur ce point particulier. On valide aussi les spécifiques qui seront
ou pas mis en œuvre. Les prestataires peuvent rendre une offre financière affinée. Mais
n’oubliez pas que l’engagement financier du prestataire sélectionné ne sera réalisé
qu’après avoir analysé en détail vos processus (voir chapitre 3 sur les coûts). Ce nouvel
engagement sera plus proche de ce que vous coûtera réellement l’ERP au final, tout en
étant toujours estimatif.
Enfin, sachez profiter des fins d’années où les commerciaux tentent de réaliser leurs
objectifs annuels. Les remises sont souvent plus fortes en décembre. Mais ne tombez pas
non plus dans des enchères à la baisse. Au final, vous en aurez toujours pour votre argent,
alors ne rognez pas sur le fonctionnel ni sur le nombre de jours de prestation.
Des conseils de négociation contractuelle sont donnés dans le Chapitre 6 : boîte à outils.
En tout état de cause, les offres et les conditions générales et particulières de vente doivent
être analysées par un spécialiste (consultant ou juriste). Beaucoup de points peuvent être
sujets à négociation. Cela dit, certaines clauses sont difficiles à exclure des contrats.
La mise en œuvre
Une fois le contrat signé avec le prestataire, le chef de projet va prendre ses vraies
fonctions. C’est là que se trouve le plus gros de son travail. Il va devoir coordonner l’effort
interne et les interventions du prestataire. Il est le garant du planning et doit suivre les
éventuelles dérives budgétaires et alerter la direction le cas échéant. Le rôle de chef de
projet doit être officialisé pour la phase de mise en œuvre. Le temps à y consacrer ne sera
plus négligeable. On parle communément de 50 à 80% du temps à consacrer à la mise en
œuvre de l’ERP (voir le chapitre 6 pour plus de détails sur cette fonction et la
réorganisation des compétences internes). Face au chef de projet de l’entreprise, le
prestataire nomme aussi un chef de projet (voire un directeur de projet). Celui-ci va
coordonner les interventions des différents spécialistes (consultant, expert métier,
formateur, etc.) pour le compte du prestataire. Il est l’interlocuteur privilégié du chef de
projet de l’entreprise.
Chaque membre de l’équipe projet va avoir un interlocuteur privilégié chez le
prestataire. À noter que si la société est petite (ou si le prestataire est de taille modeste),
certains intervenants seront multicasquettes.

Figure 8 : équipes projets et leurs interlocuteurs

En interne, le chef de projet devra rendre des comptes à un comité de pilotage s’il en a
été défini un, ou à défaut au comité de direction.
Méthodologies de gestion de projet
L’orchestration de la mise en œuvre sera effectuée selon un mode de gestion de projet
particulier. On trouve classiquement 3 familles de gestion de projet, même si tous les
prestataires ne proposent pas cette variété.
La méthode autonome est la moins exploitée. Elle consiste à former la PME à la mise
en œuvre de son projet ERP. Les formations lui permettent de prendre en main l’outil et de
comprendre sa philosophie. L’entreprise effectuera elle-même le paramétrage, la reprise
des données et le lancement de la mise en exploitation. L’implication de l’équipe projet est
maximale, mais le coût de la solution est souvent très attractif.
Les méthodes Agiles impliquent davantage le client dans les cycles de développement.
Le principe est de travailler sur des cycles courts (3 à 10 jours) appelés « sprint » qui
soient itératifs, incrémentaux et adaptatifs. La mise en production est immédiate, mais
demande une plus forte disponibilité du client dans le pilotage de la mise en œuvre.
Les méthodes traditionnelles privilégient l’investissement du prestataire dans l’analyse
et la mise en exploitation. Chaque étape est entièrement réalisée avant de passer à la
suivante. C’est aujourd’hui la méthodologie la plus utilisée dans les projets ERP en PME.
Phase d’analyse
La première étape de la mise en œuvre d’un ERP est une analyse détaillée des processus
de l’entreprise par l’intégrateur. Cette phase est aussi appelée « Phase de cadrage ». Le
prestataire, via son (ou ses) consultant(s), analyse le fonctionnement de chaque service et
décrit les solutions envisagées pour répondre aux besoins et aux problématiques (flux
cibles). Cette opération ressemble à la première étape ayant conduit à la rédaction du
cahier des charges. La différence réside dans le niveau de détail. Le prestataire doit
pouvoir identifier tout le paramétrage de chaque fonction de l’ERP. L’équipe projet et les
utilisateurs du futur ERP seront mis à contribution pour répondre aux questions du
prestataire. Le chef de projet de l’entreprise coordonne les calendriers des différentes
personnes interviewées. Cette étape dure généralement entre 5 et 10 jours (mais jusqu’à 20
jours pour les projets de grande ampleur).
Le dossier d’analyse qui sera rendu lors d’une entrevue sur site, sera l’engagement
ferme du prestataire, aussi bien fonctionnellement qui financièrement. Il vous demandera
de le signer. C’est le document le plus important. Sa relecture ne doit pas laisser de
place au doute. La recette du projet sera effectuée en concordance avec cette analyse et le
planning proposé (ce planning engage le prestataire).
Une attention toute particulière sera donnée aux développements spécifiques. En effet,
c’est à ce moment que l’entreprise valide ou non l’adoption de chaque fonction spécifique.
Un jeu d’essai doit être mentionné pour chacun de ces développements.
Il est possible (mais rare) de ne s’engager que sur la phase d’analyse, puis de décider
après coup de poursuivre la mise en œuvre avec le prestataire choisi. Cela dit, l’analyse ne
peut être effectuée à titre gracieux. Si vous choisissez de ne pas continuer pas avec le
prestataire initial, cette étape sera due et devra néanmoins être réitérée avec un nouvel
intégrateur.
Durant la phase d’analyse, le chef de projet de la PME a une tâche non négligeable : il
doit commencer la rédaction des procédures d’utilisation de l’ERP. Certes, il ne dispose
pas à ce stade de toutes les informations nécessaires. Ces documents évolueront au fil de
la mise en œuvre et serviront de support à la formation des utilisateurs, puis lors du
quotidien avec l’ERP. Les procédures d’utilisation ne sont pas équivalentes aux manuels
qui seront remis par le prestataire. Elles doivent décrire pas à pas les enchaînements
d’actions pour assurer la cohérence des données saisies. Elles s’appuient sur un grand
nombre de captures d’écran.
Installation
L’analyse terminée, le prestataire va installer le noyau de l’ERP ainsi que les modules
fonctionnels faisant partie du périmètre du projet (quelquefois l’installation est réalisée en
amont de l’analyse). À ce stade, cette installation tient très peu compte de l’analyse
fonctionnelle. Il s’agit avant tout d’une étape technique : installation sur un serveur distant
ou local, paramétrage de l’environnement système et des bases de données. Selon
l’architecture système, l’installation peut durer de 1 à 2 journées. Attention, l’installation
des logiciels marque le début de la facturation des licences !
Développement des spécifiques
Dès la fin de l’analyse, les développements spécifiques sont lancés. Il s’agit pour le
prestataire de mettre une équipe de développeurs sur la mise au point des fonctionnalités
qui n’existent pas dans son logiciel, mais que l’analyse a jugées nécessaires. Certains
éditeurs refusent de développer du spécifique propre à un client. Si le besoin identifié
s’avère intéressant aux yeux de l’éditeur – c’est-à-dire que la fonction est susceptible
d’intéresser d’autres clients ou prospects – celui-ci préférera l’intégrer au standard de son
application. Dans ce cas, cela se négocie !
Les spécifiques doivent être validés un à un, selon des jeux d’essai et des scénarios bien
définis. Idéalement, le prestataire fournira la documentation propre à ce spécifique, mais le
plus important est qu’il apporte une garantie sur les évolutions de ces développements
hors standards. La plupart du temps, il y a une maintenance supplémentaire prévue pour
les évolutions des spécifiques.
Paramétrage
 Une fois l’application installée, l’éditeur va procéder au paramétrage des modules, selon
les termes de l’analyse. Le paramétrage peut être entièrement du ressort du prestataire,
conjoint entre le client et le prestataire ou uniquement à charge du client (voir plus haut les
méthodologies de gestion de projet).
Dans cette étape, on retrouve typiquement la personnalisation des écrans (ajout de
champs, suppression de champs), la création des profils et des droits des utilisateurs (qui
voit quelle information, qui peut éditer). La base de données évolue également selon les
besoins exprimés. Les états et requêtes particulières sont également déployés. Les
interfaces de connexion avec les autres composants du SI (comptabilité, relation client,
etc.) sont élaborées selon les spécifications données dans le cahier des charges ou dans le
rapport d’analyse. Dans ce genre de paramétrage, l’entreprise doit souvent faire office
d’entremetteur entre le prestataire ERP et les prestataires des autres logiciels à interfacer.
Cela nécessite une bonne gestion de projet et l’adoption d’outils permettant de suivre les
remarques et les problèmes des 2 parties. Le risque est de très vite tomber dans un report
des responsabilités des uns sur les autres.
Le prestataire progresse généralement module par module. Les ressources internes de la
PME doivent donc avoir du répondant au moment concerné. Il s’agira en fin de
paramétrage de valider ce qui a été fait par le prestataire. Les jeux d’essai sont les
bienvenus. Chacun des points mentionnés dans le rapport d’analyse doit pouvoir être testé
et validé. Souvent, le prestataire assure une assistance lors de cette étape de recette. Ce
jalon important est aussi l’occasion de mesurer les écarts éventuels avec le cahier des
charges et donc de planifier ce qu’il reste à faire.
À l’issue de l’étape de paramétrage, le comité de pilotage, au regard du rapport de
recette, du planning et des éléments techniques, valide ou non la mise en exploitation de la
solution auprès des utilisateurs.
Formation des utilisateurs
La formation se déroule après le paramétrage ou conjointement selon la méthodologie
de gestion de projet employée. Les prestataires peuvent avoir des logiques de plan de
formation différentes. Certains la proposent en 2 temps. Une première session en amont de
l’analyse dont le but est de présenter la philosophie de l’outil, son ergonomie et ses
possibilités. Connaître l’étendue des fonctionnalités de l’ERP rendra la phase d’analyse
plus efficace. La deuxième session vise à former les utilisateurs sur le flux cible, avec un
jeu d’essai et un paramétrage définitif. D’autres éditeurs ne feront qu’une session à la fin
de l’étape d’adaptation. Dans tous les cas, il faut avoir à l’esprit que la formation n’est pas
uniquement destinée à prendre en main l’outil, c’est aussi l’occasion de discuter et définir
les flux d’information cibles. La formation est dispensée par module fonctionnel (achat,
vente, production, etc.). Le chef de projet et son bras droit assistent idéalement à toutes les
séances.
En parallèle, le responsable technique de la PME (qui peut être le chef de projet) assiste
quant à lui aux formations d’administrateur de l’ERP. Elles comportent généralement un
module sur le paramétrage, sur la personnalisation des écrans, sur la gestion des profils,
mais aussi une grande partie sur la création d’états et de requêtes. En effet, pour réaliser
des états, il est nécessaire de connaître avec précision l’organisation des données.
Les utilisateurs finaux reçoivent rarement la formation directement de la part du
prestataire. Les éditeurs préfèrent passer du temps à former les référents de l’équipe projet,
afin que ceux-ci puissent à leur tour former les équipes d’utilisateurs. Ce système de
formation pyramidal est très courant. Certains prestataires proposent toutefois de courtes
présentations générales à destination de l’ensemble des utilisateurs si tel est le souhait.
Sachez enfin que la majorité des intégrateurs et éditeurs d’ERP est référencée comme
organisme de formation, ce qui donne droit de déclarer ces heures auprès des Organismes
Paritaires Collecteurs Agréés (OPCA) auxquelles toute entreprise privée cotise. Cela dit,
les plafonds sont souvent très vite atteints lors de projet ERP, et les OPCA ne peuvent
généralement pas financer l’intégralité de la formation liée au nouvel outil informatique.
A la fin de la période de formation, il paraît indispensable de laisser du temps à l’équipe
projet pour tester ses connaissances et prendre en main l’outil. Ces tests personnels
doivent durer au moins aussi longtemps que la formation elle-même.
Reprise des données
À moins que votre projet ERP accompagne la création d’une toute nouvelle société,
votre entreprise dispose déjà d’un capital d’information. Ces données sont la
matérialisation des activités présentes et passées de la société : ancienne facture, clients,
OF en cours… La reprise des données est l’ultime étape avant le démarrage du nouveau
système. C’est l’une des plus importantes. On la considère souvent comme un projet dans
le projet. Elle peut être rapide si les données existantes sont à jour, qu’il n’y a pas de
doublons, qu’elles sont uniques et facilement localisables, et s’il n’est pas question de
recodifier certaines clés. Malheureusement, tous ces paramètres sont rarement réunis. Il
faut bien comprendre que le plus long n’est pas l’importation elle-même, mais toute la
préparation amont qui vise à constituer un fichier propre. Dans cette étape, le prestataire
intervient souvent en assistance. En effet, il ne peut savoir de lui-même où sont vos
données et comment elles sont structurées. Ce travail monopolise donc beaucoup de
ressources internes à l’entreprise.
Une des difficultés vient aussi du caractère dynamique de certaines données. En effet,
les commandes en cours ou les OF en cours évoluent constamment (statut, dates,
quantités, etc.). Il s’agit donc de mettre en place un principe d’import, plutôt que de
préparer des données dans une table prête pour le jour J. À l’opposé, les données clients et
les données techniques évoluent peu, il est ainsi plus facile d’en faire une photographie
instantanée.
Pour préparer la reprise des données, l’éditeur (ou l’intégrateur) peut vous fournir un
modèle de fichier (tableur ou autre) avec des colonnes préformatées prêt à être intégré
dans le nouvel ERP. Il ne reste qu’à remplir ces fichiers. Avant d’arriver au résultat final, il
faudra manipuler beaucoup de données. Soyez méthodiques ! C’est l’occasion de nettoyer
ces données. Prenons les articles. Dois-je réellement importer les articles, les gammes et
les nomenclatures qui ont 10 ans et que je ne vends plus depuis 5 années ? Pour la base
client se pose la même question. Mais ces données proviennent souvent de plusieurs
logiciels (comptabilité, GRC, ERP). En plus du nettoyage, il faudra fusionner ces données
et supprimer les éventuels doublons. Pour fusionner des données, il faut nécessairement
une clé commune. Il s’agit d’un champ qui permettra de faire le rapprochement entre les
tables. À défaut d’un code alphanumérique commun, il faudra tenter de faire coïncider la
dénomination du client. Mais, cette méthode génère souvent des doublons du fait de
dénominations ou orthographes différentes (ex. : « Dupont SA » et « Dupont » ne seront
pas reconnus comme étant la même société).
Une question importante concerne l’antériorité : faut-il reprendre toutes les données
informatiques disponibles ? Si l’histoire de votre entreprise est longue, réinjecter 20 ans
d’activités risque de poser des problèmes de taille de bases de données et de lenteur lors
de l’édition de statistiques ou l’affichage de résultats de requêtes. Pour l’édition des
statistiques commerciales de comparaison avec les années passées, une bonne pratique
consiste à ne reprendre que les pieds des factures des années antérieures, mais pas le détail
des lignes de celles-ci. On allège ainsi considérablement la quantité de données reprises.
Les entreprises profitent souvent de cette étape de nettoyage pour recodifier certaines
données. Codes articles trop longs (qui ressemblent à des nomenclatures), ou bien trop
courts (on ne peut plus en créer de nouveau), les sociétés ont toujours de bonnes raisons de
vouloir recodifier les articles ou les clients. La réflexion est importante et doit être validée
par l’équipe projet et la direction. En effet, la codification est souvent complètement
intégrée par tous les utilisateurs. Dans les ateliers, on n’appelle pas les articles par leur
désignation, mais par leur codification. Un changement radical de code est très perturbant
et diminue la productivité administrative, du moins dans un premier temps. S’il n’est pas
obligatoire de la changer, il est conseillé de garder la codification historique.
Dans l’autre cas, gardez toujours un champ secondaire avec l’ancienne codification dans
le nouvel outil informatique. La codification idéale dépend de l’entreprise, son métier et
surtout de son histoire.
Bascule
Tout est fin prêt pour le démarrage. Le paramétrage de l’ERP a été validé, les
développements spécifiques sont achevés, les anciennes données ont été injectées dans le
nouveau système, et les équipes sont bien formées. La bascule peut alors s’opérer.
Le vendredi soir, les utilisateurs fermaient pour la dernière fois leur ancien logiciel.
Lundi, ils verront la toute nouvelle interface du nouvel ERP. Le responsable informatique
et le prestataire sont sous pression.
À vrai dire, il existe 2 grandes approches pour d’effectuer une bascule. Si l’ancien
système est éteint le jour même du démarrage du nouveau, on parle de mode « Big
Bang ». Au contraire, si l’ancien et le nouveau système cohabitent pendant un certain
temps, on parle alors d’une bascule « au fil de l’eau ».
La bascule Big Bang, est assez spécifique aux PME, car il est inconcevable de
révolutionner l’informatique et les processus métier d’un seul coup dans une grande
entreprise. Seules les PME ont la souplesse suffisante pour opérer avec une telle rapidité
de changement. Aujourd’hui, le choix pour l’un ou l’autre des modes dépend vraiment des
enjeux et de la stratégie de l’entreprise. Statistiquement, les 2 familles de bascules sont au
coude à coude. Financièrement, l’avantage est au Big bang, car on évite la double saisie
sur 2 systèmes informatiques différents. Mais le risque d’un faux départ est plus élevé
dans le mode Big Bang. Les étapes préparatoires sont donc d’une importance cruciale.
Finalement, la méthode la plus efficace sera sans doute à mi-chemin entre ces 2 modes.
L’idée est de repartir du schéma directeur, ou de l’allotissement des modules de l’ERP, et
de réaliser un Big Bang sur chacun des lots considérés. Par exemple, on découpe le projet
en 3 phases : financière, commerciale et production. Un premier Big Bang est réalisé sur
la comptabilité (avec import des données de l’ancien système). Puis un second avec la
gestion commerciale et les données techniques. Enfin, 6 mois plus tard, l’entreprise
introduit les gammes de fabrication, la gestion de la charge et de la capacité, module qui
n’existait pas auparavant. Ce découpage en 3 est plus difficilement concevable si la PME
disposait déjà d’un module production dans son ancien ERP. Dans ce cas, les données
commerciales et de production sont déjà fortement couplées.
À noter qu’il est très fréquent de démarrer une nouvelle comptabilité le jour de
démarrage de l’année fiscale. Cela rend plus facile l’extraction des bilans et du compte de
résultat annuels. La valorisation du stock peut également profiter du démarrage à cette
date, suite à l’inventaire annuel. Si la bascule est réalisée à un autre moment de l’année, il
faudra de toute manière quand même réaliser un inventaire physique complet.
La bascule est une journée très importante dans la conduite du projet de l’ERP. La date
doit être correctement choisie. L’adhésion des utilisateurs pour le progiciel peut se jouer
sur cette seule journée. Le personnel de l’entreprise s’est investi plusieurs mois dans ce
projet et souhaite voir rapidement le fruit de leurs efforts. Pendant cette journée, l’usine est
généralement fermée (pas de production).
L’exploitation
Démarrage, la garantie
L’ERP lancé, les services concernés démarrent son exploitation. Les nouvelles données
sont saisies, on extrait des états, on vérifie des indicateurs. Il est souvent conseillé à la
PME d’être très proactive en phase de démarrage et de centraliser tous les incidents. Il
faudra aussi rassurer et temporiser certaines demandes qui n’ont pu être honorées dans un
premier temps. La remontée des problèmes passe par les « utilisateurs-clés » ou « key
users », ceux-là mêmes qui étaient membres de l’équipe projet.
Le prestataire vous doit une assistance particulière lors du démarrage. Il assiste l’équipe
projet dans la détection des problèmes et dans l’aide aux utilisateurs. Cette demande peut
être formulée dans le cahier des charges.
Sachez enfin que l’ERP fait l’objet d’une garantie contractuelle durant cette période de
démarrage. Elle commence à la livraison définitive du logiciel et a une durée avoisinant
les 3 mois (au maximum 1 an). Les conditions de la garantie et les services gratuits dus
pendant cette période doivent être stipulés dans le contrat de vente. La garantie n’ouvre
pas aux mêmes droits que la maintenance. C’est pourquoi certains prestataires proposent
les deux conjointement. Entre autres la garantie de couvre pas l’obtention des mises à jour.
Le quotidien, la maintenance
L’entreprise évolue constamment, son ERP l’accompagne dans sa mutation. On exploite
de nouveaux modules en informatisant de nouveaux services de l’entreprise, on exploite
de nouvelles fonctionnalités apportées par l’éditeur. Les enjeux concernent maintenant le
maintien en état opérationnel de l’ERP.
L’intégrateur est toujours là en arrière-plan et délivre sa prestation de maintenance. Les
règles sont régies selon un contrat annuel de maintenance (aussi appelé contrat de
support). Son montant est calculé à partir d’un pourcentage du coût des licences (voir le
Chapitre Coûts et Délais de mise en œuvre). Notez que la reconduction du contrat n’est
pas obligatoire, mais il est indispensable les premières années d’exploitation. Il donne
droit au support téléphonique, aux nouvelles versions du progiciel, à de la correction de
problèmes et à de la prise en main à distance. Les offres varient légèrement selon les
éditeurs. Mais le plus important est le maintien de la compatibilité avec les standards de
l’éditeur. En effet si vous faites l’impasse sur plusieurs années de mises à jour majeures,
vous ne pourrez pas évoluer facilement vers une version plus récente, et il faudra passer
par un mini projet de migration de version (avec reprise des données). De plus, pour
reprendre un contrat de maintenance après plusieurs années d’interruption, le prestataire
vous fait généralement payer les années manquantes.
Les politiques des éditeurs varient au sujet des mises à jour majeures. Certains les
excluent du contrat de maintenance, et seront couvertes par un autre contrat d’acquisition
de licences. Le contenu exact du contrat de maintenance doit donc être connu avant
signature avec l’éditeur afin d’éviter toute mauvaise surprise. Les fréquences de ces
mises à jour majeures sont variables selon les éditeurs. En pratique, on constate que ce
chiffre varie entre 2 par an et 1 tous les 2 ans.
Le génie logiciel considère plusieurs sortes de maintenance. Chacune offre un service
différent, qui au final, peut conduire à un document contractuel unique. La maintenance
adaptative assure le fonctionnement du logiciel vis-à-vis de son environnement. Le cas
typique est une évolution du système d’exploitation (Microsoft©, Linux, etc.) qui
nécessiterait une adaptation de l’ERP pour maintenir son intégration. On parle également
de maintenance corrective qui a pour objectif la résolution des bogues et des
dysfonctionnements rencontrés. Enfin, la maintenance évolutive, qui frôle avec les
limites étymologiques, consiste à proposer de nouvelles fonctionnalités au logiciel.
Incidents, changements et mises à jour
La maintenance corrective et la maintenance évolutive apportent régulièrement de
nouvelles versions de l’ERP à la PME. Il est important de savoir que la plupart des
problèmes informatiques surviennent suite à un changement. Si l’on ne touche à rien, il y
a peu de chance de déclencher un cataclysme. Le processus de mise à jour, qui sera
vraisemblablement déroulé plusieurs fois par an, doit être maîtrisé et accompagné d’outils
incontournables.
Tout d’abord le « bac à sable ». Il s’agit de ne pas déployer une mise à jour directement
sur le serveur de production, mais d’abord sur un environnement de test. Chaque
changement doit être validé avant mise en production. Deuxièmement, une fois la mise en
jour déployée, il faut toujours prévoir le retour arrière, c’est-à-dire être capable de
désinstaller la mise à jour et revenir à l’état fonctionnel précédent. Ces 2 outils sont
indispensables dans la gestion des changements. Cela dit, ils ne sont pas toujours simples
à mettre en œuvre. Discutez-en avec votre prestataire.
Le quotidien de la vie d’un ERP c’est aussi la gestion des demandes et le report des
incidents de la part des utilisateurs. Une bonne organisation et bonne communication sont
de mises. Chaque incident doit être référencé et remonté d’abord au key-user de son
service, puis au responsable informatique s’il n’a pu être résolu directement. Le
responsable informatique (ou le référent informatique si le poste n’existe pas) fera une
escalade des incidents vers le prestataire ERP. Un tableau permettra de suivre les incidents
ouverts. Un modèle est fourni dans la partie « Piloter son prestataire informatique » du
chapitre 6.
À force de capitaliser sur les remarques et les demandes des salariés, sur les retours et
les conseils du prestataire, l’entreprise commence à constituer une base de connaissances,
 qui servira de trousse de premiers secours aux utilisateurs et aux key-users.
Le renouvellement
Il arrive un moment où malgré ses mises à jour et ses évolutions, le progiciel connaît
une part d’obsolescence. Ce dépassement peut être d’ordre technologique (génération de
base de données ou langage de développement trop anciens) ou d’ordre fonctionnel, c’est-
à-dire que d’autres ERP plus récents apportent de nouveaux paradigmes, ou de nouvelles
fonctions intégrées nativement. On a pu voir cela récemment avec la gestion des affaires
intégrées, les workflows, la disparition progressive de compétences Prologue©.
Il se peut que le logiciel ait été correctement suivi dans ses mises à jour, mais que la
société ait subi des mutations stratégiques importantes comme une fusion, un rachat, une
spécialisation, une croissance hors norme, etc. Par exemple, une société qui passe de 5
salariés à 100 salariés en 2 ans va devoir changer de gamme de progiciels. Autre point,
une société qui fait une croissance externe devra gérer des aspects multisociétés. Un ERP
conçu pour du monosociété ne devient pas multisociétés du jour au lendemain.
Dans ces 2 cas de figure, la société devra changer d’ERP. Si elle a déjà mené un premier
projet dans les règles de l’art, un deuxième ne devrait pas lui poser trop de problèmes.
Cela dit, le renouvellement va davantage porter sur le caractère humain : il faut éviter le
syndrome du « c’était mieux avant ». On veillera aussi à la manière dont est choisi ou
imposé le nouveau progiciel. Typiquement lors d’une fusion-absorption, le logiciel groupe
imposé aux filiales n’est pas toujours le bienvenu. Surtout s’il n’est pas taillé pour une
PME. Idem lorsque la marque de l’ERP est « suggérée » par le plus gros donneur d’ordre
de la PME.
Résumé
Rédiger un cahier des charges oblige l’entreprise à constater l’état de ses processus et de son
système d’information et à réfléchir à son besoin. La composition de l’équipe projet est
capitale pour la remontée des informations du terrain.
Le dirigeant doit réorganiser les rôles et les fonctions des personnes impliquées dans le
projet ERP.
Chaque prestataire propose sa propre méthodologie de gestion de projet. L’implication de
l’entreprise cliente varie selon le type de gestion de projet sélectionné.
La reprise des données existantes doit être anticipée au maximum. Il s’agit d’un projet à part
entière
En phase d’exploitation, les référents conservent des tâches importantes dans le processus de
support aux utilisateurs. Ces rôles doivent être officialisés dans leur contrat de travail.
 [6]
Boite à outils
Ce chapitre apporte quelques techniques pour diminuer ou du moins maîtriser certains
des risques décrits dans les chapitres précédents. Il est du rôle du dirigeant de s’assurer
que ces outils sont utilisés par ses équipes dans le cadre d’un projet ERP.
Constitution de l’équipe projet
Les super-utilisateurs ou key-users
Mettre en place une équipe projet pluridisciplinaire, motivée et qui s’investit dans son
rôle, est un critère nécessaire à la réussite d’un projet ERP. Une personne seule ne peut
faire de bons choix pour tous ses collègues. Le dirigeant doit nommer une équipe projet à
partir du moment où il a été décidé d’amorcer un projet ERP. La taille de l’équipe varie
selon la taille de l’entreprise. En PME, on a généralement des équipes composées de 4 à 8
membres. Chaque membre représente un ou des processus de l’entreprise, et à ce titre, il
est la voix des utilisateurs concernés. Ce sont souvent les chefs de service qui ont ce rôle,
mais il peut tout aussi être intéressant d’inclure de futurs utilisateurs. Après tout, ce sont
eux qui auront le logiciel en face des yeux tous les jours ! L’essentiel est d’avoir un groupe
motivé, qui sera moteur au sein même de l’entreprise. Le groupe projet doit être
hétéroclite : mixez les âges et les sexes. Attention toutefois aux positions hiérarchiques
des membres des uns par rapport aux autres. Il faut que chacun se sente libre de
s’exprimer lors des séances de travail. Chaque membre sera référent processus. Il répondra
aux questions des consultants et du prestataire, recueillera les besoins auprès des
utilisateurs en avant-projet, et sera capable de former ou d’effectuer un support de premier
niveau sur leur processus en phase d’exploitation. Ces référents sont aussi appelés les
« key-users » ou « super-utilisateurs ». Ils ne sont pas informaticiens, mais ils ont
l’écoute et les outils pour répondre aux utilisateurs.
Le dirigeant doit privilégier les aptitudes humaines de ces personnes plutôt que leurs
capacités techniques. Idéalement un key-user formera à son tour un bras droit dans sa
propre équipe pour palier à ses absences ou indisponibilités. Cette notion de « backup »
est toutefois assez rare au sein d’un même service dans les petites structures. Dans ce cas,
on croise plutôt les backups avec d’autres services.
Le chef de projet et le responsable technique
Les key-users ne sont pas seuls dans l’équipe projet. Le chef de projet est le moteur du
projet ERP. Il est désigné par la direction, et il est détaché d’une partie de ses fonctions
habituelles pour accomplir sa tâche. La gestion d’un projet ERP ne peut se faire en plus
d’un autre poste à plein temps. Selon les phases du projet, le chef de projet va être
mobilisé entre 10% et 100% de son temps. Son rôle est de donner une cohérence au projet
et de piloter son planning et ses coûts. Il rend des comptes au comité de pilotage. Il est
l’interface principale du consultant et des prestataires candidats. Lors de la rédaction du
cahier des charges, il veille à l’homogénéité des besoins exprimés. Pendant la mise en
œuvre, il gère le planning des interventions et a une vue d’ensemble sur le paramétrage et
les choix d’implémentation. En phase d’exploitation, les problèmes survenus lui sont
remontés par les key-users. Le chef de projet sera chargé du suivi de la résolution des
problèmes, de l’enrichissement de la base de connaissances et plus globalement de la
communication interne autour du projet.
C’est une tâche parfois ingrate. Le manque de ressources humaines en PME oblige
souvent le chef de projet à « faire avec les moyens du bord ». La convocation des
membres projets aux réunions, les reports réguliers pour indisponibilités peuvent s’avérer
laborieux. Le chef de projet doit être tenace et ne pas se décourager au premier aléa. Son
rôle est justement de savoir gérer ces aléas qui font la vie des entreprises. Enfin, il est
important qu’il ait une vision transversale de l’entreprise. C’est pourquoi on retrouve
souvent les informaticiens, les qualiticiens et les contrôleurs de gestion au poste de chef de
projet ERP. Le choix du chef de projet est crucial. Évitez les profils qui ont trop de
responsabilités (ex. : directeur d’exploitation), ou les personnes trop récentes dans
l’entreprise. Le chef de projet est avant tout un communicant qui saura faire accepter des
choix et trouver des consensus.
Concernant les aspects techniques d’un projet ERP, c’est-à-dire tout ce qui touche aux
réseaux informatiques, à l’hébergement et à la sauvegarde des données, la direction
nomme un référent technique. Il s’agit d’un informaticien, ou à défaut, du référent
informatique, c’est-à-dire, la personne en lien avec le prestataire informatique. Il peut
aussi s’agir du chef de projet.
Une équipe au complet est donc composée du dirigeant, de membres référents processus
appelés key-users, d’un chef de projet et d’un responsable technique. Cette équipe se
réunira depuis l’élaboration de l’expression des besoins, et jusqu’à l’implémentation
définitive de la solution ERP.
Réorganiser les compétences
Une fois l’équipe projet constituée, le dirigeant va vite se rendre compte – s’il n’a pas
pris les devants – que le chef de projet est phagocyté par le projet. En effet, il est
indispensable de réorganiser les fonctions et les tâches de la personne choisie. Il faut donc
mieux en avoir conscience avant que le projet ne démarre. Il est illusoire de croire qu’une
personne déjà positionnée à plein temps sur une fonction va pouvoir absorber toute la
gestion d’un projet ERP.
Dans la phase préimplantatoire, il est généralement possible de gérer la surcharge de
travail avec les ressources internes de l’entreprise. Cette phase est limitée dans le temps
(environs 3 à 6 mois). Un simple délestage de certaines tâches du chef de projet devrait
permettre d’arriver jusqu’au choix de l’ERP. Ce délestage peut également se faire sur un
consultant externe à l’organisation. Après cette phase, les choses se corsent. Pour exécuter
sa prestation, le prestataire retenu va avoir besoin d’informations, de données et de
disponibilité des personnes. Il n’est pas rare en PME de voir un chef de projet affecté à
50% de son temps sur la mise en œuvre d’un ERP. 50% de son temps, cela signifie qu’il
ne peut plus remplir sa fonction habituelle. En outre, la charge peut, lors de fortes
sollicitations, représenter jusqu’à 80%, voire 100%, du temps plein.
À ce stade, il est du devoir du dirigeant de mettre en place une réorganisation des
fonctions. En PME, cela passe souvent par le recours à des ressources externes à
l’entreprise. Il n’existe pas de solution miracle pour résoudre ce problème de ressources.
Le dirigeant dispose de 2 familles d’options : recruter un chef de projet ERP ou recruter
une ressource pour suppléer à la fonction du chef de projet interne. La meilleure option –
si les compétences internes le permettent – est d’opter pour le chef de projet maison.
Comme cela a déjà été précisé, il faut privilégier les connaissances métiers aux
compétences techniques. Dans le cas idéal, le chef de projet connaît parfaitement les
processus et tous les services de l’entreprise. Le recours à un chef de projet externe ne doit
se faire qu’en dernier ressort.
Alors, comment décharger le chef de projet interne de sa fonction d’origine ? Il n’y a
malheureusement pas de réponse universelle à cette question. Cela dépend essentiellement
du profil de la personne et de ses responsabilités. Si le chef de projet est informaticien, il
va falloir le décharger d’une partie de la gestion des incidents et des problèmes au
quotidien, ainsi que de la gestion du parc informatique. Si le chef de projet désigné est le
responsable administratif et financier de la société, la décharge est moins évidente. Peut-
être faut-il sous-traiter la comptabilité et la paie temporairement ?
Parmi les options prises par les dirigeants on retrouve par exemple le recrutement d’un
apprenti ingénieur (en alternance) ou le recours à la sous-traitance. Une autre piste
consiste à poser la question au prestataire sélectionné. En effet, si celui-ci est dans une
phase de développement de son activité, il recrute régulièrement des ingénieurs qu’il doit
former. Une mise à disposition de ces jeunes chefs de projet chez un client constitue un
partenariat gagnant-gagnant pour le prestataire et pour son client. Assurez-vous tout de
même que le candidat possède l’expérience minimale requise : une précédente mission ou
un stage de fin d’études par exemple. Il sera de toute manière encadré (à distance) par un
chef de projet expérimenté.
La question des ressources doit être abordée et traitée dès le début du projet ERP. Les
recrutements sont des processus longs et risqués dans une PME. Ils doivent être anticipés
au maximum.
 Bien rédiger son cahier des charges
Un cahier des charges pour un projet ERP doit comporter 4 grandes parties : « le
contexte du projet », « le SI existant », « le besoin » et « conduite de projet et
contraintes ».
Le contexte du projet
Le contexte du projet décrit les marchés, l’historique, les produits, les métiers et
l’organisation générale de l’entreprise. C’est dans cette partie que le PDG est interviewé
pour donner sa vision sur l’avenir de la société. En effet, on ne choisit pas un ERP pour 2
ans (même si cela existe), mais plutôt pour une dizaine d’années. Si l’entreprise connaît
des changements importants du type nouveaux marchés, nouveaux métiers, fusion,
démarrage de l’exportation, etc., il est important de le stipuler dans le cahier des charges.
En effet, ces modifications structurelles vont impacter le cœur de l’ERP.
Dans cette première partie, on définit également les objectifs stratégiques et
opérationnels du projet. Pourquoi avez-vous besoin d’un (nouvel) ERP ? Qu’attendez-
vous de cet outil ? Quelles sont les problématiques informationnelles à lever ? Il est rare
de descendre jusqu’à des objectifs chiffrés, surtout en PME, mais cela n’est pas interdit. Il
est possible par exemple de mesurer le « nombre de devis saisi par jour » qui est censé
progresser avec un outil de gestion plus moderne et plus ergonomique.
Plan type 1ère partie : Contexte du projet
But du document et domaine d’application : nature du projet et couverture fonctionnelle
macroscopique attendue.
L’entreprise, ses produits : description de la société, sa taille, ses marchés, ses évolutions,
son organisation, son métier, ses gammes de produits.
Projet de l’entreprise : les raisons et les conditions du changement, les objectifs
stratégiques et opérationnels attendus.
Volumétrie : on donne ici une idée des ordres de grandeur des informations de l’entreprise.
Par exemple, le nombre d’articles, de commandes, de clients… On retrouve également la
tendance de ces valeurs. Ces données permettent de mieux appréhender la typologie de
l’entreprise.
Système d’information existant
L’existant constitue la deuxième partie. Il s’agit d’expliciter l’état actuel des processus,
des logiciels utilisés et le l’infrastructure déployée. C’est une photographie du système
d’information de l’entreprise avant le projet ERP. Les processus mentionnés devront être
stabilisés. Si ce n’est pas le cas, il faudra commencer par résoudre les problèmes
organisationnels (voir le chapitre 5 « Analyse des processus existants, schéma cible »).
 Les processus décrits ne doivent pas être finement détaillés. Il s’agit de permettre aux
prestataires qui analyseront le cahier des charges de comprendre les problématiques
actuelles de l’entreprise. Un bon cahier des charges doit ouvrir des pistes, c’est-à-dire
permettre aux prestataires d’apporter des solutions aux problèmes posés. Il s’agit de ne pas
être trop directif (fermer des portes) en exprimant trop formellement des solutions
attendues. C’est la compétence de l’intégrateur d’analyser l’état de votre SI et de vous
proposer de nouvelles orientations.
Les processus macroscopiques peuvent être décrits sous forme de texte et/ou diagramme
de flux. On évitera la description trop longue des cas particuliers. Il est préférable de rester
dans le cadre du flux général. Il ne s’agit pas non plus de décrire les flux théoriques, mais
bien d’exprimer ce qui se passe réellement dans les différents services de la PME. Le
consultant externe est là pour aider l’entreprise à prendre du recul sur ses flux
d’information. Une trame d’audit est donnée au chapitre 5 : « Rédaction du cahier des
charges ».
Plan type 2e partie : Système d’information actuel
Environnement logiciel : description des logiciels, de leurs fonctions et des versions
utilisées (ERP, Bureautique, DAO, Paie, Compta, Groupware, etc.)
Environnement matériel : infrastructure en place (serveurs, postes clients, réseaux). Accès
distants (VPN, Citrix, TSE, etc.). Débits et connexion Internet. Technologie de téléphonie
IP le cas échéant. Terminaux de saisie (douchettes, PDA durci, écran tactile, etc.). Pour
les ordinateurs (serveurs, postes client, terminaux), on donnera les caractéristiques
fondamentales : système d’exploitation, processeur, RAM, espace disque disponible. La
virtualisation doit aussi être mentionnée.
Flux d’information : les flux doivent être présentés par service (la liste qui suit est non
exhaustive).
Bureau d’étude (création article, gamme, nomenclature, gestion documentaire),
Gestion de production (programme de production, calcul des besoins, planification,
ordonnancement, lancement, saisie des temps, gestion des OF, analyses),
Qualité (non-conformité, qualité fournisseur, amélioration continue, chiffrage de la non-
qualité, réclamation client, gestion documentaire),
Gestion commerciale (administration des ventes, devis, saisie des commandes, gestion des
tarifs, gestion des contrats, gestion des affaires, expéditions),
Gestion comptable et financière (comptabilité générale et analytique, immobilisations,
trésorerie, moyens de paiement, tableau de bord et outils d’analyse),
Gestion de la paie et des temps (temps de présence, primes panier, travail en équipe),
Gestion des achats (approvisionnement, commandes ouvertes, sourcing fournisseur,
demande de prix, relances, gestion des prix, réception matière, sous-traitance, transport),
Gestion des stocks (dépôts, gestion des emplacements, inventaires, étiquetage, préparation,
traçabilité),
Gestion de la maintenance (parc machine, planning des interventions, stocks spécialisés,
analyse des coûts).
Le besoin
En avant-propos de l’expression du besoin, on retrouve une les orientations
fonctionnelles du projet. Il s’agit de décrire les fondements du futur système
d’information. Sur quelles briques reposera-t-il ? Quels éléments doivent être gardés ? Par
exemple : on souhaite remplacer la gestion commerciale, les achats et la gestion de
production, mais on souhaite garder la comptabilité et nos PDA pour le suivi des temps de
production. C’est également dans cette partie que l’on aborde l’allotissement du projet.
Cela permet à l’entreprise de clarifier ses priorités et d’étaler dans le temps
l’implémentation de l’ERP. Il s’agit avant tout d’un souhait de l’entreprise et sera sujet à
discussion avec les prestataires. Voici un exemple de découpage de projet en 3 lots :
Lot 1 (démarrage 1er janvier) : Comptabilité
Lot 2 (démarrage 1er juin) : gestion commerciale et gestion de production
Lot 3 (1er janvier année suivante) : gestion de la qualité et GMAO
Figure 9 : exemple d’allotissement

Selon les interdépendances des modules de leurs ERP, les prestataires candidats peuvent
être amenés à proposer des découpages différents pour le même projet.
Vient ensuite l’expression du besoin. Cette partie étant la plus dense, il est important
d’être méthodique. Il y a plusieurs façons de décrire le besoin, la plus courante étant de
lister les fonctions attendues en les regroupant par module. Il existe sur Internet de
nombreux modèles de cahier des charges vous permettant de cocher les fonctions désirées.
Ces documents peuvent s’avérer utiles pour prendre connaissance des fonctions
disponibles dans un ERP, mais attention, si le cahier des charges est trop formaté, les
réponses des prestataires risquent d’être aussi très formatées. À ce stade, il est important
de rédiger des questions ouvertes à l’attention des candidats à l’appel d’offres. Les
questions ouvertes doivent refléter les grandes problématiques rencontrées par l’entreprise
dans son projet d’amélioration. Elles peuvent concerner tous les services de la société. Il
est demandé aux prestataires de répondre en 2 ou 3 lignes à chacune de ces questions.
L’objectif est simple : comprendre comment leur solution peut apporter une réponse à la
problématique rencontrée. S’ils le souhaitent, les éditeurs peuvent illustrer leurs propos
avec des captures d’écran de leur progiciel. Voici quelques exemples de questions
 ouvertes :
Comment mettre en place un suivi des temps au bureau d’étude ?
Comment exporter la nomenclature depuis notre CAO ?
Comment introduire la gestion à l’affaire dans nos processus ?
Figure 10 : exemples de questions ouvertes

La simple réponse « oui nous avons cette fonction » ou « non nous n’avons pas cette
fonction » n’est pas satisfaisante. Rappelez-vous qu’un commercial ne sait pas dire
« non ». Les cahiers des charges trop formatés appelleront des réponses irréalistes. Ce que
vous devez attendre d’une réponse au cahier des charges ce n’est pas seulement un budget
et une faisabilité, c’est aussi de comprendre les moyens qui seront mis en œuvre pour
répondre aux problématiques de l’entreprise.
Pour éviter de n’avoir que des « oui » en face de chaque fonction demandée, il existe
une approche plus subtile. Plutôt que de laisser le choix entre 2 valeurs (oui, non), on va
distinguer 5 possibilités (voir Figure 11) :
Standard : la fonction existe en standard dans l’ERP.
Paramétrable : la fonction demandée existe, mais nécessite un paramétrage de l’ERP.
Spécifique : cette fonction requiert un développement informatique supplémentaire.
Version n+1 : les ingénieurs développent actuellement cette fonction qui sera
commercialisée dans la prochaine version de l’ERP.
Non : l’ERP ne dispose pas de cette fonctionnalité.
On peut constater que le « oui » du commercial a été décomposé en 4 valeurs possibles.
Du point de vue de l’entreprise, seuls « Standard » et « Paramétrable » assurent la
faisabilité de la fonction. « Spécifique » impliquera des développements informatiques
dont la durée et la faisabilité sont rarement connues au moment de la rédaction de l’offre
de prix. Un commercial n’est absolument pas gêné de répondre « oui » lorsqu’il sait que la
fonction arrivera dans la prochaine version de l’ERP. Sauf que le client achète la version
actuelle, et n’est pas supposé migrer après un an d’utilisation. Il faut lire le « Version
n+1 » comme un « non ».
Enfin, le choix « non » a été conservé tel quel, et sera utilisé par les commerciaux
honnêtes, mais toujours avec parcimonie.

Fonctionnalités Std Param Spéc N+1 Non

Gestion multidevise

Codification article
 sur 18 caractères

Gestion des DLUO

Figure 11 : organisation du besoin dans le CDC

Lorsque les prestataires recevront l’appel d’offres, ils devront cocher l’une des 5 cases
pour chaque fonction. Il arrive souvent que pour détailler la réponse, ils ajoutent des
commentaires sous l’intitulé des fonctionnalités. C’est à ces détails que l’on reconnaît le
prestataire qui a investi du temps de celui qui s’est contenté du strict minimum.
En synthèse, retrouvez un exemple de plan pour cette troisième partie.
Plan type 3e partie : le besoin
Orientations du nouveau système : c’est le chapitre de transition entre le système actuel et
le besoin. Il s’agit de citer les modules qui sont recherchés par l’entreprise, et de préciser
les briques du SI exclues du besoin. On y trouve également l’allotissement.
Questions ouvertes : liste des grandes problématiques qui émanent du projet d’amélioration
de l’entreprise.
Détails des fonctionnalités demandées : tableaux des fonctions selon le modèle présenté en
Figure 11. On organise les informations par module fonctionnel. En voici une liste non
exhaustive :
»Généralités et ergonomie
»Données techniques
*Fiche article
*Nomenclature
*Gamme
»Ventes
*Gestion de la relation client
*Devis et gestion tarifaire
*Gestion des commandes de vente
*Facturation
*Expéditions
*Statistiques et analyses commerciales
*SAV
*Gestion des points de vente
 *Vente en ligne
»Qualité – sécurité – environnement
»Achats
*Achats, approvisionnements
*Bilan, statistiques achats
*Administratif, facture fournisseur
*Réception, magasins
»Production
*PDP, simulation des besoins
*Ordonnancement, lancement, charge et capacité
*Suivi de fabrication et bilan de production
*Gestion des stocks
*Maintenance (GMAO)
»Gestion des ressources humaines et gestion financière
*Gestion des ressources humaines
*Gestion comptable, financière et contrôle de gestion
*Immobilisations
*Gestion de la paie et des temps
»Autres modules transversaux
*Connexion Groupware
*Gestion électronique de la documentation
*Gestion de projets
*Gestion d’affaires
*Reporting (BI)
Figure 12 : Plan type d’une définition de besoin

Besoins matériels : on précise si l’offre du prestataire doit prévoir (chiffré séparément)

une mise à niveau des postes clients, de nouveaux terminaux mobiles ou bien des
investissements sur le serveur ou le réseau. Dans tous les cas, le prestataire devra
remettre un document de spécifications matérielles minimales pour l’exploitation de sa
solution.
 Contraintes et conduite du projet
La 4e et dernière partie du cahier des charges aborde la conduite du projet ERP et les
contraintes d’interfaçage avec le reste du système d’information. L’interfaçage est un
élément important qui doit être suivi avec la plus grande attention. Avoir des données
intègres dans un SI maîtrisé évite souvent les multiples saisies. On précisera dans cette 4e
partie tous les mécanismes de synchronisation nécessaires entre l’ERP et les autres
modules du SI, qu’ils soient du même éditeur ou non. L’attention est portée sur la DAO, la
comptabilité, la paie, un site de vente en ligne ou éventuellement une CRM déjà installée.
Les contraintes aborderont aussi les problématiques d’archivage et de traçabilité de
l’information si le métier de l’entreprise impose certaines normes dans ce domaine (ex. :
industries agroalimentaires, aéronautiques, etc.).
Si le projet ERP concerne un groupe d’entreprises, c’est dans cette partie que l’on
aborde les contraintes liées à l’aspect multisociété : rôle de chaque site, flux financiers,
bases de données communes ou partagées, flux physiques et d’information réciproques,
etc.
Question centrale pour obtenir un chiffrage précis du projet, il faut donner dans le cahier
des charges toutes les informations nécessaires pour dimensionner le nombre de licences
utilisateurs. Voir le sous-chapitre « Contrôler le contenu des offres » ci-après pour plus
d’explications.
Le cahier des charges adresse ensuite les aspects liés à l’intégration et à l’exploitation de
l’ERP. On abordera les niveaux de services attendus (performance, disponibilité), la
facilité d’exploitation, la sécurité des données (procédure de sauvegarde), la
documentation qui sera remise et celle qui sera accessible via le logiciel, le principe de
formation attendu (sur site, découpage par groupe, etc.)
Concernant les informations de mise en œuvre de l’ERP, on rappellera le contenu de la
prestation attendue (fourniture des logiciels, installation, paramétrage, tests avec jeu
d’essai, récupération des données, mise en place de la procédure de sauvegarde,
formation, support, maintenance, garantie, mises à jour, etc.).
Enfin, le cahier des charges doit se solder par la présentation du rétroplanning souhaité
ayant pour objectif la date de démarrage avec le nouvel ERP.
La 4e partie du cahier des charges aborde des éléments qui deviendront contractuels par
la suite. Pour cette raison, il est préférable de laisser sa rédaction à un consultant ou à une
personne qui a l’expérience de projets ERP.
Plan type de la 4e partie
Contraintes :
Interfaçage (on précise les liens avec les autres composants du SI. Qui est garant de
l’interface? Qui pilote le format des échanges ?)
Traçabilité des données et archivage (pour les industries devant répondre à des normes de
conservation documentaire)
Gestion multisociétés (on explique les liens entre les sociétés, le partage des données et les
flux croisés)
Licences : on détaille dans cette partie le nombre d’accès nécessaires pour l’exploitation de
l’ERP. On distingue les licences complètes des accès pour les terminaux d’ateliers. On
peut aussi détailler les licences par service.
Aspects complémentaires :
Performances (l’entreprise mentionne ses exigences en temps de calcul, en exploitation de
l’infrastructure, etc.)
Facilité d’exploitation (adéquation des usages avec les compétences internes de
l’entreprise. Ex. : y’a-t-il un informaticien dans la société ?)
Sécurité (y’a-t-il des procédures de sauvegarde, faut-il s’inscrire dans un PRA ?)
Documentation : on précise dans cette partie la documentation attendue avec l’ERP
(manuel d’utilisation, aide en ligne)
Formation : on décrit le principe de formation attendu (formation de tous les utilisateurs ou
bien uniquement des key-users). On précise le nombre de personnes qu’il faudra former,
ainsi que les modules qui leur seront présentés. Ne pas oublier de rajouter la formation
« administrateur » pour la ou les personnes qui seront chargées de l’édition des états, des
écrans et de la gestion des profils des utilisateurs.
Prestation de mise en œuvre :
Installation (on liste les prestations qui seront de la responsabilité du prestataire. Ex :
fourniture les logiciels, installation, paramétrage, tests, récupération des données, mise en
place de la sauvegarde)
Adaptation, paramétrage (on précise la souplesse que doit avoir la solution pour accepter
les évolutions en cours de vie)
Essais, démarrage (on précise le cadre de la recette et le contexte du jeu d’essai de
validation)
Support, maintenance, garantie (ce paragraphe fait apparaître les exigences attendues en
matière de support annuel. Ex. : délais d’intervention, niveaux de service, présence d’un
support téléphonique).
Évolutions futures (on expose les modalités techniques de mise à jour du progiciel. Ex. :
 tests sur serveur « bac à sable », arrêts du serveur possibles, etc.)
Planning : il s’agit là de votre vision du rétroplanning avant démarrage avec le nouvel ERP.
Celui-ci doit tenir compte de vos ressources, des périodes de congés et des impératifs
métiers et financiers. Le prestataire sélectionné vous rendra à son tour son planning de
mise en œuvre, qui donnera tous les détails du phasage du projet.

ACTIONS DATES RÉALISATION

Démarrage avec nouvel ERP 1er janvier 2016

Choix du prestataire, contrat Févr.-mars 2015

Démonstrations, jeux d’essai Nov.-déc. 2014

Limite réception des réponses 18 novembre 2014

Envoi appel d’offres 10 octobre 2014

Figure 13 : exemple de rétroplanning

Contrôler le contenu des offres

Composants d’une offre
Chaque candidat qui choisit de répondre à l’appel d’offres vous enverra avant la limite
fixée dans le planning un ensemble de documents visant à présenter son logiciel, son
expertise et à faire une première estimation de prix. Les documents reçus (par courrier ou
par e-mail) peuvent être nombreux et variés et diffèrent selon les candidats. Le nombre de
pages cumulé peut atteindre la centaine par candidat. N’hésitez pas à confier cette lecture
à un prestataire qui saura en extraire l’information pertinente. Parmi les documents reçus,
on retrouve communément :
Le cahier des charges complété (réponse au cahier des charges) : vérifiez que les questions
ouvertes ont été répondues et que les cases fonctionnelles ont été cochées.
La présentation du prestataire : ses produits, ses marchés, ses compétences, etc.
La méthodologie de projet : présentation des étapes mises en œuvre pour arriver au besoin
exprimé, structuration des équipes et de la relation client-éditeur. Ces éléments peuvent
être formalisés dans un Plan d’Assurance Qualité (PAQ).
La plaquette fonctionnelle : présentation des fonctionnalités de l’ERP, avec des captures
d’écran.
Les prérequis techniques : ensembles des spécifications matérielles requises pour déployer
la solution.
La proposition financière (licences ou location) : détails du projet de prix, au format
demandé dans le cahier des charges.
Le contrat de support / maintenance
Le contrat de licences d’utilisation
Le contrat de service et les engagements de services.
Les Curriculums Vitae des chefs de projets potentiels.
Une proposition de planning
Des références, et cas d’étude
Les conditions générales et particulières de vente
Ces différents documents ne sont pas forcément présents dès l’appel d’offres. Certains,
comme les contrats peuvent être fournis que dans les phases finales de sélection, voire
après le choix du prestataire.
Format attendu de l’offre financière
Pour comparer les offres financières des différents prestataires entre elles, il faut avoir
précisé un format de réponse dans le cahier des charges. A minima, exigez un découpage
comme stipulé dans le tableau ci-dessous (Figure 14). Vous devez spécifier dans le cahier
des charges le nombre de licences simultanées en accès standard et le nombre de licences
pour les saisies ateliers. Mieux encore, précisez si vous le pouvez, le nombre de licences
nécessaires par service de l’entreprise.
Assurez-vous que tous les prestataires partent sur les mêmes quantités de licences, car
certains essaient de diminuer artificiellement leur offre en diminuant le nombre de licences
nécessaires. Ils ont peut être raison de dire qu’il ne vous faut pas autant de licence, mais le
premier but est de comparer les offres financières entre-elles, pas de déterminer le nombre
optimal de licences simultanées nécessaires.
Comparez également les nombres de jours correspondants à la prestation et à la
formation. N’hésitez pas à demander des explications aux prestataires si vous constatez
des écarts importants entre deux offres.

Nom du prestataire Dev2000

Nom du progiciel Logisoft

Total Licences 23000€

Total Prestation 17500€ 27 Jours

Total Formation 12000€ 18 Jours

Total Autre 0 €

Total Investissement 52500€ 45 Jours

Annuité 4830 € 21 %

Figure 14 : Format minimaliste d’une offre financière

Tableau comparatif des offres

Il existe un nombre important de paramètres à prendre en compte dans le choix d’un
ERP. Même si certains chefs d’entreprise se fient à leur première intuition avec des
phrases du genre « j’ai un bon feeling avec ce prestataire », vous allez vous marier avec
une société pour plusieurs années. Et ce n’est pas le commercial que vous verrez le plus
souvent. Les critères de choix doivent aborder le progiciel lui-même, mais aussi la société
éditrice et intégratrice ainsi que les intervenants.
Le plus simple est de tenir vos analyses dans un tableur informatique. Passons en revue
les différents sujets (onglets) de cette analyse comparative. Ils sont tous bâtis selon le
même principe : on met les candidats en colonne, et les critères en ligne.

Figure 15 : Exemple de tableau d’analyse des offres

Chiffrage
Le chiffrage est souvent considéré à tort comme le critère de comparaison le plus
important. Passé le premier filtre des offres surdimensionnées, le détail du chiffrage prend
toute son importance dans les phases finales de choix, après avoir validé tous les autres
aspects. Cet onglet sera très utile au moment de la négociation finale, étape qui peut durer
un mois et comporter de multiples révisions des offres.
Cette fiche doit reprendre de manière claire les données financières fournies par les
prestataires. On séparera les montants liés à l’investissement de ceux liés au
fonctionnement.

Nombre de licences standard x

Nombre de licences atelier x

Mode gestion licence Poste/Site/

Accès simultanés

Total Licence ERP €

Total Licences autres €

Total Prestation €

Total Formation €

Total Autre €

Figure 16 : analyse des investissements

La somme des 5 dernières lignes donne l’investissement en première année (hors

maintenance). Le tableau ci-après regroupe quant à lui les annuités (ou mensualités selon
votre choix) ainsi que les coûts unitaires des journées de prestation. On rajoutera une ligne
supplémentaire pour les coûts locatifs de la solution si vous optez pour un ERP en mode
SaaS.

Maintenance annuelle ERP 21 %

Maintenance annuelle ERP 2500 €

Maintenance autre 300 €

Coûts journaliers consultant 650 €

Coûts journaliers direction 850 €

Coûts journaliers paramétrage 550 €

Coûts journaliers Formation 650 €

Figure 17 : coûts de fonctionnement et coûts journaliers

Pour être complet, l’analyse financière doit aussi comporter les frais de déplacement :
forfaitaires ou kilométriques, les frais de bouche et d’hébergements des intervenants. Ces
éléments constituent aussi des points de négociation commerciale.
Enfin, on considérera les investissements matériels (nouveau serveur, douchettes code à
barres, terminaux, etc.) s’ils sont rendus impératifs par le choix d’une solution en
particulier, et les coûts des options à positionner en marge.
Références
Le deuxième onglet va vous permettre de recenser les références clients données par les
prestataires, et idéalement aussi celles qu’il n’a pas données. Questionnez-le sur ses clients
installés dont le métier est proche du vôtre, pour des tailles de structure identiques.
 Une erreur (volontaire) est fréquemment commise quand le projet est porté par un
intégrateur et non un éditeur. Ceux-ci ont la fâcheuse tendance à s’octroyer les références
de l’éditeur, même si les projets ont été menés par une autre société intégratrice. Certes,
l’information a de la valeur, mais pas autant que s’ils avaient eux-mêmes fait le travail.
Demandez-leur de préciser pour chaque référence client donnée, s’il s’agit d’un dossier
traité par eux ou par un confrère.
À ce titre, votre tableau des références clients doit comporter deux parties : les
références « intégrateurs » et les références « éditeurs ». Dans ces tables, mentionnez
également les tailles des structures clientes, ainsi que les modules installés.
Avec l’accord du prestataire, cet outil vous servira à contacter ou visiter les clients
référencés. Un guide d’entretien est donné plus loin dans « Choisir son prestataire ».
Enfin, ayez conscience que vous pourrez difficilement visiter ou vous entretenir avec un
concurrent direct à propos d’un progiciel.
Identité
Qui est vraiment votre prestataire ? Cet onglet vous permettra de catégoriser les
candidats selon leur typologie d’entreprise. En effet, la relation avec un éditeur de type
grand groupe, côté en bourse, ne sera pas la même qu’avec un éditeur régional à
l’actionnariat familial. Cette fiche vous permettra de déterminer le rapport de force avec
les prestataires et l’adéquation à vos valeurs d’entrepreneur.

Siège social Lieux

Création de l’entreprise Date

CA n-1, résultat net € €

Nb client installé
(pour ce logiciel)

Nb collaborateurs

Présence régionale Lieux

Actionnariat Famille, collaborateurs, sociétés, financiers…

Groupe Nom

Taille Groupe

CA groupe €
Société/Groupe coté ? Oui/non

Figure 18 : tableau comparatif des identités

Pour les dirigeants de PME, la pérennité de la relation avec le prestataire est

primordiale. Mais aujourd’hui, il est difficile, à moins d’être extralucide, de prédire le
futur d’un éditeur ou d’un intégrateur. Les critères de viabilité seront les mêmes que pour
toute autre société. Certaines entreprises effectuent toujours des contrôles de solvabilité
avant de s’engager avec un prestataire. La taille de l’éditeur joue aussi un rôle, mais aussi
bien les grands que les petits sont sujets à des opérations de rachat. Il est préférable de
s’attarder sur les critères d’actionnariat plutôt que sur le nombre de salariés.
Fonctionnel
Il s’agit dans cet onglet de lister les atouts et les faiblesses des solutions analysées. Ces
points sont enrichis au fur et à mesure des rencontres avec les prestataires. On commence
à le remplir à partir du document de réponse au cahier des charges.

Nb « Non » 5

Nb « N+1 » 2

Nb « Spécifiques » 12

Points forts multidevise

Points faibles interface en anglais

Points à éclaircir

Spécifiques

Autres points clés

Figure 19 : tableau comparatif fonctionnel

Le nombre de « non », « n+1 » et de « spécifique » donne tout cumulé le nombre

d’écarts avec le cahier des charges. Les spécifiques sont soit chiffrés séparément, soit pas
chiffrés du tout, dans l’attente de davantage de précisions.
Les points forts et points faibles seront positionnés après les premières démonstrations.
Quant aux points à éclaircir, il s’agit des demandes formulées par les prestataires dans le
document de réponse au cahier des charges, et vos demandes particulières. Profitez des
démonstrations pour clarifier ces éléments.
Gestion de projet
 Les informations de gestion de projet sont rarement analysées dans le détail par les
entreprises. Pourtant, elles contiennent beaucoup d’éléments précis qui justifient une
partie des coûts du projet.
La réponse à l’appel d’offres doit préciser avant toute chose la méthodologie employée
pour mettre en œuvre l’ERP. La démarche et les ressources associées (côté prestataire et
côté PME) doivent être décrites dans un document joint à la réponse. Voir
« Méthodologies de gestion de projet - Chapitre 5 » pour plus d’explications. Vous devez
ensuite vérifier la présence d’une ébauche de planning, et la prise en compte du phasage
du projet. En effet, l’allotissement n’est pas toujours intégré au chiffrage. Certains
prestataires se limitent à chiffrer le lot 1. Vous devez clairement exprimer votre intention
de recevoir une offre complète, tout lot confondu (licences et coûts de prestation).
Enfin, cet onglet permet de mesurer la charge prestataire annoncée sur différents points :
la prestation, la formation et la reprise des données. Le focus est mis sur ce dernier point,
car les méthodologies sont variées. Elle peut se faire sous la responsabilité du prestataire
ou du client ou conjointement. Toute charge de travail non mentionnée ici sera fatalement
reportée sur la PME.

Allotissement suggéré

Type de gestion de projet

Planning Durée, dates

Mode de reprise des données

Durée reprise des données jours

Charge formation jours

Charge Prestation jours

Pratique de mise à jour Fréquence, méthodologie

Figure 20 : comparaison des gestions de projet

Technique
L’onglet technique a pour vocation le recensement des technologies employées et des
configurations logicielles et matérielles recommandées par le prestataire concernant le
serveur et les postes clients.

Techno de développement .Net, J2EE, Oracle, etc.

Techno de SGBD MySQL, SQLServer, Oracle, etc.

Prérequis Serveur RAM, Processeur, OS, etc.

Prérequis Poste client RAM, Processeur, OS, etc.

Figure 21 : comparaison technique des offres

L’analyse des prérequis justifiera ou pas l’investissement dans du matériel neuf. Les
coûts en matériel peuvent ne pas être négligeables. La sécurité des données coûte cher.
Ergonomie
L’ergonomie est un sujet plutôt récent dans l’histoire du développement logiciel. Peu
d’éditeurs adoptent une démarche structurée et scientifique pour concevoir les écrans et
penser les fonctionnalités de leurs outils.
Du côté des utilisateurs, c’est un peu la même chose. On ne prend pas toute la mesure de
l’importance d’une bonne ergonomie. L’ERP deviendra pour beaucoup de salariés l’outil
principal, celui de tous les jours. Une ergonomie travaillée participe à la prise en main
rapide et optimise la productivité administrative. Il ne s’agit pas que d’une question
subjective. Il existe des critères permettant la mesure de l’ergonomie : l’adéquation du
système au public et au métier, l’efficacité de l’interface, la liberté de l’utilisateur, la
présence de l’assistance, la lisibilité et l’homogénéité de l’information. Voici quelques
questions qui peuvent être notées par chacun des membres de l’équipe projet suite aux
démonstrations.

[Adéquation] Aspects linguistiques en adéquation avec vocabulaire de l’entreprise -2 à +2

[Adéquation] Adéquation du système avec le public cible (âge, expérience TIC, culture) -2 à +2

[Efficacité] Temps de réponse général -2 à +2

[Efficacité] Minimisation du nb de clics pour accomplir une tâche -2 à +2

[Efficacité] Densité informationnelle, regroupement des infos -2 à +2

[Liberté] Trier, comparer l’info à tout moment -2 à +2

[Liberté] Annuler une opération, revenir en arrière -2 à +2

[Assistance] Guidage et navigation (on sait où cliquer) -2 à +2

[Assistance] Aide contextuelle -2 à +2

[Lisibilité] Taille des éléments, lisibilité -2 à +2

[Homogénéité] Homogénéité des formes, zones, couleurs, icônes, typo, etc. -2 à +2

Figure 22 : questionnaire ergonomie logicielle

Global
Un dernier onglet vient compléter l’analyse comparative des prestataires. Il s’agit du
récapitulatif global. À l’aide de cette fiche, on distingue les bons prestataires des mauvais
sur chaque critère vu précédemment.

Investissement Somme des coûts de licence, prestation, formation

Annuité Coût de la maintenance annuelle

Références Références de clients installés probantes

Typologie d’entreprise Adéquation aux valeurs et au type d’actionnariat

Nb Écarts avec le CDC Nombre de Non, N+1 et Spécifique

Date d’Accusé de réception de l’offre Date

Date et contenu des contacts Date, information

Date d’envoi de la réponse Date

Figure 23 : tableau comparatif final

Les dates permettent indirectement de mesurer le professionnalisme des prestataires. Un

prestataire qui répond toujours en retard saura-t-il conduire un projet dans les délais ? Cela
dit, il existe aussi des retards justifiables.
Chaque case sera surlignée d’un code couleur. On utilisera un panel de couleur allant du
vert au rouge (au moins 4 à 5 nuances).
Grâce à cette synthèse et selon l’importance (la pondération) que vous donnez à chaque
critère, vous pourrez choisir d’écarter certaines solutions de l’appel d’offres.
Choisir son prestataire
Critères de choix
En guise de conclusion, voici quelques points qui vous aideront dans le choix final du
prestataire. Tout d’abord, n’hésitez pas à rencontrer plusieurs prestataires. Même si ceux-
ci rechignent à l’idée d’avoir trop de concurrents en lice, c’est pour vous l’occasion de
faire une veille fonctionnelle approfondie et de parfaire l’idée de votre besoin. Privilégiez
les sous-traitants adaptés à votre taille d’entreprise, le rapport de force n’en sera que plus
équilibré. « Adapté » ne veut pas dire de taille identique. Les éditeurs et intégrateurs
n’évoluent pas sur la même échelle salariale que les PMI.
Dans les phases finales, vous demanderez à visiter ou prendre contact avec des clients
donnés en référence. Idéalement, vous tâcherez d’identifier des références qu’il ne donne
pas. (Voir « Questionnaire de visite », plus loin). Ces visites vous permettront de mesurer
ce qui a été réellement fait. Cela permet de temporiser toutes les promesses contenues
dans la réponse au cahier des charges et les belles paroles des commerciaux.
Sur le plan financier, veillez à bien analyser les bilans et les comptes de résultat de
l’intégrateur et de l’éditeur. Un éditeur financièrement sain peut cacher des intégrateurs en
situation difficile.
Enfin, prenez votre temps pour la décision. Si rien ne vous presse, ne signez pas chez le
mieux-disant ou chez le dernier qui a parlé. Prenez garde aux effets de promotion.
Analyse SWOT
SWOT est un acronyme anglais signifiant Strengths Weaknesses Opportunities Threats,
soit littéralement Force Faiblesse, Opportunités, Menaces. Il s’agit d’un mécanisme
d’analyse matriciel très simple à mettre en œuvre, qui peut – entre autres – permettre de
comparer des solutions ERP ou des prestataires.

Positif Négatif

Interne Force Faiblesse

Externe Opportunités Menaces

Figure 24 : matrice SWOT

Le principe est le suivant : dans un tableau comme ci-dessus, vous allez classer les
éléments marquants selon leur origine. Si les éléments concernent le prestataire ou bien
la solution elle-même, inscrivez les points forts et les points faibles dans la ligne
« Interne ». Si les éléments concernent davantage l’environnement du progiciel ou de son
éditeur, inscrivez-les sur la ligne « externe ». Voici un exemple d’analyse SWOT pour un
logiciel ERP quelconque.

Positif Négatif

Interne Unicité de la base client Pas de gestion de la Qualité

Interface avec le site web adaptable Pas d’écran d’accueil personnalisable

Externe Même éditeur que la comptabilité Nécessite l’achat de licences de base de données
 Figure 25 : exemple d’utilisation d’une matrice SWOT

Questionnaire de visite
Avant contractualisation, il est primordial de contacter des clients du prestataire
pressenti. Voici quelques questions pour préparer efficacement une visite ou un entretien
avec un client utilisateur :
Caractériser et dimensionner leur projet :
Nombre de licences installées
Nombres de jours de prestations, de formations
Quelle couverture fonctionnelle (modules installés) ?
Qui étaient les autres finalistes ? Pourquoi ce choix ?
Phase avant démarrage :
Comment s’est passée la reprise des données ? Quelle aide a apportée le prestataire à ce
sujet ?
Qui était le chef de projet, côté prestataire ? Quels sont ses points forts ? Ses faiblesses ?
Le planning initial a-t-il été tenu ? Sinon pourquoi ?
Quel temps a été consacré en interne au projet ? Par le chef de projet interne ? Par les autres
salariés ?
Quel est le rapport de force avec le prestataire (sa souplesse)
Démarrage :
•Comment jugent-ils le support du prestataire?
•Est-ce que le budget initial a été dépassé ?
•Comment évolue la relation avec le prestataire ?
•Comment se déroulent les mises à jour ? À quelle fréquence ?
Négocier son contrat
Pour être plus précis, il faudrait écrire « Négocier ses contrats ». En effet, un projet ERP
ne peut se solder par un seul contrat. Il faut distinguer le contrat de prestation
(installation, paramétrage, développement spécifique, formation) qui est ponctuel, du
contrat de support/maintenance ou de location en mode SaaS qui eux sont récurrents.
Le contrat ponctuel porte sur une version du progiciel en particulier (en général celle
présentée en démonstration), alors que le contrat de maintenance accompagnera le
progiciel au fil des années et des révisions.
 Avant de négocier, prenez bien soin d’analyser tous les documents qui vous seront
fournis. Au besoin, faites vous accompagner d’un juriste pour cette étape.
Le contrat de prestation
Les négociations portent essentiellement sur ce type de contrat. En effet, les prestataires
sont beaucoup moins enclins à faire des efforts sur les contrats récurrents que sur les
contrats ponctuels. Classiquement, ce sont les tarifs de licences qui sont souvent négociés,
en fonction du volume. Il est même possible de négocier une tarification préférentielle
jusqu’à une certaine date, après le démarrage du projet (histoire d’ajuster le nombre de
licences simultanées après coup). Certains prestataires – qui ont une tarification modulaire
– vont jusqu’à offrir certains modules fonctionnels. Concernant les autres prestations, il
s’agit surtout de ne pas rogner sur le nombre de jours alloué, mais bien sur le tarif
journalier.
N’oubliez pas de vérifier les frais de déplacement, de bouche et d’hébergement associés
aux journées de travail dans vos locaux. Certains intégrateurs les incluent dans le tarif
journalier, d’autres vous enverront les factures correspondantes. Les montants en fin de
projet peuvent ne pas être négligeables !
Pour la mise en œuvre d’un ERP, un contrat de prestation ponctuelle doit faire référence
à votre cahier des charges. Il s’agit d’une couverture en cas d’échec du projet. Voici ci-
dessous un modèle de contrat, non exhaustif, qui permet de vérifier les clauses du
document que vous aurez à signer.
0 - PRÉSENTATION DES PARTIES
1 - OBJET DU CONTRAT
2 - PIÈCES CONSTITUTIVES DU CONTRAT
- Cahier des charges du client et ses annexes
- Le « Plan d’Assurance Qualité du Projet » (PAQP) du prestataire (indicateurs de suivi,
tableau de bord, revue régulière, traitement des alertes, procédure d’escalade).
- Le rapport d’analyse
- Le plan d’architecture technique : rapport de l’architecte systèmes et réseaux
- Autres pièces en annexes
3 - CONDITIONS ADMINISTRATIVES
- Situation juridique et fiscale du prestataire
- Sous-traitance
4 - DÉLAIS, PLANNING, LIVRAISONS
5 - MODALITÉS D’EXÉCUTION DES PRESTATIONS
- Structure et suivi du projet
- Relations entre les parties
6 - DOCUMENTATION
7 - FORMATIONS
8 - RÉCEPTIONS
- Généralités et définitions
- Réception provisoire
- Réception définitive
9 - GARANTIE
- Étendue de la garantie
- Conditions applicables à la garantie
- Fin de la période de garantie
10 - ASSISTANCE
- Support
- Priorité et engagement de service
- Implémentation des correctifs
- Solutions de contournement et définitives
11 - RESPONSABILITÉ
- Responsabilité civile
- Responsabilité contractuelle
- Force majeure
12 - ASSURANCES
13 - DÉFAILLANCE
14 - RÉSILIATION
15 - CONFIDENTIALITÉ
16 - TARIFS ET CONDITIONS GÉNÉRALES
17 - CLAUSES GÉNÉRALES
- Cadre général d’exécution du contrat
 - Clause de sauvegarde
- Autres clauses
18 - LITIGES
19 - CONDITIONS PARTICULIÈRES
Figure 26 : modèle de contrat de prestation ponctuelle

Le contrat de service (support, maintenance)

Le contrat de support peut être inclus dans le contrat de prestation (voir item n°10 du
modèle ci-dessus), on bien être traité à part.
Ce contrat est calculé à partir d’un pourcentage du montant des licences (pour le mode
achat de licences). Il sera très difficile de faire baisser ce taux en phase de négociation. De
plus, s’il y a eu négociation sur les licences, c’est souvent le montant d’avant remise qui
sera utilisé pour le calcul du contrat de maintenance.
Dans un tel contrat, l’important est de vérifier les engagements de service du prestataire
(horaires d’ouverture de la hotline, délais d’intervention, etc.). Par la suite, il faudra bien
sûr se donner les moyens de les vérifier. Une réunion annuelle sur les services proposés
n’est pas superflue. L’attention doit être portée sur la reconduction tacite des contrats. Au
mieux, on essaiera d’exclure cette clause, mais peu de prestataires accepteront.
Le contrat de location et d’hébergement
Si l’entreprise ne souhaite pas investir dans un achat de licence, elle a maintenant le
choix d’opter pour le mode hébergé (en fonction de la solution choisie). L’hébergement et
la fourniture du service sont régis par un autre contrat dont vous trouverez un modèle ci-
dessous. Les niveaux de service sont beaucoup plus complexes à mesurer. Il est impératif
de tenir un tableau de bord afin de mesurer la performance de l’hébergement.
1 - CONTEXTE ET OBJECTIFS
2 - DESCRIPTION DU PÉRIMÈTRE ET DES SERVICES
3 - DESCRIPTIF DETAILLE DES SERVICES FOURNIS, DES RÔLES ET DES
RESPONSABILITÉS DES PARTIES
- Support
- Maintenance
* Les typologies de maintenance
* Livraisons
* Dispositif d’assistance dédié aux mises en production
* Suivi des problèmes
* Suivi de la sécurité
* Suivi de la disponibilité
* Suivi de la capacité
* Suivi de la continuité
- Formation et prestations complémentaires
4 – DÉFINITION DES NIVEAUX DE SERVICE
- Délais d’intervention
- Période d’intervention
- Suivi du support
- Objectifs en termes de maintenance corrective
- Objectifs en termes de maintenance évolutive
- Objectifs en termes de mises en production
- Objectifs en termes de suivi du changement
- Objectifs en termes de suivi de la disponibilité
- Objectifs en termes de suivi de la capacité
5 – PILOTAGE ET SUIVI DE LA QUALITÉ DE SERVICE
- Suivis opérationnels mensuels
- Suivis contractuels trimestriels
- Fiche de performance
- Primes et pénalités
6 – RESPONSABILITÉ
- Responsabilité civile
- Responsabilité contractuelle
- Force majeure
7 – ASSURANCES
8 – DÉFAILLANCE
9 – RÉSILIATION ET RECONDUCTION
10 – CONFIDENTIALITÉ
 11 – TARIFS ET CONDITIONS GÉNÉRALES DU PRESTATAIRE
12 – CLAUSES GÉNÉRALES
- Cadre général d’exécution du contrat
- Clause de sauvegarde
- Autres clauses
13 – LITIGES
14 – CONDITIONS PARTICULIÈRES
Figure 27 : Modèle de contrat de service récurrent

L’important dans les contrats de service récurrent est de demander la séparation des
contrats de maintenance des contrats de location. Trop de prestataires ont tendance à
constituer une offre packagée illisible pour le client. On doit pouvoir négocier séparément
ces 2 aspects, qui sont tenus par des engagements de niveaux de service différents.
Piloter son prestataire informatique
Pour piloter efficacement son prestataire en phase d’exploitation d’un ERP, encore faut-
il être organisé en interne. Tous les salariés ne doivent pas contacter le service support de
l’éditeur. La centralisation des problèmes et des demandes en interne passe toujours par le
référent, c’est-à-dire le responsable informatique ou le chef de projet. Celui-ci aura à sa
disposition un outil de suivi des incidents. Plusieurs logiciels répondent à ce besoin et
sont utilisables sous licence libre (exemple : GLPI). Plus simplement, vous pouvez aussi
utiliser un tableur. Tous les incidents seront inscrits dans cette base avant d’être soumis au
prestataire. Après quelques mois d’utilisation, la base commencera à devenir une source
de références, à consulter avant de créer un nouvel incident (base de connaissances).
De son côté, le référent se charge de répondre aux utilisateurs, ou à défaut d’escalader
les demandes vers le prestataire. À ce titre, il se doit d’être réactif et de pouvoir contacter
le support très rapidement. Enfin, le référent est responsable de la clôture des incidents, et
de la communication vers les utilisateurs.

Fiche N° Date 101 09/06/2014

Demandeur F. Martin

Libellé Colonne 5 de l’état « Chiffre d’affaires par commercial »

pas assez large

Projet ERP

Impact Personne/Service/Projet
Urgence Sans/Gênant/bloquant/majeur

Type Incident/intervention/demande

Pris en charge par J. Rémy

Statut Qualifié/en-cours/en-test/à déployer/clos/abandon

Date réalisation
prévue

Nb de relances

Temps passé 0,05

Date clôture 12/06/2014

Clos par J. Rémy

Conclusions Colonne élargie dans le modèle

Fiches cousine

Figure 28 : exemple de fiche de suivi d’incidents

Tous les engagements de service seront suivis régulièrement dans des tableaux. Seront
contrôlés à la fois les niveaux de service et les tendances au fil des mois. Le référent a un
rôle d’alerte et d’anticipation des risques liés à fourniture de services.
Mesurer la réussite du projet
Le constat d’une réussite rapide dépendra essentiellement de votre point de départ.
Observez les endroits où les pertes de temps avaient été constatées (double saisie,
recherche trop longue de l’information, etc.). Le premier critère de réussite d’un ERP sera
l’amélioration de la productivité administrative. Combien de factures sont saisies par jour,
combien de devis partent chez les clients ? Combien de temps me prend la transformation
des BL, la saisie des commandes ?
Mais pour savoir sur le long terme si un projet ERP a vraiment simplifié et amélioré
l’organisation entre les services de l’entreprise, le meilleur indicateur est encore le
nombre de tableurs utilisé par les salariés. Faites la mesure avant et après le projet ERP.
Une diminution nette sera gage de réussite.
N’oubliez pas que le premier intérêt d’un ERP est la mesure de son activité. Il est donc
l’élément essentiel d’une politique d’amélioration continue.
1 Source : Panorama Consulting Group’s 2015 ERP Report
2 Plan de reprise d’activité : Procédure que l’on déroule après un sinistre pour revenir à l’état initial de production (ex :
récupération des sauvegardes de la veille et redémarrage d’un nouveau serveur).

3 Source : INSEE, Enquête sur les technologies de l’information et de la communication et le commerce électronique
2011, 2012 et 2014.

4 CRM : Customer Relationship Management

5 Source : Forester Research, Inc, 2010
6 Source : Forrester Research, Inc, 2010
7 Source : Truffle100, 2015
8 SSLL : Société de Service en Logiciel Libre
9 Source : 2015 ERP Report – Panorama Consulting Group
10 On utilisait auparavant le terme ASP (Application Service Provider) qui désignait des interfaces web pour des
applicatifs métiers conçus ou non pour l’Internet.

11 Source : « Les pistes pour réduire le TCO de l’ERP » Patrick Rahali, Forum CXP du 18 juin 2009
12 L’étude « ERP ROI, myth and reality » de Peerstone Research (2003), stipule que 71% des entreprises cherchent
d’abord à accroître leur vision sur leur activité avec un ERP.

13 Source : Panorama Consulting Group 2015

14 Source : Panorama Consulting Group 2015
15 Conférence de Lorenz en 1972 à l’American Association for the Advancement of Science
16 EDI : Echange de données informatisées (transfert d’information automatisé entre 2 sociétés)
17 ETL : Extract Transform Load (interface de synchronisation de données entre 2 logiciels)
18 Zénon d’Elée est un philosophe grec présocratique (480 à 420 avant notre ère)
19 Le salon phare des ERP en France se trouve aux « Salons Solutions » tous les ans en septembre-octobre à Paris.
L’auteur
Avant-propos
Comprendre l’offre
Spécificités d’un projet ERP en PME
ERP, PGI : définitions
Application… logiciel… progiciel… framework…
Qui a besoin d’un Progiciel de Gestion Intégré ?
Les différents types d’utilisateurs
Le paradigme ERP
Couverture fonctionnelle d’un ERP
Quoi de neuf dans le monde des ERP ?
Le Workflow
L’information poussée
Les flux intersociétés réciproques
La mobilité
Le Cloud Computing
Segmentation des acteurs de l’ERP
Le consultant
Résumé
Notions d’architectures
Composantes du système d’information
ERP monolithique ou approche « Best of Breed » ?
ERP généralistes, verticaux et applications métiers
Faut-il choisir un ERP propre à son métier ?
Répondre à des besoins spécifiques
Exemple d’ERP spécifique
Un ERP gratuit
Exemple d’un projet open source
Client léger, client lourd
Louer son ERP
Résumé
Coûts et délais de mise en œuvre
Notion de TCO (Total Cost of Ownership)
Coûts sur le cycle de vie et ROI
Décoder une offre financière
Forfait, temps passé et prix catalogue
Resserrer une offre avant négociation
Analyser une synthèse budgétaire
 Pourquoi un ERP coûte-t-il cher ?
Qu’est-ce qui coûte si cher dans un ERP ?
Comment éviter un investissement trop lourd ?
Délais de mise en œuvre
Exemple de projet retardé
Résumé
Gérer les risques
Pourquoi initier un projet ERP ?
Renouveler son ERP
Les risques humains
Poste devenu inutile
En grève pour refus de flicage
PME disposant d’un Comité d’Entreprise
Absence d’équipe projet
Phases de conduite du changement humain
Les risques financiers
Les risques technologiques
Risques liés à l’architecture cible
Les risques sur les données de l’entreprise
La procédure de sauvegarde
Les risques informationnels
Synthèses des risques
[5]
Déroulement d’un projet ERP
Du cahier des charges à la sélection
Analyse des processus existants, schéma cible
Cartographie du SI, urbanisation
Constituer l’équipe projet
Voguer vers son objectif
Rédaction du cahier des charges
Liste de prestataires et appel d’offres
Analyse des offres
Démonstrations commerciales
Démonstrations sur jeu d’essai
À l’heure du choix
La mise en œuvre
Méthodologies de gestion de projet
Phase d’analyse
Installation
 Développement des spécifiques
Paramétrage
Formation des utilisateurs
Reprise des données
Bascule
L’exploitation
Démarrage, la garantie
Le quotidien, la maintenance
Incidents, changements et mises à jour
Le renouvellement
Résumé
Boite à outils
Ce chapitre apporte quelques techniques pour diminuer ou du moins
maîtriser certains des risques décrits dans les chapitres précédents. Il est
du rôle du dirigeant de s’assurer que ces outils sont utilisés par ses équipes
dans le cadre d’un projet ERP.
Constitution de l’équipe projet
Les super-utilisateurs ou key-users
Le chef de projet et le responsable technique
Réorganiser les compétences
Bien rédiger son cahier des charges
Le contexte du projet
Système d’information existant
Le besoin
Contraintes et conduite du projet
Contrôler le contenu des offres
Composants d’une offre
Format attendu de l’offre financière
Tableau comparatif des offres
Chiffrage
Références
Identité
Fonctionnel
Gestion de projet
Technique
Ergonomie
Global
Choisir son prestataire
Critères de choix
 Analyse SWOT
Questionnaire de visite
Négocier son contrat
Le contrat de prestation
Le contrat de service (support, maintenance)
Le contrat de location et d’hébergement
Piloter son prestataire informatique
Mesurer la réussite du projet