The EDI Mapper

Is worrying about customer service wrong for a business??

2008-03-26T00:09:00.003Z

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

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.

The Complexities of EIPP or EDI make it prime for Outsourcing

2008-03-16T00:05:00.006Z

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.

The way to profit in EIPP is Systems and Quality

2008-02-28T00:19:00.006Z

I was reading the postings of another blogger the other day, regarding EIPP. Quick note; For most people EIPP is a re-branding of the most basic of EDI, the supplier sends an invoice. We're great in IT at making up new acronyms or names for old processes in the hope of selling more.

Anyway back to the subject of the post. The blogger in question was bemoaning the fact that whilst there is a lot of interest and "new" players in EIPP, few if any make a profit. One company in question has a turnover of £3.5 Million but loses approximately £7 million per annum. Its P&L account reserve is -£27 million. Another has turnover of £1 Million and loses of £3 million, P&L reserve of -£23 million.

Now here I show my limited knowledge of the practice of Venture Capital and high finance. Both these organisations are backed by VC's and so they are NOT insolvent. But... when are the investors going to get their money back? Or to put it more accurately when are the VC's going to get a return on their investment of other peoples money? I make it that break even is 200% of current turnover, assuming costs do not rise with increased turnover. To get the £27 million pounds back at current growth rate you are looking at a minimum of 10 years. Given that the turnover of the smaller company above went down slightly last year it and that costs increased ahead of turnover at the larger company it could take longer. This is almost "Dot Com" optimism.

So much for high finance.

I think there is a different approach that can lead to a profitably growing company. It may grow slower but note the word profit. That way is to concentrate of quality and systems. Quality because that leads to better systems requiring less resource to manage the processes. Quality because it leads to fewer remedial actions, which always cost more. Get it right first time and it's always cheaper. Quality because any business must concentrate of delighting it's customers. Delighted customers lead to higher retention rates and easier new business sales because of customer referral. My other point is systems. Quality systems. If you can systematise a process rather than having to add more support staff for each new customer then you gain a much bigger return on the investment and, sorry to say, but the fewer humans involved in a process the lower the error rate so the higher quality.

The only downside to the quality and systems approach is that you cannot make a quick "land grab" for a market. But it a lot less stressful for you and your trading partners.

Here's an interesting question for you. If a new customer came to you and asked for 30 days credit, with their company finances in the state described above, would you extend them credit? If not then why would you put important business relationships between you and your business partners in their hands.

Far better to put it in the hands of a company making a profit and dedicated to a quality implementation. Preferably one with a recognised accreditation for quality. Business relationships are hard won and even something as seemingly simple as sending invoices to your customers or receiving invoices from your suppliers deservers to be handled in a quality manor that does not put the relationship at risk.

How hard can it be to integrate two systems?

2008-02-13T23:46:00.004Z

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

2008-02-02T00:09:00.000Z

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

Free EDI Podcasts

2008-01-22T23:43:00.001Z

A while ago we had the idea of a series of short documents that would show people the technology behind EDI and the benefits EDI could bring to their organisations.

Now in the age of You Tube and podcasts we are launching a series of podcasts about EDI. They are not designed to go in to the intricacies of EDI technology but rather provide a Free introduction to EDI, where it came from, how it is used and the benefits that can be accrued for a business using it.

These podcasts will not turn you in to an EDI expert, rather we hope we will give you an insight in to how EDI can and is being used to bring benefits to a large number of companies world wide.

To hear the first podcast please click here. The Podcasts are FREE and you are not asked for any personal details to listen to them. Alternatively please click on this link for an RSS feed for the podcasts.

SaaS adds more value to EDI

2008-01-22T00:08:00.000Z

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?

2008-01-11T15:50:00.000Z

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

A Simple Guide To Electronic Data Interchange

2008-01-09T09:45:00.000Z

Over the holiday period I decided to create a "Simple" Guide to EDI for our Web Site. The idea was that, without needing to register or download, people could visit the Web Site and get a "Simple" FREE introduction to EDI, an answer to the question "What is EDI?".

I wanted to highlight to people what EDI is, what standards they can expect to find and how messages are exchanged. Six Web pages later and I have a thought. The concept of exchanging business documents electronically IS Simple.

The detail of it is convoluted, but for a good reason. Most businesses have a unique way of working. Most IT systems have a unique way of working. Certainly each industry has unique features, for example the way Paper is specified in an order is nothing like how a tin of baked beans is specified which is nothing like how a length of steel lintel for a building is specified. If a human is handling orders and invoices then their knowledge is used to "translate" between the buyers instructions and the suppliers computer system. With EDI or EIPP then the software must assume some or all of this intelligence.

The concept of EDI is easy, but as Ken Foster (One of Our Data Mappers) who has sat on many EDI committees and standards bodies says "The devil is in the detail". If people say that EDI is easy, then they are ignoring the detail or spinning a line (probably in sales ;-)). We chose to do this work because we a sad people who enjoy the detail, but it is not the standard IT software role and it is not to everyone's liking. We believe, and our customers believe, that Outsourcing EDI (SaaS) is best for most businesses because it is such a specialist area. Have a look at any "simple" Guide to EDI and if it is telling the truth you will see how complex it can be.

The World (retail at least) Keeps Spinning

2007-12-30T23:46:00.001Z

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

2007-11-22T22:47:00.000Z

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

2007-11-16T17:10:00.000Z

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.

"Both Parties Must Both Gain Benefits" is the First Golden Rule

2007-11-12T16:17:00.000Z

You may recall that in "Beware the "cheap" option!" we looked at some of the wasteful abuses that can be imposed on you if a "website" substitute for business-to-business, integrated EDI is presented to you as the means to provide your customer with electronic documents, such as invoices, despatch and remittance advices. The "cheap" option only leads to your staff having to double type all the information from the documents into your systems and 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!

What can you do to avoid such abuses?

Well, the remedy is a bit like growing asparagus...

Asparagus?

Yes. To grow asparagus you dig a hole three meters long by three meters wide about one meter deep. You fill it with all sorts of good stuff from stables mixed with exquisite soil and you plant the asparagus – FIVE YEARS AGO!

You must avoid being pushed around by the eBusiness team. They are working to a very restricted agenda. They know nothing and care less about your business value to their employer. You need to maintain and cultivate your highest levels of contact within your customer. You need your relationship to be strong enough for your senior contact to be prepared to instruct the eBusiness team to co-operate with you. To make an exception in your case. You will still be a very willing eBusiness partner, but the job is going to be done properly and, to a certain extent, on your terms!

It is best if you avoid direct contact with the eBusiness team. Let your eBusiness provider do that whilst you maintain your good standing with your senior contact(s)!

What then do you offer to do for your ally in the senior echelons of your customer?

When the “website” was implemented it was configured to receive orders from your customer's purchasing systems. These orders are passed to the “website” in electronic form. They are files and they have a format. All that has to be done is for you to be supplied with this format and for your customer to agree to sending the order files to your eBusiness system by one of the accepted transport methods.

Similarly, the “website” passes the documents (such as invoices, despatch advices and remittance advices) that are inbound for the customer's systems as files and they too have formats. If the formats are made known to you and your eBusiness provider then they too can be passed directly to the customer's systems just as efficiently as the files that are currently passed to them from the “website”.

The benefits here are that you avoid doing the work twice.

All the risks listed above are eliminated.

You have reinstated the first GOLDEN RULE:

BOTH PARTIES MUST BOTH GAIN BENEFITS!

In that same WIN-WIN vein, you are perfectly entitled to follow the example of Oliver Twist and ask for more. You are being asked to make an investment in money, time and effort to help your customer. Are you getting as much business from your customer as you could? On a number of occasions I have seen the Sales Director of a supplier use the “request” for electronic trading as a very sound reason to visit the customer and literally “ask for more”. In one instance a customer of mine, a supplier of specialist tools and devices to the construction industry, went to her customer and said something along the lines of, “We would be happy to do as you ask, but currently you only give us about ten per cent of your business. You give ninety per cent to our competitor! Give us fifty per cent and we will do all you ask and do it immediately!”

She won the extra business, increasing her company's sales to that customer by 400 per cent!

In summary so far then:

You must be informed of exactly what is required, IN FULL. It can be too late to get a decent working relationship if you fail to cultivate your senior contacts in your customer and just become part of a target list drawn up by the customer's eBusiness team or their vendor. You and your customer must get worthwhile benefits out of the eBusiness relationship. Get these things right with your customer and you have both made a good start towards successful and beneficial electronic trading.

You may even find an early opportunity to multiply your sales to this customer!

In a later blog we will consider the second GOLDEN RULE for successful integrated EDI.

The use of catalogue data in EDI

2007-11-08T23:58:00.000Z

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.

EDI Can Make You Feel Good and Improve Your Business

2007-11-02T17:35:00.001Z

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.

Beware the "cheap" option!

2007-10-29T14:22:00.000Z

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

2007-10-29T02:20:00.000Z

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!

2007-10-19T16:25:00.000Z

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

2007-10-18T01:07:00.000Z

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?

2007-10-16T09:34:00.000Z

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?

2007-10-12T14:40:00.000Z

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.

Postal Strikes are good for e-trading

2007-07-09T08:11:00.000Z

Here in the UK we are now looking forward to yet another postal strike. The Royal Mail workers have decided that to protect their jobs they need to withdraw their labour.

What has this to do with e-trading? Well it's a sales opportunity ;-). The last postal strike was at the end of June. What that meant for a number of companies was that their invoices to their customers, produced at the end of the month were delayed. Not delayed by the 24hours of the postal strike but, because the strike was on a Friday and there were no Friday collections, the invoices were not collected until the Monday, and then the Royal Mail were dealing with a backlog. Invoices arrived not 24 hours late but in some cases over 96 hours late.

For large volumes of invoices some people are now looking at switching from Royal Mail to their competitors in the business postal arena. But if they look at it logically why post an invoice. Send it electronically. In most cases electronic invoices arrive the same day, in some cases we have experience of them arriving in the same minute. If people choose the correct transmission methods (e.g. AS2) then they can even receive an electronic receipt showing that the document arrived on the recipients system (No more "Invoice, What Invoice, we didn't receive it?" from the payments department :-)).

All this and it is cheaper than people and more environmentally friendly.

Damn it this is so easy I think our Sales Quota should double. Better go and discuss this with the Sales Director....

The joys of Business to Business Electronic Trading

2006-08-04T11:31:00.000Z

We started this blog to bring you all the fun and excitement from the world of data mapping…

We work for a company specialising in the integration of businesses with their trading partners, via automatic exchange of electronic business documents between their systems.

Way back, this was mainly achieved via Electronic Data Interchange (EDI) and was always driven by large organisations, such as Retailers, Car Manufacturers etc. They would “request” (force) their suppliers to receive orders and send invoices in very tightly specified data formats.

Since the late nineties additional data formats have been devised such as those written in XML, which, it was believed, would answer all the perceived problems of EDI. These perceptions were typically:

Not humanly readable (except for sad geeks like us).
Expensive, EDI was sent via a Value Added Network, for money!
Different Formats

XML is humanly readable isn't it? Well that depends on the standard. For example in SAP IDOC XML, "MENGE" means QTY, and BETRG with a QUALF of 1 means Gross Price…

Of course a different XML standard may use GrossPrice to mean Gross Price!
EDI is expensive, but for most of our customers that still use EDI the cost is under 5 pence per document, cheaper than a fax.
EDI has different formats. This is true. In the UK and Europe the main formats are Tradacoms (UK Retail), UN EDIFACT (and variants thereof) and ANSI X12 (mainly used by American Organisations). There are subtle variations (e.g. in EDIFACT there are at least 3 ways to define the supplier of a product, or ODETTE for the Automotive Industry, EDIPAP for the Paper Industry) but most of these are still based on the core of EDIFACT. Currently we know of over 500 XML standards, (not 3). The X in XML stands for extensible. This means organisations can be using a standard of XML (e.g. BASDA XML for their invoices) but 3 different organisations will use that standard in 3 different ways…

We are not sounding the trumpet for any format of data though, be it EDI, XML Flat File, CSV or Excel Spreadsheet. We don't care. Our attitude is that the format of data is irrelevant. The driver for information exchange must be the data requirements of the recipient, and that you can send and receive Electronic Business Documents without the need for human intervention. As long as all the required data are present and the recipient system can understand it all, who cares what the transmitted format is?

That is Electronic Trading.