Re: why migrate -- BPCS-L

I know very little about SAP, but I have various experience with other ERP than BPCS, and lotta BPCS experience.

I would say that compared to the competition, BPCS is a general full service ERP. Depending on your industry, there may be ERP that do a real good job in some specific areas important to your industry, but may lack depth and breadth of a general full service ERP like BPCS. BPCS is far superior in the area of TAILORING = having Business Rules that are specific to your company needs. The one thing that most makes me nervous about BPCS is not the product but the vendor that owns it. They had practices that led them to go bankrupt. They have fixed SOME of those practices, but they still doing things that could cause clients to jump ship.

When we migrated to BPCS from MAPICS and I was asked my impressions, I said BPCS is 200 times better than MAPICS except in 2 respects, which are killers. One was that at that time (1989 or so) I knew about Y2K but no one else interested in what it would take to go compliant, least of all SSA (Yes, we migrated from a version of MAPICS that was Y2K compliant to BPCS at a time when BPCS was not). The other killer I thought was BPCS does a real shoddy job of tracking who dunit ... now you can buy add on products for that, but it not in the core BPCS ... after I explained why who dunit is important, management restructured our company so that less important, but it still bites us from time to time.

Version 405 CD is very stable. I have been on other ERP that do a poor job of recovery from abnormal termination ... you have someone on a PC doing some update to the files ... the PC goes down, has to be rebooted ... the files they were updating are now somewhat messed up because the program was like a guy with a clip board ... checking off stuff to be done, only half way thru the paper caught on fire, not know where left off. With BPCS, provided the user calls IT to say what they were doing when the PC bombed, it is relatively minor action by IT to clean up the consequences. On other ERP that I have been on, such an incident means, get everyone off of the system, restore to last backup, redo all work since the last backup, because other ERP lack the stability of BPCS, and provisions for recovery from ordinary mishaps. In my real world, the end user often not tell IT about a mishap, but BPCS has file organization such that IT can deduce that someone messed up, and take care of it, without inconveniencing the entire enterprise.

Speaking as someone at a MAKE TO ORDER "Job Shop" enterprise, I believe BPCS is better attuned to MAKE TO STOCK factory (supply chain is weak), and in common with just about every ERP I have ever known much about, the PDM is extremely basic compared to engineering theory such as APICS standards.

There is some stuff that may be a limitation of the iSeries or how something is implemented on the 400. I know a company that has something like 50 different divisions ... they put each in a different BPCS environment, in which people sign on using their name and some other character at end of their name to designate which environment. Well they ran into a ceiling on how many objects can be owned by one user (SSA QSECOFR etc.) so I suggested they consider partitions ... one partition have OS/400 and all the stuff for say one human language, using the model of another company that I know that has factories in 10 different countries, with the whole thing on one iSeries host, and a different partition for each nation's operations, and most of them running BPCS.

As for migration ... I have been involved in about a dozen migrations that were successful, and 2 or 3 that bombed. The topic of how best to do a migration may be off-topic for BPCS_L. My feelings are that a manufacturer should get good at doing its core job with a decent ERP, that if a company is experienced in migrations, that implies they not know what they are doing in their core job.

Thus it is essential to have some outside consultants assist with the migration. Now they are in business not just to make money helping you, but also to find ways to charge you more money than is needed for the migration, so once you have the migration path from the consultants, it would be wise to compare notes with some company that has already gone through a similar migration to identify and fix the gotchas, before you are in a position with the consultants having your enterprise over a barrel with them getting far more money than you bargained for.

Education is critical. I believe that a company that has a cruddy ERP but excellent education for its people in how to use it productively, can competitively beat the pants off a company that has the best ERP in the world run by people who do not know what they are doing. ERP does not run itself, it needs to be run by people, it is a tool, like accounting is a tool. Tools can gather dust, be abused, broken, misaligned ... this not the fault of the tool, but the nut behind the wheel.

thanks for the help Al, there are somethings in specific i want to know :

1. what are the feature that SAP provides and not BPCS.
2. the strengths and limitaitons of BPCS.
3. what approach is followed  ( as in , is there a basic guideline or
methodology) for the migration.

- Al Macintyre http://www.ryze.com/go/Al9Mac Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/