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?

ISO 9001 can improve your business profitability

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

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

The World (retail at least) Keeps Spinning

Firstly, complements of the season to all.

As with all companies in the business of EDI, at least some of our customers have continued to operate throughout the holiday season. In particular in the retail sector orders for goods to be delivered on all days are being processed, and at least one of the logistics companies that use our service were actually working from 6pm on 25th December.

Of course our servers operate on a 365 days per year basis, but certain customers require the comfort of a support contact available as well, which we provide. This is seen very much as an insurance policy and we hope it never needs to be called upon. Unfortunately this year, on 26th December it was. Not a problem with any of our servers, but because we monitor customers traffic we were able to alert a particular customer to the fact that their systems had failed and they had not sent some of the transmissions we had expected. Sometimes, because EDI is integral to a business, we can actually help users to see errors in other systems, before any other alert is raised, and it is great to be able to offer such help.

One other issue that has come to our attention is the practice of some other providers in charging for messages stored on their servers. A number of new customers this year have contacted us concerned about storage charges over the festivities. It appears that some of our competitors charge for holding messages that the customer does not download within 7 days. Whilst this does not effect users such as those detailed above, this would obviously cause extra cost for users if they are shutdown over the festive period. What an outdated practice. One would almost think that this was the equivalent of an EDI "Stealth Tax". We were able to put users minds at rest as we do not charge for storage of up to one year. Some of our users are saying this will save them several hundred pounds which is great. We want our users to be happy customers for years to come and being short sited for a few hundred pounds would be ridiculous. It would also appear to be at odds with our views that EDI should be Software as a Service and AS2 must be Free of Charge.

One day all EDI will be this way.

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.

EDI Can Make You Feel Good and Improve Your Business

When we started developing the technology for exchanging EDI messages many moons ago, we obviously wanted to develop a software solution that would provide a service businesses would want to purchase, because without that we do not have a business ourselves. But we were also determined to ensure that the product and service were such that our customers would be able to see a return on their investment, unlike a lot of software that promises great ROI, but provides non.

We determined that the way to do that was to reduce any technical input from our customers to a minimum (reduce their costs of set-up), integrate messages to our customer's ERP systems when practical (some systems just could not cope with an electronic remittance for example) and to eliminate the need for them to change their systems to cope with our integration standard (You would be amazed how many times we have heard that from other people).

People keep buying the software and people keep renewing their licence so one could assume that we are continuing to get it right. But a better test in when customers actually talk to us and recently, as part of our program to achieve ISO 9000:2000 accreditation, we have be performing customer feedback surveys.

It's great when customers tell us what they would like from us next, as it means we do not have to keep coming up with all the new ideas. But in following up on the feedback, and expanding beyond the normal survey type questions, it was even better to find customers saying things like EDI has helped us achieve strategic alliances or we don't even notice the EDI is there it just works or we have dramatically increased the amount of e-trading we conduct. It makes you feel good when you can help someone else achieve success.

We aimed to provide the best SaaS for EDI in the UK and Europe, and the customers will judge us on that, but we also wanted to actually add value to our customers businesses and this also appears to be happening. Electronic message exchange for businesses has always had the potential to drive cost out of business but it was always perceived as a bit too much of a dark art.

Now with the combination of SaaS EDI where the actually mapping is done on the SaaS, not just a Web App you have to use, plus the best levels of customer service this is coming to fruition, and even adding to strategic business alliances.

The future of Electronic Message exchange is SaaS, the old technology of a piece of software deployed on a pc or server on site cannot deliver the flexibility needed for today's EDI.

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?