Marketplace Connectivity for Asynchronous Processes
As illustrated in Figure 1, IBM's WCS MPE provides diverse trading mechanisms, such as fixed-price buying, exchanges contract-based buying, RFQs, and auctions. Also, the punch-out mechanism can be used for remote supplier incorporation when dealing with fixed and contract pricing. Though, the more complex trading mechanisms, including RFQs, auctions, and exchanges, cannot be supported by the basic punch-out mechanism. This is since the flows between WCS MPE and the remote suppliers for fixed and contract pricing are synchronous, and take place through a real-time session with the buyer, thus making them amenable to the online punch-out process. RFQs, auctions, and exchanges entail asynchronous interactions between WCS MPE and the supplier. Next, let's look at how such asynchronous processes are handled. RFQs are used as a typical instance. Like flows and XML document interchanges can be used for other asynchronous trading mechanisms.
Figure 1. Trading mechanisms in WCS MPE
In WCS MPE, an RFQ is a trading method used when a buying organization attempts to acquire a special price for a buy, or when a buying organization cannot find a suitable offering in the EMP aggregated catalog that meets its requests. The RFQ may be issued in order to get a special price based on quantity for well-defined items or
For a collection of items. The RFQ may also be issued for exclusive items based on the buyer's explanation. The request is sent to one or more selling organizations and these may propose a bid on the RFQ. The selling organizations react to the RFQ and the buying organization may opt for one or more winning responses. The result of the RFQ procedure could be an order placed by the buyer or a contract could be created for the negotiated price. Figure 2 shows this process flow in WCS MPE.
Figure 2 RFQ process flows in WCS MPE.
Now, let's look at two dissimilar mechanisms for extending the RFQ procedure to a scattered environment. The first mechanism, referred to as "local RFQ," exploits the compensation of aggregating the catalogs at the EMP site, at the same time as distributing only the RFQ process. The second mechanism, which is referred to as "remote RFQ," allows buyers to attach to a remote WCBE at a supplier or a remote WCS MPE and issue an RFQ.
For local RFQs, the catalog is hosted at the WCS MPE site where the buyer is registered. Figure 3 shows the process flow for this configuration. The configuration includes the following parties:
Figure 3 RFQ process flow for local RFQ.
- An EMP where the buyers are registered
- One or more remote eMPs.
- One or more sellers registered on the remote EMP.
The flow starts with the buyer browsing the catalog on the EMP and creating an RFQ. The RFQ is sent as an XML message to the remote EMP Upon getting the RFQ, the remote EMP notifies the objective sellers. Each seller views the RFQ and creates a reaction for it. The asynchronous responses are then sent to the EMP as XML messages. The buyer can verify the status of the RFQ at any time. The buyer views the RFQ responses by logging on to the EMP, checks them, and selects a winner. Selecting a winner leads either to a purchase order or a negotiated contract. The order or the contract is then sent to the remote EMP or remote seller as an XML message. This solution has the compensation of an aggregated catalog and allows buyers on one EMP access to sellers on a remote EMP, and vice versa. It has, however, the earlier mentioned limitations of aggregated catalogs.
For isolated RFQs, the catalog is hosted either on the remote EMP where the seller is registered, or on the remote seller's Web site. Figure 4 shows the process flow for this relationship. This relationship also involves four parties. The flow starts with the buyer selecting on the local EMP a registered remote EMP or a remote seller. The EMP connects the buyer to the remote EMP site. The buyer browses the catalog on the remote EMP and creates an RFQ template. The RFQ template is then sent as an XML message to the EMP The RFQ template expected from the remote eMP is converted into RFQ by provided that additional information. It can then be optionally submitted for agreement. Finally, it is sent to the remote seller or remote EMP as an XML message. The remote EMP notifies the target sellers. The sellers sight the RFQ and create responses for it. The responses are then sent to the local EMP as XML messages. The buyer views the RFQ responses by logging on to the EMP, checking them, and selects a winner. Selecting a winner leads either to an order or to a negotiated contract. The order or the contract is then sent to the remote EMP or remote seller as an XML message.
Figure 4 RFQ process flow for remote RFQ.
This explanation overcomes the boundaries of aggregated catalogs for such asynchronous trading mechanisms, and allows buyers on one EMP access to sellers on a remote EMP, and vice versa. This comes at the price of losing the compensation of aggregated catalogs.