<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?>
With your ample experience, Mr. Divoky, certainly you know as well as the
rest of us that no solution escapes these needs that you mention.
Consider that when you manage your own source code:
- Your enterprise is not limited to whatever a 3rd party executable is
capable of (or incapable of...)
- You don't suffer forced upgrades. ("We're not supporting that version
anymore...")
- Your capability to debug a situation is increased.
- Your flexability is not limited to the software vendor's whim.
- Support is not limited to when they can service you.
- You don't have to spend efforts proving to product support that there IS
a problem on their part that they need to address
- You don't pay for what you're not using.
- You don't pay incrementally for what you are using.
In my opinion, the development of customized software solutions can provide
competetive advantage and if managed properly, a cost savings. But I
concede that the proper solution depends on the initial requirements.
Anthony Beecher
-----Original Message-----
From: Jim Divoky [mailto:[EMAIL PROTECTED]]
Sent: Saturday, August 18, 2001 11:50 AM
To: [EMAIL PROTECTED]
Subject: Re: Internet vs VAN vs capabilities and cost = Business Decis
ion.
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/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
