Emphasize Business Knowledge in EDI/B2B Implementations

This was originally posted on a former blog
Friday, April 13, 2007


Recently, someone observed that recruiters frequently list in great detail a number of technical requirements about an EDI/B2B position -- but mention absolutely nothing about the business processes or vertical of the hiring business. The "soft" knowledge of business and people skills are totally overlooked.

Why often the emphasis is on the technical aspect is no mystery to me. One reason is in the early days of ebXML, RosettaNet, and other XML "standards" bodies, the early XML advocates 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 resources." In fact, many EDI/B2B managers or analysts have a wealth of information on the business and technical requirements of their customers; and the internal workings of their ERP systems.

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 did not realize that EDI since the early 1990’s could also be transmitted over the internet. In addition, EDI syntax and content was also based upon a number of committee meetings. I remember participating on the early EIDX committees for Distributor specific ship & debit transactions and invoicing. They were shown "easy-to-read" XML comparisons to "hard-to-read" EDI, not understanding these were not "standards-based" XML examples.

Several years ago, a director of IT said to me. "Why do we have to meet (with our customer) and test these EDI transactions? Haven't these standards existed for years?" Many managers do 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 were implementing and maintaining processes that management presumed would be "dead" in a year or two. Then 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.

Normally, I like to reference my sources, but the person who wrote this in 2002 is respected in the B2B industry; and (I hope) would now be embarrassed by his comments.

"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. EDI was not considered to be a viable option. 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 say put the Business back into B2B. Understanding business processes is just as import as understanding the B2B syntax.

Susan http://www.linkedin.com/in/susanstecklair