The one point in your message I take issue with
is the following: "if you have a PC and you have an Internet connection
it's cheaper, faster and more reliable to send data direct, instead of using a
VAN."
For an EC user, with a PC and an Internet connection, sending
data directly may be a little cheaper (.00 per kilocharacter versus .025 per
kilocharacter). However, I do not subscribe to "faster and more
reliable". 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. 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.
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.
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.
Thanks for the feed back.
Mark
Mark,
Clearly VAN's, Internet VAN's, 3rd party service providers, portals,
whatever you choose to call an intermediary, is a necessary
function. There is a part of the trading community that relies on
intermediaries for various reasons:
-
Can't justify owning their own E-Commerce server
-
Lack the skills needed to own/operate their own server
-
Don't see E-Commerce as strategically important to their future and simply
want to "pass the monkey"
-
FUD
-
"add your own reasons here:, I'm sure there are
more.."
However, there are companies that believe E-Commerce is a
strategic part of their business and they want to control their own destiny.
A VAN is an impediment to organizations that want to take
advantage of E-Commerce as a strategic business function. They don't
want to "wait on a VAN" to implement functionality they need NOW.
They want to offer unique services and functions that their competitors
can't easily offer - this is competitive advantage! If they used a shared
service, like a VAN then their competition would have access to the same
features and functions - in other words, choosing a VAN means loosing
competitive advantage that could be gained through E-Commerce
offerings.
Case in point, a public utility company in the southern US was forced
to deregulate which resulted in them opening their customer base to
competitors. This resulted in a 15 million dollar drop in
revenues during the first quarter. Their answer to recoup the lost
revenue was to offer E-Commerce services to their
competitors. They began offering Customer Relationship Management
services to the Energy Service Companies that were taking their customers
away, effectively creating a NEW revenue stream to replace the old. If they
had chosen a VAN for their E-Commerce they would not have this revenue
generating opportunity or (if their VAN was willing to "build" the
functionality necessary to perform the CRM functions) they would have to
share the revenue with the VAN.
Using a VAN is like using 1-800-COLLECT to make telephone calls, if
you have your own phone and you can dial a number it's cheaper and faster to
dial direct. Likewise, if you have a PC and you have an Internet connection
it's cheaper, faster and more reliable to send data direct,
instead of using a VAN.
Dick Brooks
Indeed, a VAN is not very much like an
ISP at all. Value Added Networks do not simply provide a connection. If
this were the case, they would just be called Networks. There's a
"Value Add" for a reason. VANs provide tracking and auditing
of successful vs. failed passages of data, they check for the
syntactical correctness of data, and proper nesting of envelopes. VANs
also provide logistical handling of masses of envelopes on users behalf.
They allow for one point of contact for the trading partner entity,
instead of leaving the logistic nightmare to the user. They provide logs
of results, proprietary processing, archiving and most of all they are
private secure networks. In this world where we utilize (or bastardize)
the Internet as our "VAN" who is to be held accountable when
something goes wrong, or when someone gets their hands on your data?
When was the last time your ISP was able to instantaneously
provide you with an error log for an email that wouldn't go through? Or
did you find out three days later?
Our customers say "We don't want to
throw out the baby with the bath water." But most importantly, with
the increased volume of characters that is expected with the
implementation of XML, how are all these companies (especially the small
ones) supposed to maintain EC data portals? How will they manage the
trafficking of information? Will they each have to maintain a server,
connected through a high-speed Internet connection in order to do EC?
One can just imagine the horror of the little "Mom and Pop"
sock manufacturers, that do a majority of their business with just a few
large retailers, having to implement an XML high speed Internet EC
Portal. Our experience tells us that to maintain a secure TCP/IP EC
portal of any scope at all, requires millions of dollars. How many
companies requiring Electronic Commerce can afford that? More over, why
would they bother when there are Internet based VAN solutions that cost
fractions of pennies on the dollar, and do provide the same logistical
handling and services that EC users have come to expect?
sorry jgl, couldn't help
myself!
Doug
My
intent, in comparing the traditional EDI with Internet EDI was to
highlight the subtle gap between these two.The gap ofcourse is
not that big,
that it cannot be filled.
What is a VAN
after all? It is nothing but an ISP if the gaps are
filled.Like
an old wine in a new bottle.
Ashwani
>From:
Doug Anderson <[EMAIL PROTECTED]>
>To:
[EMAIL PROTECTED]
>Subject:
RE: The need for speed: XML vs. Internet EDI
>Date: Wed, 19
Jul 2000 12:13:00
-0500
>
>Ashwani
>
>Interesting insights,
but I can't say that I agree with some of your
>conclusions on
how internet EDI is different from traditional EDI.
The
>internet is just a another transport
mechanism.
>
>1. We (Kleinschmidt) support any
protocol. Therefore the sender or
>receiver of the data
is not tied down to any one means of communication.
>We
>support TCP/IP if the customer wants it.
With the internet, if the ISP
>goes
>down you are
hosed, unless you have multiple ISP's (like we do). With
a
>VAN, if your ISP goes down you can still use the old
"legacy" means of
>communication like Xmodem, or
Zmodem. Most VANs support multiple
>protocols,
>you would have to check with your specific
VAN to see if they support the
>communication method that you
would like to use.
>
>2. Delay, interesting
comment. We don't delay data here at
Kleinschmidt,
>unless the customer would like us to deliver or
pick-up data on a scheduled
>service. And many do and
that is a service we provide.
>
>We have 4 state of the
art Tandems in production with a fifth being
>installed as we
speak. We have two production sites with multiple
phone,
>ISP's, power supplies with different voltages, UPS
(battery back-up not the
>motor carrier), diesel generators
etc. so that we have what we think is the
>highest reliability
in the market. Vs. the internet, depends on the
means
>of communication. Communication over the internet
where you get an
>immediate acknowledgment is good for time
sensitive data, but if you have a
>problem who do you
call? Using email can be very sporadic, sometimes
fast,
>sometimes you can get a message back hours later that
your message can't be
>delivered for
hours.
>
>Note that my earlier post to this message
board was delayed from yesterday
>afternoon to this morning,
so I reposted. Problem could be anywhere in
the
>chain. A process must be in place with each trading
partner, defining what
>to do if you don't get the
acknowledgement back after sending the data.
>Don't forget
that timing of the acknowledgement's return can be
different
>for each trading partner. And if that process
takes place after normal
>business hours does, your company
(and your trading partner and ISP) have
>someone available to
monitor that process 24 x 7? We monitor each of
those
>items (and so do some other
VAN's).
>
>3. Cost of communication. How do
you reach the internet? Do you have
>some
>magical way of getting the data from your
computer to the ISP or do you use
>some type of communication
line? Sounds to me like the cost for the
>physical
communication method is very similar. Don't know about local
or
>not. Here in Illinois businesses have to pay for
local calls like long
>distance calls, but the long distance
is cheaper. On top of that you can
>reach customers
(suppliers) via a VAN that want to use the internet and
>those
that don't want to without having multiple processes
running.
>
>4. Basically correct. You do pay
for service. And you generally get what
>you pay
for. How many folks own a car, maybe a Lexus, Mercedes,
or
>something similar with leather seats and power windows,
vs. a Yugo or KIA.
>Both the Yugo and KIA will get you to the
same destination, for a lot less
>money, but is the
reliability the same. What about the service you
receive
>when there is a problem? Your decision on the
car, your decision on cost
>vs.
service.
>
>5. I won't specifically comment on
this one since we don't sell software.
>However, we do provide
"in-network" or "outsourced" translation for
many of
>our customers. This is platform independent and
saves our customers money.
>We already are doing XML
translations for customers. Those customers did
>not
need to change anything on their side in order to communicate via
XML
>vs. "traditional" EDI.
>
>6.
My personal opinion. XML is EDI. It is a means of
formatting data
>that
>is being transmitted between two
something's, where the something's can be
>applications,
people or whatever. It (XML) has its advantages
and
>disadvantages, depending on the application. XML is
certainly more web
>browser friendly, but as for moving data
from application to application
>via
>the internet I am
not sure that it provides all the advantages sometimes
>touted
here.
>
>Doug
>
>Doug
Anderson
>Assistant Vice President Sales
Support
>Kleinschmidt Inc.
>450 Lake Cook
Road
>Deerfield, IL
60015
>847-405-7457
>847-458-5234 (home
office)
>847-945-4619 (fax)
>mailto:[EMAIL PROTECTED]
>http://www.kleinschmidt.com
>
>
>-----Original
Message-----
>From: ashwani madan [mailto:[EMAIL PROTECTED]]
>Sent:
Tuesday, July 18, 2000 6:05 AM
>To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject:
Re: The need for speed: XML vs. Internet
EDI
>
>
>Hi Steve,
>
>I agree with
discussion group members that XML won't make much of
a
>difference in transmisson time,because XML means just a
syntax/format
>change.Adding information about the data itself
(meta data) anyways flows
>with conventional EDI as well, in
terms of tags/codes.XML is a means to
>provide easy and
efficienct data processing capabilities.
>
>Just an
insight, how Internet EDI is different from conventional EDI
is
>summarized as below :
>
>1.Traditional EDI :-*
VAN based. Uses proprietary protocols.
>Internet EDI :-
Internet based. Uses TCP/IP protocol
>
>2.Traditional
EDI :-* Offline - Delay in delivery
>Internet EDI :- Online -
Instant delivery
>
>3.Traditional EDI :-* Expensive if
VAN is not local.May have invest in
>ISDN,Dialup,Leased
Line,etc. to reach the VAN network
>Internet EDI :- Can be
reached through normal Internet
connection.
>
>4.Traditional EDI :-* Billing is
generally by character or transaction.
>Internet EDI :- Flat
monthly fee (based on pipe bandwidth or connect
time).
>
>5.Traditional EDI :-* EDI Softwares are not
Platform independent. There has
>to be a different version for
installation on different OS e.g., Unix,
>windows
etc.
>Internet EDI :- Platform
independent
>
>6.Traditional EDI :-* EDIFACT, ANSI X.12,
TRADACOMS, etc are conventional
>EDI standards
>Internet
EDI :- XML is Internet oriented. Other conventional EDI
standards
>can be easily wrapped in
XML.
>
>Ashwani
>
>
>
>
>------
XML/edi Group Discussion List ------
>Homepage
= http://www.XMLedi-Group.org
>
>Unsubscribe
= send email to: [EMAIL PROTECTED]
>Leave
the subject and body of the message
blank
>
>Questions/requests: [EMAIL PROTECTED]
>
>To
receive only one message per day (digest format)
>send the
following message to [EMAIL PROTECTED],
>(leave
the subject line blank)
>
>digest xmledi-group
your-email-address
>
>To join the XML/edi Group complete
the form located at:
>http://www.xmledi-group.org/xmledigroup/mail1.htm
>
>
________________________________________________________________________
Get
Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
------
XML/edi Group Discussion List ------
Homepage =
http://www.XMLedi-Group.org
Unsubscribe
= send email to: [EMAIL PROTECTED]
Leave
the subject and body of the message
blank
Questions/requests: [EMAIL PROTECTED]
To
receive only one message per day (digest format)
send the
following message to [EMAIL PROTECTED],
(leave
the subject line blank)
digest xmledi-group
your-email-address
To join the XML/edi Group complete the
form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
------
XML/edi Group Discussion List ------
Homepage
=http://www.XMLedi-Group.org
Unsubscribe =send email to:
[EMAIL PROTECTED]
Leave the subject and body of the
message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the
following message to [EMAIL PROTECTED],
(leave the subject line
blank)
digest xmledi-group your-email-address
To join
the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
HTML>
------ XML/edi Group Discussion List ------
Homepage http://www.XMLedi-Group.org
Unsubscribe send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
|
