1. EDI isn’t going away, at least any time soon, and
2. XML is out there and is being used for a lot of different things

Now, this was a relatively small sample and there aren’t solid statistical conclusions you can draw from the results. However, there seems to be enough information there to make it appear that you’ll need the tools and the training to support both X.12 and XML formats in the future.

I’ve mentioned in the past that we dealt with virtually every format at my previous employer, mostly due to the complexity of our business model and heterogeneity of our customer base. I think many aspects of what we have discovered over time can help explain some of the variation in the responses and may help with your interpretation of the data. For example:

• Some EDI teams support both internal and external interfaces, others are only focused externally. Several comments were made about using formats other than X.12, especially XML, to support internal interfaces. Although we were focused externally and an ERP team supported most internal connections, we picked up a plethora of additional interfaces to partners we’d never dealt with in the past when the company implemented SAP, such as credit card companies, financial institutions, benefits providers, etc. Virtually every one of these had a proprietary format and process we needed to address. Based on what we experienced, I’d say that the role of the EDI team in the IT environment has a great impact on what formats it needs to support.

• Some companies are involved with EDI only because they’ve been forced into it, usually as a result of a mandate from an important customer who wants to buy direct materials. EDI is a highly entrenched process in most large companies, and many supply chains are built around it. If you receive the ‘comply or else’ letter from a retailer or a large hub, it’ll likely be an EDI mandate, not anything XML related. My previous employer’s supply chain is almost entirely electronic, and when new suppliers were added they were required to do specific EDI transactions with us via the VAN or through a 3^rd party service. Based on the number of responses from teams using only X12, I suspect the side of the business the team supports has a big impact on the diversity of the formats supported- if you only deal with inbound orders and the associated return transactions from a big retailer, you’re probably only doing ‘traditional’ EDI.

• I think the type of product your customer wants to purchase may have an indirect impact on the transactional format. I know for a fact that it had a big effect on us. Our customers bought indirect products from our company, mostly MRO (maintenance, repair, operations) related. Although some companies buy that type of ‘stuff’ using the same EDI process used to procure direct materials (note: this is not necessarily a good thing), many businesses were late in automating that part of their purchasing process. As marketplaces (ie. Ariba) and web-based purchasing systems became more prevalent, MRO purchasing became one of their ‘hottest’ targets. Since MRO was considered by many to be a ‘black hole’ process rife with inefficiencies, companies became very receptive to what the marketplaces were selling as they attempted to squeeze costs out of their operations. Since marketplaces build their platforms on an XML base, customers buying MRO products are very likely to use XML-based transactions.

• There was a question on the survey related to which direction you’d choose if starting from scratch. It’s been a long time since we started our program, but we did occasionally have the opportunity to work with new partners who asked for direction from us on the X.12 vs. XML topic. Without getting into the advantages/disadvantages of each (these are heavily documented and available via a simple Google search), we would be as neutral as possible but do our best to promote one of the ‘standard’ XML flavors (ie. cXML) or X.12.

Those are just a few things to consider as you try to interpret the data. Obviously, there are variations in how teams are set up, who they report to, what types of interfaces they support, which business transactions they automate, and even the types of materials being purchased. You would need a lot more information about these things in order to draw conclusions from the data you could actually use. For example, if you were just establishing your eCommerce/EDI team and were curious as to whether you should support X.12 or XML, you might look at the answer to the first survey question and think that you should go in the X.12 direction, since that’s what most of the group supports. However, if your role is to support marketplace connections, that would be a bad decision.

So, taking all that into account, is there some sort of overall message? Are there any useful conclusions at all that could be drawn from the survey? My take on it is that, sooner or later, you’ll be called upon to work with data other than X.12. It’s an any-to-any world out there, and just because you haven’t had to deal with XML data yet, just realize it’s not a matter of ‘if’, but of ‘when’. It’s not the XML tsunami that threatened us old-timers back in the late 90’s, but it continues to be plugged in where its advantages can be exploited and is becoming pretty commonplace. You should do what you can to prepare for it, and even look for opportunities to expand your capabilities beyond what you already support. Becoming multilingual in eCommerce is something to embrace, not to fear.

As always, please forward any personal comments or suggestions to me at This email address is being protected from spambots. You need JavaScript enabled to view it..