Beware the "cheap" option!

A natural tendency, when asked by a customer to trade via EDI, is to put off the dreaded day for as long as possible. It is apparent that cost is involved. Who is to say that the customer will stick with you after you have spent the money to implement EDI? No wonder folks do their best to avoid it all and no wonder customers find it takes much longer than was hoped for to persuade the suppliers to trade electronically.

About the cheapest way for a customer to get correctly formatted electronic documents into their ERP system is to only have one set of integration links out to one system. To this end, cheap and freely available web technology is used to create an application that all the suppliers not taking up EDI are forced to use. Such tools are often dressed up in trendy jargon such as, “web pickup” or “zero integration”.

If you hold back on the EDI implementation you may be told to visit this “website” to find your orders, then create order acknowledgements, then despatch advices (or Advanced Shipping Notes, ASNs), and then perhaps your invoices, unless there are no invoices allowed and you have instead to find your remittance advices as part of the customer's self billing process. It seems great for the customer as all the documents to and from the website are already mapped to suit their systems.

In fact it is not all that great for the customer and it is certainly not great for you...

Your staff are expected to type it all again into your systems or copy type it into the “website”!

• Your work is doubled.
• Your risks from human error are doubled.
• Your costs go up.
• Your profits fall.
• Your prices need to go up...
• You become less competitive!

In truth that second bullet point is as deadly to your customer as it is to you. It leads to increased costs for your customer every time they get into the paper chases and escalations that always result during any remedial activities.

What to do?

Well don’t run a mile when you get asked to trade via EDI. Get the EDI integrated with your system so it runs automatically. Use a service that shines forth with efficiency and prompt attention for your customer. Stand out from the crowd and you will have a good chance of avoiding a dictated “solution” that may save you the price of a proper EDI implementation but will cost you much more in extra work and inevitable human error.

EDI, The ultimate Software as a Service

There are now more and more applications that are available as Software as a Service (SaaS). The highest profile is Salesforce.com, which we use internally for CRM, Customer Support and Project Management. We have partnered with another SaaS offering in Netsuite, which offers a complete ERP as SaaS, and we also use Google Docs for sharing Spreadsheets and Text Documents.

However, one of the very best applications that SaaS can be used for is EDI. The way EDI is moving at present with multiple standards (EDI, XML and Flat File) and multiple communication methods such as EDI VAN and AS2, it makes sense to outsource the technical complexity to a company that specialises in it. Whilst the importance of EDI as a way in increasing both profits and cash flow for your business are undeniable, it would be rare for the technical complexity to be a core business for any organisation other than an EDI specialist.

Since we started making our software available as SaaS in 2003, all our customers have moved to this model. They all share the same benefits of a single method of communications (to suit their requirements) and a single file format (which suits their ERP). On our customers behalf we currently have in excess of 800 different message translations and 17 different communication methodologies. Whilst some IT teams in large organisations may see this as "their territory", I am sure that the directors do not see it as core competency for the business, and would rather see them developing inventive uses for IT that affect their core business, whatever it might be.

SaaS is a growing market, even Microsoft are looking at planning to enter the market, and EDI SaaS is a natural fit.

EDI as it was intended: To Make Savings!

Imagine you had just discovered EDI, or "B2B Messaging", or "XML" or "eBusiness", or whatever you want to call it and you were the first so to do!

Imagine that you were able to examine the pros and cons and decide for yourself just where in your business you wanted to make savings, without the distracting pressures of trading partners demanding you start doing EDI etc. their way, NOW!

Imagine you were going to come at EDI asking "What's in it for me?"

You might decide you would rather use this handy discovery of yours to make savings in areas that you have hitherto (in the real World) had to leave for another day...

Now you can have your EDI via Software as a Service (SaaS), where the service provider takes care of ALL the message formats needed by the recipients and ALL the transport methods they prefer, you can literally dump some of your problems for good. I'm on about such nasty jobs as making remittance advices, printing them off, stuffing them in envelopes, pushing them through the franking machine, burning fuel (yours or the postie's) to get them into the post... and all this at the end of the month, when your staff have plenty of other work they could be doing.

Why not simply dump the remittance advices and all the messy work they entail?

You can if you want to...

How?

Just output ("dump") them as a file into the directory that your SaaS EDI system links to. The service can then collect them ALL. The rules engine pulls out those that are destined for suppliers who can accept them as EDI, translates them to the required formats to suit each recipient and sends the messages to them via the agreed transport method...

Yes, yes that's OK for those suppliers but what about all the rest that have no EDI capable of accepting remittance advices?

It couldn't be easier. They are all translated into .pdf documents, complete with your logo and livery, and sent via email to each of the other suppliers. From start to finish, the process takes only a few minutes.

We have a customer for whom it used to take ten staff three hours (of very hard work) at the end of every month to get their remittance advices printed, folded, stuffed into envelopes, franked and ready for the post collection. Now it takes one person less than ten minutes (and the work now is very easy). It is saving our customer quite a bit and needed no months and months of delay waiting for every supplier to implement stuff in some draconian "roll-out". Those with EDI get EDI, the others simply receive their remittance advices in their emails.

The service takes full advantage of what is there. The suppliers get their remittance advices, no matter what is happening to the postal service. The customer gets valuable time back whilst saving: money, paper, envelopes, fuel. It is a very eco-friendly process in which nobody loses out.

Now isn't this the sort of thing you would like to be doing with EDI?

Back to the Future of EDI

In my last post I looked at the benefits of using the Internet to exchange business messages electronically rather than proprietary Value Added Networks (VANS). One on the problems with the VAN approach is that customers are normally expected to have a specialised, normally proprietary, piece of software to allow the message exchange. Now this software is not normally proprietary to the Network, and your EDI software does not need to match your trading partners EDI software, but you still need specialist software.

Obviously with the Internet comes the advantage of standards based message exchange. Whilst we favour the use of AS2 as the communications protocol, preferably Free AS2, we are happy to use most Internet standards for communication. This is because by using open standards it makes it easier to engage trading partners in the exchange of electronic documents.

I actually thought, regardless of whether companies charge for AS2, that all EDI and XML message exchange was moving to Open communications standards. It was therefore a great surprise to me to find that one trading partner of a customer was trying to insist that they install a proprietary piece of communications software to exchange invoices with them. When we questioned this we were told that whilst in theory their software could support the open standards, their software provider preferred that they use the software providers own communications protocol. This was even worse than the software needed for EDI VAN communications because what the software provider was trying to say was that to exchange any messages with their customer you must use the software houses own communications software.

The IT industry has a habit of inventing solutions to problems that do not exist and here is a prime case. Having been offered the options of email, FTP, HTTP(S), SSH, EDI VAN and AS2, a software provider was trying to insist upon their own proprietary solution. Having insisted (with our customers permission) that we would not install proprietary software, the trading partner went for email (but only after days of delay), not our favourite method, which works OK.

So having moved from the world of proprietary networks and associated software, to the glorious open world of the Internet, are we really going to step back to proprietary? I hope this is an isolated instance, because otherwise we may as well go back to EDI VANs, and I don't think that helps anyone.

The exchange of business documents offers many benefits to businesses both large and small, reducing costs, reducing errors and it has environmental benefits too. Putting barriers in the way of message exchange reduces likely uptake and, when as above, it is an unnecessary barrier it is just silly.

Why is the Internet not Free?

When companies started using EDI to exchange their business messages (way back in the days of punched card) they needed a way to send the messages to each other. This method needed to be both secure and reliable and from this rose the EDI Value Added Network (VAN).

A number of IT Network companies around the world, normally in conjunction with a telecoms operation, set-up dedicated networks that could carry your business data to any part of the world as long as the recipient had an EDI mailbox. It did not matter if that person used the same EDI VAN as the sender, the networks could communicate and so messages could be reliably exchanged. Obviously the EDI VAN would charge for this service as you were using their network capacity and their servers.

Then along comes the Internet. Over time the Internet has been able to connect any computer to any other computer and this has opened up the opportunity to replace the EDI VAN with other methods of sending and receiving data. The advantage being that as long as the communications method used was an Internet standard, you would not need a specialised piece of software (as you did to communicate with an EDI VAN) and so you could send the messages for Free. So we now see people sending EDI messages using email, FTP, FTPS, SFTP, HTTP, HTTPS, SSH and AS2.

But hang on a minute, whilst you can use all the other methods for free, and no one will object, some people are trying to charge for AS2, and sometimes a hefty premium. I just don't get it. AS2 stands for Applicability Statement 2 and is a WC3 published Internet standard. Therefore we should have the choice to buy it or write it. As long as it conforms to the WC3 standard, all AS2 servers should talk to each other. But this is not what we sometimes hear.

We hear Fear, Uncertainty and Doubt (FUD) stories that you have to have each version of a given server tested with each version of another server and if all the various server products in existence have not been tested with each other then you cannot guarantee that they will work. When is a standard not a standard? I think this is arrant nonsense, dreamt up to enable people to charge for something that should be free.

Luckily the Open Source community sees through this and there are a number of Open Source AS2 servers available. We use the server from Open AS2 and have used it to establish hundreds of AS2 connections, with the vast majority of the "charged for" servers. In fact, if the last statement is true, we have done the testing that most people charge for. We have had one failure for Open AS2, but when we delved in to it we discovered that the large organisation involved had not conformed to the AS2 standard and that no one had connected a vanilla AS2 server to theirs anyway.

We are firm believers in the value of AS2 for sending business messages via the Internet, we just believe it should not be charged for. We now deploy it Free of Charge for our customers and their Trading Partners should they wish to use it. It reduces the costs of Electronic Message Exchange, greatly enhances the speed of message delivery and provides the most secure and reliable method for exchanging business messages. It's certainly better than the Postal Service :-)

Have a look at Open AS2 today. It could save you time and money.

Got EDI working? Now everyone gets fired?

Of course not! Yes EDI and all variations of it, when integrated to your systems and running automatically, will be cheaper than people. But you won't be getting rid of them. What a waste that would be! Your company IS the people within it. They are the key to your success in the past, your success right now and your success into the future.

Being a somewhat older person I am old enough to remember when companies ran their businesses without any computers at all. Everything was written down and a good head for figures, or nimble fingers for the comptometer, or add listing machine, were important desiderata.

Along came the first computers. Knees trembled. Fears mounted. What will we all do? We are to be replaced by a machine!

Our fears were unfounded. All that happened was that businesses grew without adding more folk to look after all the extra administration work. In other words we got more productive and were able to concentrate our time on work best suited for human beings than for machines like computers.

EDI, and all the other methods of integrated, automatic, electronic trading, led to the same number of people being able to handle more work. EDI takes care of the input and output of information. The people simply use the information (information that just so happens now to be more accurate and more quickly obtained than in the old days of manually copy typing everything) and so the business grows again...

Imagine a supermarket chain without electronic trading to link to its suppliers! The sheer volume of copy typing to raise orders couldn't be managed even with aircraft hangars full of people clacking away at keyboards. The shelves would have a few hundred product choices to try and satisfy hungry patrons ("consumer" is such a dismal name that implies squandering and questions like "Who ate all the pies? So let's call ourselves "patrons"). Today there are thousands of product choices in hundreds of supermarket branches, all over the country and it's all thanks to EDI.