A traditional EDI network in a typical industry
The upside of such exchanges is that PO errors and invoicing errors drop to nothing when such a system is in place. Why? It is error-free because everybody agrees on what was ordered and billed and the information enters the system (including both companies' databases) only once. There is no human intervention, keyboard mistakes, or misunderstanding of spoken phone instructions. Many EDI trading partners both pitch and catch information. Typical is the grocery brokerage industry, where middleman brokers order thousands of products from hundreds of manufacturers (all of whom use EDI for ordering and invoicing) on behalf of dozens of retailers (all of whom also use EDI). A brokerage both receives and sends EDI POs, passing them along to the appropriate manufacturers and receives and sends invoices on the return path. That's a lot of EDI traffic. Why is this interesting? Because in such an industry, EDI is generally a data-processing capability that is bundled in the broker's order-processing software system. It's a huge added expense (maintenance of this module and subscription to VANs are very costly) and a nuisance, because when it doesn't work well, the intervention required to set things right is very time-consuming and annoying. Now imagine EDI going away completely, from the broker's standpoint, in the scenario above. Letting the Web do the work for you
Let's look at it from the software provider's point of view. Fictitious Broker Software Company (BSC) provides order-processing software for the brokers in the example above. BSC also provides an EDI translator as a module attached to its package and administrates VAN relationships and EDI trading partner relationships for its client broker companies. It's expensive, time-consuming, troublesome, and not particularly profitable. Why? Because at the root of it all, the point of EDI is to build large, custom, data transport networks by interconnecting smaller networks with expensive intermediate networks. And what is the Internet? It's a large data transport network -- the largest and most accessible in the world. So BSC needs to get rid of all of those connections between its client broker companies and the VANs and keep the EDI flowing. By going to the Web, BSC can not only achieve this, it can make EDI go away too, at least from the broker's point of view, by creating a Web-based Internet on-ramp for all its client brokers. Orders, invoices, and other business documents flow from brokers to a common server via FTP and through the Internet to their destination VANs. And, while we're at it, let's put the EDI translation step in that one place as well, rather than in every broker's office. All the broker needs to deal with is the flat-file versions of the documents going in and out. EDI translation ceases to be a processing step in the broker's in-house cycle. At a stroke, by moving the EDI translation step and the dissemination-to-VANs step to the Internet, we have greatly simplified the company's life and expenses, and condensed a host of failure points down to a single location.