Overview Part III - Why EDI? (or, What to do with EDI Messages)

How is all this beneficial? How is it better than faxing or emailing a word attachment? In a human sense it isn't. The EDI (Electronic Data Interchange) formats are often not human readable (e.g. Edifact, Tradacom). The point is, it is meant to be machine readable.

Eh? So what? These days we have grown used to unstructured information but it wasn't always the way. The triumph of HTML (and the Internet) is the organising of unstructured information. This brings us on the often over-looked EDI 5th element. The elephant in the room no-one talks about. I left it off the list in Part I because I didn't want to scare you.

So what most people were, and are, doing was putting these messages into an database. For most people this means an RDBMS. For most this means SQL. It is a relatively easy task to design a database schema for a particular type of message (e.g. stock balance, planned delivery etc.) in a particular format (e.g. Edifact, Tradacom). But remember you will have many customers using their own choice of format and their own interpretation of the standard. They all need to go into the same schema.

Other EDI guides will tell you EDI is all about accuracy. Reducing typing errors. This is true. You will now have in your RDBMS an accurate representation of the message. So what are you going to do with it? Report it? Print it out? Change it from electronic data to hard copy? You will be surprised how common this is because if you do, as far as your customer (eh... I mean trading partner) is concerned, you will appear to be "EDI Enabled". You will have ticked the boxes.

EDI becomes really useful when the message is a transaction. If your customer sends you a purchase order and you can create a sales order on your business computer system (sales order / ERP system), without any typing, then there are opportunities for labour cost reduction. So EDI is very popular in high volume situations, like supermarket supply chain.

Unfortunately a transaction is more than just a message or a schema. What if the customer orders a product you don't recognise? Requests a delivery date that doesn't respect your quoted lead time? Asks for a ridiculous price? Each and every field has to be rigorously validated and you have to have a plan to cope when it doesn't validate. After all, who turns down a customer order? Equally you don't want to all that Call Centre labour saving to be swallowed up in increased IT admin costs.

So if you are a small fish supplying a big shark, it is possible you decide to find the 80/20 split by turning all this complicated EDI into a glorified fax machine. It happens.

Part I, Part II