|
Place de l’ERP dans la
classification des logiciels
Campbell-Kelly, dans
Une histoire de l'industrie du logiciel,
propose une classification du logiciel en trois catégories :
1) Logiciel sur mesures :
cette catégorie recouvre les développements réalisés pour les entreprises par
les SSII, sur cahier des charges, répondant à des spécifications précises et
propres à l’entreprise considérée.
2) Produits logiciels (ou
« packages ») : ces logiciels sont analogues à des biens d’équipement ; ils
sont produits par des entreprises spécialisées et vendus en petit nombre (et
donc cher) aux entreprises qu’ils équipent. Parmi les produits logiciels, on
distingue ceux qui sont destinés à une secteur d’activité (« packages » pour
l’architecture, la finance, la pharmacie etc.) et ceux qui concernent une
fonction de l’entreprise (comptabilité, gestion des ressources humaines, gestion
des approvisionnements etc.)
3) Progiciels grand public :
ce sont des biens de consommation destinés au grand public, aux utilisateurs de
micro-ordinateurs (systèmes d’exploitation, suites bureautiques, jeux). Ils sont
vendus en grand nombre à un prix très inférieur à celui des produits logiciels.
Historiquement, les premiers
logiciels étaient produits « sur mesures » pour les entreprises. Puis les
fournisseurs ont recherché une économie d’échelle en réutilisant pour d’autres
clients les solutions conçues pour un premier client. Ils ont mis au point des
« packages » d’abord utilisés en interne, puis qu’il a fallu documenter de façon
de plus en plus précise (notamment pour les mettre entre les mains des nouveaux
recrutés). Finalement ces produits ont mûri et ils sont arrivés au degré de
qualité, d’« industrialisation », qui permettait de les vendre aux entreprises
(documentation, maintenance) moyennant une formation de leurs utilisateurs.
L’ERP se trouve à l’extrémité
de cette évolution : c’est, à l’opposé des packages sectoriels ou fonctionnels,
un package destiné a priori à tous les secteurs, à toutes les fonctions,
les adaptations nécessaires se faisant par paramétrage.
Le premier ERP a été mis au
point par SAP, entreprise allemande ; l’acronyme peut se développer en allemand
comme en anglais : « Systeme, Anwendungen, Produkte in der Datenverarbeitung »
ou « Systems, Applications & Products in Data Processing ».
SAP et l’ERP
SAP a été créée en 1972 à
Walldorf (Bavière) par cinq anciens programmeurs d’IBM Allemagne. Comme toutes
les petites entreprises de logiciel, elle a commencé par produire du logiciel
sur mesures. Son premier contrat portait sur un système comptable et financier
en temps réel pour l’usine d’Imperial Chemical Industries (entreprise
britannique) à Ostragen. A l’époque, peu de développeurs étaient capable de
réaliser un système en temps réel et la petite équipe de SAP s’est ainsi placée
à un haut niveau d’expertise.
Conformément à la stratégie qui
vise à réutiliser l’expertise accumulée sur un
premier contrat, SAP a construit à partir de cette solution un produit interne,
le « System R », qui fut amélioré et enrichi lors des contrats suivants de façon
à devenir de plus en plus universel tout en restant intégré et cohérent.
L’idée est d’organiser le
système d’information autour d’une base de données unique, alimentée et utilisée
par les diverses applications. La cohérence du système est garantie par
l’unicité de la base de données : il est exclu qu’une même information soit
représentée par plusieurs données différentes.
En 1980 SAP est la 17ème SSII
allemande. Elle a pour clients la moitié des cent plus grandes entreprises
allemandes. Elle est protégée de la concurrence américaine d’une part parce que
les entreprises de logiciel américaines ne s’intéressent pas alors au
marché européen (elles ont trop à faire sur le marché américain !), d’autre part
parce que le produit de SAP est d’une qualité très supérieure à celle des
logiciels américains. En 1981, SAP propose R/2, un package pour mainframe. La
mise au point a été longue (six ans) et soigneuse, réalisée par une équipe de
haut niveau rigoureuse et disciplinée : le développement « à l’allemande »
se distingue du « good enough » empirique à l’américaine.
En 1982, SAP a 250 clients
allemands dont plusieurs filiales allemandes de groupes internationaux. Ces
filiales seront pour SAP des « chevaux de Troie » vers l’internationalisation :
lorsque les groupes internationaux découvriront la qualité du logiciel dont
s’est équipée leur filiale allemande, ils voudront le
généraliser dans l’ensemble du groupe.
SAP crée un bureau
international à Genève en 1984 et internationalise R/2 dont le paramétrage
devient capable de prendre en compte la diversité des monnaies, législations
fiscales etc. Le produit devient ainsi adaptable à tous les pays au prix
de l’ajustement de milliers de paramètres.
L’adaptation du progiciel de SAP à une
entreprise devient un métier spécifique, un métier pour des consultants ; la
qualification en SAP sera bientôt très recherchée par les SSII. SAP crée en 1987 un
Centre international de formation pour les consultants.
Le premier bureau américain est
ouvert à Philadelphie près des premiers clients américains de SAP en 1988. SAP
définit pour les Etats-Unis une politique commerciale spécifique, les vendeurs
percevant un intéressement qui rendra jaloux les commerciaux allemands. Des
groupes d’utilisateurs sont créés, des partenariats avec les SSII sont montés.
En 1990, SAP est au quatrième
rang mondial des producteurs de logiciels. Le système R/3 commercialisé en 1992
est adapté au monde du client/serveur.
En 1993, le livre de Hammer et
Champy lance la mode du re-engineering
qui répond d’ailleurs à une nécessité : les entreprises s’étaient équipées
d’applications non cohérentes et le besoin d’une réorganisation du système
d’information se faisait sentir. Beaucoup d’entre elles estimeront alors que la
meilleure solution consiste à mettre au rebut leurs applications et à tout
reconstruire autour de R/3. SAP a mis au point une nouvelle formule tarifaire :
le prix de la licence R/3 dépend du nombre de postes de travail équipés (2 700 à
4 000 $/station). Cela lui permet d’atteindre des niveaux de prix jusqu’alors
jamais vus dans le marché du logiciel.
Cependant le coût de la licence
ne représente qu’une faible partie de la dépense que l’entreprise doit supporter
pour implanter un ERP. Le travail de paramétrage, réalisé par des consultants,
ainsi que la « conduite du changement » – il est souvent préférable de
redéfinir les procédures de l’entreprise plutôt que d’adapter l’ERP – font que
l’installation coûte au total 5 à 20 fois le prix de la licence.
En 1998, on dénombre 20 000
installations de R/3 et 1,5 millions de salariés l’utilisent quotidiennement. Campbell-Kelly estime que SAP joue un rôle crucial dans l’économie mondiale,
bien plus important à ses yeux que celui de Microsoft.
SAP, qui employait 9 personnes
en 1972 et faisait 300 000 € de chiffre d’affaires, emploie 24 178 personnes en
2000 et fait 6,3 milliards d’€ de chiffre d’affaires.
Le graphique ci-dessous montre
que la maturation de SAP a duré près de vingt ans : c’est à partir de son
installation aux Etats-Unis en 1988 que la croissance devient rapide.
Concurrence sur le marché
des ERP
SAP n’a pas pu conserver le
monopole des ERP : d’autres entreprises se sont lancées dans les années 90 sur
ce marché prometteur.
Baan, entreprise néerlandaise
dont les origines et l’histoire ressemblent un peu à celles de SAP, se lance aux
Pays-Bas en 1978 et aux Etats-Unis en 1993.
Oracle, fournisseur du SGBD
utilisé par la plupart des clients de SAP, a mis au point son propre ERP
« Oracle Applications » autour de sa base de données et s’est lancé sur le
marché en 1995.
JD Edwards, Peoplesoft, System
Software Associates, entreprises déjà présentes sur le marché du produit
logiciel, systématisent leur offre pour offrir des ERP.
D’après AMR Research, le marché
américain des ERP se partage ainsi en 2002 ; on note que SAP a la plus grosse
part avec un tiers du marché, puis viennent Oracle (13 %), Peoplesoft (10 %) et
Baan (7 %).
L’ERP et ses clients
Un ERP se présente comme un
ensemble de composants logiciels avec lequel on peut construire un SI. Les ERP
disposent de forts arguments commerciaux pour séduire les dirigeants (ils
proposent de mettre un terme au désordre du système d’information, et aussi de
régler des problèmes d’organisation sans effort politique). Cette
offre séduisante par sa qualité et sa cohérence se révèle à l’usage plus risquée
que l'on avait pu l'imaginer : elle ne peut être efficace que si l'on
accepte les contraintes qu'elle impose. Sa mise en œuvre comporte des
difficultés et des pièges.
L’ERP incorpore une expertise
professionnelle et permet à l’entreprise de s’assurer qu’elle a introduit dans
ses processus des méthodes conformes à l’état de l’art. Toutefois les
fournisseurs de l’ERP ne peuvent pas accumuler une compétence universelle dans
leur produit car cela demanderait trop de travail : dans les domaines où
l’entreprise est particulièrement « pointue » elle dispose donc d’une expertise
meilleure que celle que l’ERP peut incorporer. Il sera ainsi raisonnable de faire appel à
un ERP pour les fonctions qui ne
relèvent pas de son cœur de métier ; par contre, sur le cœur de métier où il lui
importe d’être meilleure que ses concurrents, elle ne pourra
généralement pas se contenter de l’ERP et devra utiliser un logiciel « sur
mesures » réalisé par une SSII sur cahier des charges.
Par ailleurs adopter un
ERP implique plus qu’un contrat : c’est un mariage avec l’éditeur ;
ce mariage comporte des obligations et il sera plus difficile d'en sortir que
d'y entrer. Si l’éditeur a créé un club d’utilisateurs, l’entreprise aura
intérêt à y faire participer ses propres experts mais cela leur prendra du
temps.
Les limites de l’ERP
Tout ERP a des frontières ; il
est inévitable qu’elles ne coïncident pas avec ce que l’entreprise aurait
souhaité. Vous vouliez un carré : c’est un losange que l’on vous livre. Il
manque des choses à l’ERP par rapport à vos besoins, et par ailleurs il fait des
choses dont vous n’avez pas besoin.
Les choses que l’ERP fait en trop sont
éventuellement gérées dans votre entreprise par d'autres espaces fonctionnels ;
il faudra traiter les redondances et chevauchements qui en résultent.
Ce qui manque, mais qui vous
est nécessaire, devra être fait ailleurs tout en étant cohérent avec l’ERP :
cela occasionnera un travail supplémentaire d'architecture fonctionnelle.
Enfin le progiciel est fourni
avec ses propres solutions en ce qui concerne le référentiel (catalogue des
produits, référentiel des clients et fournisseurs, inventaire des stocks etc.) :
si vous aviez mis en place des solutions différentes, il vous faudra y renoncer
car le référentiel est au cœur du système d’information, est il est moins coûteux
de s’adapter à l’ERP que d’adapter celui-ci à l’entreprise.
Il se peut enfin que l'éditeur
de l’ERP n’ait pas fait les mêmes choix que l'entreprise en ce qui concerne les
logiciels système (système d'exploitation, SGBD etc.) L’adoption de l’ERP peut
vous contraindre soit à gérer en parallèle plusieurs versions de ces produits,
soit à vous plier entièrement aux choix faits pour l’ERP.
Les versions successives
L’adoption d’un progiciel ne
représente pas un seul projet. Le fournisseur publiera des versions successives,
différentes les unes des autres, et le passage d’une version à la suivante est
un véritable projet. Lors de la sortie d’une nouvelle version, il faut en
effet :
- faire l’inventaire de ce qui est proposé, évaluer ce qui est intéressant,
choisir ;
- évaluer le coût des travaux de reconception : la « compatibilité ascendante »
relève plus du discours commercial que de la réalité et il faudra refaire la
plupart des paramétrages ;
- évaluer l’effet du changement de version sur tout ce qui se trouve à la
périphérie du progiciel, et qu’il impacte.
Négociation du contrat
Avant de conclure le
« mariage », il faut prendre des précautions ; la négociation du contrat est
délicate. Il convient de réaliser d’abord une étude de faisabilité
approfondie, et il faudra lutter pour obtenir de l’éditeur des informations avant
la signature du contrat. Il faut vérifier la capacité de l’éditeur à accompagner
l’entreprise dans la durée et à partager avec elle son expertise sur le métier.
Il faut savoir que certains des
enjeux de l’entreprise ne pourront être atteints, si elle adopte l’ERP, qu’à la
condition de modifier la façon dont elle aborde son métier. Il faut donc que la
maîtrise d’ouvrage du SI soit encore plus forte que lorsque l’on conçoit
un logiciel spécifique, car de nombreuses demandes d’adaptation de l’ERP vont
s’exprimer et il va falloir leur résister.
Le dialogue avec les
responsables des métiers devra être approfondi. Si par exemple il s’avère que
l’ERP ne permet pas de mettre en œuvre les règles souhaitées par le marketing en
matière de facturation, il faut pouvoir s’assurer de l’accord de la direction
marketing.
Enfin, le mariage étant de
longue durée, il faut que l’entreprise acquière une compétence sur l’ERP.
Lorsqu’une entreprise achète un ERP, elle n’a pas à payer seulement les
licences : elle doit aussi s’associer un cabinet de consulting et c’est de loin
la dépense la plus importante (dans un cas que j’ai connu, la licence avait
coûté 6 MF, mais le coût total du projet a été de 120 MF)
L’entreprise fera appel à un
intégrateur lors du premier projet mais elle doit se former pour pouvoir être
aussi autonome que possible lors des projets qu’elle devra conduire
ultérieurement à l’occasion des changements de version.
Conditions de succès et
causes d’échec
L’utilisation de l’ERP réussit
souvent mieux dans les PME que dans les grandes entreprises, car les PME n’ont
pas beaucoup d’argent à dépenser et savent aller droit à l’essentiel. Dans les
grandes entreprises, la première cause d’échec est le caractère versatile de la
maîtrise d’ouvrage, qui modifie trop souvent son expression de besoins et ses
priorités ; la deuxième cause d’échec est le conflit de pouvoir entre maîtrise
d’ouvrage et maîtrise d’œuvre informatique.
Michael Hammer et James Champy, Re-engineering the
Corporation, Harper Business 1993.
|
