Re: Why did you choose BPCS -- BPCS-L

Dan,

In a message dated 6/9/99 3:27:11 PM Eastern Daylight Time, 
DThomas@lpw-mdi.com writes:

> I've followed this mail list for about five months now and most of the
>  comments seem to be rather negative about performance and stability.  I
>  realize these forums are not always indicative of the entire user base, but
>  I'm curious what is driving users to choose BPCS or even stay with it.  

Once upon a time, in a galaxy far, far away, there was a package called BPCS. 
 Rumor has it that Roger Covey wrote it in his garage over a weekend, and the 
giant entity know as SSA has been maintaining it ever since.  Up through 
version 4.05, BPCS was extremely stable and far outpaced its competitors in 
the AS/400 market in terms of stability, useability, and functionality -- 
especially for process control manufacturers.

Then a new management team (music - dom, dom, dom, dom de dom, dom de dom) 
declared the AS/400 dead and that SSA needed to port BPCS to UNIX.  Said 
management team decided to port BPCS into their CASE tool, AS/Set, because 
AS/Set would soon generate C code instead of it's usual RPG and it had the 
GUI IWS front-end.  Consideration was not given to the fact that they'd been 
working on IWS for over three years and it still did not function properly.  
After purchasing high-powered PC's for their development staff, SSA 
discovered that IWS was not useful for the BPCS conversion because it did not 
support message ID's on screens to support international language 
development, so pure AS/Set was used instead.

ADK, UDK, UDK-U, and whatever else they decided to call it never generated C 
code.  BPCS 5.x was 4.05 ported into AS/Set ADK, except that SSA was not 
satisfied with simply rewriting the code and seeing if it worked -- no, we've 
got to add functionality as well so that we can't tell if the rewrite or the 
tool or the enhancements caused the problems that they had.  Then, SSA 
decided that ADK, which had previously been widely available, would be taken 
off the market for all but BPCS users.  The "powers that be" then decided 
that BPCS needed GUI so, without fixing the problems that arose with the 
advent of V5, they created V6 by front-ending "green screen" panels utilizing 
a "screen scraper" called ODO and again re-writing OE and accounting modules 
calling it CEA and COM.  The UNIX port was achieved by utilizing a 
"skunkworks" utility that converted ADK RPG into C.

Tragic, but no, this was not yet enough.  We had to have DOCA.  Unable to get 
IWS working properly after now five years, yet even newer managers thought 
that they could write a CORBA compliant tool FROM SCRATCH in less than a 
year.  First introduced at the Fall '95 AS/Set user's group meeting, ODW 
(NEWI, then ODW again) has yet to be released to the general public and when 
it is will be available to BPCS users only.  Just what we need, another 
friggin' proprietary development tool for BPCS.  If you're lucky enough to 
get ODW, you then have to purchase NT and MS/SQL Server.  JAVA's looking 
better all the time.

These moves have led to phrases such as "What do you expect from a company 
that's ASS, backwards", "BPCS - Big Pile of Chicken, uh, Stuff", and my own 
favorite "BPCS - Better Programs Coming Soon" from the user community.  New, 
new, new management at SSA has attempted to right past wrongs and I must 
admit that helpline has gotten better as long as you call between 8 and 5 
Central US time.  One still must wonder why so many people say that 6.1 is a 
more stable release, yet that stability hasn't trickled down to the 6.0.04 
and 6.0.02 users.  One must also wonder why helpline still thinks it's "no 
big deal" for a heavily modified shop with over 1K active users to "drop in" 
a new release.  One does _not_ wonder why their stock is hovering around $2 
USD per share.

However, BPCS still beats what we in the South call the "Tea-Waddin'" out of 
90% of its competition based upon price-performance.  Just how many failed 
SAP implementations do you see in "The Trades" versus failed BPCS 
implementations?  Done right, BPCS is still a good package.  Most of the 
problems related here are due to "specialty" implementations of code that 
wasn't tested thoroughly by SSA, "bleeding edgers" who stick in new stuff 
like OLM before it's had time to be properly exercised in the field, and 
"tightwads" that try to drop in BPCS without the proper guidance.  Oliver 
Wight places choosing software at number twelve in the twenty-five steps to 
MRP implementation, yet how many companies perform 1-11 prior to choosing a 
package?  If you do not perform due diligence up front, do not expect a 
software package to solve all of your ills...

JMHO,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-mail:  DAsmussen@aol.com

"Love means never having to say you're sorry." -- Love Story (Guess we know 
why they called it a _STORY_) -- Anonymous
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---