vignette|Contenu type d'un progiciel de Gestion Intégré (ERP). Un progiciel de gestion intégré ou PGI (en anglais, ou ERP system) 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 ».

Paramètres constitutifs Le progiciel de gestion intégré n'est pas normalisé et son appellation reste flottante : d'autres dénominations existent : progiciel, progiciel intégré, progiciel applicatif, progiciel applicatif intégré, progiciel de gestion, progiciel de gestion intégrée.

Les deux caractéristiques fondamentales des logiciels de type PGI sont : Le degré d'intégration ou DI : 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 ; La couverture opérationnelle ou CO : elle définit la capacité à 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 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 phasesMRP - Calcul des besoins : 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 ; 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 ; 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 »ERP et Progiciels de Gestion intégrés, Jean Louis Tomas, O1 Informatique, Dunod 2002. « 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é »Jean Louis Tomas, op. cit.. 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 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 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 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 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 (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 ).

Adaptation au contexte d'entreprise 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