Mark Malatak
wrote:
>In fact,
properly structured Internet based Value Added Networks provide
instantaneous posting of documents to the trading partners access portal. As
these access
>portals are private, secure
and connected directly to the trading partners systems, the end result is
virtual real-time Electronic Commerce. Unless said trading partner has a
posted
>server
specifically for the receipt of EC messages, they can not count on a more
expedient delivery.
This is precisely my point,
if a company has a "system" and an Internet connection they
can communicate directly with their trading partners and "they can not
count on a more expedient delivery", as you indicated
above. Inserting a VAN in the middle would would introduce both
cost and latency, it seems we agree.
>Also, this PC
user will have to execute delivery (be it FTP, SFTP, SMTP
or
> whatever) to
each of their trading partners in separate sessions. This indeed, will take
much more time than posting their messages to one central clearing
house.
I would be interested in
seeing some statistics to quantify your claims that it takes "much
more time" for a trading partner to communicate directly as
opposed to going through a VAN. Do you have empirical data to share? We have
clients sending thousands of EDI transactions daily to their trading
partners directly over the Internet, many of these exchanges are completed
in less than 5 seconds at zero incremental cost.
Well, in fact, I do have
quantifiable examples to illustrate my point. You see we also utilize and
provide turnkey FTP packages that handle multiple FTP session and sends of
EDI and other EC data. And indeed, in instances where a user needs to
communicate with several trading partners, at several different host
addresses, the log on process alone (given the variety of the quality of the
servers hosting the FTP service) can take up to 100 times as long as a
simple deposit of a file containing several hundred ISAs in a secure
Internet based VAN. Now, from there, it's up to the quality of the VAN to
assure instantaneous delivery. Those that are posting simple FTP servers
(like what you're proposing large EDI/XML users do) are unable to provide
instantaneous deliver because they require intermediate processing to take
place which grabs and feeds data to interpretors. A higher quality IVAN
centralizes the process, so deposits are in effect, posts to the trading
partners mailbox. Also, a "fly by night" IVAN might simply let the
data sit there until the trading partner picks it up. A quality IVAN will
send electronic notification to the trading partners systems, which can be
utilized as an instantaneous trigger to run a batch process to retrieve that
data. These are things that traditional telephony based VANs can do without
tremendous costs. Again, as our customers say: "Don't throw out the
baby with the bath water."
I have a hard time
believing it's more efficient to communicate through a third party when two
parties can communicate directly. Perhaps a technical explanation
showing how an intermediate point is able to speed communications
between two end points would help. I'm thinking of a scenario where a
company uses software that can simultaneously send to multiple trading
partners, this is possible today and is the typical configuration at our
client sites.
>Additionally, clearly, one of the advantages to a well architectured
Internet based VAN is the reliability and security they provide. One could
not conjecture that a direct transmission, >without auditing, log
reports, and verification, without certificate handling and encrypted
message handling would be more reliable than a properly structured IVAN
without fear of >contradiction.
There are products
available that provide logging, auditing, key handling, encryption and
efficient, reliable, secure delivery. I've met people that
have experienced ROI's of 4 months moving from VAN's to the Internet,
without compromising reliability or
security.
Still, in order to experience reliable,
secure and timely transmissions, the receiver must have, at minimum, an FTP
server on stand-by, waiting to receive your transmission. You must also have
something to manage the outbound and inbound traffic.
>Regarding
your "case in point", which I think is a valid one: Clearly, we
are talking about a company with vast resources and capital. Unfortunately,
E commerce needs to be the venue >of the masses, not limited few that
have the resources to compete with multi million dollar companies. I do
however think we are in agreement on this point. Implementing unique
>services does provide a competitive advantage. But the post office must
operate for everyone, not just the rich. The rich, however, can feel free to
hire a messenger as they have the >resources.
Actually, any company
spending $1,000 or more per month on VAN charges can experience a very
reasonable ROI by implementing their own E-Commerce system. I'm not sure if
you consider this a company with "vast" resources. I do agree that
we will always need a "post office box" (VAN) for those
people who can't justify having their own
"mailbox".
And so what you propose is that high volume
trading partners interact directly, and low volume users utilize
intermmediary VANs to gonglomerate data. That's interesting because our high
volume clients say "For the price, I'd rather pick it up all in one
place, not have to maintain a system for managing traffic myself, not have
to higher people to maintain it and not make my trading partners worry about
several different methods of security, transmissions and
communications." But you have a valid point here. Perhaps there are
users at some level (approximately $1000 a month user (approximately 2.5 MB
worth of EDI)) who could post an FTP server for about $400 dollars a month
and save money. Oh wait! I'm wrong. 2.5 MB of EDI only costs less than $200
bucks on our VAN!
Dick
Brooks
