EDI Expert: Five Reasons to Get Off the VAN
Posted by Jim Cantrell on June 13, 2011
On a daily basis I talk to companies confronted with limitations in their supply chains. In many cases, a direct link can be drawn from a business need to their VAN’s inability to provide a solution that is either cost-effective or flexible enough. This isn’t surprising. Many companies, when addressing a business connectivity requirement, try to jam a round peg into a smaller square hole.
In this blog series, I will demonstrate five reasons why companies MUST strongly consider getting off a VAN ecosystem in order to increase agility, achieve better economics, and maintain compliance with current and upcoming privacy legislation and industry mandates.
The initial VANs or Value Added Networks, made their debut years (literally decades) ago. At the time, the internet had not been “invented”, and companies were communicating across asynchronous phone lines. While EDI was their only data format, they also handled simple messages. The VAN was used primarily for basic order to cash processes such as Purchase Order and Invoice with various acknowledgements and occasional Shipment Notifications thrown into the mix.
The concept of re-using data, real-time messaging, business rules, process-based integration, e-commerce, and business intelligence didn’t exist. While some VANs have made improvements and “moved up the stack”, for the most part the solutions are disjointed or incomplete, and are still not really cost-effective.
In today’s internet, cloud-based environment, connectivity should be faster and easier. Businesses today are beset with managing more applications, with multiple formats across several transport protocols to far more business partners. At the same time security, speed and cost must be managed.
This series will explore the following ideas:
1. Any-to-any EDI (X.12) exchange is old news. In today’s IT environment, companies must be able to consume multiple document formats across several different transport protocols. Providers must be equally versatile with UBL, cXML, Rosetta and other formats.
2. A “Value Added” partner should be able to do more than relay data from point to point. Business process management, semantic and syntactic validation, security and policy mediation are critical points in delivering more value in the cloud.
3. What do you mean ‘we don’t have the order yet’? Many processes rely on documents which can’t spend 45 minutes in a queue and must have real time processing. We also can’t ignore dropped messages or VANs with a reputation for simply going offline for hours.
4. Confounding growth and improvement. Traditional VAN models while maintaining a “pay as you go” pricing model naturally penalizes companies for growing their business and increasing either the number of trading partners or document types. Commoditization of the kilo character (Transaction), is a market effect and not related to efficiencies being passed to companies by “Value” Added Networks.
5. Companies don’t just need someone to transmit data; they also need someone to safeguard it. As the breadth and variation of data being transmitted between two companies’ increases, it becomes more and more important for providers to have validated systems in place to protect that information.
Jim Cantrell will be featured in an upcoming Webinar, titled: “Get off the VAN and into B2B Cloud Integration”. Register here
Tags: Cloud Integration, EDI VAN, purchase order exchange, Retail EDI, Supply Chain Integration
I would advocate very highly for the model of E 2.0, such as Hubspan, bring greater in network intelligence to the partner communications process. However, the global system of routed communications is still in place, and for suppliers and upstream megahubs, the diversity and availability of that massive pool of ID’s is going to be with us, and should be improved upon with more intelligent services such as directory services, interconnection management, and enhancements to the x12.56 interVAN signaling wrapper.
And in truth, there is no need to take an either / or stance. A Hubspan type B2B SAAS can offer transparent interVAN routing via the appropriate web services API, and no one needs to know. No end user should be so concerned of the minutia of AS2, FTP, etc., there communications services should underpin the applications, as all other IP comms services are available and consumable by all applications developers – HTTP, FTP, SMTP, etc.
Therefore, if a message has a ISA header, the end user need not even worry about having a VAN account, if the appropriate comms handling services are available. As you know, as Hubspan knows, such technology is available, and it should not a political thing,
I think the “VAN exodus” has more to do with toxic business practices and the fallout that has occurred as a result of the recent VSN consolidations – a whirlwind that bode ill for the end users of EDI communications.
We are ready for a reformation of global routing technologies, and many sincere communications engineers are in the process of bringing the next thing to market. We count ourselves and Hubspan type SAAS model operators as quite kindred in outlook.
Comment by alan wilensky — June 17, 2011 @ 8:31 am