EDI for ROI

Underestimate the impact of EDI and you will have problems

Last month I was involved in two very different conference calls with clients and their trading partners that highlights a successful and unsuccessful approach to implementing truly integrated EDI.

It struck me that one of the major issues the unsuccessful approach had was that they had totally underestimated the impact integrated EDI would have on their trading partners business processes and systems. Remember, EDI involves at least two parties, if both parties cannot process the data automatically then what you have is a fax.

In this case the party sending the purchase order had not realised how much manual effort the recipient put in to processing their orders because the data was inconsistent. For example, the delivery point required was never codified and so the same delivery address could appear on an order (Paper based) in several different formats, sometime complete, sometimes not. In the end a human being can "infer" the meaning and in this case 95% of the time they got it right. However, the sender of the data had decided to use an XML format for the message which did not impose any data requirements upon the sender. Needless to say they did not see need to change the data from that being sent on the Paper PO. The result was that as soon as the PO hit the recipients system it failed to process because the computer system did not know where to deliver the goods. The orders could still be processed but all would require manual intervention. We then had to have a one hour conference call to explain to the technical people at the senders software house why this data was essential.

The second conference call was totally different. The two parties exchanging information discussed minimum requirements for their individual systems, these were specified, added to business rules at the hub, just to be on the safe side, and test data exchanged. Some further rounds of testing took place in the week that followed, testing various scenarios, but all passed because of the upfront cooperation.

The result is that, despite the second instance above starting one week after the first, the second instance have now moved to LIVE message exchange. The first instance are still ironing out the wrinkles, but may go live next week.

I am not saying that every implementation of EDI needs the upfront level of detail shown in the second example but it must be worth your time to do this with your biggest trading partners. You will get a bigger and faster ROI if you do.

Getting two systems to talk is easy isn't it?

We had a simple request from one of our clients the other week, "Please provide us with a simple document that describes the transformation of our data to the recipients data". So we did it, sent it and found out that the document was too complicated. Back to the drawing board.

Three revisions later and I think we have it. For a one line purchase order from one company to another for completely integrated EDI (XML actually in this case) it took a 25 page document. This appears ridiculous because if I send a PO by Fax or email to a human, a one line PO will only take them 5 minutes to enter on to a system so it can't be that complicated can it.

Well it can be. You see the human brain is brilliant. It can scan a document and translate it in to the correct form for entry in to a computer system very quickly, sometime there are errors as we have all seen when we have ordered items but received something else, but on the whole the human brain is superb.

But when you try to get one computer to talk to another it is a lot more difficult. Computers tend to be a bit thick. If you provide the correct data in the correct format they cope very well and can process purchase orders far more accurately and faster than any human, hence EDI. But computers have no intuition. Therefore if you send it something it is not expecting it just won't know what to do. And guess what, most suppliers computers run different systems to their customers and so they don't use the same data formats.

So for most of our customers we do some form of transformation, from simple transformations like implied decimals to explicit decimals, to splitting some vital piece of information from a larger piece of information, to complete lookup tables that translate one product code (e.g. The buyers Code for a product) in to three other codes.

The 25 page document has not been entirely wasted though. The customer concerned has at least two other suppliers that they require the same documentation for. Unfortunately they both use different data formats from each other and from the first supplier, so we will only be able to reuse 60% of the documentation. Standards are great, everyone should have one, and everyone does (their own).

The Complexities of EIPP or EDI make it prime for Outsourcing

Last week I had a review of our mapping process with our lead data mapper. Ken is a man of over 20 years experience in the EDI and data mapping world. He has contributed to international EDI standards and even written a standard for the Paper industry. He knows what he is talking about. He is also a strange being who delights in the minutiae of data mapping and he enjoys nothing better than solving the problems inherent in getting one computer system to talk to another.

We were looking, as we do on a regular basis, at how we could improve the mapping process, automate more and therefore offer a better service for our customers, which of course leads to better profit. One thing we homed in on was the number of different mappings we have created for our customers and their partners.

Having looked at that number, we then looked at the number of standards available that users either are or could use. The numbers are staggering. In EDI in the UK and Europe we mainly see Tradacoms and EDIFACT. Of course there are various versions of each and in particular with EDIFACT one persons EDIFACT D96a order is not the same as another persons.

We then looked at XML, once touted as the great hope for simplifying EDI. Over 500 standards, and a lot of the standards are varied by the end user.

We then looked at ways we send and receive messages, 10 basic methods (AS2, EDI VAN, FTP, email etc) and most FTPs have slightly different requirements (e.g. do we delete the file when download or archive it) and HTTPS is different for each user we implement for.

Now we actually enjoy all this variety but we then thought about users, not our users, but users that were trying to implement EDI themselves. Don't get me wrong, we do not do anything our users could not do for themselves BUT the question is at what cost. Given the variety of message standards and comms methods around your average customer that either buys or supplies goods to and from various parties will need at least one, more likely two specialist to handle any significant EDI initiative.

If they have an IT department the skills may be present but here's the question. If you business is buying, selling, manufacturing or distributing widgets do you want your IT team spending their time trying to integrate with one of your trading partners or do you want them to concentrate on adding value to your core business activities? Integrated EDI will add to your bottom line, but not if it is diverting you and your team from your main business.

This is where the value of outsourced EDI can be found. Firstly does EDI make sense for your business. We do a simple activity based costing exercise with some of our customers to identify when EDI will add to their bottom line. Once this is done we can then look at the costs of "Do it yourself" against outsourced EDI. For any significant EDI program, outsourcing wins easily.

A friend of mine in the pub on Friday asked me why I don't do DIY at home. My answer was simple, I know what I am good at, and DIY isn't one of those things. When I did try DIY in the past I would find I would have to buy tools and materials, most of which I would never use again and then I would have to pay someone else to correct what I have done anyway, so there is no saving. The same should apply in business, do what you are good at, and leave the nasty world of EDI to someone that enjoys it, it will save you money.