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.
1. Technical flexibility
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.
2. Logical flexibility
Traditionally, EDI services have been seen as document exchange platforms that are primarily used for data integration. They are designed to solve the data mapping challenge between the partner application systems but lack automated end-to-end EDI processes. When a company engages in e-business, it actually outsources its EDI processes to the provider. These EDI processes are seldom simple, inside weighted the logic often spans multiple companies, systems, and countries. In order to meet these requirements, EDI services must deploy functions that allow customers’ EDI processes to be modeled and carried out end-to-end. To make things even more complicated, companies’ processes are typically customized. Therefore in order to serve each company’s business requirement, the service must support the customization of EDI processes as well.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.
3. Business process visibility
Once the EDI provider is capable of automating EDI processes end-to-end, it also has the foundation on which you can start building visibility into the EDI processes and transactions that occur within. Visibility can be achieved, for example, through automatic business process discovery (ABPD) that is based on the transition events taking place within the process. Equipped with ABPD and the content of transaction data collected from the EDI process, companies can efficiently identify and manage process bottlenecks, optimize resources, and proactively manage technical and business relates issues.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.
4. Capability to evolve
Equal to ICT ecosystems everywhere, e-business and its standards are constantly evolving. Existing technical standards die or change. New standards are introduced along with new and better technologies. And regulatory requirements drive the need for change. In this constantly changing environment, EDI services must be ready to evolve as well. They must allow changes to be deployed quickly and in a backward-compatible manner from a customer’s perspective. In many cases, there is not even a business need to expose all technical and regulatory changes to the customers, but instead, hide them and prevent the need for a customer to launch yet a new development project that ultimately doesn’t provide value. However, when the change actually introduces real business or technical benefits to the customer, any good EDI service provider must be willing to share those with the customers - either through decreased service costs or better performance.
