EDI or API or web services?  Yes, please.

By Bob Raida on

EDI has been around for decades, and experts have been predicting its downfall for nearly as long.

Many criticisms of traditional EDI are valid.  EDI software can be expensive and difficult to implement.  It can require specialists with a depth of experience in niche technology that is far removed from your company’s core competency.

At the heart of the matter is that it’s really hard to get transactional data from one business system to another business system and behave as the first business system anticipated.  Those two systems use different naming conventions, support different types of data, and behave differently.  Furthermore, they were both configured to suit the needs of two different companies – also with different expectations about what data is meaningful, what is required, what things are called, and what their business processes should look like.

This problem may never be truly solved.  Businesses and the software they use are too different, so there will always be the need for some service or tool to act as the mediator.  Thankfully, modern EDI services shield the end user from much of this pain.  Where it used to be necessary to purchase costly software and experts to make it work, many EDI users simply choose to outsource the whole thing to service providers like Foundational because we can manage EDI more cost effectively and smoothly than the end user.  In fact, for us, EDI is the core competency.

However, there is one popular criticism of EDI that can be solved.  Traditionally, EDI is run in batches, on timed intervals.  Data is pulled from one system, and it sits until the EDI system translates it.  Then it sits until the receiving system is ready to pick it up, and so on.  In fact, sometimes data is only picked up and processed once a day.  These delays in movement could cause operational inefficiencies.  Removal of this limitation opens up a new world of opportunities for improvements.

Real Time EDI?

Traditionally, EDI has used flat file import/export functionality, or direct read/write with business system databases to integrate with ERP systems.  These are tried and true methods that are easy for the EDI expert to implement, but are inherently limited to batch-like processing.

Modern tools such as APIs (Application Program Interfaces) and web services create new possibilities.  Think of these methods as ways for software systems to talk directly with one another.  For example, when Business System A needs to inject a sales order into Business System B it could make a “call” to the function in Business System B that facilitates order creation.  Similarly, Business System B could make a call to the function in Business System A when the invoice is ready.

Many modern business systems support APIs and web services, and some see this as the death knell for EDI itself.  Why would anyone want to keep using an old batch-based EDI system when modern software can simply share data and eliminate the middle layer of EDI?  The reason is because, as stated above, different systems and users have different expectations of what data should look like, how it is used, what is required, etc.  It would be a daunting task for anyone to set up their ERP system to talk with the ERP systems of various trading partners – the number of connections quickly gets out of hand.  This is where the EDI translation service comes in.  The service gets data from your ERP system and formats it in whatever manner the trading partner wishes, and delivers it in whatever format the partner wishes.  If the EDI service as well as the sender and receiver can take advantage of modern integration tools such as APIs and web services, then real time (and universal) collaboration is possible.  In this scenario, Business System A makes a call to the EDI service and tells it to insert a given order to Vendor B’s system.  The EDI service instantaneously calls Business System B and inserts the order.  When Business System A makes a call to the EDI service and tells it to insert an order to Vendor C’s system, the EDI service knows that Business System C is a little different and manages that transaction accordingly.  When Business System A needs real time inventory status, shipping information, etc. from anyone in the supply chain it makes similar calls to the EDI service. The EDI service knows how to communicate with each vendor’s system and makes the appropriate call, query, data extraction, etc.

What Does It All Mean?

Real time e-business is incredibly meaningful in retail.  Consumer behavior is changing the way retailers need to interact with their supply chains.  Consumers may want to purchase products online, via their mobile devices, and sometimes in person.  Regardless, they want instant access to information about pricing and availability.  The need for instant information is fairly obvious when the consumer is online, but giving the retailer this type of functionality in the store is very powerful.  Imagine a consumer goes to a store and the product he or she wants to purchase isn’t available.  With real time collaboration between business systems, the retailer can instantly access current information about the item’s availability from various suppliers, pricing, when it can be shipped, etc.  The order can be placed immediately via the retailer’s system and instantaneously update the supplier’s system with an order.  The experience is seamless, and pleasant.  The consumer is happy.

The consumer buying example can be useful to paint a general picture, but the principles involved can also be applied to other industries that rely heavily on EDI (think manufacturing, distribution and logistics).  When systems can share information and collaborate you gain insight to valuable information and streamline your processes.  For example:

  • Shipment tracking information could be accessed from your suppliers’ systems and displayed from within your ERP system
  • Real time inventory stock status could be accessed from your suppliers’ systems and displayed within your ERP system’s order entry screen, item inquiry, etc. Imagine the customer needs item X, and is on the phone.  Who has it?  How much does it cost?  When can it arrive?  Up to date information could be instantly accessible.
  • It could be as simple as real time order entry. When your customer creates a PO in their system, the transaction is automatically communicated to your ERP system.

 

What Next?

Getting various systems to talk with one another is usually not easy, and this is where the lessons learned in the world of EDI come into play.  For decades EDI translators have been gathering information from various sources, distilling the information and integrating it into ERP systems.  Now, many of those systems (and yes, you can count Foundational’s Managed EDI among them) can use flexible, real time integration options to change the e-business game.  How would this impact your business?