Née de la problématique de la gestion électronique des achats, la place de marché flexibilise les échanges clients-fournisseurs. La convergence entre les achats et les places de marché a débouché sur deux architectures différentes s’appuyant sur des principes opposés. La première, plutôt adaptée aux PME ou aux achats non stratégiques, et choisie par des éditeurs tels qu’Exponentiel Technologies et RightWorks, concentre la gestion des achats sur la place de marché. Cette dernière va alors héberger un seul catalogue, sur lequel les clients bénéficient de vues personnalisées et d’un référentiel décrivant les adhérents ; leurs organisations ; les profils ; les droits (par exemple, les plafonds de dépenses) ; les tarifs négociés ; et les circuits de validation. Les utilisateurs se connectent, dans ce cas, via le Web. La seconde architecture s’adresse de préférence aux grandes entreprises, ou aux achats stratégiques. Prônée par Commerce One, associé à SAP, ou par Oracle, elle va délivrer des services transactionnels à la gestion des achats, elle-même décentralisée au sein des entreprises qui possèdent leurs propres catalogues, leurs référentiels et leurs serveurs Web.
Un noyau de services standards
Les deux architectures peuvent cependant se rejoindre. Si une place de marché décentralise la gestion des achats, elle devra toutefois être capable de synchroniser son catalogue central et les catalogues distants. Enfin, certains éditeurs laissent le choix entre la décentralisation et une gestion intégrée à la place de marché des achats élémentaires. Une autre question essentielle pour les entreprises concerne la gestion de leurs achats stratégiques vis-à-vis de leurs achats hors production. Certains éditeurs, tels Commerce One ou SAP, préconisent une séparation franche, tant les processus sont différents. D’autres, à l’instar d’Ariba ou Oracle, estiment qu’il doit s’agir des mêmes applications, dans lesquelles seront décrits des processus spécifiques.Au-delà de ces disparités, la plupart des offres de développement de places de marché ont en commun un noyau dur de services centralisés. On y trouve la gestion des adhésions et du catalogue de produits ; le moteur de recherche associé ; le passage d’appels d’offres ; et les mécanismes de convergence de l’offre et de la demande (enchères ou enchères inversées). Une fois les transactions concrétisées, la place de marché peut ainsi créer un contrat, recevoir les commandes des acheteurs, les répercuter auprès des fournisseurs et, enfin, mettre à jour les systèmes d’information des deux parties. Elle assure aussi la sécurité, la non-répudiation et la traçabilité.Ces transactions peuvent s’effectuer via le téléphone, le fax ou le Web. Mais l’un des services essentiels consiste à aiguiller des transactions véhiculées par des messages XML (Extensible markup language). La plupart des places de marché confient cette tâche à leur moteur transactionnel (qui s’appuie, en général, sur HTTP), quand le dialogue s’instaure avec leur propre outil de gestion des achats. En revanche, la communication entre une place de marché et des applications tierces (gestion des achats, ERP ou applications spécifiques) est souvent déléguée à des offres d’EAI ( Enterprise application integration) interentreprises telles que webMethods B to B. Il en va de même lorsqu’il s’agit de mettre en relation deux places de marché, lors d’un achat.
Vers la gestion collaborative de la chaîne logistique
L’implémentation de ces services repose sur des serveurs d’applications, respectivement dédiés à la gestion du catalogue et du processus d’initialisation des transactions, et à l’intégration transactionnelle. De plus en plus souvent, ces serveurs ciblent le monde Java. Dès lors, le progiciel peut prendre la forme de composants Java, tandis que l’interface graphique reprend les standards du Web.Les places de marché débordent désormais du seul cadre de la gestion des achats, pour s’orienter vers un domaine complémentaire des achats stratégiques, la gestion collaborative de la chaîne logistique. Dans ce cadre également, il va falloir choisir entre une architecture centralisée et une architecture distribuée, avec une problématique toutefois différente. Oracle ou i2 Technologies incitent ainsi à la prise en charge, par la place de marché, d’une application de gestion de la chaîne logistique ayant pour mission de centraliser l’ensemble des informations fournies par le client et le fournisseur (prévisions de ventes, stocks, capacité de production ou délais), à partir desquelles sont calculées et transmises d’autres informations. Les partisans de cette approche estiment que seul ce modèle offre une vision globale, chaque entreprise ayant forcément plusieurs clients et fournisseurs. De plus, ceux-ci peuvent toujours connecter à la place de marché leurs propres moteurs de gestion de la chaîne logistique, qui délivreront et exploiteront les informations qu’elle centralise. À l’inverse, les entreprises ne possédant pas leur solution de gestion de la chaîne logistique seront séduites par cette externalisation de fait.De leur côté, Ariba ou RightWorks défendent, au contraire, une topologie décentralisée. Les différents adhérents possèdent alors leurs propres applications de Supply Chain, et le rôle de la place de marché se borne à les faire dialoguer directement, de point à point.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
