To host or not to host?
What must BSC do to get such a server up and running? Here's a list of functions it must absorb:

• Interconnects to the major EDI VANs
• Translation software covering the required EDI versions (X-12, UCS, etc.)
• Mappings for the incoming and outgoing flat files
• A standards compliancy checking mechanism
• A system of organising inbound and outbound traffic by user for billing purposes

If BSC can take on these functions, the client brokers will only require:

• Database import/export of the relevant flat files
• FTP capability
• A way of tracking the inbound and outbound traffic for reconciliation purposes

Is a picture forming here? The client already has these pieces; they may require minor modification, but changing over to an EDI-free system basically means letting go of the hard parts. Little else will be required. Finally, there's the matter of this server that will now serve as a front end to the Internet for all the client brokers. BSC is looking at a formidable effort to create a front-end Web presence that can do all of those things. Except that it isn't necessary. There are data-conversion services on the Web that already do all of these things for a fee. Why would BSC go to the trouble and expense when service providers are already in place? There's still the matter of setup and fees. The fees are simple; BSC can lay the cost back on the client broker, because it's going to be less than what BSC has been charging for EDI maintenance under the old system. Setup is still a nuisance; converting all of those trading relationships over to the data-conversion service is going to be time-consuming and costly. What BSC wants to do is hand that task off to whoever was providing and maintaining its EDI module. Again, the cost is covered by the client brokers, and it's still less than they were paying before. Everybody wins -- almost. There are two problems: first, BSC has been providing software and services for its client brokers with EDI integrated and bundled as part of the package. Now, it's forsaking this role and sending its clients to a third party (cheaper, but no longer integrated, and now the client broker has someone else they have to deal with). Second, the data-conversion service is going to be making more money than necessary because each of BSC's clients represents a separate new client relationship. This situation is more costly than it needs to be for BSC's clients. So, what is the solution? BSC puts a front end on the front end. A trafficking server can be set up within the client community. All EDI messages in and out for the entire client base go to and from that server. The messages are batched and forwarded to the data conversion service as though from a single client, BSC. There's less overhead and less expense in the relationship with the data-conversion service and a business opportunity for BSC: the client brokers can be charged a modest maintenance fee for use of the trafficking server that is less than they would pay for direct services from the data conversion people; BSC pays a single client fee to use the data-conversion service (though usage fees would be very high, of course); and the maintenance of the trafficking server, as well as the administrative interaction with the data-conversion service, can be handed off to the subcontractor who did EDI for BSC. To summarise:

• EDI goes away for all of BSC's clients.
• BSC never has to think about EDI again.
• The company is paying much less per month for data exchange.
• BSC is actually making money from EDI.
• All the problems and errors will occur in two confined locations, rather than all over the map, as in the past.
• The intercompany exchange of data, and the underlying business processes, work better than they ever have before.

Everybody wins
As Web services and new interface possibilities proliferate, and developmental platforms and database technology become increasingly robust and flexible, the potential for distributed applications can only go through the roof. Do you have a system you share with other companies that could benefit from such a migration? Now is the time to consider it.