What to look for in an edi service
What is an electronic data interchange service? 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 analogue 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.
TECHNICAL FLEXIBILITY
15 years ago if an EDI service were able to support only one or two documents 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 the technical flexibility in terms of integration technologies and messaging standards. Such flexibility allows the provider to adapt to a company’s technical interfaces and prevent 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.
LOGICAL FLEXIBILITY
Traditionally, EDI services have been 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 are lacking 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, insif weiftead 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 modelled and carried out end-to-end. To make things even more complicated, companies’ processes are typically customized. Therefor in order to serve each company’s business requirement, the service must support 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 their business requirements. Each deployed service means another solution for your company to learn and manage, which in turn means increased costs.
BUSINESS PROCESS VISIBILITY
Once the EDI provider is capable of automating EDI-processes end-to-end, it has also 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.
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.
