La phase d’audit
109
© Groupe Eyrolles
global de l’éditeur et que représenteront-ils dans l’avenir ? » ; la seule réponse possible est que cette part aille en diminution croissante, sinon le produit choisi ne
sera jamais un progiciel !
Le tableau ci-après montre le type de rapports de forces entre les éditeurs et l’utilisateur en fonction de la stratégie adoptée, selon que l’utilisateur s’appuie sur un
seul éditeur d’ERP, ou un éditeur d’ERP plus des modules de compléments d’éditeurs tiers, ou encore en adoptant d’emblée un noyau constitué d’un ERP principal et des modules d’éditeurs concurrents interfacés avec ce noyau.
Tableau 2.3 : Les rapports de forces typiques entre utilisateur et éditeurs
L’intégration vue par l’utilisateur final
L’intégration vue par l’éditeur se veut industrielle. L’éditeur a pour objectif de
recouvrir le maximum de domaines fonctionnels possible, de prendre le contrôle
du marché le plus large pour lui. Il poussera, en conséquence, vers une intégration
forcée de nombre de produits : soit, de vrais modules natifs, conçus par ses services
avec les mêmes outils que le reste de son ERP, soit des progiciels d’acquisition
récente sont, dans un premier temps, simplement « pontés vers l’ERP », dans
Stratégie
Évolutions
Un seul éditeur
d’ERP
Un ERP plus
des compléments a
a. C’est-à-dire des modules ou des progiciels de tierce partie.
Un éditeur d’ERP
plus des concurrents b
b. Les concurrents, au sens « éditeurs importants » de suite de gestion, d’autres types de progiciels
prenant en charge l’ensemble d’un domaine horizontal. Par exemple : un éditeur de DRP, voire un
deuxième ERP.
Site pilote
Contraintes utilisateur
prépondérantes
Contraintes utilisateur prépondérantes
Efforts ou recherche
d’interfaces
Contraintes utilisateur
prépondérantes
Efforts ou recherche
d’interfaces
Déploiement
des 1 ers modules
du domaine
pilote
Répétition du site pilote
au domaine pilote
Répétition du site pilote au
domaine pilote
Répétition du site pilote
domaine pilote
Autres domaines
cibles
Contraintes utilisateur
Contraintes éditeur
Efforts d’interfaces facilités
Contraintes utilisateur
prédominantes
Utilisateur en position
de force
Éditeurs en concurrence
Réingénierie
complète
de l’architecture
applicative
Contraintes éditeur
prépondérantes
Monopole de fait
de l’éditeur
Utilisateur maître
du système
Interfaces déjà facilitées
Éditeur d’ERP en pole position sans monopole
Architecture ouverte
Éditeurs en concurrence
Utilisateur en position
de force
Interfaces déjà facilitées
109
© Groupe Eyrolles
global de l’éditeur et que représenteront-ils dans l’avenir ? » ; la seule réponse possible est que cette part aille en diminution croissante, sinon le produit choisi ne
sera jamais un progiciel !
Le tableau ci-après montre le type de rapports de forces entre les éditeurs et l’utilisateur en fonction de la stratégie adoptée, selon que l’utilisateur s’appuie sur un
seul éditeur d’ERP, ou un éditeur d’ERP plus des modules de compléments d’éditeurs tiers, ou encore en adoptant d’emblée un noyau constitué d’un ERP principal et des modules d’éditeurs concurrents interfacés avec ce noyau.
Tableau 2.3 : Les rapports de forces typiques entre utilisateur et éditeurs
L’intégration vue par l’utilisateur final
L’intégration vue par l’éditeur se veut industrielle. L’éditeur a pour objectif de
recouvrir le maximum de domaines fonctionnels possible, de prendre le contrôle
du marché le plus large pour lui. Il poussera, en conséquence, vers une intégration
forcée de nombre de produits : soit, de vrais modules natifs, conçus par ses services
avec les mêmes outils que le reste de son ERP, soit des progiciels d’acquisition
récente sont, dans un premier temps, simplement « pontés vers l’ERP », dans
Stratégie
Évolutions
Un seul éditeur
d’ERP
Un ERP plus
des compléments a
a. C’est-à-dire des modules ou des progiciels de tierce partie.
Un éditeur d’ERP
plus des concurrents b
b. Les concurrents, au sens « éditeurs importants » de suite de gestion, d’autres types de progiciels
prenant en charge l’ensemble d’un domaine horizontal. Par exemple : un éditeur de DRP, voire un
deuxième ERP.
Site pilote
Contraintes utilisateur
prépondérantes
Contraintes utilisateur prépondérantes
Efforts ou recherche
d’interfaces
Contraintes utilisateur
prépondérantes
Efforts ou recherche
d’interfaces
Déploiement
des 1 ers modules
du domaine
pilote
Répétition du site pilote
au domaine pilote
Répétition du site pilote au
domaine pilote
Répétition du site pilote
domaine pilote
Autres domaines
cibles
Contraintes utilisateur
Contraintes éditeur
Efforts d’interfaces facilités
Contraintes utilisateur
prédominantes
Utilisateur en position
de force
Éditeurs en concurrence
Réingénierie
complète
de l’architecture
applicative
Contraintes éditeur
prépondérantes
Monopole de fait
de l’éditeur
Utilisateur maître
du système
Interfaces déjà facilitées
Éditeur d’ERP en pole position sans monopole
Architecture ouverte
Éditeurs en concurrence
Utilisateur en position
de force
Interfaces déjà facilitées