Wayne makes a valid observation:
> May I suggest a slight revision to the above comment????....
>
> IMHO, SAP and many other applications are too flexible for
> most companies. If
> your company cannot make a decision, then
> [insert_your_application_name_here] will become a nightmare.

Yes, this is true.  And others have posted other truisms such as having good
bills of materials, etc.  But SAP is a tad higher on the complexity meter
than other ERP systems.  For example,
http://www.bmc.com/offers/performance/whitepapers/docs/1997/sap_r3_tuning_an
d_upgrade_practices.pdf starts by saying:

"SAP promises increased corporate business performance.
Those responsible for Information Systems can not risk
Information Technology performance becoming a
constraint on corporate business performance. SAP
includes the Computer Center Management System
(CCMS) which provides an abundance of performance
data through monitoring and trace tools. CCMS, however,
lacks a forecasting capability to prioritize tuning and
upgrade alternatives, which increases risk by pushing
performance into a re-active rather than a pro-active
position. Setting and monitoring exception thresholds on a
multitude of metrics for O/S, UNIX process, database,
storage, and configuration will display a serious amount of
information, but may not communicate the problem
because performance problems usually can't be traced to a
single metric, or even a select few. It takes substantial
amount of time and effort to correlate an immensity of
metrics to locate a problem. Once the problem has been
found there is typically no method to determine the
performance payback of a proposed tuning or upgrade
alternative that hopes to alleviate the problem. Sizing
estimates by hardware vendors need to be validated
according to customer specific roll out estimates, and a
raft of business practice customization to a system that has
over eight thousand tables. Stress testing can validate the
target configuration, but is expensive in terms of setup and
cannot "see" beyond the first bottleneck detected. By and
large the most frustrating issues facing SAP performance
is determining where the problem really is and which part
of this complex system needs adjusting - SAP, the
RDBMS, or the hardware configuration."

Eight thousand tables!  A system so complex that it comes with its own
"Computer Center Management System!"  SAP is written in its own programming
language ABAP/4, which looks very much like Cobol.  (See
http://www.guidancetech.com/people/holland/sap/abap/zsol.txt for an example
ABAP program that plays Solitaire.  Hmm, no wonder nobody finishes their
implementations - they're out playing cards...)

SAP has multiple modules that perform similar functions.  I worked on EDI
integration in the early to mid '90s and we could use: ALE - application
linking and embedding, Intermediate Documents (IDOCS), output control (send
info to a printer, e-mail, fax, file, etc. LPORTY on steroids for you MANMAN
developers), or write a custom routine in ABAP.  They seem to keep adding
layers and features like crazy.  I believe they have several ways to manage
process workflow and this is the one that I think trips up everyone because
their current processes are not well-known and/or not well-defined.

It seems the answer to every question posed to an SAP consultant is "YES".
So the trouble, even for a company that has a good handle on its business
processes, is that they don't know the best way to use the system because
it's just too damn big to know.  That is why I believed they moved to the
pre-configured model and the later suggestion to mold the company to the
configuration.  You can still change it since you have the source and the
language at hand.  But with a system so large and so complex, you never
really know what you've done until you try it out.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *