|
Sorry Dean, you mucked up the most important fact -- Covey wrote BPCS on his aunt's kitchen table! |--------+-----------------------> | | DAsmussen@aol| | | .com | | | | | | 06/11/99 | | | 01:42 AM | | | Please | | | respond to | | | BPCS-L | | | | |--------+-----------------------> >----------------------------------------------------------------------------| | | | To: BPCS-L@midrange.com | | cc: (bcc: Dan Mitchell/Nexgen) | | Subject: Re: Why did you choose BPCS | >----------------------------------------------------------------------------| 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 +--- +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.