Tom makes some valid points, but I have to wonder how the justification for
the additional expense of the migration should be made.

If I were running a manufacturing plant, knew that I had a stable working
machine (and application complete with customizations), and were looking at
it solely from the cost management standpoint, any analysis would show me
that prudent monitoring of the secondary market and diligent backups with a
well thought through disaster recovery plan would make this a nobrainer.

If I don't have millions of dollars to spend on a new system (who does, and
yes it would cost that to migrate a large shop), but I do have a system that
works well now, plus companies lining up to take the support dollars from HP
in both the hardware and software arenas (i.e. they have a good business
reason to be there when I need them), a recognizable windfall on the
secondary market for replacement parts in the near future (i.e. a tolerant
supply of used parts that will become *less* expensive through the mid
term), and a comfort level both with my current application and with
expected changes or needs for expansion....tell me how I get anyone to give
up their portion of the budget to reinvent the wheel?

I work in the credit union industry and will migrate to HPUX with the
remainder of the Summit clients who don't jump ship, but also intend to keep
our 3000(s) running for some time thereafter.  Were I not an institutional
user (i.e. my software vendor is actually driving the migration/homesteading
decision for me), I would have to look at the argument I presented above,
and I don't think I could argue well for the migration anytime soon.  When
the economy turns around, maybe, but for now and the next two years?  No
way.  The reasonable expectation that I can get three to five years out of
my system, or (darn it) have to buy a more powerful one on the secondary
market much more cheaply than I can get today, or just get a second machine
identical to what I have and run half my workload on each, makes staying put
the best decision I could make for now.

Just my $.02,
Rs~

Russ Smith
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * *
The opinions expressed in this email are mine, and are not meant to reflect
those of any other party.  The subject matter herein is intended solely for
the named recipient(s) of this email.  Spellcheck cancelled.  Your mileage
may vary.  Look both ways and hold hands when you cross the street.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * *




----- Original Message -----
From: "Tom Tont" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, August 19, 2003 8:44 AM
Subject: Re: [OPENMPE] Customer Eval


> I don't think it is so much the expense of keeping the 3000 running.  That
> is the easy part because the reliability and the low cost of replacement
> parts if needed.  I think the expensive part (at least in the eyes of a
CEO
> or CFO) is the risk of losing the company's competitive advantage.  For
> example: a manufacturing company using a software package (lets just use
> ManMan for this example) is not only facing a platform that will
eventually
> be outdated in the ability to keep up with transactions per second
(compared
> to what is available on other platforms) but also faces the problem of
using
> a solution that has limited updates.  Yes, the machine still does what it
> was purchased to do (and still does it well) - and yes, the software with
> all the tweeks and custom code works for the organization; however, the
> market and technology change faster than we would sometimes like.  Just
> doing what has always been done simply because it works is a death wish.
> The competition (especially in manufacturing) is always looking for ways
to
> speed up transactions, increase the network bandwidth, process decision
> making reports faster (sometimes several hours faster) and to increase
> productivity based on all the above.  The cost of another platform and
even
> the cost of a new application is small compared to the possible cost of
> closing the business due to not being able to keep up with the
competition.
> I know it sounds awful to say "you should keep up with the Jones'" but to
an
> extent it is true.  Okay, yes we offer a total  ERP/MRP solution that runs
> on HP-UX but I came from the 3000 world and can honestly say that the
always
> up - always on message carries over to HP-UX.  We have helped customers
make
> the move and it is not as painful or costly as one might think (with a
good
> plan).  And yes, the 3000 can still run in the background if it makes
> everyone feel better or to keep historical data.  The point I am trying to
> make is that you have to stay competitive to keep the overall cost of
doing
> business manageable.  The HP3000 users I spoke with at HPWORLD said they
> would run the 3000 till the bolts fell off and I can appreciate that;
> however the few C-Level (CEO/CFO) people I spoke with are concerned about
> the risk of doing that.  I think there is a serious difference of
viewpoints
> at the different levels of the organization.  Is this based on experience,
> fear or concern?  I am open to other viewpoints.
>
> Tom Tont
> The Newman Group
> ----- Original Message -----
> From: "John Lee" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Tuesday, August 19, 2003 10:53 AM
> Subject: Re: Customer Eval
>
>
> > I don't understand what could be expensive about keeping a 3000 running?
> >
> > John Lee
> > Vaske Computer Solutions
> >
> > :
> > >Gavin writes:
> > >
> > >>
> > >>  But for most people it *isn't* a long term solution.  Ultimately
most
> will
> > >>  move to something else, but many will do it only because they're
> forced to
> > >>  by changes in their business or because they can't afford to keep
the
> 3000
> > >>  running any more.  Quite a few (many of the smaller customers) will
> > finally
> > >>  make the transition catastrophically when the 3000 dies and can't be
> > >>  resurrected, or the backup tapes can't be read, or it turns out that
> the
> > >>  last backup was done in 1995 :-)
> > >
> >
> > >
> > >