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.
Showing posts with label AS2. Show all posts
Showing posts with label AS2. Show all posts
Sunday, March 16, 2008
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.
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.
Sunday, December 30, 2007
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.
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.
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.
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.
Friday, October 19, 2007
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?
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?
Thursday, October 18, 2007
Back to the Future of EDI
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.
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.
Tuesday, October 16, 2007
Why is the Internet not Free?
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.
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.
Monday, July 09, 2007
Postal Strikes are good for e-trading
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....
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....
Subscribe to:
Posts (Atom)
