Mark wrote:
>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."
Based
on the description above I counted at least two logins per
interchange, one by the "sender" into your VAN to send data,
the second by the "intended recipient" into your VAN to
retrieve data. How can two separate logins be faster than a
single login by the sender into the intended recipients own system?
Because like a traditional VAN, users communicate with
several hundred trading partners with one log-in to their secure
mailbox. They can even download one file containing EC messages for
several hundred, even thousands of trading
partners.
In your
scenario, I'm assuming the "intended recipient" uses
a polling process to check for new messages at your
In fact, no. We send an
electronic notification to them once data is posted to them.
They use that to trigger queries.
VAN, this
polling interval ALONE could be longer than the time it
would take a sender to login and send data directly to the intended
recipient. Your conclusion that a VAN provides faster delivery than a
direct connection are not backed by the evidence you present
Indeed, they are. There
is another assumption in your assertions, in order to receive your
supposed efficiency all parties MUST BE ON THE SAME VAN, what about the
overhead and cost incurred when multiple VAN's are involved in an
interchange? We
inter-connect.
>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.
I never said anything
about FTP, I always recommend HTTP
HTTP sends and receives, in most cases, are simply
piggybacking an FTP process. We provide these services via browser as
well. because of it's ability to handle both bulk file
exchanges and interactive web forms. The software that's needed to
manage inbound/outbound Internet EDI is relatively low cost, compared
to many companies VAN charges.
>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!
That same 2.5 MB
could be sent over the Internet, directly, for $0 incremental cost
Plus the cost of managing and maintain the systems
to do this.... provided a company has an Internet connection,
most already do. Also, you're not counting the "FULL
COST" to exchange the 2.5 MB of EDI data, both the sender and
receiver are charged $200, the real cost to exchange this
data is $400 ($200x2).
I was comparing our costs to the the
$1000.00 a month of transmissions you presented in your first scenario.
I may have been mistaken, but I assumed you are not currently paying
your partners leg of the transmission. We attempt to reduce the users
telephony base VAN costs by 80%. $1000 a month moves from 2.5 to 4 MB on
a telephony based VAN for an average user. We move that for under
$200.00.
Thanks again,
Regards
MJM
Again, I never suggested using FTP, that was an
assumption on your part - MY suggestion is to use HTTP/Web technology
for both bulk EDI and Interactive Web Form based
E-Commerce.
All this discussion about cost and efficiency
is interesting but candidly another major advantage
for companies that establish their own E-Commerce capability
is "CONTROL OVER THEIR DESTINY".
These companies are free to implement advanced,
unique E-Commerce applications without having to
"negotiate" with a VAN over pricing and functionality.
VAN's will continue to service companies
that believe E-Commerce is not strategic or cannot "cost
justify" implementing their own E-Commerce
solution.
I'm becoming concerned that this thread may not
be of interest to the entire xmledi list, perhaps we should take this
discussion off list.
Feel free to email me privately.
You have my address.
Regards,
Mark Malatak
Dick Brooks
Dick
Brooks
