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.

SaaS adds more value to EDI

With more and more off our customers we are happily finding ways to add value to the normal EDI processing that has been experienced with older, on-site solutions.

Firstly new acronyms are appearing, for example EIPP (Electronic Invoice Presentation and Payment). Sceptics might call this EDI invoices and BACS. I shall explore the differences in a future post.

For a lot of our users, up until about 18 months ago, traditional EDI with a hint of XML for spice, was just fine. But we have started to notice a sea change in the requirements for EDI. Obviously there is the move towards AS2 and other methods of sending and receiving data. We have been using AS2 for our customers for nearly 4 years but in the past 18 months the adoption rate has accelerated markedly. This is a great move, it reduces the costs of EDI and adds value by removing the latency built in to most EDI processes by the nature of the timed connections.

We have also seen a move to increased data requirements. This has proved difficult for some users as it was not always easy, as I am sure you will realise, to modify their ERP system to process the additional data. However they often had the additional data in "Non EDI" data, for example catalogues, or even the incoming documents such as Purchase Orders.

Because of the nature of our SaaS solution, being based around the concept that all data has value whatever the format, plus the fact that the solution is based on a repository we have been able to take these disparate data sources and merge them to create enhanced EDI messages that the recipient requires. This would be a real struggle with traditional on-site systems.

Over the next few months we intend to expand the use of such solutions to both enhance customer data, add functionality to the user experience of the service and to provide translations of product codes, units of measure, delivery points and many other requirements that are becoming the norm for the modern EDI message exchange.

By adding more value to EDI messages we believe that adoption will accelerate through the next 10 years.

EDI as a Supplier: Brownie Points or Valuable Benefits?

A customer of ours just happens to be the largest privately owned company in the world. Naturally there is a superb information services arm to this global giant. The skills available have allowed the company to determine, in meticulous detail, some of the things that make up operational costs. One such item is… a keystroke!

A simple sum, taking the numbers of keystrokes saved through integrated EDI and multiplying them by the keystroke cost quickly determines the viability of each electronic trading relationship.

This has proven to be very useful. It makes assessing whether eBusiness is actually saving the company any money as well as showing up any benefits and what those benefits are worth.

All well and good for a giant, but how is a smaller company able to know things are moving in the right direction, if there are simply insufficient resources to measure these things for you?

What are the opportunities for improvements if you are a supplier to a customer requiring EDI?

Here are a few:

Integrated EDI improves the certainty of delivery for your invoices. You can avoid the “Haven’t received the invoice. Send a copy!” conversation when you enquire what the Devil has happened to your money!

It also improves the timing of invoice delivery, which is very helpful as:

(i) closer invoice timing to goods delivery improves the likelihood of trouble free delivery (GRN) approval

(ii) the earlier invoices are produced & delivered the earlier the “payment due date” clock starts ticking

You are doing the invoice input for the customer, which leads to better information quality going into your customer’s ERP and ensures 100% data integrity across the supply chain!

Your integrated EDI will reduce the likelihood of delayed payments because errors are flagged up earlier, on processing the invoice, rather than as a result of chasing non-payment. A faulty invoice sent via EDI is rejected by the system and you can know in seconds. A faulty paper invoice might remain undetected by you until well after the end of your agreed payment terms with the customer!

You may not have the resources for obtaining detailed measurements of the effect of EDI on your business but you can still determine if things are going in the right direction for you. All you need do is watch one or more of some easily ascertained Key Performance Indicators (KPIs)…

• Improved Process Effectiveness – watch to see if the numbers of Day Sales Outstanding are reducing.
• Improved Productivity – is the number of invoices (or detail lines) processed per fiscal period increasing?
• More Automation – is the proportion of transactions that are processed automatically increasing?
• Improved Quality 1 – check that the ratio of credit notes raised to invoices produced is decreasing!
• Improved Quality 2 – is the number of rejected invoices decreasing?
• Improved Quality 3 – is the number of queries raised also decreasing?
• Cost – is the average cost of processing a transaction decreasing?

So, even with limited time and resources available to you, a glance at any one of these can reassure you that you, as well as your customers, can benefit from integrated electronic trading.

Next time we can look at the same subject from the customer's perspective

It's the data that matters, not how it looks

This blog could also be entitled the triumph of substance over style.

We had a new customer sign with us last week, not in itself unusual, but that fact that we were replacing an alternative solution, and at the same time becoming the partner of choice for another software house is worth mentioning. At a more technical level it gave me an insight in to the limitations of some of the older methods for EDI integration.

The client concerned required a particularly rapid turn around of one specific trading relationship and asked if we could move faster than our standard Service Level Agreement (SLA). We had a quick look at the data, the format required by the recipient and the how the missing data could be deduced. We then said yes.

However, the reason for the rush was that this particular Trading Partner (a customer of our customer) had been waiting for over six months. The reason was that whilst the previous EDI vendor had claimed that their tool was flexible and did not need rigid formats. The truth was more like "we have several different formats that we can use, but outside of these formats we will struggle or it will be a an expensive consultancy exercise".

I have a problem with this approach. I do see the benefit of standard data formats being developed, in fact I really admire the business analysis that has gone in to the development of standards such as UN EDIFACT. However these standards are rarely rigidly adhered to and that is both the problem and the beauty. Different businesses have different data requirements, sometimes based around restrictions in the ERP system, sometimes around the business process. Therefore, your EDI solutions must have the flexibility to change as the business requirements or you or your partner changes, this may involve merging data from various sources, using a message intended for one purpose to provide the data for a different message, splitting or concatenating data to provide different data and the use of look-up tables or catalogues. Sometimes we are even asked to use one message between trading partners to add data to another message between the same partners. Obviously, because our service is Software as a Service (SaaS), the idea of such data merging is easier than for software deployed at the end user site, especially when like us you can be using industry catalogues that are shared amongst many users.

One thing is certain, the format of the data (XML, EDI, csv, Fixed Width or even MS Excel) is irrelevant as long as the data that is required by the recipient is either present or can be deduced. You see the style of the message is not as important as the substance (aka content) of the message.

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.