Anthony:
Your posting really cracks me up. Keep it up. You made my day!
Thanks,
Benita Delfin CPA
----- Original Message -----
From: "Beecher, Anthony" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 16, 2001 11:27 AM
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/
