It's not free, and it's not easy, but if you want to grow and attract new customers, EDI is a requirement.

The first thing I want to make clear is that the title for this article was chosen by my editor, a woman who lives in a villa surrounded by a pack of vicious dogs that she calls "my pets." Needless to say, her view of the world is a little harsher than mine. Actually, Electronic Data Interchange (EDI) is more like one of those 1940s road movies with Bob Hope and Bing Crosby. There are ups and downs, a few chills, and some laughs. All in all, it's not that bad, you just have to make the right choices as you go along.

Why Do EDI?

I love it when people ask me this. "Why should I do EDI, Dave?" They're so innocent. It's sweet, really.

The reason you should do EDI is that it's the best way to really streamline your supply chain, tie yourself more closely to your business partners, and automate as much of the busy work as possible. However, 99 percent of the time it's because somebody bigger than you, someone who helps you determine whether or not you had a good year, someone whose emails you look at right away is telling you that you have to. It's the golden rule, don't you know.

No matter what the reason, however, starting out on EDI can be kind of scary, and there are some basic things you should know.

What Do You Need?

There are a number of things you need to get started with EDI.

The first is management commitment. No, I mean a real management commitment. Top management must realize that EDI is necessary (not just important) to more fully automate the business function, and they must be willing to spend some money up front and provide ongoing resources to make sure that happens. I know; the minute you mention money, everyone gets spooked. How much money? That will depend on a lot of factors, but be suspicious of anyone who says you can do it for "almost nothing." Spend enough to be able to build a secure, reliable, easy-to-customize system but not enough that you get features you are never going to use. More on that later.

Second, I would take a few moments and do a trading partner review. How many trading partners do you think you will have (who has asked you about EDI, who does EDI, that sort of thing), what types of documents do you think they will want to trade (orders, POs, invoices, shipping schedules, etc.), how do they want you to communicate with them (VAN, AS2, etc.), what standards are you going to have to use, will you be providing document models or will they be giving you specs, etc. Don't spend forever on this, but get some sort of idea what you're heading for.

Third, you're going to have to integrate EDI into your back office business system—that is, just printing off the output of the EDI is not enough. It's not even good. If that's what you're going to do, don't even bother to do EDI. You're not ready for it. For EDI to be meaningful, the data must drop into and out of your ERP system automatically (or pretty automatically). For input EDI documents, this means you'll need a batch editing system that mimics your online editing function (order entry, etc.) and lets you tweak the EDI data if necessary. For outbound documents, it means you need to be able to create files instead of paper documents (think invoicing) and then use those files to build your EDI documents. Seriously, if you're not ready to do that, think twice about doing EDI. These functions are generally add-ons, not rewrites to your business system, but the costs and time for this have to be considered, although if you own a packaged ERP system there's a very good probability that it already contains EDI-oriented apps. Something to check into, though. Don't promise somebody you can accept 867s until you know you can handle them in or out of your business system.

Fourth, regardless of the business system you have, there are some EDI-specific tools you'll need to purchase. These tools allow you to set up and configure an EDI system to interface with your business system. The alternative to buying and learning how to use these tools is to hook yourself in with a third party that acts as a service provider for you (managed services). Which you do depends on your psyche. Do you like to have control over stuff (in that case, buy the tools) or do you want to just sign a contract and not worry about it (managed services)? Some people do a little of both; they buy the tools and set up the environment in their machine but have someone from outside do the setup and regular maintenance.

VAN Services

Back in the olden days, people did point-to-point communication. They used Bisync or something similar to connect directly with their customers. Today, most people use a Value Added Network (VAN). This VAN handles all of the communications and recovery activities. Otherwise, you need to initiate the connection to your trading partner (that's what we call your customer or vendor) and handle all of the recovery (did the comm session complete successfully, etc.).

There's a cost for the VAN services, but there's also a cost for not using it. The choice is up to you. The VAN provides you a secure, dependable pipeline to send and receive EDI documents to and from your trading partners without having to set up a separate comm session for each one. And it provides a high level of traceability and recovery. If your trading partner says they never received an invoice from you, you can check your VAN's online records and see when it was picked up from you and when it was dropped off to their mailbox.

I guess I should say something about the Internet. When it first started gaining traction, everyone saw the Internet as a way they could do EDI for free. Just send your data over, and it would all be good. We don't need no stinkin' VAN. Unfortunately, the Internet by itself has no security (yes, you can set things up under HTTPS, but you have to do that; it doesn't happen automatically) and no recovery (if your trading partner says they didn't receive an order, what are you going to do, call them a liar?). Unless you want to have to do all kinds of setup work for every trading partner, you still need to purchase software to do the AS2 connection (a direct Internet connection). I have no problem if you do that, but it isn't free. Just thought I'd mention that.

Translator

You will also need a translator, a piece of software that somehow creates an EDI document out of your user files (outbound). Or else creates records in your user files from an EDI document (inbound). And it handles the connections to your VAN so that communications can occur automatically again without your having to get your hands dirty.

A number of translators are available, TLi (formerly owned by Inovis but now by GXS) and Gentran (formerly owned by Sterling but now by IBM) being the two most common. Both of these run on the i. There are a bunch of other translators that run on PCs, but seriously, dude. If you're on the i, choosing a PC translator is just asking for trouble.

The one warning I would give is not to go overboard. As I said, TLi and Gentran are owned by GXS and IBM, respectively, but those are not the only EDI products in their stable. GXS has BizManager, and IBM has Integrator. Both are generally referred to as B2B integrators as opposed to EDI translators. In many ways, this nomenclature difference is no more significant than when we switched from MRPII to ERP to describe a full-function business system. The point is, you may not need a B2B integration program. Maybe all you need is a translator. B2B integrators have a steeper learning curve and require more tweaking. Oh, and they're more expensive. What they provide that's important is additional, non-traditional ways of connecting with your partners. The vendor (no matter whether it's GXS or IBM or whoever) will naturally try to slot you toward the integrator rather than the translator. Think carefully (and this is where the trading partner analysis may come in handy) and make sure you need that extra functionality before you drink the Kool-Aid.

Standards: X12 and EDIFACT and XML, Oh My!

Don't you just hate it when somebody uses a bit as old as that? Yeah? Well tough luck, pal. Too late now. What gives EDI its strength are the standards: sets of segments and elements that are predefined and included in the translator (that's one of the things you're paying for). They're used to make sure that someone can trade with you without knowing anything about your system or your file structures. You both know the standard, and that's what you use to communicate with. There are many standards, but you're likely to run into only two.

• X12 is the EDI standard most often used in the U.S. It's the best one, providing spots for all the data you would need, but isn't too (that is a relative term for EDI) verbose.

• EDIFACT is a standard developed by the UN. It's used heavily in Europe, Asia, and Africa. It's OK but tends to have more segments involved than a comparable X12 document. I would rather use X12 if I can, but it's still a good, solid standard.

And then there's XML. Truth be told, XML is not a standard. In fact, it's an anti-standard, a way to define a stream of data that's specific to you. I guess the idea was to reduce the amount of data being transmitted, and 20 years ago XML was touted as the replacement to EDI. You could use it to define your own documents and share them with your trading partners without having to bother with (or buy) the standards. Yeah, like all your trading partners need is a document that's completely proprietary to you, not like anything else for anyone else. The simple fact is that XML found more of a home as a language to move data from one application to another on the Web. And even that's being threatened as many people are starting to use JSON as a data movement mechanism (but not related to EDI). Unfortunately, some companies are on an XML for EDI kick, and it takes so long to switch over that they can't get out of it.

When you're dealing with a standard like X12 or EDIFACT, you can just import the standard into the mapping between the EDI document and your user files (or vice versa). With XML, unless the trading partner provides a schema, you have to build that yourself in the translator. In general, XML documents take longer to build and provide no real advantage in terms of transfer speed or efficiency. But you will run into it out there.

Bottom Line

EDI isn't something new. It's been around the block a few times, but it still remains one of the most cost-effective ways to streamline your business and help cement your relationships with your trading partners (somebody is going to think twice before switching from you to someone else if they have to set up EDI for the new guy first). But it does require some work (sometimes a fair amount until you get up and rolling). And it's not free, although wise decisions can keep the cost within reasonable limits. The important thing to remember is that if you want to grow and attract new customers, EDI is a requirement. 

David Shirey is president of Shirey Consulting Services, providing technical and business consulting services for the IBM i world. Among the services provided are IBM i technical support, including application design and programming services, ERP installation and support, and EDI setup and maintenance. With experience in a wide range of industries (food and beverage to electronics to hard manufacturing to drugs--the legal kind--to medical devices to fulfillment houses) and a wide range of business sizes served (from very large, like Fresh Express, to much smaller, like Labconco), SCS has the knowledge and experience to assist with your technical or business issues. You may contact Dave by email at This email address is being protected from spambots. You need JavaScript enabled to view it. or by phone at (616) 304-2466.

---

MC Press books written by David Shirey available now on the MC Press Bookstore.

		21st Century RPG: /Free, ILE, and MVC Boost your productivity, modernize your applications, and upgrade your skills with these powerful coding methods. List Price $69.95 Now On Sale

Also Read

One Click Away: Where Does the Data Come From?

Technology Focus: Electronic Commerce Apps and Services

Instrumentation and Automation Fuel Customer Experience Data Collection