SSA Interview -- BPCS-L

"QUOTE: We, as a company, have a policy of not sunsetting any product.
UNQUOTE
perhaps a misconception on my part ... I thought many versions of BPCS had

already been sunsetted ... does this mean that BPCS will never be
sunsetted, but they will continue to sunset some versions, or does it mean

that all current versions can continue to infinity?"

Al,

SSA GT stopped sunsetting their BPCS releases as soon as Mike G. took over
as CEO. We were concerned about that very subject two years ago when we
attended the 2001 SSA GT Conference in Boca Raton, FL. We had (and still
have) two environments of 4.05 CD and were making budgetary arrangements
to convert them to the latest version (6.1.02 at the time) due to
anticipating a sunset announcement, but got a big surprise instead. Mike
took the stage at the conference and said sunsetting had changed - as long
as someone was willing to pay OGS for a version and/or platform they will
keep it viable. However, as fewer people are paying OGS on a release the
level of service will go down as the amount of OGS fees per customer goes
up. Basically the OGS fees received for each version will have to support
the activities to keep that release viable. Some may view this as a
penalty to be on less utilized platforms and/or versions, but I view it as
a well thought out plan. SSA will not force you off a version, but will
charge you higher fees to adequately maintain the version. If you don't
like the fees for that version and/or platform, move to one of the others
for better support, functionality, and fee structure. The choice is yours
- not forced upon you by SSA.

With that same mentality, at the same meeting he also said that versions
and platforms which were in the majority of the user base would be
addressed first with new functionality and then that functionality would be
evaluated for release on other versions and/or platforms on a case by case
basis.
Again - the ability to make money driving which versions and/or platforms
get functionality increases. Prior SSA management wanted their software
to run on everything without thinking about the financial implications of
such a decision. Back then, the complaint was that OGS dollars were
funding the silliness of creating a UNIX version of BPCS - which they were
and SSA didn't get very much of a return on that investment and neither
did those of us on the AS/400 platform. With new mentality at SSA GT of
each version/platform needing to support itself, I would not want to be
running BPCS on any platform other than the AS/400 since 95% of the user
base is on it. Understand that this is not a comment on the capabilities
of the AS/400 versus other platforms - it is the fact that other platforms
will have to pay a more aggressive OGS fee structure as the user base
shrinks, may not see additional functionality unless the business case is
made, and will see a lower level of support since fewer resources would be
devoted to a such a small percentage of the user base.

On your comment on AS/400 upgrading and BPCS key generation - I suspect
people are looking to upgrade their box for variety of reasons. For some
it may be due to migrating to another release of BPCS. Others may have a
growth curve that is forcing them to increase their box capabilities. But
I suspect the two main drivers of companies upgrading their AS/400s are
IBM's method of OS/400 releases and hardware maintenance cost. First -
IBM has forced AS/400 obsolescence with their OS/400 releases. Each new
release is not supported on older AS/400s and they do not support more
than two releases of OS/400. If you want to be current on your OS/400
release and receive software maintenance, you are forced to upgrade your
AS/400 every so often. Second - the hardware maintenance cost of older
AS/400s is higher than new AS/400s. At some point, it is better to invest
those monies in new hardware rather than keep the old functional. At my
company, our analysis showed that replacing our current 5 AS/400s with a
new AS/400 that has more interactive and total CPW, more DASD, and more
internal memory was cheaper and would break even at the two year mark if
purchased and day one if leased.

Timothy C. Luce, MBA, CPIM
Director of Application Development
ESAB - North America
tluce@xxxxxxxx
--------------------------------------------------------------------------------------------------------------------
This communication and any files transmitted with it contain information which
is confidential and which may also be privileged. It is for the exclusive use
of the intended recipient(s). If you are not the intended recipient(s), please
note that any disclosure, copying, printing or use whatsoever of this
communication or the information contained in it is strictly prohibited. If you
have received this communication in error, please notify the author and then
delete the e-mail together with any copies of it.

Information or opinions in this message that do not relate to the business of
ESAB shall be treated as neither given nor endorsed by it. ESAB does not
accept liability for any changes which may occur in transmission due to
network, machine or software failure or manufacture or operator error. Although
this communication and any file(s) transmitted with it are believed to be free
of any virus or any other defect which might affect any computer or IT system
into which they are received and opened, it is the responsibility of the
recipient to ensure that they are virus free and no responsibility will be
accepted by ESAB for any loss or damage arising in any way from receipt or use
thereof.