Every day, companies around the world are migrating applications to the Web and expanding the potential of their businesses in the process. It's about more than cutting costs and increasing access—it's about rethinking the possibilities of your business. Forget incremental improvement—Web deployment can give your apps power and flexibility you never dreamed of, and you may find your business reinvented, your industry in a paradigm shift, and another bonus of Web migration—a way to get rid of EDI.
EDI: The ultimate legacy app
EDI has been a staple of my career for 12 years and I don’t remember ever really enjoying it. The same difficulties, barriers, implementation headaches, and user grumbles are always present. It also curtails innovation by requiring an extremely rigid adherence to accepted convention.
In the end, you're happy just to have it working at all, and all parties involved in an EDI chain generally heave a sigh of relief when the lowest common denominator is satisfied. Lofty EDI goals almost never are met. It works like this:
- Company A wishes to issue a purchase order (PO) to Company B. Company A's system generates the PO, which now resides in its database, and copies it into a convenient flat-file format.
- Company A converts the flat-file PO into EDI format, a very specific variable-length string of delimited values, with an EDI translation package. A header and trailer are attached, addressing the string.
- Company A accesses a value-added network (VAN), a proprietary data communications network that hosts a mailbox system for EDI users. Oops! Company B uses a different VAN, so VAN A hands off the PO to VAN B. It's stored in Company B's mailbox. (As a side feature, one of the VANs might screen the message for standards compliance; this is sometimes offered by VANs and used by EDI trading partners, though most EDI translators perform this same function.)
- Company B retrieves messages from its mailbox, including Company A's PO. It automatically generates an EDI message back to Company A along the same route; this message simply acknowledges receipt of the PO.
- Company B's EDI translator converts the PO back into flat-file format. It is imported into Company B's database and, consequently, into its order-processing system.
- Company B generates an invoice in flat-file format from its database. Internally, it ties the invoice to the original PO.
- Company B submits the flat-file invoice to its EDI translator, generating a similarly formatted EDI string, addressed back to Company A.
- Company B accesses its VAN and fires off the invoice, which jumps VANs and winds up in Company A's mailbox; Company A retrieves it, then generates an acknowledgement, which is sent back to Company B.
- At some point in both systems, POs are reconciled to invoices, and acknowledgments are reconciled to the documents they refer to.
This is a very simple example of EDI exchange. PO changes, advance ship notices, promotion documents, and other EDI messages make the whole system much more complex than this bare-bones exchange.
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.
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 organizing 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.
- 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.
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 some system you share with other companies that could benefit from such a migration? Now is the time to consider it.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.