Add to Technorati Favorites The EDI Mapper: ERP
Showing posts with label ERP. Show all posts
Showing posts with label ERP. Show all posts

Tuesday, January 22, 2008

SaaS adds more value to EDI

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

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

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

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

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

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

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

Friday, January 11, 2008

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

Friday, November 16, 2007

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.

Monday, November 12, 2007

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

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.

Thursday, November 08, 2007

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.

Friday, November 02, 2007

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.

Monday, October 29, 2007

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.