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.

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.

“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….