EDI is Dead (Long Live EDI) November 28, 2007
Posted by Bill Chessman (Inovis) in EDI.Tags: EDI, Standards
trackback
Okay, I’ll admit my statement may be premature. In fact, I may even be pulling your leg. Over the years, I’ve been reading a lot about the Next Big Thing that will seal the fate of the venerable, dare I say, ancient technology known as Electronic Data Interchange.
I, for one, like EDI. I think that the abbreviation EDI can stand for Efficient Data Interchange or even Effective Data Interchange equally well. Yet I keep reading that EDI has problems. Only thing is: I don’t hear what those problems are.
Since it’s inception, EDI has had several things going for it. It’s concise. You can transmit a lot of information in a pretty small footprint. It’s standardized. There are accredited, bona fide standards organizations such as ANSI ASC X12 and UN/CEFACT that have been producing standard EDI definitions from the start. It’s simple.
So what’s wrong with EDI? I’d be a starry eyed dreamer if I were to say, ‘nothing.’ I will say that I have not encountered any big difficulties. The syntax isn’t that different from a CSV-type file. If there’s a problem, it has to do with the inconsistent implementation of standard definitions across the industry. I’ve seen plenty of cases where a given mandatory element with a given meaning was deemed irrelevant by a given user so, by imperial fiat or some other mysterious logic, they simply dropped some other piece of data into it. Is a user’s failure to follow directions what’s wrong with EDI? (Hint: notice which word failure is most closely associated with in the previous sentence.)
We’ve seen Next Big Things come and go, but EDI continues to forge ahead. New versions of the big standards are still being produced. The US Government has even mandated the use of EDI data (specifically, some X12 transaction sets) in the healthcare industry with the Healthcare Industry Portability and Accountability Act (HIPAA). And, though the implementation guides are long and tedious, proper use should result in accurate and consistent data transmissions. That’s what EDI was made for.
So, I’m curious. What do you think is wrong with EDI?
Comments
Sorry comments are closed for this entry
EDI is about as exciting as watching paint dry!
The great thing about EDI is that it conforms to laid down standards that the trading partners can easily work to.
If ONLY the US would realise the great benefit of Tradacomms, as a standard, things would move on much quicker.
What are the problems with EDI?
First is the perception of what EDI is and isn’t. Your statement that EDI is “ancient technology” illustrates that your own perception is skewed.
EDI isn’t Technology! It is a set of Standard Definitions of data formats; Documents, Segments, and Elements as we call them. Technology is how you get the document to where it is going, and that has been changing to keep up with the times (see BizManager and AS2).
I’m often asked some version of this basic question. Why didn’t external communications move from dusty old EDI to the shinny new HTML? There was never any real need to do so. That would have moved the data from a format definition into the realm of ever changing technology. Once we had re-invented the wheel for HTML, how soon before we would need to switch to XML? How about Y or Z ML?
EDI doesn’t care what technology you use to send the data. Semaphore flags, Morris Code, Tape, Modem, Thumb drive, Email, AS2, or Sub-space Communications, are all the same to EDI as long as you can feed the data into your translator. That is why EDI won’t die; it is totally independent of technology.
As you mentioned, the next problem is getting all EDI Trading Partners to work from the same rulebook.
In the US retail industry the problem has always been the existence of huge retailers that won’t join VICS or follow their lead. They seem to want to make their EDI the most difficult in the world, creating an obstacle or ‘wall’ if you will. So that the vendor will do as much their work as possible, and so that the vendor will have more opportunities to fail, providing them with discounts in the form of chargeback fees.
The next issue is that ERP system designers still don’t seem to want to believe in the utility and longevity of EDI and design External Interfaces that will easily work with EDI and grow with EDI from version to version. Some ERP’s only work well with EDIFACT, while others are still set up for X12 version 3010. I sometimes wonder if the designers even EDI literate.
I still see new or upgraded ERP’s that don’t store such basic information as what the customer calls their ship to in the address file. I have to find some way to help customer service keep a cross-reference between the customer’s number and the ERP’s number for each location. No, that isn’t a job for the EDI coordinator. Does your postman keep your address book up to date? Never mind what we go through trying to keep a list of each customer’s numbers for our products.
EDI being sent using the latest communication technology is still the best external communication solution going. Long live EDI, and who’s ready for 5040?
For Tom Reynolds: I knew that if I left out TRADACOMS, I’d hear about it. So, I guess I’d better be inclusive and also mention GENCOD, VDA, SEDAS, EIAJ, CII, and my personal favorite, etc.
“The best thing about standards is that there are so many to choose from!” – Anonymous
For Mike Herlihy: You said it differently than I did, but I think that we’re on exactly the same page except that I would say EDI is a technology. It’s a very basic and simple one from a construction point of view, but just look at all the technical specifications there are for it!
5040? That’s old news! 5050 is just around the corner! Bring it on!
Have you heard about hm.gov.uk and Electonic Data Transfer?
http://news.bbc.co.uk/1/hi/uk_politics/7111660.stm
Puts me in mind of Pidgeon Protocol
http://www.ietf.org/rfc/rfc1149.txt
Reguards,
EDI Eddy
http://myediblog.blogspot.com/
Back in the olden days (between my college graduation in the stone age and the creation of the X12 standard), we had one similar: SneakerNet. The principle advantage was that it was possible to transport not only 8″ floppy disks, but (heavy) card decks and (heavy) tape reels. I’m not sure that the pidgeons (like African sparrows) could manage much more than a couple of CDs (“…it’s a simple matter of weight ratios!”)
As I look back at the path of EDI since I started, I would have to agree that EDI is a very basic Technology although more a business paradigm. I have practiced EDI with several different companies and the basic flaw I see in all is that they lay the entire program on an individual to manage. I was taught (way back) that in order to make the process work you needed a consortium of folks within the company to work as a team (not daily of course) to guide this process through, by managing the parts that make the whole. The transmission needs change and protocols change but the business still drives the need for EDI. Long Live EDI.
[...] 25, 2008 Posted by Meg Suggs in News. trackback Today’s question is inspired by a great post that Bill Chessman wrote a few weeks back. Is EDI dead? What, in your mind, WILL “seal the [...]
EDI is great.
EDI is good.
EDI upon my table,
has provided all my food.
“The best thing about standards is that there are so many to choose from!” – Anonymous
“If ONLY the US would realise the great benefit of Tradacomms, as a standard, things would move on much quicker.” – Tom Reynolds..
“… I knew that if I left out TRADACOMS, I’d hear about it. So, I guess I’d better be inclusive and also mention GENCOD, VDA, SEDAS, EIAJ, CII, and my personal favorite, etc.” – Bill Chessman
The above has been bandied back and forth in this blog – and, frankly, for years – but the basic question really can go back to the original quote about standards and the number of them!
Tom, why is TRADACOMS any better than ANSI X12 or any of the others…? Truly, it’s probably not… it’s just that it’s what YOU are used to and YOU see the benefit and the wonders of it and don’t understand why anybody would use something as _______ (clunky, complex, old, cranky, fill in your favorite descriptor!) as ________ (fill in any other standard)…
It’s just like the argument the XMLers are making against EDI -” why do something so arcane and complex? XML is SO easy to do!” But, then again, you suddenly have to have this document format for this trading partner and that document format for that trading partner and this other one over here for… well, you get the idea…. Just like any spoken language, the language of XML is going to be “speaker specific” – in that I will send you a “purchase order” and some other company will send you a “sales order” and they’re both the same thing – but you have to have 2 different XML formats to translate them (or whatever phrase you want to use!)….
Tom also makes a GREAT point in his first comment – about EDI being as exciting as watching paint dry…. but who says something has to be exciting to be something that works and gets the job done…?
Volkswagen had the “original beetle” or bug in production for over 60 years – in various parts of the world… that orignal rear-engined, air-cooled, round-roofed “people’s car” started production in 1938 (I think) and the last one rolled off some assembly line in South America (Mexico) in 2003… I don’t think that anybody would consider that car to be “exciting” by any stretch, but it was functional, affordable, and got the job done…
But, sure, it also wasn’t the only game in town…. For cheap transport, there were many competitors that came and went over the decades, but the Beetle soldiered on….
EDI is much like that Beetle…. Completent…. reliable…. variable…. capable…. and still around… EDI is NOT dead….
EDI is NOT dead…, just like COBOL and ACP/TPF are NOT dead. Like the Beetle as Craig pointed out, they are very much alive. As for XML, it is a standard of standards within the EDI concept, a child so to speak of EDI. However, protocols, standards, programming languages, operating system or even hardware is NOT the issue. At issue are “poor” systems designs, systems analyses and “cost savings”. Not linking in-house “stand alone” systems with EDI in most cases are attributed to “cost savings”, by passing the workflow from one desk to another for some action. While this “works” at HQ, in the field it is another story, the Designer and Analyst fail to [or are prevented from] account[ing] for the human element and that these external entities may fill multiple roles at the same time.
In the pre-office automation days, in a field office, a worker would have multiple “dumb” terminals on their desks. The workflow is NOT passed from one desk to another for some action, the same worker does the action, and because of the lack of EDI back at HQ, the same worker will copy data from one electronic document or email in one system and paste the data into an electronic document in another information system, or worse still, rekey the data from paper copy and takes some action, all done in name of “cost savings”. This is the cause of typographic, transposition, omission, filtering and other errors in system records, which would have been prevented by EDI.
With office automation, the multiple “dumb” terminals are hidden by a single desktop PC or laptop with multiple terminal emulations and now multiple web browser windows. The workers in the field are still copying data from one electronic document or email in one system and pasting the data into an electronic document in another information system, or worse still, rekey the data from paper copy and takes some action. Now with XML, the worker downloading a file from one system and uploading into another system and takes some action and since in many case temporal [time] delays are not critical, or considered in the workflow process and “cost savings” is critical, this is permitted occur in many business.
The NOT linking of “extranet” “stand alone” systems with EDI besides “cost savings”, there is another matter; it is a lack of trust between the “partners”. Since the internal business practice may have the worker copying data from one system to another, the same method is used with the “partners” system since in most cases, temporal delays are not critical in the workflow process and “cost savings” are critical.
Earlier this month another boggler was musing about temporal delays that were noted in the logs of a command and control system, where there were significant differences for the actual time an activity occurred and when it was recorded in the command and control system. This is a system of systems, were “partners” interacted and recorded their activities to promote “situational awareness” of an event. http://jonaslandgren.blogspot.com/2008/02/temporal-delays-in-command-control.html. It is most likely this system of systems is based on the business model describe above, where day-to-day, these temporal delays are not critical, however in a crisis these temporal delays distort the “situational awareness” when it is need most.
While again the lack of EDI or the lack of interoperability between the “partners” could be attributed to “cost savings”, it is also most likely the systems designer and systems analyst did not factor in the limited trust and relationships between the “partners”. As another boggler noted recently this is critical in a system of systems of this type and for “situational awareness” http://www.disaster-zone.com/2007/12/relationships-trust.html / http://www.disaster-zone.com/2008/03/quote-of-week-mad.html
Long live EDI, now if we could only get someone to use it, and also use XLM the correct way.
[...] and “EDI Thrives Once Again.” I believe our own Bill Chessman covered this with his EDI is Dead (Long Live EDI) post. EDI is far from dead, and it does continue to thrive not only in the regular software [...]
[...] we pose to readers to help us improve our company. A few of our most popular posts include: EDI is Dead (Long Live EDI), Five strategies for coping with retail chargebacks and our Question of the [...]
A standard is necessary. EDI is a true standard, it works, and it is proven.
Hello all, Tom Reynolds here again. Quite surprised to see my blog entry still here. I think it is a great innovation to create this blog. As I’ve said before, only a “techie” could get excited about EDI, per se….I once saw the presentation from “hell” when a developer put up an EDI map and proceeded to talk through it….
Now, I can get excited about how EDI will reduce my sales order processing paperwork, especially seasonal variations. I can get excited about how EDI will simplify my purchasing cycle and reduce my outgoing paperwork – remember 3, 5 even 7 part sets?
Anyway. Moving on. I liked Meg Sugg’s comments about how green is green. Not very. Have a look at: http://www.eco-net.org.uk
Keep blogging you lot.