With EDI heavily embedded in supply chain transactions for a wide variety of commerce in the US it seems unlikely that anything could cause significant enough dissatisfaction to cause entire segments like the auto industry, retail, transportation, and medical to shift from their established and stable processes to something entirely different. In fact, the issues we've identified with regard to increased transaction costs possibly generated by GSX and increased licensing fees from X12 only affect segments that don't have the power and authority to force changes.
Transaction costs are likely to be passed along from the EDI service providers to their customers - the suppliers who have little choice but to follow the dictates of their retailer customers if they want to conduct trade with them. And the licensing of the X12 updates is an expense that only directly affects large companies that create their own applications and the EDI service providers that also create software and updates. But the coalessing of multiple factors like these when combined with other issues could bring about the 'perfect storm'.
It would seem that there are no viable alternatives to EDI that would justify the enormous amount of effort and expense required to make a change. But the world of corporate software, viable forms of data communication, and international connectivity have changed tremendously since EDI was first envisioned.
One obvious difference is the availability of cheap connections via high speed internet services. The need for VANs as the arbiter of connections evaporated long ago. New age companies that were built from the ground up to take advantage of centralized software (SaaS/Cloud) and internet connections have spread their gospel by offering more affordable services than the old VANs could provide. But they still need to connect to the trading partners that use the old VANs. As GXS (one of the legacy VANs) looks to find viable revenue sources, it sees how its competitors are taking advantage of a technical loophole that allows them to access their own customers at low costs. If its statements hold true and the company acts to require individual licenses for each trading partner accessing its service (read more here) this represents one step toward the tipping point.
Unrealistic Licensing Charges
Other alternatives are raising their heads and companies are being given some impetus to consider changing. X12's new licensing plan adds significant costs to the mix, but some may say there is little reason for any users of the X12 standard to go through the extensive efforts to change; and to change to what? While XML has been bandied about for years as the replacement for EDI, the more likely candidate, at least for some companies, may be the European EDIFACT standard. Though this may seem unlikely for companies like WalMart that control their supply chain, consider Chrysler Motor Company - an early adopter of X12.
Chrysler is owned by Italian FIat, and Fiat is heavily committed to EDIFACT. As tighter integration between the two companies progresses, it's conceivable that Chrysler's long time commitment to X12 may be overtaken by its loyalty to its corporate entity that may decide to concentrate on one more global standard.
And possibly the most progressive of the changes is the increasing direct integration of supply chain activities with enterprise ERP systems. I'm not talking about simple data transfer and conversion of purchase order documents to EDI, then translated to the receiving trading partner's EDI version, then converted once again to that trading partner's ERP. The iterations and translations add to the complexity of the entire process and result in millions of changes and updates spread across the supply chain.
Most EDI service providers already have some kind of API available to link their services to ERP systems. But the translations still involve multiple changes and updates. And some of these transitions are managed as XML files. It would be an unusual and bold challenge to simply use the XML files spawned directly from ERP systems as the transport system between trading partners. Of course, if successful this could eliminate the entire need for the X12 spec, as purchase orders generated by ERP systems move to a central repository and are then moved to the receiving company's ERP system without multiple translations.
I believe the international marketplace is at the point where some kind of global integration is possible. The spectre of having a single repository managed by one company or one entity is likely to simply replace an old regulatory body (X12) with a newer but hopefully 'We Won't Get Fooled Again'. Last modified on Thursday, 11 July 2013