I am looking for some feedback from this
group as far as your perception of the useful-
ness of Access databases to solving business
needs. We are a small manufacturing company
that was looking into an all-encompassing ERP
(Enterprise Resource Planning) software system.
I have observed many attempted implementations of "all-encompassing ERP
software" which cost millions, and required years to "set up" even if no
"custom code" was involved. In many of those cases, my colleagues and I
were called in to create, enhance, or maintain an "old Access solution" in
some area that, purportedly, eventually would be covered by the ERP system.
And, in some of those cases other departments (looking out two, three, or
more years before their area of the business would be set up and handled by
the ERP), talked to our clients and hired us to create _new_ Access
solutions to their particular business needs to "tide them over."
And, some of those ERP implementations, done by "reliable, reputable
vendors," have turned out to be even longer than originally projected, and
others have simply soaked up so much money with no useful results that they
have been cancelled. Thus, I'd advise that anyone considering ERP solutions
hire the very best _disinterested_ advisors they can -- the vendors, and
especially management consultants with an ERP specialty will, as has already
been pointed out, be looking out for their own vested interests. Some may
not have a particular ERP product they are "pushing," but just be pushing
_some_ ERP solution.
The "make or buy" decision is as old as business, and this is just another
manifestation. If you can find commercial software that matches the way you
do business and solves your business issues, it is likely that you can buy
it for less than you can build it. But, if you have to adapt your business
to the software, you may find that the savings are illusory.
. . . I have hired an IT professional part
time who is of the opinion that developing different
Access databases to solve individual problems
is not the way to go.
If the person is knowledgeable about the business, and about your specific
needs, knowledgeable about all the software being considered, and has
performed a thorough analysis, then this conclusion may be correct. If any
of the qualifications I stated are lacking, then it is likely not a _valid
conclusion_.
That's not to say that a similar recommendation will not result if reached
by competent personnel, knowledgeable in appropriate areas, after a thorough
analysis, but that the one that not based on those standards just cannot be
trusted.
Giving the various personnel and departments
solutions that they are requesting in this piece-
meal fashion only enables them to carry on in
a way that ultimately will be cost prohibitive.
This may or may not be true. If your company has been successful so far,
operating as the personnel and departments now operate, it is unlikely that
introducing software that will assist them in that mode of operation is
suddenly going to make them ineffective, or be cost prohibitive.
1. Future maintenance of the system
will become a major problem.
As there have, apparently, been no detailed requirements, design, nor
implementation of "the system" (the individual applications), it is
impossible to determine -- sounds to me like "marketing hype scare tactics"
from someone who's looking out for their own vested interest.
2. By this piecemeal approach the true
development costs are not realized.
This may be true. It may also be true that "true development costs" for any
solution may "not be realized." Is there any evidence that appropriate
management and accounting procedures will not be followed for this approach,
but will be for some other approach? "Piecemeal" is an example of an
emotionally charged term intended to bias your view -- see above "sounds to
me" clause.
It may also be indicative that your IT professional has simply never had
occasion to observe or experience a well-planned, well-managed Access
database implementation. If that is so, then I'd also count that against
his credibility on the issues.
I've been involved in software development since 1959, and experienced both
utterly chaotic projects and well-managed projects. I assure you that
whether a project falls in one category or the other is NOT dependent on the
software used, nor whether it is phased or staged in separate parts which
are (more or less) integrated at the end.
In fact, the answer to a high rate of mainframe project failures in the past
was to break them apart into manageable-sized phases or stages ("piecemeal"
perhaps?) but to apply good planning and management techniques to each. It
also let the users stay involved with the development and get something that
would start to help them with their work much sooner.
And, a number of the hottest approaches in today's development world are the
antithesis of the "all-encompassing" approach required by massive ERP
implementations, where little pieces are built, reviewed, modified, and
released. Often the increments are released in just a few days or a week or
two.
3. He also feels that MS Access is not a
"robust" enough program to rely
upon for mission critical operations.
If this was his statement, without qualifying it regarding datastores as the
various experienced, respected Access specialists have done here, then your
"IT Professional" is one who either has, without carefully investigating,
_accepted_ half-truths from those with a bias against Access, or is someone
who is knowingly putting forward half-truths in a manner intended to bias
_you_ against Access as a database software development tool. In either
case, in my view, this advice alone would disqualify the individual as a
reliable consultant.
I think I understand where an IT professional
is coming from but I would like some
feedback from a group that uses MS Access
on a day-to-day basis to solve these very issues.
I hope, for that individual's continued employment status, that your
evaluation is more charitable than mine would be just based on what you have
said.
Since 1994*, I have used Access daily, developing business database
applications for a variety of clients. Most, but not nearly all, of those,
used an ODBC-compliant server database as the "backend" or "data store."
Sometimes that was to accomodate performance for larger user audiences (up
into the low hundreds of users), but often it was for reliability and
recoverability.
* in 1993, all the Access applications I
developed were individual applications,
but with the advent of Access 2.0, it
really "took off" in the business world
Some of these business database applications would be considered by their
owners (my clients) to be "mission critical" and, if they so considered it,
we would carefully consider using a server database as a back end. But, in
other cases, carefully considering their criteria and their needs for
recoverability, those were developed as multiuser Access applications with a
shared Jet backend. As Ross Perot said, when he was running for President,
"The Devil's in the details." All we can do in (even such a lengthy)
newsgroup response is to advise you what you should consider and what may
appear to be unfounded claims and bad advice.
If you have the same team of Access developers doing the departmental
databases, and direct them ahead of time, they can likely create databases
that can easily exchange data, or perhaps share it in a common backend
datastore (whether Jet or a server DB).
Any feedback would be much appreciated.
I hope we have been able to be helpful and I wish you much success in
whatever approach you decide to follow.
Larry Linson
Microsoft Access MVP
