Wow, I wish I could be as professional as you are in your response, Ginny. My first
response was not so refined.
I have implemented many VAN connections as well as several Internet EDI connections
(and once even a brand new VAN!)
over the years and that included a number of sites that paid my employer $1500 a day
plus expenses just to get a
bisynch modem installed and working properly. These were not small companies, never
under several billion dollars in
sales. I doubt very much if they were in a position to design there own EDI network
as perhaps Mr. Beecher can.
Assuming I have the expertise and the knowledge to create a secure Internet solution
from scratch for a client, who is
going to maintain it, upgrade it, and enhance it as security & transfer standards
change and bugs are discovered in
the standards upon which the solution was built?
Suffice to say, there is definitely a secure place in the electronic commerce industry
for VANs and Internet EDI
software providers.
Jim Divoky
EC Solutions, Inc.
PO Box 667
Kent, OH 44240-0012
Providing EDI/EC Consulting and Contracting Services
Mobile 330-606-6826
Pager 877-282-3426 (Toll free)
Email [EMAIL PROTECTED]
To send short message to mobile phone:
email [EMAIL PROTECTED]
----- Original Message -----
From: "Ginny Crane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 17, 2001 8:12 AM
Subject: Re: Internet vs VAN vs capabilities and cost = Business Decis ion.
> Anthony,
>
> Thanks for the follow-up. I definitely think we have different priorities
> and realities when it comes to building company dependant, industrial
> strength systems that manage mission critical data.
>
> Thank you for sharing your opinions and views.
>
> Highest Regards,
>
> Ginny
>
> ----- Original Message -----
> From: "Beecher, Anthony" <[EMAIL PROTECTED]>
> To: "'Ginny Crane'" <[EMAIL PROTECTED]>
> Sent: Friday, August 17, 2001 6:46 AM
> Subject: RE: Re: Internet vs VAN vs capabilities and cost = Business Decis
> ion.
>
>
> >
> >
> > -----Original Message-----
> > From: Ginny Crane [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, August 16, 2001 5:41 PM
> > To: Beecher, Anthony; [EMAIL PROTECTED]
> > Subject: Re: Re: Internet vs VAN vs capabilities and cost = Business
> > Decision.
> >
> >
> > Anthony
> >
> >
> > These items include 24x7 mailboxing,
> > - leave you machine on all night
> >
> > industrial strength processors,
> > - as if that meant something...
> >
> > communications devices,
> > - duh!
> >
> > audits/logging & tracking, reporting, redundancy & network backups
> > - you don't have these things without a van?
> >
> > and the most expensive piece of all - customer service.
> > - If you didn't have people like Sterling mangling your data in the first
> > place, then you wouldn't need service.
> >
> > This
> > Value Added "stuff" costs alot of money so please do not be fooled by the
> > adage of the Internet being free. You simply move the VA from an outsource
> > type of solution to an in-house problem with hard core dollars associated
> > with it.
> >
> > - What's the problem? You build a good system once and it saves you money
> > over and over again which, I might remind you, is the goal of EDI. They
> way
> > you've described it a Van is for companies that don't want bother with a
> > quality implementation
> >
> > Anthony
> >
> >
> >
> > The person who created the Hypothesis email (albeit 100% correct or not)
> hit
> > it with a nail on the head when they said to VAN or not to VAN is solely
> up
> > to the type of processes a business wants to take on for themselves.
> >
> > Respectfully,
> >
> > Ginny Crane
> > Easylink Services
> > EDI Business Manager
> > 303-750-4527
> > [EMAIL PROTECTED]
> > www.easylink.com
> >
> > ----- Original Message -----
> > From: "Beecher, Anthony" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, August 16, 2001 12:27 PM
> > Subject: Re: Internet vs VAN vs capabilities and cost = Business Decision.
> >
> >
> > > Good lord! What is all this garbage?
> > >
> > > A perfect example of the shortcoming of EDI - get two overzealous
> > > sophisticates involved in your decision making process and you get
> bogged
> > > down in a bunch of perfumed garbage.
> > >
> > > The internet instead of the VAN is a no brainer! What company doesn't
> > > already have some internet connectivity? Why pay a cost per character
> when
> > > you can do it for no cost per character?
> > >
> > > If I had used VAN instead of internet, my monthly VAN costs would have
> > been
> > > about $50,000. Using the existing internet connection, the van fees were
> > 0$.
> > >
> > >
> > >
> > > Anthony
> > >
> > >
> > > -----Original Message-----
> > > From: Stephen O'Shaughnessy [ mailto:[EMAIL PROTECTED]
> > > <mailto:[EMAIL PROTECTED]> ]
> > > Sent: Thursday, August 16, 2001 1:21 PM
> > > To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> > > Subject: Re: Internet vs VAN vs capabilities and cost = Business
> Decision.
> > >
> > >
> > > I'm afraid your use of hypothesis testing is flawed. It is of crucial
> > > importance which hypothesis is used as the null. You can't just flip a
> > > coin. The null hypothesis looks to find just that ONE instance that
> > > disproves your hypothesis. The alternative is to find EVERY instance
> that
> > > proves the hypothesis. A formidable if not impossible task.
> > >
> > > The alternative hypothesis will never actually be tested. It is only
> > > inferred based on the results of testing the null hypothesis. If you
> find
> > > the one instance, you disprove your hypothesis. If you don't, well, it
> > > proves nothing.
> > >
> > > The case, as presented, is really two hypotheses: VAN's are less
> expensive
> > > and Internet is less expensive.
> > >
> > > For the current discussion we are wondering if moving to the internet is
> > > less expensive than the status quo of using VAN's to transact business
> > > documents. The null hypothesis always states the opposite of what you
> are
> > > trying to prove. In this case internet is less expensive. Again, this
> is
> > > because it's easier to find one example that disproves the hypothesis
> than
> > > the many required to prove the hypothesis. In my opinion our test
> should
> > > say:
> > >
> > > (Ho: is the standard notation for a null hypothesis)
> > > (H1: is the standard notation for the alternative hypothesis)
> > >
> > > Ho:The use of VAN's is the least expensive method of transacting
> business
> > > documents electronically.
> > > H1: The use of VAN's is the same or more expensive than other methods of
> > > transacting business documents electronically.
> > >
> > > The independent (the one we can manipulate) variable is methods used to
> > > transact business documents electronically.
> > > The dependent variable (the one we would like to measure) is cost.
> > > Unless you want to delve into multi-variate statistics, all other
> > parameters
> > > must remain the same (see below).
> > >
> > > Now all we have to do is find one method that is less expensive than
> using
> > a
> > > VAN. If we do we can reject the null hypothesis and accept the
> > alternative.
> > > Note: This does not prove the alternative, just that we couldn't find
> > > statistical significance to reject it.
> > >
> > > This may sound like a bunch of semantics to you but it is vitally
> > important
> > > if you don't want to be duped by statistics. Statistics don't lie. But
> > our
> > > ignorance, fueled by zealous sales people, can be used against us. From
> > > Michael's hypotheses it is very easy to prove both. Most ISP are less
> > > expensive than VAN's. But given the right set of additional parameters
> > and
> > > the VAN's will come out ahead. In short the original hypotheses are
> > useless
> > > unless you are trying to sell something to an unsuspecting buyer.
> > >
> > > What's key to this discussion is whether or not all the other parameters
> > are
> > > the same. I fear our hypotheses are too broad to be tested. At least
> the
> > > cost is not a simple access fee. There are many other costs which must
> be
> > > factored into the test. Michael did a good job of showing us just how
> > many
> > > other parameters are involved.
> > >
> > > As Michael noted, to make an informed decision an number of things,
> unique
> > > to your business, must be looked at. In general internet transactions
> are
> > > less expensive. They offer a wider variety of formats and options.
> But,
> > > unless you are in a position to take advantage of these other options,
> the
> > > VAN will be the best deal.
> > >
> > > -----Original Message-----
> > > From: Michael Burbury [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, August 15, 2001 11:35 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Internet vs VAN vs capabilities and cost = Business Decision.
> > >
> > >
> > > Hi there all,
> > >
> > > Due to the number of responses I have received on my previous email, I
> > > believe it would be worthwhile to start a new thread to discuss the NULL
> > > versus ALTERNATE Hypothesis of Internet versus VAN service provision,
> > costs
> > > and capabilities, and therefore ones sound and quantified Business
> > Decision.
> > >
> > > As discussed previously, I offered two Hypothesis.
> > >
> > > The Null Hypothesis:
> > >
> > > "Using the Internet to transact business documents is cheaper than using
> a
> > > VAN."
> > >
> > > Of which the Alternate Hypothesis is:
> > >
> > > "Using a VAN to transact business documents is cheaper than using the
> > > Internet."
> > >
> > > The order of these two Hypothesis is not of importance. I could have
> > > flipped a coin and ordered them accordingly and the outcome would not be
> > any
> > > different. There are only three possible outcomes:
> > >
> > > 1. The NULL Hypothesis is true
> > > 2. The Alternate Hypothesis is true
> > > 3. Neither Hypothesis is true - the costs are the same.
> > >
> > > There can be no other outcome to the proposed Hypothesis.
> > >
> > > The outcome of your research into the two Hypothesis will result in a
> > sound
> > > and quantified Business Decision.
> > >
> > >
> > > It has already been proven that the following Hypothesis is true:
> > >
> > > Transacting Business documents in Electronic Format can save money,
> > > streamline business processes and reduce the number of defects on each
> > > opportunity. The opportunity for defect can be anything from re-typing
> > data
> > > from a form to supply of the correct "stuff" to a customer on time and
> > > within budget - to billing the correct amount. An opportunity for a
> > defect
> > > can be any piece along the process of performing the desired business
> > > outcome. By reducing the number of possibilities of a defect, one can
> be
> > > assured it will impact the business bottom line significantly (you can
> > tell
> > > I work for GE <grin>).
> > >
> > > Now, working on these two Hypothesis statements above, one needs to
> weigh
> > up
> > > all the factors that impact the choice to be made.
> > >
> > > For example:
> > >
> > > What computing environment and capabilities do I currently have?
> > > What computing environment and capabilities do my trading partners have?
> > > What is the Business computing strategy?
> > > What is my Industry computing strategy? <- Important one that is often
> > > neglected.
> > > Do I have sufficient in-house skills to complete the project myself?
> > > Should I outsource the project to a provider of service whom has
> specific
> > > skills I require?
> > > How do I quantify if I should do it in-house or outsource the project?
> > >
> > > Each business will have it's own answers to these types of
> "Brainstorming"
> > > questions and there is usually many more than what I have listed above,
> > I'm
> > > just trying to give you a starting point. I would recommend that you
> > > consult with your trading partners to also find out what their computing
> > > strategy is, if they have one. This will all aid in your calculations
> on
> > > how the project will proceed.
> > >
> > > One you have defined some background as to the possibilities of your
> > > project's scope, you may now define a "List of Requirements".
> > >
> > > For example:
> > >
> > > I require that 100% of my trading partners communicate electronically.
> > > I require a minimum 99.7% uptime for the service provision.
> > > I require data formats to be compatible with the solution proposed and
> my
> > > trading partner's solutions.
> > > I require the solution to be secure and free from possible abuse.
> > >
> > > Now you have your list of requirements, you can then move forward and
> > > "tender" for a quotation of service provision.
> > > This may be in-house or may be from an external consultant or may even
> be
> > > from a friend and should be from all of them.
> > >
> > > From the tender(s), one must break down all pieces associated with the
> > > service provision and costing(s) associated with each piece until you
> > > finally get to a "cost per transaction". These pieces should include:
> > >
> > > Network and redundancy or availability guarantees and fees/penalties.
> > > Software, upgrades, annual maintenance and consulting fees.
> > > Internal resource utilization time and training.
> > > Infrastructure requirements.
> > >
> > > Again there will be many more items of consideration.
> > >
> > > Now, going back to the Hypothesis, one will be true for YOUR business
> and
> > > one will not. How you come to this decision will be based on the
> > questions
> > > you ask and the capabilities of your business and that of your trading
> > > partners.
> > >
> > > To best describe this, I will provide an example in which the resultant
> > > answer was that the NULL Hypothesis was true and the Internet proved to
> be
> > a
> > > more cost effective medium of service provision.
> > >
> > > A specific "closed community" wished to form an alliance to trade
> business
> > > documents electronically. The meaning of "closed community" is that
> these
> > > businesses did not require the trade of business documents outside of
> the
> > > closed group of partners. The community itself was of reasonable size
> of
> > > 500 partners. The 500 partners mostly had no computing environment or
> > > strategy and were in areas of poor communications infrastructure (ever
> > been
> > > to Papua New Guinea or Fiji?). The requirements of the trading partners
> > > were minimal and most already had access to the Internet for Web
> browsing
> > > and email. Security was important for the business transactions, but
> the
> > > consortium of partners chose to use the least expensive security option
> > > (being PGP Email). Secondly, the reliability of the solution was not
> > > paramount as if email systems failed, a reversion to FAX was used. In
> > house
> > > integration to back end systems also was not paramount for the project
> for
> > > each partner as most did not even have back end systems and relied
> heavily
> > > on manual processes.
> > >
> > > So as you can see, each business case will make one of the Hypothesis
> true
> > > and one not or it may in fact come out as being equal in cost of
> > provision.
> > > If it does come out equal, how do you choose? If two cars you like are
> > > identical in price and services, which car would you choose to buy?
> Brand
> > > name? Reliability? or even a recommendation from a Friend? If the two
> are
> > > equal, you will need to "drill down" into the long term costing of
> > provision
> > > of service, reliability and features. It should also provide a means of
> > > "future proofing" your solution so that new technology can be easily
> > > incorporated. It may be EDI and XML over SMTP S/MIME or HTTP/S today,
> but
> > > who knows what is coming in the future? Maybe a method of monitoring
> > human
> > > thoughts for patterns so that businesses know when to target specific
> > > services or products to your "thoughts of improving your specific
> > > requirements?" Who knows?
> > >
> > > As always, I welcome feedback and will happily assist in helping you
> > > determine what is best for your situation.
> > >
> > >
> > > Best Regards,
> > >
> > > Michael Burbury
> > > GE ecXpress
> > > System Administration
> > >
> > > My views are not those of the company I work for and are purely my own
> > views
> > > on this subject. Please do not think that because I work for a VAN, I
> > might
> > > be biased towards the ALTERNATE Hypothesis. I take a passive stance
> that
> > > states that either Hypothesis may be applicable to a specific
> requirement
> > > definition and will mostly be equal in cost of provision.
> > >
> > > =======================================================================
> > > To contact the list owner: mailto:[EMAIL PROTECTED]
> > > Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
> > >
> >
>
> =======================================================================
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
