Michael,
Your message below is one of the most reasoned and rational thought process
articulated to this list since its inception. Kudos and congratulations!
This is exactly the analysis process we try to encourage our clients to
follow before leaping off the cliff to buy the latest hyped technology.
This is great! I plan to save your message for future reference - it can be
applied to many scenarios, and not just the VAN vs Internet issue for EDI.
It has extremely broad applicability to the entire challenge of a stragegic
approach to electronic business messaging - in all of its guises and
formats!
Good job! Thanks!
Rachel Foerster
Principal
Rachel Foerster & Associates, Ltd.
Professionals in EDI & Electronic Commerce
39432 North Avenue
Beach Park, IL 60099
Phone: 847-872-8070
Fax: 847-872-6860
http://www.rfa-edi.com <http://www.rfa-edi.com>
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
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
