Do you wonder what an electronic data interchange service is? What does EDI even mean? I’ve been forced to think about such questions quite often lately. It seems as though there is a lot of talk about EDI and EDI services, and from what I can tell, everybody understands EDI a bit differently.
For some, EDI (Electronic Data Interchange) means good old (or clumsy) EDIFACT and ASC X.12. EDIFACT is widely used across Europe and APAC, whereas X.12 is used mainly in the US and Canada. Old legacy systems use such standards to change different business documents, such as invoices and orders.
Somebody may actually open the acronym and understand EDI as the name implies: electronic data which is interchanged between different applications, systems and people – that is, pretty much all the Internet traffic but also the traffic that flows outside the Internet, like mobile calls and analog TV signal. Doesn’t sound very good either.
If we find the middle ground, we will see EDI as an exchange of business documents executed between two or more business partners on the Internet that aims to automate a business process (EDI process), like Order fulfillment, between the partners.
Business documents exchanged as a part of the EDI process do not necessarily need to be EDIFACT or X.12, rather they can be anything, like XML, JSON, text, or why not even binary data, like scanned PDFs. The content of these documents can be anything (kind of), such as invoices, orders, incidents, contact information, or whatever is required by the aligned business process. In addition, in order to complete the EDI process, it is possible there may be a need to exchange several documents between the partners.
Since companies are focusing more and more on their core business, building this kind of messaging service, which is capable of engaging in an electronic dialogue amongst all involved parties using a variety of, somewhat cumbersome technologies and document formats, is not often a desirable way to go. This has led to a situation where, as with other functions that they do not see as part of their core business, companies are looking to outsource their EDI processes to an external service. A so-called EDI service provider.
There are several factors that make up a good EDI service and EDI service provider. I have detailed some technical success factors that companies looking to outsource their EDI functions or even looking to replace existing ones should look out for.
15 years ago, if an EDI service were able to support only one or two document standards, for example, EDIFACT and X.12, it may have been enough. However, that is no longer the case. Nowadays, they must support various communication methods, from legacy and batch-based communication to real-time and online messaging. This means that it must have technical flexibility in terms of integration technologies and messaging standards. Such flexibility allows the provider to adapt to a company’s technical interfaces and prevents the need for those companies to integrate with the provider’s interfaces. If this kind of technical flexibility is not achieved, it creates a technical challenge for the companies using the service when they need to adapt to the technologies and interfaces provided by the service and not vice-versa.
Failing to reach the logical flexibility may also lead to a situation where a company needs to deploy a number of different providers in order to meet all its business requirements. Each deployed service means another solution for your company to learn and manage, which in turn means increased costs.
In addition to a real-time tactical view provided by the service, companies may need to utilize tracked data as a part of their in-house Business Intelligence (BI). For this, the service provider may enable customer BI to pull the desired tracking data from the service directly.