Logiciel ERP définition

Qu’est ce qu’un ERP ?

Un logiciel ERP est un outil informatisé qui permet le pilotage de l’entreprise. Sa particularité
est d’embarquer, en un même logiciel et une seule base de données, les fonctionnalités
nécessaires à la gestion de l’ensemble de l’activité d’une entreprise : gestion comptable,
gestion commerciale, gestion des stocks…

Le terme « ERP » est l’acronyme de « Entreprise Resource Planning » dont la traduction

littérale est « Planification des ressources de l’entreprise ».

Son parent francophone, moins populaire, est « PGI » pour « Progiciel de gestion intégré ».

Le groupe Divalto, qui édite Divalto infinity, est l’un des acteurs historiques de ce marché. En
effet, nous proposons des solutions de gestion depuis 1982 et accompagnons aujourd’hui
plus de 12 000 entreprises.
Un progiciel de gestion intégrée ou PGI (en anglais : Enterprise Resource Planning ou ERP) est
un progiciel qui permet « de gérer l'ensemble des processus d'une entreprise en intégrant l'ensemble de
ses fonctions, dont la gestion des ressources humaines, la gestion comptable et financière, l'aide à la
décision, mais aussi la vente, la distribution, l'approvisionnement et le commerce électronique »1.

Sommaire

 1Définition
 2Historique
 3Enjeux des PGI : une meilleure intégration
o 3.1Industrie
o 3.2Services
 4Description
o 4.1Adaptation au contexte d'entreprise
o 4.2Structure organisationnelle
o 4.3Données
o 4.4Traitements
 5Évaluation de l'emploi des PGI
o 5.1Mise en œuvre des PGI
o 5.2Avantages
 5.2.1Avantages natifs des PGI
 5.2.2Opportunités liées à l'implémentation d'un PGI
o 5.3Inconvénients
o 5.4Bilan de l'apport
 6Avenir des PGI
 7Notes et références
 8Voir aussi
o 8.1Articles connexes

Définition[modifier | modifier le code]

La définition donnée par le CXP2 regroupe l'ensemble des paramètres constitutifs d'un PGI :
« Pour être intégré, un progiciel de gestion doit :

 émaner d'un concepteur unique ;

 garantir à l'utilisateur l'unicité d'information assurée par la disponibilité de l'intégralité de la structure de
la base de données à partir de chacun des modules, même pris individuellement ;
 reposer sur une mise à jour en temps réel des informations modifiées dans tous les modules affectés ;
 fournir des pistes d'audit basées sur la garantie d'une totale traçabilité des opérations de gestion ;
 couvrir soit une fonction (ou filière) de gestion, soit la totalité du système d'information de l'entreprise. »
Concernant la notion d'éditeur unique, les travaux de l'OAG (Open Application Group) feront qu'à l'avenir il
n'en sera vraisemblablement plus de même.
Il n'en reste pas moins que l'objet « PGI » n'est pas normalisé et son appellation reste flottante : d'autres
dénominations sont utilisées comme : progiciel, progiciel intégré, progiciel applicatif, progiciel applicatif
intégré, progiciel de gestion, progiciel de gestion intégrée…
Face à cette diversité, les deux dimensions fondamentales qui caractérisent les logiciels de type PGI 3 sont :

1. Le DI ou degré d'intégration : il définit la capacité à fournir à l'ensemble des acteurs de l'entreprise

une image unique, intègre, cohérente et homogène de l'ensemble de l'information dont ils ont
besoin pour jouer pleinement leur rôle.
2. La CO ou couverture opérationnelle : elle définit la capacité de fédérer l'ensemble des processus
de l'entreprise dans chacun des domaines qui la constituent et ce, dans une approche
transversale qui optimise sa productivité.

Historique[modifier | modifier le code]

L'origine des PGI se trouve dans les méthodes de planification des besoins en composants qui ont été
développées dans le cadre d'un impératif d'intégration de plus en plus poussée des fonctions de gestion de
l'entreprise. Dans les années 1960, Joseph Orlicky étudie le programme de production de Toyota et conçoit
le Material Requirements Planning (MRP). Puis Oliver Wight et George Plossl mettent au point le MRP into
manufacturing resource planning (MRP2). D'où une évolution en trois phases4 :

1. MRP0, en anglais material requirements planning zero (littéralement, « planification des besoins en
matières 0 ») : méthode de calcul des besoins matière, mise au point en 1965 ;
2. MRP1, en anglais material requirements planning one : première application industrielle de la
gestion intégrée des flux de production, mise au point en 1971 ;
3. MRP2, en anglais manufacturing resources planning two (litt. « planification des ressources pour la
fabrication 2 ») : en plus du calcul des besoins nets en matières premières et composants,
effectue une planification des lancements en tenant compte des capacités des ressources par
période ; mise au point en 1979.
À partir de 1990 environ, la logique introduite par le MRP s'étend progressivement à l'ensemble des
fonctions de l'entreprise, pour donner l'«ERP» (E comme entreprise). Cette transition est facilitée par :

 L'état des systèmes d'information dont « les applications de base sont installées dans différents
départements (services clients, marketing, ventes, comptabilité, fournisseurs, production, distribution, personnel ) et ne
permettent pas aux utilisateurs de partager un langage commun. Si des interfaces entre ces différents
domaines de l'entreprise ont été mises en place, elles sont rarement en temps réel et les exemples où
la même donnée est saisie deux ou trois fois, voire plus, ne sont pas rares. (...) les coûts induits sont
inestimables : perte de temps, manque d'efficacité, mauvaise visibilité, mauvais processus décisionnel,
duplication d'effort, taux d'erreur élevé. (...) Dysfonctionnements qui se traduisent (...) par un mauvais
service client et une perte de compétitivité de l'entreprise »5.
 « Le développement de logiciel est un domaine (...) encore au stade artisanal où l'approche composant
- autrement dit l'approche objet- n'en est encore qu'à ses débuts ». Le développement logiciel dépend
fortement de la capacité individuelle du développeur et n'est pas conduit par la recherche systématique
du réemploi de ce qui a bien fonctionné dans le passé. « Le composant logiciel (l'objet) n'occupe pas la
place qui devrait être la sienne alors qu'une nouvelle industrie logicielle est en train d'émerger qui
s'inspire des concepts des ateliers de production des industries manufacturières : recherche,
engineering, nomenclature, montage, assemblage, version, pièces détachées, inventaire, réutilisabilité,
contrôle qualité »6.
 Les objets logiciels ne sont pas les seuls éléments à devoir faire l'objet d'une meilleure intégration. Les
composants techniques issus de fournisseurs divers et indépendants ne facilitent pas l'intégration :
systèmes d'exploitation, protocoles de communication, base de données, Interface Homme/machines,
machine serveur et machines client, réseau local et étendu, composants bureautiques et multimédias,
etc.
 Enfin, les profondes modifications nécessitées par le passage informatique à l'an 2000 et le passage à
l'euro (dans la zone euro), ont fait que les progiciels de gestion intégrés ont été considérés comme une
opportunité technique à saisir pour remplacer des systèmes informatiques vieillissants et difficilement
convertibles pour des raisons d'obsolescence technique. L'expansion considérable de ces logiciels
dans les années 1990 s'explique en grande partie par les améliorations techniques apportées dans la
conception et la mise à jour des systèmes d'information, mais aussi par les opportunités conjointes de
refonte des organisations ouvertes à cette occasion.

Enjeux des PGI : une meilleure intégration[modifier | modifier le

code]
Le concept d'un PGI part du constat simple selon lequel l'union fait la force.

 Intégration des composants : « la somme des optima est parfois inférieure à l'optimum de la somme ».
En d'autres termes l'intérêt de disposer d'un PGI est que l'apport global d'un PGI (nativement intégré)
est toujours supérieur à celui de la somme des apports de chacun des modules (de provenance et de
constitution hétérogènes) qui le composent.
 Intégration personnalisable : un PGI peut être orienté en fonction du métier de l'organisation. Véritable
cerveau et support organisationnel pivot pour toute l'entreprise, un PGI vise une gestion globale,
cohérente et simplifiée.
 Intégration orientée utilisateurs : pour ce faire, le choix d'un logiciel pertinent, son paramétrage pour le
faire correspondre à la spécificité de l'activité de l'entreprise, une intégration dans les services et une
appropriation réelle par les utilisateurs sont les facteurs-clés de succès. Il est fréquent que la mise en
place et le déploiement d'un tel outil nécessite un délai (souvent sous-estimé) ainsi que l'assistance
d'un prestataire tiers spécialisé appelé « intégrateur ».

Industrie[modifier | modifier le code]

Les PGI industriels trouvent leur origine dans le besoin de planifier la production. On reconnait le PGI
industriel à ce qu'il repose sur un module central de type GPAO ou MRP assurant une couverture plus ou
moins étendue de fonctionnalités telles que :

 gestion du processus de planification et de l'ordonnancement ;

 suivi de fabrication et de la traçabilité de la fabrication ;
 gestion des stocks, approvisionnements de matières premières, composants ou semi-finis ;
 gestion de la sous-traitance, gestion de la maintenance, gestion de la qualité.

Services[modifier | modifier le code]

Les PGI destinés à gérer les activités du tertiaire ne sont pas toujours répertoriés dans la catégorie des
PGI. Ils sont néanmoins très nombreux à cibler des secteurs aussi variés que la santé, l'éducation, la
distribution, le commerce de détail ou la finance. Avec des modules divers qui vont de la gestion de
projet jusqu'à des fonctions métiers très pointues (gestion d'abonnements, cours de formation…). L'offre
dans le domaine est moins abondante que pour l'industrie et beaucoup plus éclatée : les éditeurs de PGI
ont été précédés sur ce créneau et se trouvent en situation de concurrence forte avec les éditeurs de
logiciels GRC/CRM.
On distingue néanmoins deux familles de produits :

 les outils de type PSA (professional service automation) qui s'adressent à des activités de service qui
nécessitent une organisation en mode projet : ils sont centrés sur le service des fonctionnalités de
gestion de projet et éventuellement sur celles du GRC/CRM, ce qui ne couvre donc pas l'ensemble des
fonctions de l'entreprise à la manière d'un PGI.
 les outils de type ESA (enterprise service automation) plus conformes à la définition d'un PGI. Les
solutions d'ESA sont en effet capables de servir les fonctions usuelles d'un outil de GRC/CRM,
 (comme la prise de commande ou l'élaboration d'une proposition commerciale) mais également la
plupart des fonctions de gestion administrative d'une entreprise.

Description[modifier | modifier le code]

Le principe fondateur d'un PGI est de construire des applications informatiques (gestion des commandes,
des stocks, de la paie, de la comptabilité…) :

 de manière modulaire et intégrée au niveau des traitements offerts (les différents modules qui le
composent sont indépendants mais parfaitement compatibles entre eux) ;
 de manière rigoureuse et cohérente au niveau des données gérées (partage d'une base de
données unique et commune).
Cela comble une lacune importante :

 Dans la situation préexistante aux PGI, des applications sur mesure, d'origine diverse, coexistent tant
bien que mal, ne partagent pas ou peu leurs données, et ne sont pas forcément toujours prévues pour
travailler simplement et correctement ensemble. Les équipes informatiques ont alors fort à faire pour
construire et mettre en place des interfaces ad hoc, dont le fonctionnement pratique peut réserver des
surprises.
 La compatibilité entre les modules qui composent les PGI est garantie par leur concepteur : la
compatibilité du module achat avec le module stock est garantie, qui est lui-même compatible avec le
module gestion de commandes. Les données sont désormais supposées standardisées et partagées,
ce qui élimine les saisies multiples et évite (en théorie) l'ambiguïté des données multiples de même
nature (exemple : société TRUC, TRUC SA et Sté TRUC…).
L'autre principe qui caractérise un PGI est l'usage systématique de ce qu'on appelle un moteur
de workflow (qui n'est pas toujours visible de l'utilisateur), et qui permet, lorsqu'une donnée est entrée dans
le système d'information, de la propager et d'offrir des vues logiques pertinentes dans tous les modules du
système qui en ont besoin, selon une programmation prédéfinie.
Ainsi, on peut parler de PGI lorsqu'on est en présence d'un système d'information composé de plusieurs
applications partageant une seule et même base de données, par l'intermédiaire d'un système automatisé
prédéfini éventuellement paramétrable (un moteur de workflow).

Adaptation au contexte d'entreprise[modifier | modifier le code]

Le PGI peut rarement être considéré comme un outil livré "clé en main" dans le sens qu'il n'est pas
directement utilisable à l'installation. Bien qu'il propose nativement des processus de gestion informatisés
qui correspondent à des standards et bonnes pratiques largement répandus il est parfois nécessaire de les
adapter aux spécificités de l'organisation de l'entreprise ou de ses processus métier. La dimension standard
produit et l'intégration native, qui sont des caractéristiques clés des PGI, ne pourraient pas se concrétiser
dans un contexte particulier sans une nécessaire adaptabilité du standard. Pour cette raison les PGI sont
plus ou moins paramétrables, c'est-à-dire qu'il est possible d'adapter le comportement du PGI (en
particulier des moteurs de workflow mentionnés précédemment) via des valeurs de données gérables soit
directement par des utilisateurs métiers qualifiés soit par la direction des systèmes d'information. Les
fonctionnalités non couvertes par le standard produit peuvent être intégrées dans une version logicielle
existante ou faire partie de la feuille de route de l'éditeur. En dernier recours les sociétés peuvent faire
appel à des développements spécifiques pour couvrir les écarts résiduels entre les besoins métier et le
standard.

Structure organisationnelle[modifier | modifier le code]

La structure organisationnelle est la modélisation dans le PGI du maillage de l'entreprise à tous les niveaux
de gestion :

 Maillage juridique et financier : périmètre analytique, holding, sociétés, filiales ;

 Maillage logistique : sites de production, distribution… ;
 Maillages fonctionnels : la plupart des fonctions de l'entreprise (achats, ventes, magasin…) possèdent
leur propre structure organisationnelle. Exemple : structure organisationnelle vente comporte une/des
organisations commerciales, canaux de distribution, secteurs d'activité, agences commerciales…
La structure organisationnelle est la base d'un PGI, seules les données de définition (exemple : définition
du fournisseur comprenant son identifiant, adresse sociale, etc) peuvent être indépendantes de la structure
organisationnelle, toutes les données de gestion sont définies à un ou plusieurs niveaux de gestion. De
plus la structure organisationnelle conditionne les processus TI d'un PGI. Par exemple la plupart des PGI
permettront de gérer des flux de transferts entre deux sites modélisés comme tels dans la structure
organisationnelle. De plus si ces deux sites appartiennent à deux sociétés différentes dans cette même
structure organisationnelle alors un processus de facturation inter société sera associé au flux de transfert.

Données[modifier | modifier le code]

La base de données d'un PGI contient toutes les informations nécessaires à l'entreprise, communes aux
différents modules. La première table est la table des produits. Puis selon l'orientation de l'entreprise,
contient les nomenclatures, les gammes, les matières premières, les capacités de production, les quantités.
D'un autre côté sont gérés les clients ou les fournisseurs, ainsi que leurs commandes ou livraisons,
jusqu'aux catalogues des fournisseurs. Un troisième aspect contiendra les stocks, les durées de
conservations, les délais d'acheminement des transporteurs. Enfin, mais la liste est loin d'être exhaustive,
on trouve presque toujours les tables relatives aux aspects financiers de l'entreprise.
La donnée de base produit est une donnée centrale pour le fonctionnement du PGI. Elle contient un grand
nombre de paramétrages niveau utilisateur (par distinction des paramétrages IT) qui conditionnent les
traitements du PGI. Ces paramétrages doivent accompagner l'évolution des politiques de gestion des
produits ou l'impact de ces politiques sur des conditions de marché changeantes. Ils font par conséquent
l'objet d'un suivi et d'une mise à jour récurrente au cours de l'utilisation du PGI.

Traitements[modifier | modifier le code]

Bien programmé et sous réserve d'accords préalables, un PGI est également capable de communiquer
avec les fournisseurs afin de recommander les matières premières courantes ou avec les transporteurs.
Ses échanges se font le plus souvent par messagerie.

Évaluation de l'emploi des PGI[modifier | modifier le code]

Mise en œuvre des PGI[modifier | modifier le code]
Un projet PGI est un projet de transformation. Pour qu'un PGI soit un succès il faut une mobilisation
complète de l'entreprise.

 La DG ou les directions métiers sont mobilisées dès la phase de choix d'un PGI avec l'élaboration
d'un business case qui vise à partager largement dans l'entreprise, les raisons de la mise en place, le
périmètre visé et les gains attendus.
 Une phase de sélection permet à l'entreprise de trouver les partenaires qui vont l'accompagner,
généralement un éditeur (du PGI), un intégrateur (ou SSII spécialisée) pour la mise en œuvre et
parfois un cabinet de conseil pour la refonte des processus et l'accompagnement des changements.
 Les PGI sont mis en place dans les organisations en « mode projet ». La méthodologie utilisée
s'appuie sur les démarches et outils de gestion de projets, de gestion des risques et surtout
de conduite de changement nécessaire pour les projets de transformation et donc essentielle pour les
projets PGI7.
 La méthodologie de base d'un projet d'implémentation de PGI prévoit les principales phases
suivantes : conception générale (recueil des besoins métier, définition des processus SI et
identification des écarts avec le standard produit), conception détaillée (définition des fonctionnalités
utilisées par processus et règles de gestion), réalisation (paramétrage, conception technique et
développements spécifiques), tests d'intégration (tests systèmes permettant à l'intégrateur de s'assurer
de la conformité de la solution avec la conception générale + détaillée), recette (tests métier, une
population de futurs utilisateurs choisie joue des flux correspondants à l'activité opérationnelle de
l'entreprise), mise en production (ou démarrage), support post démarrage.
 Le démarrage du PGI en "Big Bang" (tous les sites sont démarrés en même temps) est rarement mis
en œuvre dans les grandes entreprises. En effet :
o En phase de conception du PGI il est difficile de prendre en compte l'exhaustivité des besoins de
chaque site. Les sites ne sont pas forcément tous au même niveau de maturité et la multiplicité
des acteurs impliqués pourrait être un frein.
o La conduite du changement et l'organisation à mettre en œuvre pour le démarrage peuvent se
révéler extrêmement lourdes et risquées.
 Au démarrage en "Big Bang" les grandes entreprises préfèrent souvent la démarche de construction
de "Core Model" et de "Déploiement" consistant à construire et démarrer une première solution pour un
site pilote (le "Core Model") puis à démarrer les autres sites les uns après les autres dans un ordre
défini (le "Déploiement"). Un déploiement donne lieu la plupart du temps à une conception en "Gap
Analysis" pour identifier les écarts entre les besoins métier du site déployé et le "Core Model" afin de
les intégrer dans celui-ci pour le démarrage du site.

Avantages[modifier | modifier le code]

Les PGI (opposés aux applications dédiées) présentent plusieurs avantages :
Avantages natifs des PGI[modifier | modifier le code]

 Intégration des processus de gestion, largement exploitée par les entreprises pour optimiser le suivi
financier et le contrôle de gestion ;
 Cohérence et homogénéité des informations (un seul fichier articles, un seul fichier clients, etc.) ;
 Intégrité et unicité du Système d'information ;
 Partage du même système d’information facilitant la communication interne et externe ;
 Fiabilité. Une entreprise optant pour un PGI bénéficie généralement d'un outil éprouvé par de
nombreuses entreprises de son secteur d'activité et par conséquent en fiabilisation continue au titre de
la maintenance éditeur.
 Évolutivité, garantie par la cohérence du modèle de données qui constitue le socle de tous les
processus / fonctionnalités SI couverts par le PGI. Le PGI permet une implémentation adaptée et
progressive de ces processus / fonctionnalités.
 Rationalisation de l'architecture applicative et technique : diminution du nombre d'outils et par
conséquent des interfaces entre ces outils, potentielle diminution ou optimisation des machines et
serveurs supportant le système d'information.
 Minimisation des coûts : pas d’interface entre les modules, synchronisation des traitements,
maintenance corrective simplifiée car assurée directement par l'éditeur et non plus par le service
informatique de l'entreprise (celui-ci garde néanmoins sous sa responsabilité la maintenance
évolutive : amélioration des fonctionnalités, évolution des règles de gestion, etc.) ;
 Globalisation de la formation (même logique, même ergonomie) ;
 Diminution du nombre de salariés ayant pour mission principale la saisie comptable (aide-comptable);
 Maîtrise des coûts et des délais de mise en œuvre et de déploiement ;
 Disponibilité et maturité (au niveau coûts, délais, qualité) des prestations de service dédiées au PGI.
Opportunités liées à l'implémentation d'un PGI[modifier | modifier le code]

 Favoriser l'intégration entre les départements, matérialiser la stratégie et les politiques de gestion de
l'entreprise dans le système d'information.
 Rapprochement des métiers et de la DSI, appropriation du système d'information par les métiers. Les
PGI étant nativement calqués sur les processus métier et flexibles, ils favorisent l'émergence d'une
population métier sensibilisée aux aspects techniques du PGI et d'une population DSI sensibilisée à
ses aspects métier.
 Étendre l'intégration du système d'information à la chaîne logistique amont et aval (fournisseurs et
clients).
 Standardiser les processus SI et déployer les standards sur l'ensemble des organisations de
l'entreprise.
Ce dernier point est essentiel et la mise en œuvre d'un PGI dans une entreprise est fréquemment associée
à une révision en profondeur de l'organisation des tâches et à une optimisation et standardisation des
processus, en s'appuyant sur le « cadre normatif » du PGI.
Les PGI vont pouvoir gérer et prendre en charge :

 plusieurs entités ou organisations tel que l'AH() ;

 plusieurs associations telles que l'OAC (conférence) ;
 plusieurs devises ;
 plusieurs langues pour les utilisateurs et les clients (cas des multinationales) ;
 plusieurs législations ;
 plusieurs plans de comptes ;
 plusieurs axes d'analyse en comptabilité analytique.
NB : L'intérêt de faire l'acquisition d'un PGI, au niveau de la comptabilité, est la création des écritures
comptables en temps réel, et en automatique. C'est un outil de productivité car il permet de supprimer les
saisies redondantes, et de partager une information plus fiable. L'utilisation d'une base de données unique
permet de rassembler l'ensemble des données et d'assurer ainsi une mise à jour constante de ces
données. Il peut également être couplé à un site de vente en ligne pour une synchronisation en temps réel
des données.

Inconvénients[modifier | modifier le code]

Les PGI ne sont cependant pas exempts d'inconvénients :

 La mise en œuvre peut s'avérer complexe si le périmètre fonctionnel est mal déterminé ou trop
mouvant ou le projet mal piloté ;
 coût élevé et pouvant rapidement augmenter en fonction de l'industrie et de la complexité du projet.
Par exemple, l'entreprise Dow Chemical, spécialisée dans la fabrications de produits chimiques, a
dépensé 500 millions de dollars et passé sept ans à implémenter un logiciel d'ERP qui s'est révélé
obsolète avant même de pouvoir être exploité8. L'option fonctionnellement riche des solutions
de logiciels libres si elle réduit les coûts de licence, ne supprime pas les coûts d'accompagnement et
de formation. Le paramètre coût est également fonction de la lourdeur et de la rigidité de mise en
œuvre de l'outil qui peuvent être accrues par les difficultés de son appropriation par les utilisateurs. De
telles difficultés peuvent même, à terme, conduire à la faillite de l'entreprise concernée. À la fin
des années 1990, l'entreprise FoxMeyer Drug Corp a accusé le groupe SAP de l'avoir conduite à la
faillite suite aux dépenses engendrées et aux difficultés rencontrées par l'implémentation de leur PGI 9.
 périmètre fonctionnel non adapté au besoin réel de l'organisation : le progiciel peut être sur-
dimensionné et donc sous-utilisé s'il est plus large que les besoins effectifs de l'organisation, ou au
contraire être sous-dimensionné s'il n'est pas capable de couvrir l'ensemble des besoins avérés 10 ;
 nécessité d'une bonne connaissance des processus de l'entreprise (par exemple, une petite
commande et une grosse commande nécessitent deux processus différents : il est important de savoir
pourquoi, de savoir décrire les différences entre ces deux processus de façon à bien les paramétrer et
à adapter le fonctionnement standard du PGI aux besoins de l'entreprise) ;
 captivité vis-à-vis de l'éditeur : le progiciel choisi ne peut pas toujours s'adapter à l'organisation qui
s'équipe. Le choix d'une solution devient fortement structurant pour l'entreprise, et, au-delà d'un simple
paramétrage, ce sera à l'organisation de s'adapter au progiciel (et non l'inverse). Par ailleurs, l'outil PGI
risque d'être extrêmement lourd et couteux à gérer notamment s'il nécessite une maintenance
continuelle et s'il rend la moindre adaptation (voire son abandon pour un autre produit) très difficile.
Une offre intégrée apparaît avec des produits d'inspiration bureautique reposant sur les systèmes de
gestion de bases de données les plus diffusées du marché : MSSQL, MySQL, Oracle, DB2. Ces produits
sont généralement diffusés par des éditeurs spécialisés en Gestion de la Production. Les inconvénients
cités ici sont alors moindres.
De plus, l'émergence récente de plusieurs PGI libres permet de minimiser les inconvénients de coût (liés à
l'acquisition des licences logicielles), de rigidité et surtout de captivité. L'utilisation de formats ouverts facilite
également les échanges de données, en interne et vers l'extérieur.
Pour finir, la pérennité de l'éditeur est un élément majeur à vérifier avant de s'engager dans un projet PGI.
Le vrai coût est celui du temps passé en interne, plus que celui de l'achat des licences. La validité du
modèle économique du partenaire retenu, dans le temps, est un critère fondamental. Quel que soit le
produit retenu, à méthode de travail égale et périmètre fonctionnel identique, les coûts ne sont pas
forcément très éloignés d'une société à l'autre quand on compare les acteurs historiques qui durent dans
cet environnement très concurrentiel.

Bilan de l'apport[modifier | modifier le code]

Les progiciels de gestion intégrés ont permis à beaucoup d'entreprises d'accéder à une meilleure maîtrise
de leurs activités :

 Une partie de leur essor s'explique par l'évolution nécessaire des systèmes d'information pour
le passage à l'an 2000 puis pour la mise en place de l'euro. En effet, nombre d'entreprises ont estimé
préférable de remplacer un ensemble disparate et non homogène de logiciels par un progiciel intégré à
 la pointe de la technologie plutôt que d'engager des corrections des programmes existants plus ou
moins anciens.
 Si cette démarche a parfois donné lieu à des démarrages dans l'urgence, l’enjeu de la mise en place
d'un PGI aujourd'hui n'est plus de passer l'an 2000, mais d'optimiser la gestion des flux logistiques et
financiers de l'entreprise. Le paradigme sur lequel ils se basent repose essentiellement sur une
optimisation de l'utilisation des ressources, qu'elles soient humaines ou matérielles. Le PGI induit donc
une orientation stratégique vers la réduction des coûts comme vecteur essentiel de la création de
valeur donc de la croissance de l'entreprise. Ce modèle est critiqué depuis le début des années
1990 car il met l'entreprise (et éventuellement ses fournisseurs) au centre de l'attention, au détriment
du client.
Les principaux éditeurs de PGI sont regroupés au sein d'associations comme la BASDA Business
Application Software Developers Association ;

Avenir des PGI[modifier | modifier le code]

Les grands PGI proposent à leurs utilisateurs une vaste couverture fonctionnelle. Mais la richesse de cette
offre se heurte rapidement à certaines limites :

 Aucun PGI ne peut prétendre correspondre parfaitement à tous les métiers ou activités. Une fois sorti
de leur cœur de métier, les PGI peinent à offrir certaines fonctions (sauf à les traiter de manière plus
complexe, voire moyenne). Les logiciels couvrant des fonctionnalités de niche demeurent
concurrentiels.
 L'intégration technique des traitements et des données arrive à un niveau de complexité à la limite du
gérable (une correction pouvant avoir des impacts sur tout un ensemble de fonctions, avec souvent
des corrections prérequises, corequises et sous-requises). La plupart de ces progiciels ont désormais
un module destiné à la gestion de ces corrections (le module qui gère les modules).
 Les exigences du marché ou de la réglementation sont constamment renouvelées et les principaux
éditeurs de PGI doivent en permanence s'efforcer d'intégrer ou de mettre à jour les fonctionnalités
nouvellement requises comme la gestion de la relation client, la gestion des risques, le développement
durable.
 Les besoins des entreprises en matière de solutions informatiques ont considérablement évolué :
collaboration croissante (interne mais aussi externe avec les partenaires), dématérialisation accrue
touchant tous les métiers, mobilité et nomadisme des collaborateurs, contraintes économiques,
environnement légal et réglementaire toujours plus strict… Parallèlement, les outils de gestion tels que
les PGI jusqu’alors déployés par les entreprises s’avèrent parfois contraignants et inadaptés à ce
nouveau contexte et leur évolution est inévitable11.
 Le développement du Cloud Computing qui demande aux éditeurs une adaptation de leur progiciels
pour qu'ils soient accessibles en ligne sur Internet via des plateformes mutualisées ("multi-tenants"),
facturées mensuellement au nombre d'utilisateurs et non via une licence élevée la première année et
un coût mensuel récurrent (15-20 % selon les éditeurs)7.
En conséquence, un virage fonctionnel et technique est en passe d'être pris avec la faculté de distribuer
des fonctions plus spécifiques et/ou plus avancées sous la forme d'applications indépendantes
techniquement et interfacées avec le noyau du PGI. Cet agencement est édifié selon une architecture de
type Intégration d'applications d'entreprise (IAE). Cette articulation fait que l'usager dispose en même
temps :

 de fonctionnalités capables de gérer toute la profondeur du métier ;

 d'une large panoplie d'applications couvrant l'essentiel de ses besoins de gestion.
Parmi les applications spécialisées souvent requises par les utilisateurs, on peut citer la gestion :

 des entrepôts (IMS ou WMS) ;

 des ateliers (MES) ;
 des laboratoires (LIMS) ;
 de la relation client (CRM) ;
 de la chaîne logistique (SCM) ;
 de la maintenance (GMAO) ;
 des approvisionnements (e-procurement).
Si la démarche est aujourd’hui au stade embryonnaire, tant au niveau de la performance des architectures
techniques que des méthodes de construction fonctionnelle, l’évolution de la structure technique des
progiciels est clairement engagée et s'accélère. On trouve notamment des solutions plus globales
nommées application d'entreprise (PGI, SCM, CRM, LPM, SRM, Sidetrade…) et des PGI basés sur
une plateforme d'entreprise[Quoi ?] comportant une architecture orienté services comportant notamment un
système de gestion des processus d'affaires (BPMS) autorisant beaucoup de flexibilité et la réponse aux
besoins métier.