EDI stands for Electronic Data Interchange and, simply put, it is the exchange of data and documents between computers.
I have worked on around 30-odd EDI projects over the past 10 years. All of them were about “integrating” external client systems with my company’s systems. So we also tend to call them “Integration Projects”.
Note that in the remainder of this post I may use the terms Integration and EDI interchangeably.
So, I will be covering the following:
- What is EDI?
- How to establish EDI.
I will try to explain the concepts in such a way that the non-IT among us can understand what it is. I will of course be explaining it based on my specific integration experiences.
What is EDI?
I like to think of EDI as a translation layer between 2 computer systems that speak different languages.
I have given here a diagram with a particular transaction between an ERP and a WMS. The diagram helps us visualize how EDI, as a translation layer, facilitates the automated exchange of sales order related transactions.
The most important word here is Automated. There is no human intervention required. The EDI layer automatically translates the messages to what the receiving system can understand. Without this layer in between, there is no way that each system can understand the other.
Also, without the EDI, we would have had to do a lot of manual work on both systems. Not to mention the redundancy of the efforts involved. You can also imagine the amount of back and forth email messages in a sans-EDI world.
How to establish EDI.
The EDI layer mentioned above is actually broken down into two sides. One is the client-side EDI and the other is the company-side EDI.
Each side’s EDI layer is responsible for taking the data from it’s master system (EDI or WMS) and passing it onto the other side’s EDI layer.
The integration therefore boils down to how the two EDI sides talk to each other. So we need to consider 2 important points.
- How to structure the message (the common language), and
- How to exchange the message (the communication method).
When we say message structure, we mean the common language that both EDI sides can understand. There are many standards out there but most companies I have worked with prefer XML as the message structure. What I love about XML is that it is human-readable.
Once we have the EDI message in a standardized structure (such as XML), we have to figure out how to send that file to the other side. In other words, what is the communication method? Once again there are many ways to do this. But based on my experience the two most common methods are SFTP and AS2.
With either method, the EDI files are encrypted and sent across the internet to the other side.
It is becoming more common these days to use AS2 rather than SFTP. The reason being that when you use AS2 the sender will automatically know when the file has been successfully received and decrypted. SFTP does not provide this level of confirmation to the sender.
In Conclusion
With EDI, you get the speed of automation and the associated data accuracy. You can do some actual productive work rather than duplicated data entry jobs.
I have seen many articles online where companies that adopt EDI talk about the huge cost savings from implementing it.
My hope is that this article has provided you more clarity on the concept of EDI. And if you happen to be on your company’s next integration project team, I am sure you can impress them with these concepts. 😉
Credits
Featured image created by freepik – www.freepik.com