What's a mB, milliByte? Megabyte would be
MB.
Steve O
-----Original Message-----
From: James Bryce Clark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 06, 2001 8:35 PM
To: [EMAIL PROTECTED]
Subject: Re: Fee structure question
Everyone has their own proprietary pricing schemes, but a few general principles are probably worth mention. Here is what the landscape looks like to me as an occasional purchaser. Anyone who disagrees, please feel free to speak up.
1. VAN charges vary widely. This makes them somewhat hard to comparison-shop. In large part, this is because many of them bundle their prices. It is also because this is an apples-and-oranges market, with some big brand names and some little-known small players.
2. As a starting point, take a look at two public examples of pricing data.
a. CTI's public site: $25 per month (2 year minimum), plus $5 per mB sent/received, plus a one-time initial charge (US$995 for new users on TCP/IP and Windows). Quoted from http://www.cticomm.com/van.htm.b. The VAN comparison chart from San Antonio ECRC (possibly unavailable after 30 Sept 01) at http://www.saecrc.org/van/vanReport.html.
One interesting question is whether per-character or per-session models will persist. Certainly the broader software industry would like to move in this direction -- see SIIA's "Software as a Service" initiative. On the other hand, there have been a fair number of EDI sales to would-be early-adopters who get bogged down in implementation, and so do not progress to high transaction volume. If that remains so, it would motivate vendors to stick with a one-time or periodic component instead of pure taxi-meter pricing.
3. Further to #1, on bundled pricing, and what's bundled. While everyone has their own reasons, it is not uncommon for sellers to use bundled prices to obscure their separate cost basis in various components. So a careful analysis requires that you mentally unbundle the services and do a piece-by-piece comparison.
With VANs, you may be buying combinations of the following:
a. Some degree of segregation of communication channel. E.g., a separate POTS session, a dedicated line, a VPN, specific retry or messaging/tracking protocols.
b. Some degree of security other than segregation. E.g., proprietary or third-party encryption, pre-arranged protocols regarding passwords.
c. Some degree of authentication (that is, automated or third-party confirmation) of the location or identity of your correspondent/trading partner.
d. Some degree of objective control over, and evidence of, workflow. E.g., transaction logs, confirmation messages, functional acknowledgements, third-party time stamping.
[I haven't spent a lot of time on this four-item taxonomy. It's just what comes to mind as I type. Any other major classes I've missed?]
Since the early EDI market in the late 1980's, each of the foregoing functionalities has become a more competitive marketplace. To state the obvious, among other things that have evolved to compete are (1) the Internet, (2) a number of commercially-available security and authentication schemes using electronic signatures, password-based and other types of encryption, smart cards and biometrics, (3) a number of private and public marketplaces that authenticate or pre-qualify trading partners, and (4) various open and proprietary workflow and collaboration software solutions. So, at the cost of careful analysis, custom integration (if needed) and comparison shopping, EDI users can choose to piece together adequate functionality from those sources without buying turnkey VPN service.
4. Further to #1, on brand names among VANs. It is not uncommon for buyers to prefer large brand name vendors in some circumstances. (Here in the U.S., my family has always bought Sears refrigerators. Whether or not Sears makes the best refrigerators on Earth, we feel that they have a good track record for product quality, and (equally important) a reliable, pervasive service delivery infrastructure which is likely to persist.) Again, to state the obvious, factors that may be relevant include:
a. Actual stability of corporate entity or parent, as discernable from public data.
b. Actual traffic, as an indicator of experience and commitment to the product.
c. Cost.
d. Reputational perception of stability, as it may affect your customers' preferences, the derivative effect on your own reputation, or the managerial defensibility of the vendor choice.
e. Extent to which your use is real-time, 24/7 or mission-critical, versus episodic, batched, or easily interruptible and resumable.
f. Substitutability: the extent to which the service can be obtained from multiple sources, and the ease (or difficulty) with which you can re-integrate and change vendors. (E.g., lower reliability may be acceptable if prices are low, there are many other sellers available, and switching is easy and cheap. The latter seems rarely to be true.)
g. The software and hardware supported.
h. The terms of service the vendor will assure to you.
i. The extent to which you expect to be able to legally or commercially enforce those terms if there is a breach -- which goes to things like the vendor's reputation, their location of assets and of incorporation, and their creditworthiness.
5. As a practical matter, we have clients who prefer that we use VANs for their data, and some who do not. Three of the common contributing factors seem to be
a. Some users who have greater security needs may prefer the implementation ease of a turnkey higher-security VAN, over the do-it-yourself issues in implementing higher-security non-VAN solutions.
b. Some users with sophisticated in-house IT help tend to like do-it-yourself non-VAN solutions, for the greater opportunity to control and customize.
c. Sometimes -- often, actually -- choice of channel is forced by the preferences, limitations or connectivity issues of major trading partners. Every community has its own quirks, such as pervasive legacy software installations. Sometimes the perceptions in a particular vertical about installed bases, dominant vendors and typical tech requirements vary widely. (In other words, objective trading partner surveys often reach different conclusions than press releases.)
6. Retrofitting EDI capability into an XML shop is an interesting task (and the reverse of what many are facing this year). There are several specific schema you should know about. Drop me a line if you want to get into that in more detail.
Hope this helps. I would be happy to hear other takes on the topic. JBC
James Bryce Clark
VP and General Counsel, McLure-Moynihan Inc.
Chair, ABA Business Law Subcommittee on Electronic Commerce
1 818 597 9475 [EMAIL PROTECTED] [EMAIL PROTECTED]
At 02:28 PM 9/5/01, david frenkel wrote:
I agree. It is just XML is growing up with the Internet and EDI has been around for a while as we all know. Dave Frenkel
------
From: Mark Kusiak
* * * I most certainly agree with your assessment and your comments. I further realize that there is no silver bullet approach to solving this issue. My point here is that the XML side uses this issue as a club to beat EDI over the head and say that they have an advantage because we can avoid communications costs. EDI can be accomplished in the same manner as passing an XML formatted file to a target server. Conceptually, the file format isn t going to make a hugh difference. * * *
-----
From: david frenkel [mailto:[EMAIL PROTECTED]]
* * * I agree conceptually with what you are saying but every business opportunity may have political, strategic, or technical requirements that may drive how an opportunity is solved. Certainly the Internet is a viable solution but the alternatives also have their advantages. * * *
-----
From: Mark Kusiak
* * * Why does the data transmission need to be routed through a VAN? This is not a cast in stone requirement to do EDI!!! * * *
-----Original Message-----
From: Lou van Dyk
Sent: Wednesday, September 05, 2001 4:35 PM
To: [EMAIL PROTECTED]
Subject: Fee structure question
* * * We are an XML shop, but getting pulled into the EDI arena also. I have a question: what is the standard fee structure for EDI VANs? Do they charge per document or flat rate? What are typical rates? I appreciate any input. Thanks, Lou
Lou van Dyk
IT Manager World Wide Wood Network, Ltd. * * *
