Following is my recent response to several entry on a EDI blog:

Hi Michael & EDI-L'ers --

I'll add my 2 cents for the reasons that businesses trivialize the understanding of business in an B2B implementation. It is no mystery to me. I've been researching the early days of ebXML, RosettaNet, and the 2000 other XML "standards" bodies. The early XML zealots made the case -- and some still do -- that their respective committees have brought together all the experts from hundreds of companies and the business issues have been resolved -- by committee. All you need to do is register your company at an internet registry, use their business models, & suppliers/customers can come to you & "plug & play" the B2B process. What many EDI/ebiz folks do not understand is that this message was -- and still is -- conveyed to senior management of a very large number of companies and by organizations/universities that should know better. A Silicon Valley rumor is that executives were advised they should fire their EDI folks as they were no longer needed, and think of the cost savings of getting rid of these "expensive consultants"!! There was no appreciation of the business knowledge of these individuals.

The high-tech management was especially susceptible because they wanted to believe an internet solution was cheaper and the business process issues just dissolve because of the use of the internet. They were shown "easy-to-read" XML comparisons to "hard-to-read" EDI, not understanding these were not "standards-based" XML examples, some of the comparisons were absurd; and does the computer care how "readable" it is, as long as it is mapped properly. Marketing took over eBusiness. Remember all the ads: "We saved $500 million by doing eCommerce"? They were too far removed to understand that EDI over the internet existed since 1995 and was already evolving. They also did not understand nor appreciate the level of sophistication required to implement complex processes across companies. In the early days of eBusiness, it was not uncommon for large companies to have one group piloting the "new" eBiz transactions based on web/XML, and another "old" legacy EDI group doing that "low techie stuff" that management thought would be "dead" in a year or two. Only after years did some of the management begin to understand that the two groups were facing the identical business issues; XML did not prove to be faster, more accurate and less costly to implementation; AND EDI was not dead. There was no magical silver bullet out on the internet that solved their business issues or created standardized business processes. Many senior managers still do not understand this.

Normally, I like to reference my sources, but the person who wrote this in 2002 is respected in the B2B industry; and (I presume) would now be embarrassed by his comments. His former company (which sells an XML solution) still has his article on their web site:

"The cost of installing a basic XML application can be as much as 50% less than an EDI link. Any browser that is capable of presenting the transmitted data is an adequate client, and the costs per transmitted message are significantly lower when compared to EDI. Additionally, with EDI, data must often be re-entered before it can be processed further with a company's other applications, such as its internal accounting software, or its merchandise information system. XML, on the other hand, enables data to be easily exchanged between different applications and then processed directly."

Misinformed (to me) as the above quote seems, it was the basis used by a Harvard B-school publication written by one of their professors to recommend XML standards over the use of EDI. Quoting from a promotional piece from the VP of Sales of a very small company is not the usual rigorous Harvard B-school quantitative methodology one would expect. Stanford University gets in the act, too. In their paper, "Measuring Benefits of RosettaNet Standards -- Final Report", in their ROI analysis they include instructions for their worksheet.

{This worksheet includes the detailed calculations of the expected reduction to be realized in [...EDI-related...] manpower costs [...] -- due to the move to non-EDI type(s) of transactions}. In another part of the paper they say: "Lower costs and increased efficiency are expected even if previous processes were not manual, but were rather based on EDI transactions. In addition, the accuracy of the data is increased."

I believe the movement to outsource EDI/B2B is also contributing to the lack of understanding of the business issues, and the frustration of implementing EDI or any XML B2B-based process. It is unclear if it is the chicken or the egg. It appears to me that many of the outsourcing companies oversell their B2B capabilities, then get caught up with the techie stuff -- which often appears to be the only thing they know. But, big business should understand when they are getting a slick sales pitch on outsourcing -- create a rigorous evaluation process, and be ready to exit if the provider can't deliver.

I recently was involved with implementing EDI with a customer that had outsourced EDI. Their implementors had no clue about guidelines, X12, nor how to map, how to make changes to their maps, and basic ebiz concepts. Example (one of a laundry list), they had never heard of SCAC codes (although we were doing a world-wide ASN implementation & they were representing very large Fortune 100 company). Pre-outsourcing days, this company's implementors were some of the finest, their people were trained, and certainly had known what SCAC codes were & supported them. Finally, we said, "Send us your proprietary carrier codes you want us to use on the ASN's". 6 weeks later, they couldn't figure this one out either. Then they said, "OK -- just hard-code this ONE carrier code in your map. We know it will work." Yipes!!! Thank gawd they were cheap! But you know this one will require corrective action later on..... Betcha that won't be cheap.
MP< Here was the train of emails that I responded to:

Re: [EDI-L] Job Description | EDI Gentran/Mercator | Atlanta, GA

We have the following urgent requirement.

Experience with Gentran Integration Suite Business Process Development and mapping as well as administrative setup, code Lists, Partner Configuration. Familiarity with EDI X12 standards. Familiarity with Unix environment.

Preferred Skills: Unix AIX platform familiarity as well as shell scripting. Knowledge and experience with Mercator/Ascential Data Stage TX and Commerce Manager.

Says Michael Mattias of Tal Systems Inc.:

"I continue to be amazed that a post this long and so detailed about operating system and application software experience required says precisely ZERO about the industry, documents or type of trading partners to be handled. I would think "banking" or "retail" or "manufacturing" or something like that would appear somewhere."

"And we wonder why we get software which does not meet Real World Requirements?"

Michael C. Mattias
Tal Systems Inc.