Re: PARADOX product life cycle
- From: "Rodney Wise" <NSpamPlease_rodney1@xxxxxxxxxxxxx>
- Date: Sat, 25 Feb 2006 15:06:57 -0500
Roy,
I agree with you... your scenario points out "real" issues. However...
those doctors depending on the internet to conduct business, could not
conduct business for several weeks after the hurricane we experienced.
Internet, Telephone and Cable TV were all down in some cases for over a
month.
I believe there needs to be a combination setup. Data specific to a
Doctors operations needs to be maintained locally and the application
software needs to maintain data synchronization and application updates
seamlessly in the background. If the WAN or Internet is not available, then
the system should be able to run in a "crippled mode" locally. This
"crippled mode" would be one where business could continue to function with
a reduced feature set and update the remote server automatically once an
Internet connection was restored.
If a doctors office depends on your software for the core functions of their
business.... and an on-site IT staff is not practical.... then the software
and system must be as "self-healing" as possible.
Why not consider using a network storage device? One of the inexpensive
Linux OS computers designed to operate as a network file server.... They are
pretty dependable and can be serviced remotely.
In addition... you should insist that your software is sold and installed
ONLY through a network of trained value added vendors (VARS).... All VARS
who sell your solutions must successfully complete a training course (which
you provide at a price)... During this training course, you instruct them
how to install and maintain your software... you also provide a list of
"Approved Hardware" and "Approved Hardware Configurations". These Vars
become the endusers first level for service. The endusers never call you
(the software developer)... only the Vars contact you if there is a problem
they can't fix.... In which case, if the installed Hardware at the problem
site is not approved.... or the Hardware configuration is not approved...
you then tell your Var to correct it before you can provide any tech
support. If a particular Var seems to violate this list of requirements
often, then you drop them as a Var. By not following your instructions,
they are giving your software a bad reputation... re-assign the enduser to
another Var.
If a Doctor gets a hold of your software through some other means (the
purchase of another Doctors business or an auction for instance), then you
direct them to their local Var (if they call you). This prevents the semi
tech savvy brother in-law from installing your software and creating
problems for you and everyone else..
You can have complicated systems running in offices without a full time IT
department... but they do need:
1. Software that is not finicky.
2. A "known system configuration".
3. A trained VAR to service them.
--
....
`·.¸¸.·´¯`·.¸¸.·´¯`·-> rodney
.
- Follow-Ups:
- Re: PARADOX product life cycle
- From: Doug Kanter
- Re: PARADOX product life cycle
- From: Roy F
- Re: PARADOX product life cycle
- From: Rodney Wise
- Re: PARADOX product life cycle
- References:
- PARADOX product life cycle
- From: rhug
- Re: PARADOX product life cycle
- From: Larry DiGiovanni
- Re: PARADOX product life cycle
- From: rhug
- Re: PARADOX product life cycle
- From: Rodney Wise
- Re: PARADOX product life cycle
- From: Larry DiGiovanni
- Re: PARADOX product life cycle
- From: janM
- Re: PARADOX product life cycle
- From: Roy F
- Re: PARADOX product life cycle
- From: Jean Friedberg
- Re: PARADOX product life cycle
- From: Rodney Wise
- Re: PARADOX product life cycle
- From: Roy F.
- PARADOX product life cycle
- Prev by Date: Re: Adding calculated field to report
- Next by Date: Re: PARADOX product life cycle
- Previous by thread: Re: PARADOX product life cycle
- Next by thread: Re: PARADOX product life cycle
- Index(es):
Relevant Pages
|
Loading