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.

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?".

ISO 9001 -- The route to a profitable company

We have recently been going through the process of achieving ISO 9000 accreditation for our Software as a Service EDI/EIPP offering. It has been a fascinating process. I had always believed that one of the secrets of a successful outsourcing or SaaS offering is to reduce the number of support calls to a minimum. I know this is a statement of the blindingly obvious but you would be amazed the tales we hear from customers moving to our service from other offerings.
When we started out on the route to ISO 9001 accreditation I thought it would have some benefit in terms of seeing where we were making mistakes, correcting them and of course there is the marketing benefit, but mainly in making sure that we continued to provide a quality service for our customers. I believe we are the only SaaS EDI or EIPP provider to be accredited for ISO 9001.

But the more I, with the help of our ISO 9001 consultant, got in to the depths of understanding ISO 9001 it became clear that whilst ISO 9001 does highlight the quality of whatever systems are being measured, the major benefit is the application of the continuous improvement principle.

We have been accredited for our data mapping processes and our systems and support processes for the provision of EDI data mapping, translation and transportation. In my next blog I will discuss the application of process to data mapping and translation, but today I want to concentrate on support.

When I look at a lot of our competitors, especially in the SaaS EDI or EIPP space, I notice that whilst the are bigger than us in terms of turnover, they are typically making huge losses. Some have accumulated losses of over 26 million and yet they still have turnover that is substantially less than their costs.

Looking at it even closer you can see that whilst they increase turnover they are increasing staff, and staff costs, much faster. To me this leads to the conclusion that whatever systems and support they have are not efficient enough. And that is one of the major benefits of the ISO9001 process.

What we have found is that every time we have have a support call/system issue the ISO process of continuous improvement has helped us to eradicate that error/issue for the future. It does not mean that we never get errors but analysis shows use that over 85% of all support calls/issue we received are outside of our service. They are either errors with the data sent to us or the comms of the sender or the recipient.

By concentrating on the ISO 9001 continuous improvement process we are able to keep our support costs to a minimum, we are able to handle millions of transactions per annum with a much smaller team than any of our competitors and we are able to keep improving the experience for our customers and their trading partners.

ISO 9001 does not make you infallible, but it helps you to learn from each mistake and improve your business and profitability.

I did have a cheeky thought though, should I go to the bigger players making all the losses and offer that we do the product, service and support for them, there will of course be an element of cost for them ;-). We could then show them how to make money instead of burning it. Just a thought....

Is worrying about customer service wrong??

I have a friend and occasional wise sage of business who says we provide Customer Service that is too good. This got me to thinking, is it possible to provide customer service that is too good?? Can it be that by constantly trying to go "above and beyond" for our customers we are not helping them to help themselves?? My friend has built up and sold three successful software businesses so his thoughts need consideration.

I know that for me personally I value customer service very highly. I am one of those people that will not tip if the service in a restaurant has not been as I believe it should be. I get infuriated when left hanging by some outsourced call centre, whatever the location, or I get to talk to some disembodied voice that I can tell does not give a damn about my account. And I get even more annoyed if I think we have let a customer down. But is this going too far?

In our job we get the "privilege" of working with some of the largest names in IT and IT consultancy and it always astounds us that the level of service they provide to their customers is sometimes shockingly bad. But by dint of the fact that they are a "Big Name" they get away with it. Don't get me wrong, we make mistakes occasionally as we are human, but we always have an in depth enquiry afterwards to try to ensure it does not happen again. But these larger organisations don't seem to have the same fear of poor customer service that we do. I can tell you absolute horror stories of call centres and voice-mail systems.

If their server goes down they get round to fixing it, in time. They then tell everybody else to rush to resend the messages they didn't receive or lost. The other day I was called to a meeting by a customer. The meeting was to explain what we were doing about all the server outages that we have experienced in the last two weeks, not our outages but the big expensive consultancy firms outages. This big consultancy firm was offering no explanation or apology, just a warning that our customers messages were delayed and they should stop this happening. But it was the big consultancy firms servers that were the problem!!! They should know how to stop the problem, fix your damn servers. But we are the ones being asked what we are doing to stop the outages. Go figure.

But I still think that you cannot provide customer service that is too good. Yes I try to ensure we over specify servers and back-ups and comms. But I still fret that we have not got enough, that we might let a customer down. We try to ensure we won't, put systems in to try to prevent it, but I still worry.

And I am glad I do, and we do as a company, because I would like to think that if I was a customer I would be happy to, metaphorically, pay that 20% gratuity for good service. Because I would like to think that our customers are treated as I would like to be treated. It cannot be wrong to strive to be the best, to try to do the best for someone paying you to do a job.

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).

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.