I agree, but I do feel like I need to stick up for XML a bit.
--I mean XML over HTTP is pretty cool and cheap compared to some other alternatives. --XSLT isnt half bad either. Having a high-powered transformation language that is an industry standard and simply beats up any mapping tool on the market. Now that is cool. --I can get an XML parser with IE Explorer or Firefox for free. The last time I needed an EDI Parser, I found it easiest just to write my own. --Now with EDI, it took me a bit to realize that *3589*Lakewind***GA**30066** spread over a few lines was actually an address vs. a <MailingAddress> tag. All in all, I like EDI & XML. From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Stecklair Sent: Wednesday, April 11, 2007 10:44 PM To: [email protected] Subject: [EDI-L] Real World Requirements 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 magic 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: Quote: "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." End quote. 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 -- but they do not have necessarily a methodology to do so. 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 very large Fortune 100 company). Pre-outsourcing days, this company's implementors 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. P.S. For my research, I've been looking for any early presentation from Fadi Chehadi, formerly the president of RosettaNet. If you know how/where I can receive a copy or ask him directly, I would appreciate it. Regards, Susan (see contact info below) 4a. Re: [EDI-L] Job Description | EDI âEUR" Gentran/Mercator | Atlanta, GA Posted by: "Michael Mattias/LS" [EMAIL PROTECTED] <mailto:mcmlserve%40talsystems.com> mcm_talsystems Date: Tue Apr 10, 2007 9:54 am ((PDT)) 4/10/07 >>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. 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. Racine WI [EMAIL PROTECTED] <mailto:mmattias%40talsystems.com> Susan Stecklair, President Electronic Commerce, Inc. <http://www.ecommerce-inc.com> ( 408.996.7492 Business Office [Non-text portions of this message have been removed] [Non-text portions of this message have been removed] ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/EDI-L/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
