Two stages of destandardisation must take place before automated interoperation can take place between any two business systems:
If transaction files were not translated to a specialised EDI language, most of the complexity, cost and inefficiencies of the old EDI approach would be eliminated:
Often custom-written programs are required to transform the "untranslated" result into a form that can be processed by the receiving application program. It would appear that this custom-written program could be used just as easily to convert the raw transaction file directly into the form required for processing. This would eliminate everything to do with EDI committees, "standards" and languages, at the same time eliminating all the training and familiarisation problems and costs associated with them.
This is, in fact, the basis of an alternative technology based on "adaptors", which is now more widely used than EDI.
However, the business processes of different sizes of organisation even in the same industry have differing functionalities resulting in differences in the transaction attributes they use. Across industry borders, the situation is even worse.
The conceptual problems outlined above are the root cause the many implementation problems which inhibit the widespread adoption of EDI.
In practice, the larger organisation or the organisation with the most economic clout (often the customer) will dictate to the other party all these factors. This means the larger organisation implements once and all the smaller organisations have to face the heavy cost and disruption penalties they can least afford.
The cost of meeting with each trading partner to decide the detail of the transaction attributes to be used between them prior to implementation can make widespread implementation impractical. E.g An organisation with 1,000 trading partners would have to hold at least 1,000 meetings before being able to switch to automated interoperation. Further contact will be required between the parties if either want to change an earlier decision.
As the implementation of each new trading partner is contemplated, different transaction attributes can be demanded and another round of redesign and reprogramming can be required. With continual redesign and reprogramming (process re-engineering) always a consideration, adoption of EDI is restricted virtually to those organisations with in-house IT capability - particularly system design and programming. This could be one reason it is mailnly the larger organisations that have adopted EDI.
When this task is completed, the interoperation is tested between the parties and then real transactions can be processed.
It is interesting to contemplate the dilema when different trading partners demand different and incompatible business process re-engineering be carried out in order to implement "their" customised EDI transactions. Perhaps this explains the many cases where a business system used to work effectively before introducing EDI, but thereafter never seemed to do the job as well. Of course, the EDI "experts" a very quick to blame the IT people or unsuitable application programs......
As a result, an industry of "EDI specialists" has evolved to support those organisations. To avoid having to hire additional staff to do these tasks, organisations often contract out the pre-planning and preparation work to these EDI specialists. Every time a new trading partner is to be implemented, or any of the trading partners want changes made, the consultants are called in again.
Organisations not large enough to absorb these overheads by developing this experise in-house are involved in continuing reliance on consultants and contractors to maintain their EDI implementations.
If the organisation elects to train its own people, the training is expernsive and the disruption to the orgnanisation's business while the newly trained people gain some experinece can be quite considerable.