ec-bp's Bloggers

Do We Need VANs? Reader Comments

Written by Ken Kinlock
Published on Tuesday, 12 June 2012

We recently wrote about “Do We Need VANS?” With supply chain platforms providing the E to E linkage and Managed File Transfer Services- do VANS still play a role? The pros and cons of VANs, AS2, FTP, Electronic Commerce Communications Providers. We will be evaluating TRANSPORT, not mapping,  Web portals, or other services which could be performed by a VAN as well as by other EDI service providers.

We had quite a few comments from several forums and groups. We are generalizing and grouping these comments to be able to address them.


A concern is resources to support in-house connections. Many small EDI teams opt for using a VAN because of not having internal support resources.

For large companies that have hundreds of trading partners some responders think the value a VAN adds is the support for communications. The expense of VAN fees is far less than hiring in a full time communications specialist.

One good thing with VANs is if there is a change/issue in your infrastructure(firewall changes, server crashes, upgrades etc...) you do not have to test with 500+ TPs. You just inform your VAN.

Vans are like supermarket ready meals - nobody needs them but they can make life a whole lot easier. Direct connections are great if both ends of the connection have the skills to set up the connection and the resources to maintain them.

We all prefer direct connections when applicable but there are cases where a VAN is preferred. Examples: (1) The trading partners direct connect is unstable; (2) There are repeat issues where the trading partner claims they sent something and we didn't get it. (3) There are repeat issues where the trading partner claims they never received our data and we have a good MDN for it. I let the VAN be the referee whenever I have a trading partner who is difficult.

A VAN protects the sophisticated partner from the unsophisticated. When you have thousands of partners there is always a small group that just do not have their act together, especially with data communications.

We often get challenged with 'why can't we do this ourselves - its just a simple data connection'. VANs add a lot of value: (1) On-going they have the resource and processes to offer comprehensive support to both ends of the connection, and (2) No two companies truly work with the same data format, using direct connections adds significant cost to the set-up and onboarding new partners. A VAN can carry out all the mapping and validation across thousands of connections, providing only one connection for the customer to manage.

With our AS2 product and it's connection licensing, smaller low volume partners aren't cost effective if taken off the VAN as well.


One respondent did everything he could to eliminate the use of VANS. He saved tens of thousands of dollars in charges by moving to FTP and AS2 connections. There were a few customers that required him to use a VAN so he could not completely get rid of the VANs.

One suggestion is for for those with a large trading partner community to offer a variety of connection methods including traditional VAN if they want to maximize take-up, but review your VAN traffic regularly and encourage the heaviest users to consider an alternative by demonstrating the cost savings to be made by both parties.

VANs are repositioning themselves to provide alternative, more aligned services - for those no longer in need of the traditional services. However, the technology is available to do it all 'inhouse' - so why outsource? One question still remains  - Is there a point where cost, quality and control are sufficiently balanced to persuade an organization to outsource to a 'VAN'?


A VAN minimizes the amount of work to set up the communication connection. It reduces the number of communication protocols needed and sometimes the value added services are helpful. On the downside the costs and reliability concerns sometimes are arguments against a VAN strategy.

We work both ways - using VAN for inexperienced and smaller partners with limited capabilities but direct communication with high volume and experienced partners. Looking at the cost structure this makes most sense even if we need to have a team internal to cover the setup. The costs savings for a high volume partner compared to a VAN connection easily cover the internal costs. Of course setting up an internal team and gaining the needed experience takes time and if I work with a VAN provider I might be reluctant to invest this money. But having a good team in the end does lower the costs reasonably. I agree using a VAN is convenient and I can 'outsource' the responsibility of monitoring, comm setup and even mapping implementation to a partner that is specialized in it.

Todd Gould shared some other comments with us:

“The underlying story of my original article was about the lock the VANs have on routing and how the market would serve the users better if the playing field was more level for the service providers, who user-facing are identical to the VANs. More choice + more technology + more invention = better environment for end users.

Ultimately, this comes down to build v. buy, insource v. outsource. There is a huge body of thought on this, my favorite is Geoffrey Moore. I think he sums it up quite nicely in his book Living on the Fault Line. He uses the concepts Core and Context. A function is Core to a company if it helps it differentiate itself in the market from its competition (e.g. better, cheaper, faster, cooler), and Context if it does not, but is still a necessary part of business (payroll, accounting, janitorial services).

Two important things are that 1) Even though it is Context, does not mean it is not critical or mission critical; it simply does not differentiate no matter how well you do it – not doing it well could differentiate, but everyone must do it; and 2) What is Context to one company may be Core to another (e.g. payroll is Context to most, but to ADP it is Core).

When whole markets such as EDI see themselves moving a Context process (EDI) from outsourced back to insourced, something is terribly wrong in the market. I am evangelizing a robust service provider market where companies can stop wasting time, attention and resources on this Context process and put their focus back on their Core processes, making them competitive in the market and thereby making their companies more valuable to their customers.”

You have no rights to post comments

eC-BP Bloggers

eC-BP's bloggers offer their opinions and experiences in this series of (usually) short articles.

Supply Chain Buzz




Fields marked with an asterisk (*) are required.