RECHERCHE :
Bienvenue sur le site de Michel VOLLE
Powered by picosearch  


Vous êtes libre de copier, distribuer et/ou modifier les documents de ce site, à la seule condition de citer la source.
 GNU Free Documentation License.


 

Les ERP (« Enterprise Resource Planning »)

26 mars 2004

Version imprimable

Pour poster un commentaire


Pour lire un peu plus :

- Une histoire de l'industrie du logiciel
- De l'Informatique
- L'EAI

Place de l’ERP dans la classification des logiciels[1]

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[2] 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[3]

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.


[1] Martin Campbell-Kelly, Une histoire de l’industrie du logiciel, Vuibert 2003, p. 209.

[2] Michael Hammer et James Champy, Re-engineering the Corporation, Harper Business 1993.

[3] Guillaume Benci, « Ingénierie du SI à base de progiciel », conférence au Séminaire du club des maîtres d’ouvrage des systèmes d’information, 25 mai 2000.