iTech uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognizing you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Using electronic data interchange (EDI) in supply chain in these times, is like a stock broker trading using yesterday’s data – an anachronism. Yet, 85% of the freight industry is still using it today. Picture this, if Uber’s on-demand pricing did not have access to real time data? It certainly would not have the global footprint it enjoys now.
Freight and transportation systems are now awakening to the industry-wide application of nanosecond information transfer. If EDI is being left behind, it is because better technology is here to stay. In 10 years, the industry is expected to transition completely to application programming interface (API) technology. The API vs EDI debate while ongoing, is heavily loaded in favor of the former.
Challenges legacy systems face in current supply chain demands
EDI might be the industry default and moving out of this comfort zone might be a difficult transition to make. The technology that became popular in the 1980s has not been able to modernize itself with changing needs. When milliseconds count, a system that runs data on timers, leads to increased inefficiencies and the ripple effect can be felt right down the supply chain. Rather than automating processes, there is a higher dependence on emails and phone calls to dispatch freights, track freight, get rate quotes and for faster documentation. Airline systems are powered by API-web systems so that they can fill their flights on a variable pricing model based on supply and demand. Unless carriers integrate a pricing engine API they could find themselves under-selling or over pricing.
Many 3PLs are influenced to implement EDI since their business partners are using it but when there is no one standard, it does not make communication easier. This is because each EDI uses its own “dialect” to communicate. Businesses might follow different EDI standard protocol formats for exchanging documents. X12, EDIFACT and TRADACOMS are just a few of the commonly used formats and each has different variations. Typically there is a translation to be done when sending documents as well at the receiving end. Different formats used by each partner will need shippers to have a large IT team to set up partner protocols to transform the data to suit each others business systems.
Advantages of API led connectivity
One of the greatest benefits of web-based APIs for carriers and 3PLs is that it makes real-time supply chain management a reality. Unlike in EDI where there is a time lapse in information transfer, millisecond transfer of data through APIs means many processes can be automated such as rate quoting, pick-up requests and shipment tracking. Recent development efforts in freight and shipping deals with transactional APIs for synchronous (request/response) processes with small payloads that allow for this millisecond response rate. This agility is necessary for carriers who build their success on agile pricing by allowing them to raise or lower bids on loads to fill up capacity. A greater price transparency has been enabled through APIs linking to a large number of carriers and providing customers better quotes quickly. The use cases are many but what they have in common is a quick response time. This is why APIs are cruising along in the fast lane.
A key reason for APIs to have surged forward is the emergence of many middleware providers. This translates into readymade third-party APIs that are much better than any that can be built in-house. It saves on time and resources needed to build these connections and allows for a wider adoption rate. One of the primary ways in which APIs score over EDI is speed of implementation. It can take anything up to 18 to 20 weeks to create an EDI connection and it comes at a hefty price. A third-party API on the other hand takes away the complexity of building and maintaining the functionality that has been honed through exposure to larger data sets. And since the API is built for a specific purpose the number of parameters it uses are much less than that of an EDI which is more general purpose. Another way that API scores over EDI is that it allows integration of artificial intelligence to analyze API data flows, such as ML based data capture. This can cover the entire customer and vendor relationship spectrum.
Integrating APIs with existing systems
Enterprises will not be ready to switch over from EDI to API in one fell swoop. The truth is that many have a working EDI communication in place and it is tightly integrated with many core business processes. They do not want to take the risk for an obvious long-term cost saving. And that is fine because EDI works perfectly for processes such as sending confirmation and purchase orders as well as invoices.
For real-time communication, APIs can be integrated into your existing EDI solution. This is done using a middleware application that allows processing of information from the API to the EDI and vice versa. Let’s put this into a better perspective – Company Green purchases steel from Company Blue through its EDI system that generates the invoice. Now Green needs to know where the goods exactly are while in transit. The legacy EDI system is not capable of providing this information but the API is able to pick up this query and pinpoint the location of the freight. This in simplified terms is EDI and API setting up a communication system that allows each to do what it is suited for.
Supply chain and transportation companies cannot afford to turn a blind eye to the benefits of APIs for short and long-term gains.
If you would like to know more about how to implement API or integrate it with your existing systems, reach out to me, Jason Dodge at jason@itechdata.ai