Electronic data interchange tools

True or false?

A. EDI is a dynamic technology and a trusted standard; keep it handy for electronic
transactions.

B. EDI is a dinosaur technology and a sinking ship; keep your 10-foot pole handy.

Both statements are true. Electronic data interchange can be of great value to your
agency, but to get that value, you must tread as though through a minefield.

EDI was created to solve a specific problem. In the bad old days, Agency A would key
purchase order information into its computer, which would print the purchase order, and
Agency A would mail it to Company B.

Company B would key the information into its computer, which would print an invoice for
mailing to Agency A. Agency A would key the invoice information into its computer, which
would cut a check for mailing to Company B.

The process could take weeks, even months. That’s not counting the time both
organizations would have to spend keying and rekeying the same information, and tracking
down and fixing the resulting, inevitable errors.

It didn’t take a genius to realize it would make more sense if Computer A and
Computer B communicated directly with each other.

The big problem was that different—and proprietary—hardware, operating
systems, software and data formats prevented that communication.

What was needed was a common language that machines could speak to conduct
transactions.

ANSI X12, the first major standard for EDI, was welcomed on the scene in 1984.

X12 defines possible transactions, or transaction sets, and the supporting
structures—in X12 parlance, segments and the constituent data elements—to create
the transactions.

Each transaction set has a unique 3-digit number.

You’ll hear EDI pros tossing the numbers around—810 (invoice), 840 (request
for quotations), 843 (response to RFQ), 850 (purchase order) and 997 (functional
acknowledgement).

Since X12 arrived, several other standards have emerged. The United Nations, wary of
American EDI imperialism, in 1987 created the EDI for the Facilitation of Administration,
Commerce and Transport (EDIFACT) standard, which is based on X12. Another is Tradacoms, a
European EDI standard developed by the Article Numbering Association.

In the United States, X12 is by far the most common standard, but other countries use
X12, EDIFACT or Tradacoms, depending on the country and with whom they are trading.

The next problem was how to connect Computer A and Computer B. Enterprises used direct
modem or leased line connections; many still do. If an enterprise has only a few
connections to make, it’s feasible, but as the number of connections rises, the
bottom line swells fast.

Enter value-added networks. A VAN is a third-party central clearinghouse for EDI.
Agency A and Company B both subscribe to the VAN.

Both send their EDI transactions to the VAN at their convenience, probably after hours,
when telephone rates are cheaper. The VAN sorts the transactions and stores them in the
right electronic mailboxes.

Subscribing enterprises periodically check their mailboxes and download EDI
transactions addressed to them. The setup allows asynchronous EDI communications among
enterprises.

VANs also provide services such as security and guarantee of delivery. A VAN can be a
good place to find more enterprises with which to do EDI.

The more EDI trading partners an enterprise has, the greater the likely savings. To
contact particular trading partners, many enterprises use more than one VAN.

Major VANs include General Electric Information Services and IBM Corp.’s Global
Network. Federal agencies that want to use a VAN must choose from a list of VANs
registered with the General Services Administration. The Defense Department’s list
includes AT&T Corp., Harbinger Corp., IBM, Loren Data Corp. of Marina del Rey, Calif.,
and MCI WorldCom Inc. Although the mandate for its use has been repealed, most agencies
still use the Federal Acquisition Network.

Electronic payment is a fairly recent wrinkle. Electronic funds transfer lets an entity
make payments through a third-party automated clearinghouse, usually a value-added bank.

Agency A uses EDI to authorize payment to Company B. The bank makes the transfer of
funds, then notifies both that the financial transaction has taken place.

Federal agencies provide some of the driving force toward EFT; various mandates decree
the paying of taxes and other fees using EDI and EFT. Some agencies also pay their
suppliers using EFT.

EDI software has two main purposes: translation and mapping. You send your data, and
the EDI software translates it into an EDI format. When you receive data, the software
accepts the incoming EDI and translates it into a format your applications can handle.

Mapping refers to the exchange of information between EDI transactions and other
applications, a tricky maneuver. If you’re doing EDI, you’re probably using both
translation and mapping.

Government uses EDI for several main purposes.

First, of course, is procurement. EDI is made for sending out requests for quotations,
creating purchase orders for goods and services, and authorizing payment using EFT.

Second is payment of taxes and fees. Enterprises must use EDI to pay tax installments
to the federal government, for example.

Another use is reporting to regulatory agencies—oil companies use EDI to submit
quarterly petroleum reports to the federal government.

One special difficulty that government agencies often face is trying to satisfy
multiple agendas that may be mutually exclusive.

For example, an agency may have a mandate to implement EDI, buy from off-the-shelf
vendors, and encourage small businesses, all while cutting the budget.

There’s a problem here. Implementing EDI may take a lot of capital and support. It
may also preclude buying off-the-shelf—there is no EDI shelf. Which EDI tool and how
it is implemented depends on the activity for which you wish to use it—one size
doesn’t even fit two.

Implementing EDI may also mean cutting small businesses, which usually are not
EDI-capable, out of the loop. But making the allowances to deal with small businesses may
complicate your process beyond what EDI can handle.

It is quite likely that your agency already has a mandate, such as the Federal
Acquisition Streamlining Act, to use EDI, that also covers what software and VAN to use.
Your major decision would be where to plug things in. Everyone else has to decide on one
or more of these items. Your decision involves several considerations:

For example, you could tie together previously separate departments to simplify
workflow. Many agencies have entirely separate branches for requesting, acquiring, paying
for, and receiving goods and services, with no easy way to check on who’s doing what.
EDI can be the central technology that lets you coordinate all these activities and
exercise greater control over the process.

It is especially important that upper management commit to an EDI project. Implementing
EDI will require effort and dedication, and the returns are not immediate, so it is
important to take the long view.

For the most part, the Web does not. Granted, Web implementations have ways to provide
excellent security, but it simply does not have the long history that many find
comforting. The same is true of reliability. VANs can produce statistics to document
decades of reliability; such information for the Web is not available.

That’s much easier to achieve if people don’t have to learn all-new systems
of doing things. If people willingly buy into the new EDI system, you stand a good chance
of succeeding. That happy coexistence may not be possible. You may have to choose between
your existing applications and applications that will work with the EDI system. This is
one advantage that Web-mediated EDI has: A Web browser can go almost anywhere.

The application integration issue has another aspect. One reason for implementing EDI
is to simplify your work processes. But even if the EDI software, such as a Web browser,
can coexist with your applications, that does not mean it will be supporting the full
advantages of EDI.

If you can get the data, but it just sits on your desktop, that’s no help. You
must be able to keep that data moving through the applications—and the other
agencies—that need it.

EDI is not an all-or-nothing technology. You may decide to use EDI to distribute RFQs
and continue the status quo for handling other processes. This is often a good way to ease
into EDI.

There is probably at least one area where you feel EDI can make a definite difference
in how you do things.

Go with that, and see what happens. If that is successful, you can think about other
ways of taking advantage of EDI.

When choosing EDI systems, you need to look at the big picture, including mandates you
must follow, agencies and enterprises you must interact with, your goals for using EDI,
the users themselves, existing computers and software, and costs.

You need to make some basic decisions: whether to use a VAN; whether to use the Web;
what to use EDI for and what not to use it for. EDI is a tried and trusted technology for
automating and simplifying many of your transactions. It is not going away anytime soon.

In fact, the influence of the Web may well give EDI the boost it needs to help you
reach a whole new audience of users.  n

Edmund X. DeJesus, of Norwood, Mass., is a free-lance writer on information technology.

Since the advent of Web commerce and corporate intranets, pundits have predicted the
demise of Electronic Data Interchange.

The predictions are usually gleeful in tone; EDI’s
characteristics—inflexibility, incomprehensibility and intractability—and roots
in the mainframes of big business and big government are anathema to the Web-minded.

Extensible Markup Language, a flexible subset of the more formidable Structured
Generalized Markup Language, supports a variety of user-defined structures and
characteristics. To Web-enabled EDI supporters, these virtues make XML appear a shining
knight, ready to slay the EDI dragon.

But enterprise EDI users see that the Web does not threaten EDI. Rather, it offers new
opportunities for extending its life and usefulness.

A prime example in business is the ANX project, an effort by the Big 3 U.S. auto makers
to move their thousands of suppliers and partners from leased-line communications systems
to Internet networks.

Offices such as the XML/EDI Group—posted at
www.geocities.com/WallStreet/Floor/5815/xmledigroup.htm—are using XML to create a
framework for bringing EDI standards to the Web.

After all, XML’s structures can easily support those of EDI itself. And why
redefine from scratch the characteristics of a purchase order? As EDI already does it, why
not simply incorporate EDI capabilities into a new structure: XML? In such a move you
combine EDI’s completeness and years of experience with XML’s Web-readiness and
flexibility. Far from slaying the EDI dragon, XML takes it surfing on the Web.

The strategy plays out like this: First, incorporate EDI standards—X12, EDIFACT or
whatever—into XML. Second, make those XML structures freely available on the Web.

Then watch as third-party entities start setting up shop on the Web to deal in XML-EDI,
much as VANs deal with EDI now. The inherent openness of the Web will start drawing
more—and smaller—enterprises to the XML-EDI standards.

Enterprises will use their intranets, with an XML-EDI backbone, to support their needs
for security while providing data for trading partners to import. Some see EDI as the way
to widespread electronic commerce.

Many of the largest VANs are moving in fast on the Web version of EDI, usually by
implementing linked intranets. By doing so, the train of thought seems to be, they
won’t be left out in the cold if Web EDI takes over but will instead have the same
commanding position they’ve held with ordinary EDI.

It also puts them in a position to offer agencies a whole new set of services. Web VANs
can provide the same kind of secure handholding they offer to feds skittish about
electronic commerce over the Web.

The ubiquity of the Web works in VANs’ favor, extending their reach to a vast new
audience of potential customers: small and midsize enterprises that found conventional
VANs prohibitively expensive or complex.

VAN powerhouse GE Information Services of Rockville, Md., is introducing GE InterLinx,
which uses XML to support EDI over the Internet. Similarly, St. Paul Software Inc. of St.
Paul, Minn., has WEB EC.

Loren Data Corp. of Marina del Rey, Calif., at www.ld.com, is a pioneer in another form
of enterprise: the EDI boutique. A subscribing company’s users can set up search
criteria on Loren Data’s Web site. Loren then monitors government EDI for requests
for proposals that fall within the users’ criteria.

The users examine the RFQ and bid on it. Loren translates the bid into EDI that returns
to your agency. The arrangement benefits the company, which gets a crack at government
business, and agencies, which get more trading partners onto EDI.

The last-ditch argument of doomsayers is the old “The Internet is falling”
refrain. Not an unreasonable prediction, given the near-vertical increase in Internet use.
There is, of course, a need for assured bandwidth for pushing transactions along.

But we’ve heard the same forecast annually for at least the last five years, and
it hasn’t happened yet. Again, indications are that the reverse will be true.

Given that megacorporate America will be moving many transactions to the Internet, they
will take pains to ensure that the Internet keeps up as a viable transaction medium.

Far from being the hapless victims of an imminent Internet collapse, they will be the
Internet’s most valuable defenders.

The moral of the story: Don’t count your Chicken Littles before they hatch. 

The foremost of an electronic data interchange ’s many benefits is that it
eliminates a lot of human intervention—no more rekeying of transactions. That saves
time and money.

The resulting paperwork reduction represents an additional time and cost savings: no
more producing, moving, handling and storing bales of paper.

It speeds the whole purchase order-invoice-payment cycle.

The internal changes EDI usually forces on an enterprise—elimination of data
duplication and streamlining of processes—are valuable in themselves.

EDI is more versatile than it is flexible. For example, some enterprises use EDI for
automatic stock replenishment. Because the system notifies suppliers when stocks run low,
the amount of supplies kept on hand can be reduced. That can cut warehousing costs
dramatically.

On the flip side, EDI is an external transaction communications system: After the
information arrives in-house, you must route it to the proper applications.

This can requires excruciating integration projects to link EDI with existing
back-office systems. Also, per-transaction costs and value-added network subscription
expenses can be high.

EDI communication is mainly an asynchronous process, so it doesn’t offer the
immediacy of real-time interactions.

You can only do EDI with enterprises that have EDI capability, and of the many millions
of companies, several hundred thousand are members of the EDI club. EDI’s advantages
are enjoyed mostly by very large enterprises.

Because EDI is complex to set up and can be expensive, it is an option that many small
and midsize enterprises forgo. That can mean they must drop out of the pool of potential
government suppliers.

Finally, EDI has inflexible, nearly impenetrable standards.

Government is attracted to EDI’s standards and simplicity, and the security that
EDI connections—VANs—provide. Suppliers have little choice: If they want to do
business with the large enterprise, they must implement EDI.

Smaller suppliers, for which EDI is not cost-effective, have called this a
gun-to-the-head EDI implementation.

The solution to the problem for small and midsize organizations is EDI over the
Internet, EDI-INT.

In fact, with the advent of Web transactions, many people question both the necessity
for and role of EDI.