Hi, Dave & Jeff.

That's why ERP vendor salesman makes a big bucks, 
sell those technical products to non technical management guys 
to make them to believe CAN ERP software will do everything that 
business need, illusion sellers.

Later, they spent a big bucks plus more big bucks for implementation on new
off shelf software product then find out It won't do stuff, the salesman sold for
to do, now management cover up start...

What they really needs is cheap GUI product on front and good ODBC driver.
to facelift on front end...

Cheap GUI ->MS Office(Access,Excel), 
Good ODBC driver (ODBC/32 from Minisoft).

Cheers

Peter Chong
Sr. ERP/MRP Analyst.
L3 Communications
714.956.9200 x 363
http://www.powerparagon.com

>>> Jeff Kell <[log in to unmask]> 01/24/00 09:36PM >>>
David Gale wrote:
>
> I think Richard raises a good point. The project is co-founded from
> the beginning. A marriage of disciplines, both that of your business
> department, and that of the IS department.
>
> I have seen many projects 'managed' by managing the manager. It
> takes the excellent communications skills that Richard suggests. The
> point is, who takes ownership of the project?

This is all too true.  Third-party packages on a grand scale (ERP, Baan,
Peoplesoft, Banner, etc) are most often marketed to non-tech
administrators.  The vision is that you buy the software off the
shelf, they provide maintenance, you can relocate / reassign / outsource
your IT infrastructure.  Save big bucks.

They don't mention the administrative overhead, ignore the probable
change of platform/DBMS/development tools/utilities, evade the issues
which are unique to your business policies that they likely don't
support, and other issues.

IS/IT/whatever technical people need to be involved to point out issues
that may affect your specific infrastructure.  Network demands,
client platform and minimum requirements, and multiple points of failure
in a multi-tiered client/server environment need to be addressed.
Typical management has an ostrich mentality to this, they don't know and
don't want to know, so they stick their heads in the sand.  If the
project stumbles, in the worst-case scenario the finger is pointed at
IS/IT incompetence, or unco-operation, or simple resistance to change.
This can bleed down to the functional areas as
well.

A brand new implementation with no precedent - sure, you have no metric
to measure against and blindly follow the vendor like so many lemmings.
But replacing an existing system has to have proven advantages that make
business sense.  A pretty GUI is worthless if it is unreliable,
bug-ridden, inefficient, or doesn't meet your business
needs.  Moving to Unix/NT makes no sense for the same reasons plus
the additional system administration and software maintenance often
required by such systems.

In the "old days" IS/IT did tend to dictate business practices based on
what they could produce, which admittedly had it's faults.  But
currently we face a 180 degree shift where non-technical management
is dictating what IS/IT should do.  Neither paradigm works.

Hopefully both sides will see the light and we can come up with a
solution that satisfies the real business needs for the end-users while
remaining a solid, reliable platform that IS/IT can support
and enhance to benefit the enterprise.

Jeff Kell <[log in to unmask]>