EDI for ROI

The True Value of Electronic Document Exchange

This week I have been fortunate to begin working on a project with a very large FMCG supplier. The project is to integrate supply chain messages with their logistics suppliers. This project involves their SAP system, a number of haulier back office systems plus warehouse management systems. 

This project shows the true value of complete supply chain integration. Why? Because not only does this project revolve around business process improvement but it also shows a direct link between the supply chain and the turnover/profit of the FMCG company and its supply chain partners, the hauliers. The improvements being built in the integrations with the hauliers will reduce costs for the hauliers, for the FMCG company and the final document in the chain, the Proof of Delivery (POD), leads directly to the invoicing of the client. By having this document integrated rather than retyped the reduction in errors will reduce the need for crediting notes and queries. The improvement in the speed of receiving the POD in to the SAP system will mean the FMCG company can invoice earlier and in this size of organistion that one or two days improvement can mean a significant cash and bank interest benefit. 

The project will involve a variety of file formats, some Electronic Data Interchange (EDI) formats, some flat files and some XML. The various formats will be to suit whatever each individual supply chain partner requires. The FMCG company using SAP will have one format to suit them, each haulier will have a format to suit their system therefore minimising the amount of extra effort required by both sides of the supply chain equation. The communication protocol will also be flexible, but AS2 will be the preferred method due to security, non-repudiation and reliability. 

Because of the benefits the FMCG company has identified in the project they are implementing this project in the most professional way I have seen over the past eight years. With input from SAP users, technicians and the haulier companies to ensure the success of the project. being involved in the project will be one of the highlights of 2010 for me. 

GXS and Inovis to merge...

Hot of the press an announcement that GXS and Inovis are to merge. Following hot on the tail of the BT EDI*NET closure announcement it may be big news in the Electronic Data Interchange (EDI) world but not that surprising. 

The traditional EDI market is dying, replaced by internet based transactions using non EDI Value Added Network (VAN) communications methods such as AS2, FTP(S) or even HTTP(S). These communications methods SHOULD be cheaper (Not always the case unfortunately), faster and more reliable. Indeed we have been involved with a household brand replacing the GXS EDI VAN with a secure FTP comms process. The results of a one month, 4500 document trial was that the Internet based FTP service was more reliable than the VAN and the time the files arrived at the trading partners showed that the configuration improved the speed the documents were delivered by approximately 10 minutes. 10 minutes may not appear to be much but in this case for a given document type (Delivery Notes) that is the difference between the document being present in the system when the goods arrive and not being present, which saves both the recipient and the sender of the data a lot of manual effort. We have now moved to all documents being exchanged via the Internet based process, saving time, money and frustrations from VAN failures.

Further issues arise for traditional EDI suppliers from new kids on the block such a Electronic Invoice Presentment and Payment (EIPP). A number of vendors claim this capability and it may be that for the most part this is a case of "The Emperor has No Clothes" but the marketing is good. These vendors claim that EIPP is "better" than EIPP, easier and more cost effective. However suppliers still need to produce the invoice in some data format, send it (often in a  different way to other EIPP vendors) and the costs are often more per document than for traditional EDI.  And to add to the issues each EIPP vendor uses a different pricing structure and the actually act as gate keepers to the customer rather than facilitators (If you want to send this customer invoices then you must do so through us and pay us is a typical refrain). 

If you think about EIPP it is less than 50% of a full procurement and the benefits to the recipient, and certainly to the sender, are therefore greatly reduced. If you want to gain the full benefits of an integrated supply chain then EIPP just does not cut it. Look at the business model, the customers pays and the supplier pays. The supplier does not have a choice but to pay. Why? is it because the customer cannot be charged the full price because the ROI would not stack up?

Finally there is the question of what is the value added proposition for an EDI VAN. It used to be security but you can now get the same levels of security from internet based technologies as outlined above. A few decades ago customers did not mind having to invest in IT resource to create a funny format document and send it by an unusual comms method, but now they want to have a provider that delivers a true value added service, where their IT department can do the minimum required but they can communicate with all their customers and suppliers. For a proposition that provides a real ROI, which customers need in this day and age, the Supply Chain Integrator has to provide open communications methods, value added services such as receipting, master data maintenance, on-line matching and other services.  Services that should mean for the customer (recipient) they receive nothing but valid documents for their system, and for the supplier (sender) any documents that fail are reported instantly, so allowing them to respond today, not in several days when/if the recipient reports it to them. So providing an all round improvement in the Supply Chain.  

Sometimes I just love what we do

Sometimes you just love your job and in my case it is when a customer says we have helped them gain more benefit for their business.

Last week a customer called. EDI is essential to their business and to be without it these days would be impossible without increasing staffing levels. The customer was implementing a new ERP system and had been unable to test properly the EDI functionality that is essential to their business for order processing and cash-flow. We had understood, and done everything in our power to ensure that customers orders were received efficiently and that the invoicing of customers was not overly impacted by the change in ERP.

Was the process smooth. No, but I guess very few ERP implementation are, especially one of this size.

Was it uncomfortable for us, yes. Late nights, implementations and retests with no notice, message changes to be made in a hurry. Rush testing and retesting. Changing goalposts.

But what was great was that our people really did put in a big effort as a team to get the customer though it. And what made it really worth while was the customer ringing up "just to say thanks, your team did a great job and helped us with when we didn't help you."

We are not in a business, like restaurants, where good service is rewarded with a gratuity, but that one sentence is better than any tip. 

Now is the time to invest in EDI.

Credit Crunch, layoffs, financial doom and gloom. Personally I try to avoid the 24 hour news feeds. Problem is they have to have something to say and good news rarely sells new papers or draws people to web sites.

I am not saying that a downturn hasn't arrived in the western economies, it obviously has, but I like to look to solutions rather than just accepting the end is neigh. Any economic downturn is an opportunity to look at existing business processes and just ask the question "Why do we do it like that?". It is amazing how often the answer is "Because we have always done it that way".

One place to look is at the exchange of business documents with your trading partners and can it be done electronically. EDI has been around for decades, yet still a lot of companies have not invested in fully integrated EDI, it is astonishing. Investing in EDI will not add millions of GBP, Euro or USD to you bottom line, but some of the savings can be eye opening.

A small example is one of our customers. We performed a simple activity based costing exercise with them. Based upon a single trading relationship with one of their major suppliers, their own estimate given the time taken to enter a single line invoice in to their system, the volume of invoices received and the cost of the people to enter the invoices was that they had saved over £30,000.00 per annum. Now this excluded any more difficult to quantify savings such as improved accuracy, reduced invoice queries etc. They also send the supplier a purchase order and given that the supplier fully integrates the purchase orders then they can expect similar savings, so everyone wins. Integrated EDI makes sense.

What was even better for the customer though, was that they do not require EDI specialists in house, so they savings are real savings, no hidden costs. The customer pays for a service which First B2B provide for a price. After paying First B2B, they make the savings outlined above. Further, because of the use of AS2 and no EDI Vans, there are no transaction costs.

Other customers have similar experiences and even though some of them may be seeing reduced volume because of the downturn they know that EDI gives them a further advantage. That is when the downturn is over they will not have to ramp up staffing to cope with increased activity, the system takes care of it.

Not only does integrated EDI reduce costs now, but it puts you in a better position for when the recovery starts.  But the start has to be "Why do we do it like that?".

Slow Down, your processing our data too fast!!

A client rang me this week with what I believe to be a first in terms of customer requests for us. His problem was that we were processing the EDI invoices TOO FAST. I guess sometimes speed isn't everything.

This was however a genuine business problem as follows. The sender of the invoice issues the invoice upon dispatch of the goods, not an uncommon practice. Both parties are linked via our FREE AS2 service. When the invoice is issued it is placed in the AS2 outbox, received by our service, translated and sent via AS2 to the recipient. The whole process takes less than 1 minute from the time the invoice is issued, to the time it is received by the recipient. The recipient then loads the invoice in to their system (all automated) and it is immediately rejected because the goods have not been received by the warehouse. Hardly surprising because the goods have just left the loading bay at the supplier and still have hours of road time before they will arrive.

It's good to be able to have a laugh at work and the client and I found this quite amusing (maybe we're just a bit sad), but it is worth noting that no matter how efficient and fast we make the technology it still has to take the actual business practice in to account.

There are many resolutions to the problem. The first would be for the invoice issuer to delay sending the invoice until the following day. The second would be for us, as the central hub service, to stall the invoices until the following day. This was the option that was taken as our systems were easier to configure than any one Else's. The recipient could delay processing invoices until the following day as another option.

However the best solution would be for the invoice to be raised not upon dispatch, but upon receipt of an electronic Goods receipt Note (GRN), sent by the recipient of the goods when they are received in to the warehouse. This would be electronic trading haven, you could even make the invoice match the GRN, so that there would be no chance of the invoice being refused by the recipient. There is a flaw in this process though. If the recipients systems and/or the senders systems cannot process a GRN they will have to alter their ERP systems, which has a cost. It might be possible to cost justify but it is a major change of business process and proper thought must be put to the business/profit advantage to be gained. Too many times we see technologists come up with a great technology solution to a problem without thought to the true business benefit.

For these customers the simple solution worked best. We have other customers using the GRN process and they have established a huge cost reduction by doing this. Luckily with SaaS it is easy for one system to accommodate both customers, so both customers get the electronic trading that their business justifies.

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.