As my career in EDI is now reaching the decade mark, I recently began some self-reflection and surprisingly found both depth and breadth of the opportunities and experiences those three letters combined have brought my way. Daily interaction with all levels of an organization from customer service representatives to executives, across multiple industries and platforms has given me the opportunity to view business operations from a multitude of perspectives and become what I believe to be a more well rounded in the entire supply chain process.

Through those interactions and conversations I have found there is a common misconception about timing and delivery of EDI messages where it is believed that they follow the same transmission schedules of an email message.

While this could be the case as in the AS1 protocol, most times it is not that cut and dry. When an EDI and email is generated and sent, it is automatically routed through the ether to arrive at the final destination. The concepts are generally the same, but there are typically major differences in execution and delivery. Usually emails are required to be a more on-demand message, so the infrastructure that supports that protocol is configured to accommodate it as such. There are countless times when I am on a call with someone and they need me to see a specific file or dataset right then. If there are no shared network drives, how do we accomplish this? 99% of the time…e-mail.

In contrast, when a buyer cuts a purchase order to go EDI, it typically doesn’t show up in the vendor’s system within a few minutes as it’s’ cousin the email does. Since the underlying reason for this is technical in nature, it can be difficult to defend to someone in sales or customer service that has been contacted about an order that needs special attention.  It has been my experience that they aren’t as concerned about the “how” of the message getting from A to B, as the “when”.

The main issue that comes up that we likely have little to no control over is the polling schedule of the originating system. I have experienced customers that schedule their EDI batch jobs to run only certain times of the day so receipt of the message will depend on that schedule, with little the EDI team on the receiving end can do to expedite. What can be done is to configure the EDI infrastructure to be ready to receive and process the file as soon as it is received. Of course this has to be evaluated on a case by case basis, and largely is determined by message volume and computing horsepower, but a balance between the two must be reached in order to optimize the EDI process and provide best in class support to the customer’s business needs.