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.

How hard can it be to integrate two systems?

Earlier this week I was working with a particular mapping for a client. They required to send invoices to one of their customers and we were already processing the same invoices for this client from a different (Older) system. The idea was that the client was migrating from their old system to the brand new shiny system.

Not a problem one might think, as a newer system should have better abilities to trade electronically than a system well over 10 years old. We live in the modern, integrated world.

Well it turned out not to be quite that simple. First we had an email to our mapping project system to say that the new system could not produce a particular piece of data, rather it provided a piece of data that was incorrect. We found a work around for this using our facility to treat message data as look-up data and so we were able to agree how we could process the data and produce the correct information for the recipient. All a standard part of the service.

We had the software vendors file specification and we had sample data so, on we go. Then we stopped. A quick check by the mapping engine highlighted that the sample file did not match the specification. Close but no cigar.

So we requested, and were sent, two files contains not one but two specifications. We were also sent two sample files. So we now have a quandary. If we choose, we have a 50% chance of getting the wrong specification. No problem, quick chat with the client and they point to the latest specification. Couple of hours later and we have a mapping of the input data, a mapping of the output data and we can test to make sure that the documents match business rules, add up etc.

Guess what, they don't. Well if everything worked first time there would be no need for testing. We changed some of the mapping, checked the arithmetic of the data and it just did not make sense, did not have tax totals and so was basically totally invalid.

After further discussion with the customer we find the root cause of the problem. You will remember we received two specifications and two sample files. It turns out that one of the sample files, sent by the software house, had nothing to do with the final specification and between us we had contrived to choose the wrong sample. Such is Sods Law.

This is the work of data mappers, and this is not a whinge about wrong specification etc. The work of data mapping involves detailed data analysis. Yes we at least have tools that speed that process up significantly but never the less it is detailed work and we love it. After completing the mapping, in less than 8 hours including dodgy files and specification, we had a laugh with the customer, a promise of a pint owed and a happy customer.

But here's the thing. Without the tools that we have built the data analysis and mapping process would take days, in fact we have heard competitors quote large sums of money for such work, if they do not already know the file standard, and I can understand why. Some people believe there cannot be much to sending a file of invoices from one company to another, but the devil is in the detail and that is why EDI or EIPP is becoming more and more a Software as a Service arena. Without the specialist skills and tools it is the Total Cost of Ownership of EDI or EIPP, the costs of skilled data analysts, mapping tools, testing teams and support, that more and more Financial Directors are saying is too expensive to do in house. The sending and receiving of physical files is easy, but the set-up of the variety of communication processes is not. What a lot of companies are now saying is get somebody else to cope with the messy bit, we just want to send and receive one file format and use one communications method.

After all, if you distribute building materials do you want to spend your money on making the distribution more efficient and selling more OR staffing up the IT team to have data analysts, EDI experts, XML experts, communications experts, oh and have them also run you IT systems as well?

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.

Some times you can process EDI too fast, Nice Problem to Have

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 use of catalogue data in EDI

One of the big issues that faces companies exchanging data electronically in any industry is the alignment of the data on all trading partners systems.

As a simple example we can look at a purchase order sent from a retailer to a supplier. The purchase order contains data that has been produced from the retailers back office system that is required by the suppliers back office system in order that the order is fulfilled efficiently. This data will include information such as the delivery point and the code for each product ordered.

When the order is processed by a human, the human interprets the data they see and translates this in to the data required by the suppliers ERP system. When the data is exchanged electronically this "translation" needs to be done automatically. For a lot of suppliers ERP systems this has already been accommodated, but we still get requests from customers to help with this process.

One of the advantages of a Software as a Service (SaaS) is in the nature of having a centralised hub. We have taken the approach of hosting catalogue data on the hub which means that ALL customers that need access to this data, to enhance the data they send or receive, can use it. If our software was deployed at our customers sites then each customer would need a copy of each catalogue they use, and they would have to be regularly updated. With the SaaS approach one catalogue is shared by all relevant users, and is regularly updated in one place.

I should say that to us a catalogue is a name given to ANY look-up data which we process. This could be a list of valid delivery points, a list of product groupings and, of course, products and prices. The important thing to do is to enhance the data received by the recipient so that they can process the incoming data automatically without human intervention. After all that is what EDI is about.

Whilst we have found this approach to be some use in the retail sector, the real advantages have arisen in the construction sector, where EDI is still a maturing technology and the back office systems of both sides of a trading relationship are not a well configured for electronic message exchange as those in the retail sector. But as we are adding construction trading relationships at the rate of 20 to 30 LIVE trading relationships per month, this technique is proving its worth.

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.