If you use EDI, the following scenario is probably all-too familiar: You’ve been using EDI to communicate with partner companies for years. Long ago, you were initially impressed with the technology, then skeptical when implementation proved nearly impossible, then discouraged when maintenance grew increasingly expensive, and finally grateful when the whole system quietly settled into a bloated but unobtrusive equilibrium.
Let’s be honest: Your victories in this area were hard-won. Partnerships were, in some cases, difficult to negotiate; EDI gives the more powerful company in a business partnership the upper hand. Implementation was awful, and your EDI software vendor and value-added network service (VANs) probably gave you assistance at their convenience and at high cost. You’ve always been just a little bit at their mercy because, when you first set all this up, they were the only game in town.
Now you’re ready for some real playing time with your partner companies. You not only have a choice of technologies for exchanging business documents and other data, you have entire paradigms to choose from, almost all of which are Internet-leveraged—with far more flexibility and room for growth than the VANs that service EDI. But your EDI system can’t go away entirely, because you have partners who, for whatever reason, must stay with what they have. So you’re faced with maintaining this old dinosaur, while bringing in faster, stronger mammals to live alongside it. There’s no way around that scenario—but there are some concepts that can help you come to terms with the job ahead, and give you a dynamic edge in what could otherwise be an ungainly compromise.
Blending the old and the new
If you’re facing a system design that blends an existing EDI system with more advanced data transfer technologies, your first task is to assess just how much change you need to inflict on the legacy system. It’s tempting to throw it all away, of course, but you’ve learned the hard way that the EDI network you have in place isn’t very fault-tolerant—and you may not have to go to such an extreme.
If it isn’t broken…
A typical EDI system contains several key components:
- A conversion utility for importing and exporting EDI-transmitted data into and out of a company’s databases
- An EDI translation package for converting raw EDI into and out of an intermediate flat-file format
- Communications software for pitching and catching with the VAN
- A reporting system to monitor EDI traffic on a day-to-day business level and at a lower communications-tracking level
The biggest piece that will differ is the database import and export. Most EDI legacy systems were put in place before the days of ERP database environments, and the import/export routines are customized. The contemporary IT shop has better means, and you’ll employ them in setting up data transport with Web services and other advanced B2B technologies. The other pieces, such as your EDI translator and VAN-specific communications, can remain the same if there’s no reason to change them.
Can your VANs go away?
On the other hand, cost alone could motivate you to ditch your VAN. Whether or not this step is practical depends on a couple of things. First, what are the limitations of your partner’s VAN? The major VAN services have been setting up interconnects for passing off your data to each other for almost two decades. Your EDI partner is staying with its VAN, so now you must determine what’s involved in setting up your own interconnect. If it’s a lot of trouble, or very expensive, it may be better to just keep your own VAN, since that interconnect is in place and working. Second, you need to assess what your VAN is doing for you. Does your EDI software do compliancy checking on both inbound and outbound EDI, or do you rely on your VAN for this? Most VANs provide compliancy checking if you need it. If not, you may find it’s cheaper to stay with your VAN, rather than investing in a new EDI translator.
Let your database do the work
The piece of your EDI system that needs upgrading the most is the part that handles getting the data into and out of your house system. Why? Because the same kinds of information you’re sending to the EDI partner who won’t abandon EDI for something better is also going to all your business partners that will, or already have, taken the leap. You need to have separate import/export transactions because everything ends up in a flat file anyway, and your EDI translator permits you to easily map and re-map transactions according to the layout of the source flat file. Since your database (probably an ERP system) easily accommodates this kind of traffic, it’s a simple and practical step to dispense with your customized EDI import/export routine, and simply remap your EDI transactions to the flat files you’re generating for your other B2B transactions.
Take the good stuff from EDI and put it into your other systems
Another important point is that EDI, while behind the times in terms of core technology, still has some conceptual edges over the leaner, meaner platforms. For example, EDI has a vast agreed-upon lexicon for document translation; it provides business-level message audit; and EDI benefits from and therefore encourages the synchronization of all partner databases, with respect to master data such as product and pricing information.
The means by which you can take such powerful ideas and implement them in more contemporary applications are too diverse to explore here—but it’s a good idea to think about bringing some of these great EDI concepts forward into your new apps.
Renegotiate your EDI vendor relationships—it’s no longer a seller’s game
If you’re going to hang onto your EDI translation package (for which you undoubtedly must maintain an expensive maintenance contract) and one or more VANs, consider the following: When EDI was new and hot, these guys ran the show. You had no choice but to use them, and they were not shy about charging you an arm and a leg for their service. Now that the Internet is secure and robust, they don’t have anywhere near the power over you that they once did. In fact, they’ll do just about anything to keep your business.
So make them work for it. Consider that your contracts with them are probably on 36-month cycles, or even shorter. Explore the idea of ditching them altogether, then call up the sales reps and prenegotiate a better, more advantageous contract for the next round. You can even factor the savings into your budgeting for your new B2B applications.
Accommodate the little guy
Here’s a final word. Make this thing work, clean out the closet, and dispense with all the old technology you can, and by all means cut costs in the process—but have some respect for your smaller partners. Remember that EDI, once heralded as the Great Egalitarian, in fact turned out to harshly empower the rich and strong, and is not such a great deal to the poor and weak. Can you comfortably assist a smaller partner in shedding some expense? For example, if you have small trading partners who have implemented EDI just for you, can you exchange data via Web services, allowing them to cut the expense of their VAN? If so, why not improve your business relationship by doing so? Be on the lookout for such opportunities.
Never forget that, while EDI purported to bring small and large companies onto common footing, the Internet is really doing so. Those smaller, weaker partners may someday be in the position to offer you the same generosity.
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.