SAP vs. BPCS vs. Master-Pack vs. Oracle-Manufacturing
Ben Rosenberg
> Organization: Internet Exchange Carrier
> Subject: Re: Software Engineering
> Date: Sat, 29 Apr 95 11:59:12 PDT
> Newsgroups: comp.databases.pick
>
> My company is in the midst of evaluating a new application software
> base for our manufacturing, grocery store, and home and office delivery
> businesses. The two major frontrunners are BPCS produced by a
> midwestern software company and SAP produced out in Germany.
>
> I have seen some preliminary demos and it looks like SAP is winning by
> a mile. What strikes me is that SAP IS NOW THE PREMIER CLIENT SERVER
> BASED APPLICATION IN THIS COUNTRY, surpassing anything written by
> companies like Computer Associates, Peoplesoft and even Microsoft.
This is interesting. Does the word "PREMIER" refer to gross sales
dollars, or number of sites, or number of seats (licensed individual
users)? What is the average dollar$ / per site for SAP?
> I have also been told that SAP, due to the German mentality HAS
> NOT MISSED A SOFTWARE RELEASE DEADLINE IN ELEVEN YEARS! They have even
> gone so far as to create their own language that I've never heard of
> called ABAP/4 which is the language of choice when using SAP.
My father was born and raised in Germany and is notorious for tardiness.
Still, I've always felt that his mentality was, indeed, quite German.
Meeting deadlines is admirable but is it uniquely German?
I question the assertion that "the German mentality" is the reason for
the success of SAP.
> I used to think that we as Americans had the software industry sewed up.
> I am not so sure any more. As computer hardware and communication gets
> cheaper and more ubiquitous, more and more companies find that it is
> more cost effective to be in places like Germany (where SAP employs
> 1600 programmers), Ireland and even China over places like Seattle,
> Boston or New York.
The best software comes from my ex-employer in Denver, of course. :-)
But seriously, software modules seem to integrate with each other about
as well or about as poorly as their respective programming teams
communicated with each other, and programmers, regardless of their
location, can meet the needs of the customers ONLY IF there's good
person-to-person communications among the three groups, the customers,
the software sales and marketing folks, and the software developers.
> That a German company using a proprietary language can develop a system
> that has most Fortune 500 companies in this country quickly migrating
> to it, is astounding. I just worry that we as Americans have become
> as overconfident about our software industry as we were about our
> automobile industry. Just remember, Japan did not take our market away
> with creativity and philosophy, they beat us with quality, price and
> discipline.
> -- Enrique Vargas -- var...@ixc.net
I'm very curious to see the findings of other people who have compared
various vertical application packages for manufacturing and distribution.
Is SAP really as great as Mr. Vargas says that it is?
Why?
What software engineering lessons should the rest of us be learning
from the success of SAP?
For what sorts of manufacturing and distribution businesses
would SAP be a good fit?
For what sorts would SAP be ill-suited?
Has anybody had SAP on their "short list" and then decided to buy some
other package, such as Oracle-Manufacturing and Oracle-Financials,
or BPCS, or Master-Pack, or something else?
--
Ben Rosenberg
Rosenberg Technical Services, Trenton, NJ, USA, 1-609-695-0370
b...@rosenberg.org
Michel Baudin
>
> > I have also been told that SAP, due to the German mentality HAS
> > NOT MISSED A SOFTWARE RELEASE DEADLINE IN ELEVEN YEARS! They have even
> > gone so far as to create their own language that I've never heard of
> > called ABAP/4 which is the language of choice when using SAP.
>
country achieves some competitive success, local idiots are prompt to credit
it to the national culture. They usually never bother to explain why the
same national culture didn't help before or why it still doesn't help in
other industries.
It won't help in the future either. Industries have their own dynamics,
which transcend national cultures. Whatever happens to be "high technology"
in 2035 may come from Pakistan or Cuba, and there will no doubt be local
"philosophers" to explain the roots of those successes on the basis of
national culture.
It's counterproductive. Let's not do it.
Michel Baudin
Tel:(415)856-8928
FAX:(415)858-1873
Jim Hall
ARE NOT REPRESENTATIVE OF ANY EMPLOYER PAST OR PRESENT OR OF ANYTHING ELSE,
THEY ARE ONLY MY OPIONS!
In article <3o3jft$p...@huron.eel.ufl.edu>, b...@rosenberg.org says...
>I'm very curious to see the findings of other people who have compared
>various vertical application packages for manufacturing and distribution.
>
>Is SAP really as great as Mr. Vargas says that it is?
>Why?
SAP has the best marketing and demo staff on the planet. Their utilization
of machine resources and Oracle is quite humorous compared to other efforts
I've seen. Just compare SAP's hardware requirements to your own development
experience.
Off-the-shelf vanilla SAP, while having a whole host of modules, doesn't
really seem to provide much functionality. In order to get a SAP module to
do what you want you HAVE to write a lot of ABAP code. Kinda like saying
"my package does everything, and look it includes a C compiler so that you
can extend it to do anything it doesn't already do". As far as I can tell,
what SAP software does best is sell time for SAP consultants.
>
>What software engineering lessons should the rest of us be learning
>from the success of SAP?
That marketing and presentation are more important than technical
excellence.
>
>For what sorts of manufacturing and distribution businesses
>would SAP be a good fit?
The sort that can change their practices and procedures to fit the SAP
model.
>
>For what sorts would SAP be ill-suited?
Any that do things differently (better) than the SAP business model.
- jim
--
An expatriated American hoping to find some fun!
James & Cathy Marland
> Enrique Vargas <var...@ixc.net> wrote:
> > I have seen some preliminary demos and it looks like SAP is winning
by
> > a mile. What strikes me is that SAP IS NOW THE PREMIER CLIENT
SERVER
> > BASED APPLICATION IN THIS COUNTRY, surpassing anything written by
> > companies like Computer Associates, Peoplesoft and even Microsoft.
>
>This is interesting. Does the word "PREMIER" refer to gross sales
>dollars, or number of sites, or number of seats (licensed individual
>users)? What is the average dollar$ / per site for SAP?
SAP is the largest vendor of Client/Server solutions in 1994, based on
total revenue of licences sold, as auditted by IDC.
David Crane
: Enrique Vargas <var...@ixc.net> wrote:
: > That a German company using a proprietary language can develop a system
: > that has most Fortune 500 companies in this country quickly migrating
: > to it, is astounding. I just worry that we as Americans have become
: > as overconfident about our software industry as we were about our
: > automobile industry. Just remember, Japan did not take our market away
: > with creativity and philosophy, they beat us with quality, price and
: > discipline.
: > -- Enrique Vargas -- var...@ixc.net
: I'm very curious to see the findings of other people who have compared
: various vertical application packages for manufacturing and distribution.
: Is SAP really as great as Mr. Vargas says that it is?
SAP has definitely taken the market by storm. Good writeup recently (in
Infoworld, as I recall). Basically they did it by 1) being first with the
most (integrated financial packages), 2) shoehorning themselves into the
larger companies with a mainframe version (R2) and following quickly by
their relatively new client-server version (R3), and 3) gaining a large
and loyal following from quite a few major consulting firms.
: What software engineering lessons should the rest of us be learning
: from the success of SAP?
Function, tenacity, and service can overcome a lot of obstacles,
especially if you are in the right place at the right time. I don't
consider SAP to be a software engineering breakthrough.
: For what sorts of manufacturing and distribution businesses
: would SAP be a good fit?
Oddly, the success of SAP seems related to the degree to which companies
are willing to adapt to the requirements of the software rather than the
ability of the software to adapt to a variety of business approaches.
: For what sorts would SAP be ill-suited?
Very large companies, for one. And SAP isn't too easy to adjust, it's a
bit of "take it or leave it". I've seen several instances in which
companies committed to SAP at the suggestion of their IT department (one
of which was an outsourcer/consultant rather than an in-house IT
department) without even realizing that they would have to change a lot of
the ways they do business. That's not all bad for some old, staid
companies that need a kick in the pants but there are a lot more rational
ways to re-engineer an organization.
: Has anybody had SAP on their "short list" and then decided to buy some
: other package, such as Oracle-Manufacturing and Oracle-Financials,
: or BPCS, or Master-Pack, or something else?
There were several examples in the aforementioned cover story of companies
that went to SAP and then switched. One found it unable to handle
companies their size, etc. I think they went to Oracle's packages.
Mainly I think SAP is successful because it is the broadest set of
packages off the shelf at a time when "buy, don't build", downsizing,
and a big dissatisfaction with mainframes and software maintenance
happened to coincide.
Clients should be aware, however, that "off the shelf" doesn't mean that
SAP can be installed for the price of the software. The average cost of
getting things up is about four consulting bucks for each licensing dollar.
That is, multiply by five.
David Crane
: SAP has definitely taken the market by storm. Good writeup recently (in
: Infoworld, as I recall).
The article I had in mind was in INFORMATIONWEEK on April 24th. They
mention Dow Chemical and DuPont as early users of SAP in the USA. They
claim 3,000 installations worldwide and 300 in the USA. Article points
out that SAP is not cheap, costing from $1 million to $10 million,
including consultants. It also requires a lot of server horsepower.
Boeing is mentioned as having tried SAP but switched to Baan
International's Triton. Boeing says it was a price issue. SAP says they
walked away from the deal because Boeing "wanted to completely change our
development schedule for their needs". In other words, it didn't fit
what Boeing wanted.
Eastman Kodak selected SAP and then discovered it wouldn't handle a
company of their size. They are now looking at Oracle.
SAP consultants are in short supply in the USA. ICS-Deloitte claims to
have 3,500 in the US and needs more.
The article is a "keeper", so look it up. It's followed by a technology
assessment that compares SAP to other offerings. The bottom line seems
to be:
Strengths:
Effective use of three-tier client server (they push hard on the fact
that they have an "application server" level).
Tight data integration across departmental boundaries
Comprehensive functionality spanning the enterprise
Committed to open systems
Support for multiple languages and currencies
Weaknesses:
Complex configuration
Lengthy, company-wide design cycle
Business processes must be fit to SAP model, not vice versa
Susan Joslyn
>
>Enrique Vargas <var...@ixc.net> wrote:
>>
>> > NOT MISSED A SOFTWARE RELEASE DEADLINE IN ELEVEN YEARS!
>Nationalism rears its ugly head again. Whenever some industry in some
>country achieves some competitive success, local idiots are prompt to credit
>it to the national culture.
>It's counterproductive. Let's not do it.
>Michel Baudin
Its not that I don't agree with much of what you've stated. And going
any further with this discussion would be out of place in this forum,
but I can't resist the impulse to argue: While successes and failures
can not be attributed in any blanket fashion to a culture -- national,
religious or _corporate_, these influences on the people, the work habits
the flow of creative thought and general discipline can not be _ignored_,
either.
There are similar arguments in other sciences: genetic predisposition v.
birth order in personalities, for example.
There is a different work culture and work ethic in different countries.
There is a different view on creativity. This influences the products
and ideas that come from that country. Likewise different companies
within this country (or any other).
Susan Joslyn
sjo...@pacifier.com
Vancouver, WA USA
var...@ixc.net
In article <3o7ts0$6...@crl12.crl.com>, <dcr...@crl.com> writes:
> SAP has definitely taken the market by storm. Good writeup recently (in
> most (integrated financial packages), 2) shoehorning themselves into the
> larger companies with a mainframe version (R2) and following quickly by
> their relatively new client-server version (R3), and 3) gaining a large
> and loyal following from quite a few major consulting firms.
for the same reasons we chose Microsoft Office as a standard. If you look at
any one of the Microsoft Office products you will find that another company has
a better product. However, the integration is the key. People are tired of
having 10 to 20 legacy systems that do not talk to one another. Getting
information from one application into another is like being in the tower of
Babel. Both Microsoft and SAP did an excellent job of tying the products in
their suite together so that they are more than just the sum of their parts.
> Function, tenacity, and service can overcome a lot of obstacles,
> especially if you are in the right place at the right time. I don't
> consider SAP to be a software engineering breakthrough.
>
Again, a good point. However, the things they have done have not been
revolutionary, but they work well. For instance, I am impressed with the way
they embraced the three tier client server model. This model has a back-end
database server, usually a large Unix RISC machine whose only role is to dole
out database requests and updates. The advantage is that your database of
choice whether it be Oracle or Informix can consume that entire machine and be
tuned specifically for it. (Which is good, because everything I know about
Oracle tells me that it doesn't play nice with other applications.)
The second tier called the application servers are usually a number of Intel
based machines running Windows NT. As Intel boxes are cheap and plentiful, if
you hit a performance bottle neck at the application level, you can throw
another application server at it. Finally at the client level, you have the
Intel based workstations (i.e. PC's) handling all the graphical interface.
> Oddly, the success of SAP seems related to the degree to which companies
> are willing to adapt to the requirements of the software rather than the
> ability of the software to adapt to a variety of business approaches.
>
Again, true. I find that companies are frustrated both with themselves as
corporations and with their IS departments for "letting them get that way."
Therefore, they are using the acquistion of a major new canned package like SAP
as an excuse to reengineer their business processes and outsource their IS
departments.
> : Has anybody had SAP on their "short list" and then decided to buy some
> : other package, such as Oracle-Manufacturing and Oracle-Financials,
> : or BPCS, or Master-Pack, or something else?
I'll let you know. Right now, we have a short list of SAP and BPCS. We are
leaning towards SAP because they will run on any of the major Unix platforms
TODAY (HP,SUN,DEC,IBM). BPCS is in the midst of porting to Unix, and hope to
have this rolled out sometime this year. When they do role, they will support
IBM AIX, and HP/UX PERIOD. As we are already running Unix, who wants to go to
proprietary AS/400 if they don't have to?
As for Oracle Financials, well, the problem is then you are not only tied to
your application vendor, you are also tied to the database itself. We are in an
age where not only has the hardware become a commodity, but the databases
themselves have become a commodity.
It really is a question of who has the price, performance and integrity lead
TODAY. Also, like I mentioned earlier, Oracle "doesn't play nice" with anything
that isn't Oracle. Oracle databrowser ONLY talks to Oracle databases, SQL*NET
and their desktop tools have the same problem. Also, what VAR in their right
mind wants to develop applications for a database company that may be one of
their biggest competitors? I believe that SAP will not do everything we want it
to do. However, when we decide to buy/write those pieces, I would hate to find
out that few VARs have developed anything close to what I need because of
a conflict of interest problem.
> Clients should be aware, however, that "off the shelf" doesn't mean that
> SAP can be installed for the price of the software. The average cost of
> getting things up is about four consulting bucks for each licensing dollar.
> That is, multiply by five.
Again, very true. However, I believe a very large chunk of the expenditures we
are up against is going TRUE client server. Contrary to popular belief, client
server is significantly more expensive than your traditional host based
computing. Between the cost of wiring a nationwide TCP/IP based network running
ATM (or any other really fast protocol) for split second response time, the
capital investment of buying/leasing all those PC's, the cost of training all
those users and all the hidden costs of maintaining the network or buying
desktop applications is horrendous! But there is no way around it, the world is
going to client server, and like it or not, we as IT people have to accomodate.
Enrique Vargas
var...@ixc.net
var...@ixc.net
In article <3o7hai$l...@gulfa.kw.us.com>, <jeh...@access.kw.us.com> writes:
> SAP has the best marketing and demo staff on the planet. Their utilization
> of machine resources and Oracle is quite humorous compared to other efforts
> I've seen. Just compare SAP's hardware requirements to your own development
> experience.
Absolutely true. However, have you ever seen a cheap implementation of
client/server? (No, screen scraping doesn't count). Their fundamental paradigm,
is that databases like Oracle, and Informix already do what good databases
ought to do. If the backend databases run like pigs then that is more a
function of Oracle/Informix than SAP.
> That marketing and presentation are more important than technical
> excellence.
Agree and disagree. They are one of the few application vendors offering a
completely integrated suite of true client/server based products. I am not sure
to whom I WOULD give the award for technical excellence.
> >
> >For what sorts of manufacturing and distribution businesses
> >would SAP be a good fit?
>
> The sort that can change their practices and procedures to fit the SAP
> model.
>
I guess the same could be said of any number of canned applications. If they
don't fit out of the box you have to customize.
-Enrique Vargas
var...@ixc.net
Jim Hall
>
>David Crane (dcr...@crl.com) wrote:
>
>: SAP has definitely taken the market by storm. Good writeup recently (in
>: Infoworld, as I recall).
>
>The article I had in mind was in INFORMATIONWEEK on April 24th. They
>mention Dow Chemical and DuPont as early users of SAP in the USA. They
>claim 3,000 installations worldwide and 300 in the USA. Article points
>out that SAP is not cheap, costing from $1 million to $10 million,
>including consultants. It also requires a lot of server horsepower.
There was also an article posted recently on the SAP Listserver from a
german business magazine that ran down a whole host of problems experienced
by several european companies when trying to implement SAP. Perhaps
somebody from the SAP Listserver could post that article.
><snip>
>Strengths:
>Effective use of three-tier client server (they push hard on the fact
> that they have an "application server" level).
>Tight data integration across departmental boundaries
>Comprehensive functionality spanning the enterprise
>Committed to open systems
This is really a questionable commitment. Next time you talk to an SAP
person ask some questions about which operating systems they have actually
installed R3 on. Try to talk to someone in the IS group at a customer that
really is running R3. And if you really want some entertainment, ask
SAP about using some other Oracle based tools (say SQL*Forms or SQL*Report)
against the Oracle tables used by R3. You'll be impressed by their answers.
Basically you can't access the data because they don't use Oracle the same
way the rest of the world does. An open system that cuts off your access to
the underlying DBMS engine? How open is that? Why don't they use Oracle in
the "normal" fashion? Ask SAP, it's fun.
>Support for multiple languages and currencies
>
>Weaknesses:
>Complex configuration
>Lengthy, company-wide design cycle
>Business processes must be fit to SAP model, not vice versa
How about that you have to ABAP code the functionality you need, and guess
who makes money on just about every ABAP consultant that there is?
- jim
--
An expatriated American hoping to find some fun! (formerly
ha...@stimpy.mfa.com)
Rine Le Comte
|>
|>
|> > >
|> > >For what sorts of manufacturing and distribution businesses
|> > >would SAP be a good fit?
|> >
|> > The sort that can change their practices and procedures to fit the SAP
|> > model.
|> >
|> I guess the same could be said of any number of canned applications. If they
|> don't fit out of the box you have to customize.
|>
|> -Enrique Vargas
|> var...@ixc.net
|>
|>
I do agree on this point, but the amount of time and effort that must be
put in the implementation and customization differs between the various vendors.
One of SAP's strong points in my opinion have been the alliances with the
large consulting firms. These firms are really necessary to make the
implementation possible.
Regards
--
|************************************************************************|
|* Rine le Comte Zonneoordlaan 17 *|
|* Dept. Tools P.O. Box 250 *|
|* Baan Development B.V. 6710 BG Ede *|
|* e-mail: rlc...@baan.nl The Netherlands *|
|************************************************************************|
var...@ixc.net
In article <3oar8j$6...@gulfa.kw.us.com>, <jeh...@access.kw.us.com> writes:
> This is really a questionable commitment. Next time you talk to an SAP
> person ask some questions about which operating systems they have actually
> installed R3 on. Try to talk to someone in the IS group at a customer that
> really is running R3. And if you really want some entertainment, ask
> SAP about using some other Oracle based tools (say SQL*Forms or SQL*Report)
> against the Oracle tables used by R3. You'll be impressed by their answers.
> Basically you can't access the data because they don't use Oracle the same
> way the rest of the world does. An open system that cuts off your access to
> the underlying DBMS engine? How open is that? Why don't they use Oracle in
> the "normal" fashion? Ask SAP, it's fun.
Actually, I have asked questions of some of their user sites and their
technical staff. Basically, they use Oracle in a very vanilla way. They don't
use any stored procedures, replication or two-phased commits. This is because
they don't want to use any features that would tie them to a specific database.
They want to keep you trapped into using SAP, not Oracle.
They don't, however, discourage the use of things like SQL*REPORT writer or
Oracle databrowser, but they strongly discourage direct updates of the
database. This is because they have thousands of tables, and since they don't
use the referential integrity features of Oracle, you'd have to know all the
tables that needed updating at any given point.
Enrique Vargas
var...@ixc.net
Fabian Geyer
> How about that you have to ABAP code the functionality you need, and guess
> who makes money on just about every ABAP consultant that there is?
ahead of the others. We compared SAP to Baan's Triton late last year.
Triton was missing a lot of functions essantial to us (version 2.2)
example Legal consolidation which is a must for us..
(or at least Triton did it in an undesirable manner)
SAP in contrast is (or was when I last looked at the appropriate moduls
last year) weaker in PPS and such areas.
I have no idea how Sales&Distribution relates to other products.
Triton will become better in financials with Release 3.0, not all
the code for that was written when he evaluated the two product.
Neither is SAP R/3 Release 3.0 finished deveolpment (as far as I know)
cannot be long finished anyway.
AS FAR AS I KNOW R/3 3.0 IS THE FIRST TIME SAP DID NOT MEET THE SCHEDULE !
If you stick to financials R/3 is a better choice than Triton.
These modules (financials, controlling, assets management) are quite well
designed AND YOU WON't NEED TO CODE A LOT OF ABAPS !
We just needed ABAP for data input (permament and onetime data transfer)
Although once you know it it, ABAP is just a fantastic language
to program your datatransferstuff in. Internal tables are such a convenient
tool! I tried to write an ABAP->C precompiler once because it was so nice
but I gave up because of lack of time.. :)))
If you also want a PPS-System you have to take a closer look.
Estimate at least half a year to install and customize the system !
From what I saw the basis functionality is greater in SAP
(report management and such, Worksation up- and downloads, graphics)
Triton was displayed with a GUI on the CeBit and it still looked rather buggy.
Maybe it is catching up, but who knows.
We took a look at Oracle financials also (mid last year) but It did not
seem to fit for the german requirements then.
Be careful with Release 3.0 On the CeBit it was still unclear in some areas
what functionality would or would not come with 3.0.. And also it is
rather unwise to start with an 3.0A release.
'nough said ..
--
Fabian Geyer ge...@umawihp0.wifo.uni-mannheim.de
The_Fabe@IRC 134.155.59.144
SY-SAPRL 2.2C http://umawihp0.wifo.uni-mannheim.de:4000/~geyer
My SAP-page is http://umawihp0.wifo.uni-mannheim.de:4000/~geyer/sapr3d.html
Experimental archive of de.alt.comp.sap at http...geyer/SAP/News-archiv
Craig D. Lansing
Jim Hall <jeh...@access.kw.us.com> wrote:
> Basically you can't access the data because they don't use Oracle the same
>way the rest of the world does. An open system that cuts off your access to
>the underlying DBMS engine? How open is that? Why don't they use Oracle in
>the "normal" fashion? Ask SAP, it's fun.
I agree completely. Despite how kewl SAP can be made to look to non-technical
managers, the underlying architecture is a giant step backwards unless
"Closed Systems" is going to be the next vogue trend in IT.
We have a mangement team looking into Purchasing / Accounts Recv. packages
and SAP is on the list, but two others are also being evaluated, Computron
and Lawson. I there anyplace that I can get some info. on these
products?
--
Craig D. Lansing (lan...@ixc.ixc.net) | My opinions are not necessarily
METRO Information Services, Inc. | those of my employer and are quite
Virginia Beach, Virginia USA | often diametrically opposed to them.
Alvin Law
> In article <3o841c$f...@crl10.crl.com>, dcr...@crl.com says...
> >
> >David Crane (dcr...@crl.com) wrote:
> >
> >: SAP has definitely taken the market by storm. Good writeup recently (in
> >: Infoworld, as I recall).
> >
> >The article I had in mind was in INFORMATIONWEEK on April 24th. They
> >mention Dow Chemical and DuPont as early users of SAP in the USA. They
> >claim 3,000 installations worldwide and 300 in the USA. Article points
> >out that SAP is not cheap, costing from $1 million to $10 million,
> >including consultants. It also requires a lot of server horsepower.
> There was also an article posted recently on the SAP Listserver from a
> german business magazine that ran down a whole host of problems experienced
> by several european companies when trying to implement SAP. Perhaps
> somebody from the SAP Listserver could post that article.
*******************************************************************
By Burkhard Boendel, Wirtschaftswoche (the German magazine, "Business Week")
Title: Software Star SAP: In Danger of a Fall?
(with a burning bomb in the background)
Subtitle: Like Lemmings
An increasing number of customers of the German Software-Star SAP complain
about outdated technology, high costs and of expensive installation. Is this
the begin of the plunge?
The introduction of the new software system ended in a debacle. For three days
the British sales office of Bahlsen Keksfabrik KG in Hannover was unable to
accept any orders. Bahlsen's dream of decentralized data processing ended here
for the time being. 700.000,-- DM of investment vanished. "This is
unreasonable for the user", says Bahlsen Manager Volker Gassner.
More and more companies had negative experience with the software that made
the north-German cookie-producer fail: Werner Unger, Commercial Manager of the
Institute Fresenius in Taunusstein, also feels ill advised. After a few months
only, the software supplier for finance and accounting at Fresenius let the
people in Taunusstein know that compatibility with the operating system VMS
Open, that is employed for the research and development sections, can no
longer be guaranteed. "If we knew that we would not have installed it", an
annoyed Mr. Unger says. The decision to employ more software packages of this
supplier was delayed: "Their behavior is incalculable for us", says Unger.
After three months only, Urs Oechslin break off the software test operation.
The responsible person for data processing of the Swiss conglomerate Zellweger
Uster in canton Z?rich tried to decrease data processing cost and to direct
production. Both could not be realized. "The system does not offer enough
functionality - especially in production planning and -coordination".
Volker Gassner, Werner Unger and Urs Oechslin are annoyed with the same
enterprise, the Walldorf software supplier SAP AG. The four founders, Dietmar
Hopp, Hasso Plattner, Hans-Werner Hector and Klaus Tschira - all of them
former IBM managers - realized unknown growth. Since 1989 until today they
multiplied turnover by five to 1,8 billion DM. The bank, Julius B?r, even
estimates that turnover will double again by 1996.
SAP is the super star among Germany's young enterprises, some kind of Germanic
Microsoft. Worldwide SAP ranks no. 5 of the software suppliers. Their stock
market value with around 13 billion DM lies above that of Lufthansa or
Commerzbank. BMW comes into reach. The analysts of the US broker Goldman Sachs
name SAP as the only German title on their European Priority List besides
Daimler-Benz. The press too, from the "B?rsen-Zeitung" over "Die Woche" to
"Top Business" spoil the German showpiece. Some weeks ago, in an
"Spiegel"-article SAP founder Hopp had the opportunity to brood over his
heritage and to toy with the idea that "the crash might already have begun".
The previous SAP-euphoria had reasons: There is no big German enterprise not
monitoring its internal company processes with SAP-programs. The companies
handle General Ledger, Logistics, Sales, Purchasing and Human Resources by the
Walldorf software. No matter if Siemens, Bosch, Daimler, Henkel, BASF, Bayer,
BMW, Hoechst, Otto Versand or Hochtief: The German economy is firmly in the
hands of SAP.
During the past few months, however, the complaints about the market leader
for operational software increased and criticism is getting tougher.
"SAP-technology is basically outdated", stated computer scientist Joachim
Grisese, Professor at the University of Bern. In SAP-systems you will look in
vain for anything said to be with a promising future in the computer market
at the moment: Object- and process information, lean, flexible and open
systems, software ergonomics. Instead, R/3 bluffs with the smartest graphical
user interface presently available.
The reason for this dilemma was that the R/3 System that has been put on the
market in 1992 has not been re-developed. The software engineers took the
concept from the previous R/2 model. But this is derived from the centralized
world of mainframe computers. "R/3 is the same as R/2 except that it now runs
on workstations", says Karl Schmitz of tse- company for Technology Consulting
and System Development in Hamburg. A consultant who prefers to stay anonymous
judges even more drastically: "R/3 is an afterbirth of the mainframe area."
This has serious consequences; one is the giant requirement for computer
memory. R/3 requires about eight gigabytes of memory capacity - to the delight
of hardware suppliers. The SAP dinosaurs need at least double of the computer
power than comparable products of competitors. Suppliers like Hewlett-Packard
(HP), SUN or IBM are not at all sad when SAP cleans up on every hardware deal.
Insiders say, SAP charges 20 to 30 percent for a so-called basis platform
consultancy. In clear: If SAP advises Hoechst AG to run R/3 on HP-computers
the lavish commission of the computer supplier for the order arrangement goes
to the accounts of the software supplier, often a high amount. Experts
estimate that the Frankfurt chemistry and pharmaceutical multinational has to
order hardware for about ten million DM as he changes software. The old
technocratic thinking pattern of the mainframe technology prevails
everywhere. ?Both economically and organizationally SAP is aligned to a
center", criticizes Martin K?tz, DP-Manager of Braas GmbH, a tile producer.
This is what the Europa Carton AG in Hamburg felt, too. The structures of the
company are like a network in which most different production processes are
performed. "With SAP-Software we would never have managed this unless we had
installed R/3 four times, ", says Heiner Emrich, Organization and DP Manager
of Europa Carton. Emrich decided for the more flexible program Triton of the
software supplier Baan BV in Ede, Netherlands. Expenses were about the fifth
part of what SAP would have taken in, estimates Emrich. Also, implementation
only takes 18 months.
SAP customers can only dream of such a speedy implementation. Like Hoechst AG
who decided for R/3 last year and cannot run the modules in production before
1998. Siemens AG who plans to implement the same software in the sector of
medical technology calculates four years from projecting until the final
operation.
From the moment the software runs - the real problems start. Business
processes once installed are very difficult to change. "Nobody wants to touch
it because nobody understands the interaction between the forms", says a
former employee of Ploenzke software supplier in Wiesbaden who organize the
implementation of SAP products at SAP-customer sites. Even the implementation
of a new cost center becomes a never-ending task. "The immense complexity of
the system turns into inflexibility", says tse-consultant Schmitz.
Esso in Hamburg gave up attempts to introduce individual additions. Experts
estimate that it takes a software engineer three years just to understand the
forms labyrinth you need for individual additions. Computer scientist Griese
sees in this inflexibility the decisive deficit of SAP: "Which enterprise that
targets at competitive advantages can afford permanently to set on standards
only?"
For most enterprises the abandonment of software adaptations is out of
question, anyway. As their own programming capacities are usually tight
external consultants are often busy with the continuation of R/3 - a huge
market. Frank Solbach, General Manager of the market researcher Input
Deutschland in Langg?ns-Niederkleen estimates that external consultants for
SAP software turn-over 5 billion DM per year. Solbach calculates the internal
staff requirements to the same number. The daily rate for an external expert
is at least 2000,-- DM. In emergency cases and when production threatens to
come to a stance because of software bugs the rate might even go up to 8000,--
DM.
Sales of SAP systems is established through so-called logo partners like
Ploenzke, Debis, Price Waterhouse, KPMG, Anderson Consulting, Coopers &
Lybrand. The excessive consultancy expenses fill their cash box - Siemens
Medical Technology calculated approx. 20 million DM for this purpose. To the
outside the consultants appear to be independent, however, they are SAP
experts. So it is clear where the order is placed. "We were advised to consult
the customer with a direction to SAP", a former Ploenzke employee reports.
Once caught in the tentacles of the clique of SAP, hardware producers and
consultants it is hard to get out again. For example Boehringer Mannheim: The
enterprise has been SAP customer since the seventies. It all began with the
software R/2 running on mainframe computers. Today the company wants to
decentralize its DP and to realize a client/server architecture with R/3.
Workstations will replace the mainframes.
But it is not that easy. The R/2 version running at Boehringer Mannheim can
only be updated to R/3 by going a long way round. At first the customer has to
install the latest R/2 version (Release 5.0) because there is only one main
connection thread prepared from here to the R/3 update. Insiders estimate the
cost for the implementation of the new R/2 version to a two-digit million
amount. The customer, however, has no choice: The switch to another software
would be even more expensive - and often comes along with massive delays in
production.
The SAP case is similar (in a fatal way) to the best times of the world?s best
computer supplier--IBM. "What IBM was then, is SAP now", says Detlev Ruland,
General Manager of the German Institute for virtual intelligence in
Kaiserslautern. Just like people automatically bought IBM computers then,
almost everybody is installing SAP-Software today without much thinking about
it. "I get phone calls of people who ask for a SAP introduction who haven't
seen more of SAP but their brochures", wonders Udo Ramsperger, KPMG consultant
in Hamburg. Computer scientist Griese knows from his examinations: "Economical
calculations are made very seldom concerning decisions for SAP".
Not surprising: With a decision for SAP nobody risks his own carrier because
all important enterprises employ SAP software. Managers who shy away from risk
follow the trend like lemmings. The SAP fanclub is decreasing as examples like
Bahlsen or Fresenius show. More and more companies decide not to use SAP:
Siemens, SAP's biggest user in Germany will not use SAP's HR but the one from
Peoplesoft. KWO Kabel GmbH, a long R/2 customer changes to Triton from Baan
instead of R/3. Cost is only one third and the DP headcount can be reduced.
"Now half of the resources is sufficient", says commercial director Gerd
Schlenzka. Engineer Hilti in Schaan/Liechtenstein changes from R/2 to Oracle
software.
Though Henkel KGaA plans to implement SAP worldwide the production of the
chemistery section swears to Software Prism of the US-supplier Marcam. SAP can
only support production that is organized in bills of material which is not
sufficient for Henkel.
Last year, SAP lost the most lucrative and demanding order in the world. The
US aircraft company, Boeing, invited tenders for a three-digit million project
in order to re-organize its entire DP section. Boeing plans to re-organize the
production process of the airplanes, starting with customer requirements up-to
the suppliers. They plan to employ 45,000 users with the final model. For more
than six months the US SAP-daughter tried to fulfill these requirements -
without success. Now, Baan signed the mega-deal.
It is questionable, too, whether SAP's strategy to concentrate on
middle-classed industry will be successful. This is what they are forced to do
if they want to continue expansion. Three weeks ago, SAP signed cooperation
contracts with several small system suppliers, mainly to use their
industry-know-how. SAP urgently needs this know-how. It already showed in the
past that their attempts to develop special solutions for communes, agrarian
enterprises or hospitals where not really successful. Industry observers are
convinced that the mighty R/3 system, the expensive implementation and the
tremendous consulting requirements will rather scare off middle-class
companies. "Software downsizing has never been successful", warns Peter Kirn,
Chairman of the Management Board of IBM Applications Systems GmbH in Stuttgart.
Even some SAP logo partners agree on this opinion and are simply unfaithful in
this market segment, like Siemens Nixdorf who decided for Baan. SAP's attempt
to find a potent partner to roll-out the middle-classed industry failed.
Ditec Information Technology GmbH&CoKG in Villingen-Schwenningen and Munich -
deriving from the Digital-Kienzle and parts of Digital Equipment - seemed to
be the ideal assistant to SAP with its 20,000 middle-class customers. At first
SAP's courting seems to be successful. For the Cebit computer fair, that just
ended, advertising spots showing the SAP logo had already been produced. But
than Ditec sent their experts to Baan. They found Baan's concept so convincing
that they agreed on a strategic alliance with the Dutch - just on
Aschermittwoch. The SAP logo in the advertisement was spotted out.
It will get real dangerous for SAP when software giant Microsoft will join the
competition community of Oracle, Baan, Peoplesoft and Marcam in the future.
"This is only a question of time", says Input General Manager Solbach.
Interview
"There can't be more flexibility"
SAP founder Dietmar Hopp does not accept criticism to his products. Still he
is planning a re-organization.
Mr. Hopp, you lately said in a German news magazine that you were very lucky
with the development of your business. When you lost the Boeing order, would
you say you were without luck?
Hopp: We analyzed the required functionality together with Boeing for six
months. During this period it became clear that Boeing's requirements to the
software would have demanded developments that do not fit with our current
strategy. That is why we were no longer interested in the order as it was.
In the industry they say you were not able to trigger off your product R/3.
This is not true. We would have to make up development which we were unable to
do due to obligations for another grand customer.
You sold your systems with the argument that it was standard software. How
can it be called standard when you have to do extensive further development,
when installation takes more than three years and causes high implementation
costs?
On average, implementation periods are far shorter, in most cases even less
than six months. With our product R/3 that has been on the market since 1992,
we have made almost 1000 customers ready for production. Certainly there are
still some deficits. There are industry- and company specific details that
have to be developed afterwards. We plan to halve implementation periods
during the coming two years.
Many customers complain about the tremendous cost for the change from one
program version to the next.
These changes are done automatically in R/3. Admittedly, in the beginning they
came in very fast series in order to make the entire functionality available
as soon as possible. That will reduce considerably with today?s version 3.0.
Companies who do not like the change might have started too early.
Many SAP users miss the opportunity to save data centrally.
I invite those who claim this possible to show us the database that can do it.
There is none.
Suppliers of such databases think different.
This is not comprehensible for us.
Another point of criticism you can often hear about SAP is the missing
flexibility.
More flexibility than in SAP systems offer is impossible. The same critics who
complain about missing flexibility complain about high complexity, too.
They'll have to make up their minds: Do they want a simple PC software, that
cannot be adapted or a software like SAP's that is adaptable and therefore
necessarily complex. They cannot have both at the same time.
Why is it then that so many of your customers complain about missing
flexibility? Could it be a communication problem if you think the reproaches
are unfounded?
We cannot do more than inform our customers through all kinds of channels. If
there are still deficits in this respect we'll have to improve this item.
Today's trend heads towards a modular structure of software systems. The
individual module can be purchased from different suppliers. Where will your
integrated concept be in the future ?
Our integrated solution is very successful and just what the enterprises need.
The future scenario may certainly look different. Various software packages
are puzzled together to a whole. We are confident that this is feasible. We
already run the first test projects. We want to play a leading role in this
scenario.
SAP-System
A Giant Framework
SAP's success is based on a simple idea: instead of writing their own programs
for financials, material- and personnel administration or logistics the
companies can purchase standard software from SAP. SAP has defined the ideal
characteristic business processes in a reference model. The advantage of the
alreayd formed programs is that the companies need not take the part of a
software supplier themselves and need not continue the development of the
programs which causes high expenses. The service for self-made software can be
ten times more expensive than the investment in the development of the program
itself.
The software modules for accounting, general ledger, sales or material
resources management are linked together. As soon as sales dept. has delivered
goods an invoice is issued automatically and claims for delivered material are
settled immediately. On order entry the respective material orders are send to
warehouse. When parts are taken from the warehouse purchasing dept. receives
the order to order new parts. Additionally, integration allows to consolidate
the company's code numbers which means more efficient controlling.
A standard program, however, can never exactly picture the individual
requirements of the different enterprises and so it always has to be adapted
to a certain extent - experts call this customizing or parametering. As a
basis they use the detailed company structure as well as seed data describing
material, assets or employees.
How these data get through the system and which actions they trigger off SAP
demonstrates with a giant formswork. Which concrete types of orders with which
data exist in an enterprise, which rights the purchaser has, how an entered
order is processed, what the cost centers look like, which payments are booked
on which accounts, whether the company has a simple bill of material, a closed
or a variable open bill of material, what the analysis procedures of
controlling look like: all this is written down in almost 3000 forms with
almost half a million fields. Each single field is like some kind of adjusting
screw that adjusts the general functionality of the SAP-modules to the
concrete application case. Thus the user can chose in each field how to fill
it in. If the functionality is not sufficient, like for very specified data
analysis the user has to create question routines in SAP's own programming
language Abap.
----- End of Message -----
--
"And this is all I have to say about that..." - F. Gump
`o<'
---------------------------------oo0(__)0oo--------------------------------
__ __ __ __ __ _ _ __ U __ _ __ _
/__\ ( )( )( )( )( \( ) ( ) /__\( ( ) ) This message is
/(__)\ )(__\ () / )( ) ( )(__ /(__)\\ / / brought to you from
(__)(__)(____)\__/ (__)(_)\_) (____)(__)(__)\/\/ Cedar Creek, California
Christopher B. Browne
>
>In article <3o7hai$l...@gulfa.kw.us.com>, <jeh...@access.kw.us.com> writes:
>> SAP has the best marketing and demo staff on the planet. Their utilization
>> of machine resources and Oracle is quite humorous compared to other efforts
>> I've seen. Just compare SAP's hardware requirements to your own development
>> experience.
>
>Absolutely true. However, have you ever seen a cheap implementation of
>client/server? (No, screen scraping doesn't count). Their fundamental
>paradigm, is that databases like Oracle, and Informix already do what
>good databases ought to do. If the backend databases run like pigs then
>that is more a function of Oracle/Informix than SAP.
What's a little troubling is that there isn't *all* that much advantage
to the strategy of supporting multiple backend databases.
If you write an Oracle query that doesn't go through R/3 (meaning
that it won't *really* be an Oracle query, but rather an ABAP query),
there is very little guarantee that you will actually get anything
resembling the real data because of all the additional buffering that
R/3 does.
If you write an Oracle program that *writes* to the database
directly, you really risk trashing the system, particularly if
you do it while R/3 is running. (It might not be *as* unsafe if
R/3 is down. Although that is rank speculation. I have heard SAP
staff stating that writing direct to the DBMS is drastically unsafe
to the point of voiding warrantees of the software's fitness, and
that reading data directly is not guaranteed to provide correct
results.)
Based on all this, R/3 might as well be using a proprietary RDBMS,
because they really don't want to let you get at the data directly.
Moreover, they'd probably gain in performance if they decided to
actually directly support one or another of the products. I think
you'd see much better performance if R/3 was written to run solely
under Oracle. Or solely under Informix. Or, for that matter, under
an SAP-developed RDBMS.
The apparent fact that it's "compatible" with all sorts of RDBMS
systems has its own bit of "smoke and mirrors." It may *work* with
the products, but that doesn't gain you the things you'd expect it
to provide, and means that there is another vendor to deal with
as well as another possible point of failure.
--
Christopher Browne - cbb...@io.org
Microsoft Office - What you use when you don't have access to good software.
Dave Erickson
> Date: 7 MAY 1995 15:23:53 -0400
> From: Christopher B. Browne <cbb...@io.org>
> Newgroups: sci.engr.manufacturing, comp.databases.pick,
> comp.databases.oracle, comp.client-server
> Subject: Re: SAP vs. BPCS vs. Master-Pack vs. Oracle-Manufacturing
In SAP's defense, I can't imagine putting out an application where the users
are encouraged to do database writes/updates and still guarantee the integrity
of the database, unless your application is written entirely in database
triggers. This would be a pretty major task, considering the size of SAP's
application and the fact that R/3 is their first foray into RDBMS.
Now Read-Only access, on the other hand, should be available, with the
understanding that there is no warranty or support agreement covering the
user's own reports. Ie, if you come up with a report that you believe shows
some problem data, you shouldn't expect support from SAP, as you may be
interpreting the database wrong.
IMO, the main reason to be database engine independent is not so much to
allow users to use their own tools to access your database, it's to allow
users with existing SUPPORT bases for various DBMS platforms to support
installation and maintenance of your application easier, especially when the
client in question may have corporate standards and alliances exclusively with
one RDBMS vendor and can not practically deal with any others.
-- Just my contribution to the discussion without really contributing to the
original topic; all the expected disclaimers about my opinion vs. my employers
apply...
Dave
David B Erickson, Project Leader *
McHugh Freeman * "YIP YIP YIP YIP YIP YIP YIP YIP YIP"
eric...@mfa.com * -Dino
Mark Schmidt
>
>> This is really a questionable commitment. Next time you talk to an SAP
>> person ask some questions about which operating systems they have actually
>> installed R3 on. Try to talk to someone in the IS group at a customer that
>> really is running R3. And if you really want some entertainment, ask
>> SAP about using some other Oracle based tools (say SQL*Forms or SQL*Report)
>> against the Oracle tables used by R3. You'll be impressed by their answers.
>> way the rest of the world does. An open system that cuts off your access to
>> the underlying DBMS engine? How open is that? Why don't they use Oracle in
>> the "normal" fashion? Ask SAP, it's fun.
If you really want to have some fun, ask an SAP person about
implementation times for r/3 and what their customers say
about "time to benefit." Find out how long it takes to
implement, and how many consultants from a big-6 it will
take to get your system up and running; and then you will
understand why so many big-6 firms recommend SAP. Find out
how much hardware you will need to run r/3, and how much
more you will need to run it well; and then you will understand
why so many hardware companies push SAP.
Compare that to QAD's MFG/PRO (manufacturing, distribution,
financial, service and support applications). You won't have
to give your first-born to the company that helps your
implementation, and you won't need to add a new wing to your
offices to hold all the hardware, but you could recognize your
'time to benefit and profit' in six months or less.
Besides that, MFG/PRO is written in simple-but-powerful Progress
4GL. And it runs on Progress or Oracle RDBMSs.
Besides, "3-tier" just means 'client-server-server'. MFG/PRO
is client-server. :)
mark.
Trevor Paquette
.. deleted ..
> Excellent point. From my company's perspective, we are leaning towards SAP
> for the same reasons we chose Microsoft Office as a standard. If you look at
> any one of the Microsoft Office products you will find that another company has
> a better product. However, the integration is the key. People are tired of
> having 10 to 20 legacy systems that do not talk to one another. Getting
> information from one application into another is like being in the tower of
> Babel. Both Microsoft and SAP did an excellent job of tying the products in
> their suite together so that they are more than just the sum of their parts.
>
You have obviously never had to tie Microsoft with other applications.
I am talking about products outside of Microsoft. Sure it works great as long
as you are within the Microsoft family of products. Everything is all nice
and fuzzy within the worm comfortable walls of Microsoft..
Meanwhile back in the REAL WORLD, the REAL people who have to deal with the
REAL issues in REAL time, applications dictate that it should be relativily
easy to mesh with your entire suite of applications..
Microsoft has never (In My Humble Opinion) been able to do this without
turning summersaults, doing a jumbling act, and doing hi-wire without a net..
--
Name:Trevor Paquette |Alberta Energy Company Ltd |Work: (403)266-8400
Email:TrevorP...@aec.ca|3900, 421 7th Ave S.W. | Fax: (403)290-8400
postm...@aec.ca |Calgary, Alberta, Canada |ICBM: 51'05"N/114'01"W
ro...@aec.ca |T2P 4K9 |Mind: In the Rockies..
Trevor Paquette
.. deleted ..
> Excellent point. From my company's perspective, we are leaning towards SAP
> for the same reasons we chose Microsoft Office as a standard. If you look at
> any one of the Microsoft Office products you will find that another company has
> a better product. However, the integration is the key. People are tired of
> having 10 to 20 legacy systems that do not talk to one another. Getting
> information from one application into another is like being in the tower of
> Babel. Both Microsoft and SAP did an excellent job of tying the products in
> their suite together so that they are more than just the sum of their parts.
>
You have obviously never had to tie Microsoft with other applications.
James & Cathy Marland
writes:
>THE FOLLOWING STATEMENTS REPRESENT MY OPINIONS AND EXPERIENCE ONLY!
THEY
>ARE NOT REPRESENTATIVE OF ANY EMPLOYER PAST OR PRESENT OR OF ANYTHING
ELSE,
>THEY ARE ONLY MY OPIONS!
>
>In article <3o3jft$p...@huron.eel.ufl.edu>, b...@rosenberg.org says...
>
compared
>>various vertical application packages for manufacturing and
distribution.
>>
>>Is SAP really as great as Mr. Vargas says that it is?
>
>SAP has the best marketing and demo staff on the planet. Their
utilization
>of machine resources and Oracle is quite humorous compared to other
efforts
>I've seen. Just compare SAP's hardware requirements to your own
development
>experience.
>
doesn't
>really seem to provide much functionality. In order to get a SAP
module to
>do what you want you HAVE to write a lot of ABAP code. Kinda like
saying
>"my package does everything, and look it includes a C compiler so that
you
>can extend it to do anything it doesn't already do". As far as I can
tell,
>what SAP software does best is sell time for SAP consultants.
>
>>
>>from the success of SAP?
>
>excellence.
>
>>
>>would SAP be a good fit?
>
>The sort that can change their practices and procedures to fit the SAP
>model.
>
>>
>>For what sorts would SAP be ill-suited?
>
>Any that do things differently (better) than the SAP business model.
>
>- jim
>--
>An expatriated American hoping to find some fun!
>
Now lets get a few things clear here. No "off-the-shelf" application
will ever completely match th requirements of the Enterprise. SAP
provides key core functionality, and customisation tools to tailor the
business models.
SAP customisation is not writing code, but configuring a system to meet
your needs. This frequently means adding entries to tables which have
externalised program logic. SAP is sometimes criticized for have
"100's" of tables to configure. Of course the competition merely
hardcode logic in these types of situations.
Also, with regard to the "best marketing and demo staff", SAP spends a
spectacularly small amount of money on Sales and Marketing, compared
with Oracle, for example. The last annual reports indicates that SAP
has yet again exceeded 20% of revenue invested in R&D.
James Marland
mar...@ix.netcom.com
James & Cathy Marland
writes:
>
>In article <3o841c$f...@crl10.crl.com>, dcr...@crl.com says...
>>
>>David Crane (dcr...@crl.com) wrote:
>>
>>: SAP has definitely taken the market by storm. Good writeup
recently (in
>>: Infoworld, as I recall).
>>
>>The article I had in mind was in INFORMATIONWEEK on April 24th. They
>>mention Dow Chemical and DuPont as early users of SAP in the USA.
They
>>claim 3,000 installations worldwide and 300 in the USA. Article
points
>>out that SAP is not cheap, costing from $1 million to $10 million,
>>including consultants. It also requires a lot of server horsepower.
>
>There was also an article posted recently on the SAP Listserver from a
>german business magazine that ran down a whole host of problems
experienced
>by several european companies when trying to implement SAP. Perhaps
>somebody from the SAP Listserver could post that article.
>
>><snip>
>>Strengths:
>>Effective use of three-tier client server (they push hard on the fact
>> that they have an "application server" level).
>>Tight data integration across departmental boundaries
>>Comprehensive functionality spanning the enterprise
>>Committed to open systems
>
>This is really a questionable commitment. Next time you talk to an
SAP
>person ask some questions about which operating systems they have
actually
>installed R3 on. Try to talk to someone in the IS group at a customer
that
>really is running R3. And if you really want some entertainment, ask
>SAP about using some other Oracle based tools (say SQL*Forms or
SQL*Report)
>against the Oracle tables used by R3. You'll be impressed by their
answers.
> Basically you can't access the data because they don't use Oracle the
same
>way the rest of the world does. An open system that cuts off your
access to
>the underlying DBMS engine? How open is that? Why don't they use
Oracle in
>the "normal" fashion? Ask SAP, it's fun.
>
Yes its' fun. SAP recommends any SQL or ODBC tools to report against
the data. In fact these tools are even used in Sales Demonstrations,
including the construction of the Database View (never usually shown in
a presentation !). SAP stores the data in the same way as every other
RDBMS user - of course some DBAs choose to de-normalise for
performance, but this approach is no different from other OLTP RDBMS
systems. SAP recommends no de-normalisation for the current release.
Not sure I understand the comment about SAP not running on all of its
supported Operating Systems.
James Marland
mar...@ix.netcom.com
Stefan Zwischenbrugger
- you now are able to do everything with ABAP (Code an ABAP as an Add-on to
run unmodified transactions! it works!)
The company I work for is going to install Oracle Financials in their
market-organizations, thinking Oracle is more flexible. (Database and tools
are smart...)
8 years SAP experience:
DON'T let SAP-consultants fix bugs without reporting them on OSS (the online
service system of SAP)!!!
Dennis Weatherly
[snip]
> > >
> > >For what sorts of manufacturing and distribution businesses
> > >would SAP be a good fit?
> >
> > The sort that can change their practices and procedures to fit the SAP
> > model.
> >
> don't fit out of the box you have to customize.
>
> -Enrique Vargas
> var...@ixc.net
>
>
Out of the box, SAP provides a dizzying array of configuration options that
you can choose from during implementation. They don't fit every business
model (I doubt anyone's package does) but they do give you a _lot_ of
flexibility. This is one of the reasons that SAP is not easy or quick to
implement; you have to map your business practices and configure SAP
appropriately.
Dennis Weatherly
Mentor Graphics Corp
dennis_w...@mentorg.com
Jim Hall
eric...@mfa.com says...
>In SAP's defense, I can't imagine putting out an application where the
users
>are encouraged to do database writes/updates and still guarantee the
integrity
>of the database, unless your application is written entirely in database
>triggers. This would be a pretty major task, considering the size of SAP's
>application and the fact that R/3 is their first foray into RDBMS.
It goes deeper than that Dave. SAP doesn't want/allow direct updates to the
database because of the way that they "cluster" (note this is not the same
as the Oracle meaning of the word "cluster") tables. Basically you cannot
read/write/update tables that are used by the SAP applications. Your MFA
applications still allow others systems/applications to read the data from
your tables. SAP does not.
>Now Read-Only access, on the other hand, should be available, with the
>understanding that there is no warranty or support agreement covering the
>user's own reports. Ie, if you come up with a report that you believe
shows
>some problem data, you shouldn't expect support from SAP, as you may be
>interpreting the database wrong.
See my note above, this was my point way back on this thread. SAP does NOT
allow access to their tables. This is because they don't use Oracle in
anything that could be considered a "normal" fashion.
>IMO, the main reason to be database engine independent is not so much to
>allow users to use their own tools to access your database, it's to allow
>users with existing SUPPORT bases for various DBMS platforms to support
>installation and maintenance of your application easier, especially when
the
>client in question may have corporate standards and alliances exclusively
with
>one RDBMS vendor and can not practically deal with any others.
This is a debate that you and I (and many others) have gone over before.
But it doesn't really apply here, since an SAP/Oracle database will likely
not comply to any corporate standards regarding Oracle. SAP is still very
much grounded in the ISAM file mentality. All their "use" of Oracle buys is
the ability to market the SAP product line as being "relational" and "open".
The simple fact that it is neither, of course doesn't count for much, since
SAP is more of a marketing machine than a software vendor.
>-- Just my contribution to the discussion without really contributing to
the
>original topic; all the expected disclaimers about my opinion vs. my
employers
>apply...
OBTW - Dave, do you have any experience integrating one of your MFA apps w/
SAP? How smoothly/roughly did it go? What sorts of pitfalls did you hit?
- jim
--
An expatriated American hoping to find some fun! (formerly
ha...@stimpy.mfa.com)
Jim Hall
says...
::> Excellent point. From my company's perspective, we are leaning towards
:> for the same reasons we chose Microsoft Office as a standard. If you look
at
:> any one of the Microsoft Office products you will find that another
company has
:> a better product. However, the integration is the key. People are tired
of
:> having 10 to 20 legacy systems that do not talk to one another. Getting
:> information from one application into another is like being in the tower
of
:> Babel. Both Microsoft and SAP did an excellent job of tying the products
in
:> their suite together so that they are more than just the sum of their
parts.
: You have obviously never had to tie Microsoft with other applications.
:I am talking about products outside of Microsoft. Sure it works great as
long
:as you are within the Microsoft family of products. Everything is all nice
:and fuzzy within the worm comfortable walls of Microsoft..
: Meanwhile back in the REAL WORLD, the REAL people who have to deal with
the
:REAL issues in REAL time, applications dictate that it should be relativily
:easy to mesh with your entire suite of applications..
: Microsoft has never (In My Humble Opinion) been able to do this without
:turning summersaults, doing a jumbling act, and doing hi-wire without a
net..
Of course, neither has SAP. Integration with SAP software is quite
difficult - especially since you can't share data from Oracle tables with an
SAP application (so what's the point of SAP using Oracle - other than
marketing).
Cynthia Young Pinchot
>. . . . From my company's perspective, we are leaning towards SAP
> . . .
My company purchased SAP Financials several months ago, and is in the
conversion process now. Some other factors to consider before purchase are:
1) It is complex. Most conversions to SAP require help from consultants
knowledgeable of the SAP product. Unfortunately, those people are in
very short supply and in high demand, and thus are now extremely expensive
$$$$$$, and have waiting lists that are months long.
2) Although the SAP financials package we purchased uses an Oracle database,
it does not use it as a true relational database.
It stores the data in non-relational formats. Then it adds an extra layer
for conversion in the application. For example, it stores all the fields
for one table into one very wide column. Because of this and other reasons,
normal query tools and report tools written for Oracle cannot be used against
the database. Also, some of the normal tuning techniques, such as adding
another Oracle index, are not possible.
As another person pointed out,
>> Clients should be aware, however, that "off the shelf" doesn't mean that
>> SAP can be installed for the price of the software. The average cost of
>> getting things up is about four consulting bucks for each licensing dollar.
>> That is, multiply by five.
The opinions expressed above are my own (or those of people quoted).
The opinions do not represent my employer.
Cynthia Pinchot
DBA
PG&E
Christopher B. Browne
Mark Liversedge <ma...@yaffle.demon.co.uk> wrote:
>DISCLAIMER: I do not, and never have, worked for SAP and do not
> speak for them. I am, however, an R/3 BC consultant.
Likewise.
>>Try to talk to someone in the IS group at a customer that really
>>is running R3.
>
>I do everyday. What is your point?
It must be admitted that there are a lot of sites still "in
test" that are not using R/3 as a "live" system. If you're
fortunate enough to be amongst those that are "really running
R/3" as opposed to "getting it ready to run," then more power
to you!
>>And if you really want some entertainment, ask SAP about using some
>>other Oracle based tools (say SQL*Forms or SQL*Report) against the
>>Oracle tables used by R3. You'll be impressed by their answers.
>
>Well, not impressed, re-assured maybe.
Reassured that "You really ought to be using ABAP, SAPScript, and
ABAP-Query to do the job. And offline batched ABAP transactions
if you really must read/write from external sources."
Reassured that you really shouldn't use SQL*Forms to implement parts
of system functionality.
>>Basically you can't access the data because they don't use Oracle
>>the same way the rest of the world does. An open system that cuts
>>off your access to the underlying DBMS engine? How open is that?
>>Why don't they use Oracle in the "normal" fashion? Ask SAP, it's
>>fun.
>
>False [and bordering on rumour mongering]. Most tables are stored
>transparently, ie DB level == SAP level view of a table; these
>include all static 'master' data like materials, vendors, customers
>etc and can be read directly from the DB.
I disagree.
The point is that Oracle tables can only reasonably be accessed by
using R/3 as a go-between, not by using Oracle (or Informix etc)
native tools.
- If you use Oracle's tools to read the data, there are no
guarantees that the data won't be out of date due to the
buffering that takes place within R/3.
- If you use Oracle's tools to *write* data to the DBMS, you're
liable to seriously mess up the system integrity, because you
can't ensure that what you wanted to update wasn't in a buffer
that Oracle couldn't touch.
A supposed selling feature of R/3 is that you're using a
non-proprietary RDBMS (i.e. one not proprietary to SAP AG).
Unfortunately, you aren't allowed to access the data using
other than the proprietary tools provided by SAP AG. I don't
take this to be "rumour-mongering."
--
Christopher Browne - cbb...@io.org
In most of their applications, GUIs are primarily a tool that enables
capitalists to exploit cheap, dispensable, unskilled labour.
Mark Liversedge
In article <3qo9uq$1...@yaffle.demon.co.uk> Mark Liversedge (ML) wrote:
[stuff deleted... assume nodding of head]
>>>And if you really want some entertainment, ask SAP about using some
>>>other Oracle based tools (say SQL*Forms or SQL*Report) against the
>>>Oracle tables used by R3. You'll be impressed by their answers.
ML> Well, not impressed, re-assured maybe.
CB> Reassured that "You really ought to be using ABAP, SAPScript, and
CB> ABAP-Query to do the job. And offline batched ABAP transactions
CB> if you really must read/write from external sources."
Agreed for write, not for read.
CB> Reassured that you really shouldn't use SQL*Forms to implement parts
CB> of system functionality.
>>>Basically you can't access the data because they don't use Oracle
>>>the same way the rest of the world does. An open system that cuts
>>>off your access to the underlying DBMS engine? How open is that?
>>>Why don't they use Oracle in the "normal" fashion? Ask SAP, it's
>>>fun.
ML> False [and bordering on rumour mongering]. Most tables are stored
ML> transparently, ie DB level == SAP level view of a table; these
ML> include all static 'master' data like materials, vendors, customers
ML> etc and can be read directly from the DB.
CB> I disagree.
CB> The point is that Oracle tables can only reasonably be accessed by
CB> using R/3 as a go-between, not by using Oracle (or Informix etc)
CB> native tools.
True for writing, false for reading.
CB> - If you use Oracle's tools to read the data, there are no
CB> guarantees that the data won't be out of date due to the
CB> buffering that takes place within R/3.
I disagree. The application server buffers do not have lazy write.
The bufrefmode setting assures the R/3 buffers stay in sync &
instruct an appserver to re-read the DB for up-to-date data.
CB> - If you use Oracle's tools to *write* data to the DBMS, you're
CB> liable to seriously mess up the system integrity, because you
CB> can't ensure that what you wanted to update wasn't in a buffer
CB> that Oracle couldn't touch.
Agreed; don't update the DB outside of R/3. But not because of R/3
buffers; because of DB integrity which is not implemented at the
database -- this is a very perceivable shortfall. If you update
the DB outside of R/3 on YOUR OWN tables then the R/3 buffers will
need re-syncing to reflect your changes. (The same is true for any
R3trans updates on SAP delivered tables).
In plain english, the R/3 buffers always reflect the DB, unless
you update the database outside of SAP.
CB> A supposed selling feature of R/3 is that you're using a
CB> non-proprietary RDBMS (i.e. one not proprietary to SAP AG).
CB> Unfortunately, you aren't allowed to access the data using
CB> other than the proprietary tools provided by SAP AG. I don't
CB> take this to be "rumour-mongering."
What I said (and was silently deleted) in the previous message
still holds true -- if you want to access data from outside of R/3
then you can -- "just" run SE11 & SE14 on the tables you wish to
access. Admittedly you must only ever READ these tables.
User updates of the DB on SAP delivered tables outside of SAP is
unsupported and no secret is made of this fact.
Sorry, if this sounds like a flame ;-)
[sig deleted]
--
Mark Liversedge | space [absence of matter] is infinite; matter is finite
DRUID SYSTEMS LTD | I speak only for myself, I suggest you do likewise...
Mark Liversedge
speak for them. I am, however, an R/3 BC consultant.
Anyway, I'm resurrecting this thread due to a late arrival, this reply
is fairly long by my standards [83 lines of text] and lightly edited ...
In article <3oar8j$6...@gulfa.kw.us.com>, Jim Hall wrote:
[stuff deleted]
>>[SAP are] committed to open systems
>This is really a questionable commitment. Next time you talk to an SAP
>person ask some questions about which operating systems they have actually
>installed R3 on.
HP-UX
OSF/1, Ultrix
AIX
Solaris
Windows NT
There are other platforms though: SINIX (Siemens Nixdorf R/3 Live)
and BOS (?) from Bull (which is essentially AIX). There was OpenVMS
[now withdrawn; due to low user demand] and, similarly, MPE.
>Try to talk to someone in the IS group at a customer that really
>is running R3.
I do everyday. What is your point?
>And if you really want some entertainment, ask SAP about using some
>other Oracle based tools (say SQL*Forms or SQL*Report) against the
>Oracle tables used by R3. You'll be impressed by their answers.
Well, not impressed, re-assured maybe.
>Basically you can't access the data because they don't use Oracle
>the same way the rest of the world does. An open system that cuts
>off your access to the underlying DBMS engine? How open is that?
>Why don't they use Oracle in the "normal" fashion? Ask SAP, it's
>fun.
False [and bordering on rumour mongering]. Most tables are stored
transparently, ie DB level == SAP level view of a table; these
include all static 'master' data like materials, vendors, customers
etc and can be read directly from the DB.
A "few" tables are stored in cluster records for performance, and
some are stored in pools for resource/bufferring control; these
tables cannot be read from the DB directly --- however --- you are
more than welcome to change the table type to transparent (using
SE11) and convert the DB level store (using SE14]) to allow reading
directly from the DB.
Of the so-called unreadable tables, the vast majority are tables
which control the SAP application functionality (customisation).
Some are base configuration, and a small percentage are document
data [the stuff you most likely want to read from outside].
The cluster tables may seem offensive at first glance but they do
offer a performance gain and that is why they are there. If you
are more interested in "OPEN" databases then you are welcome to
take the performance hit of converting them to transparent.
I do sympathise with the original poster's comments, I thought the
same when I first saw these cluster/pool tables; In the real world,
taking note of the above comments, this is not an issue.
[more stuff deleted]
>>Weaknesses:
>>Complex configuration
>>Lengthy, company-wide design cycle
>>Business processes must be fit to SAP model, not vice versa
>How about that you have to ABAP code the functionality you need, and guess
>who makes money on just about every ABAP consultant that there is?
This might be stated more favourably ... [I translate to :-)]
"How about that if the functionality you require is not currently available
SAP do support the end-user organisation extending the base system using
the ABAP/4 language, and changes to SAP delivered code is possible, since
the application is delivered in source code format. In some instances,
end-user organisations have worked alongside SAP and have shared their
experiences for the benefit of all."
Personally, I find the frequent upgrades irritating and some of the
security aspects frightening (e.g: SAPR3/SAP or SAP*/PASS or SAPCPIC/ADMIN).
The architecture, however, is IMHO, robust and extendable, but I guess
I am biased ...
Jeff Schasny
mazu...@netcom.com (Sanjay Mazumdar) writes:
[SNIP]
>In my experience very often business practices develop over time around
>limitations of existing systems and organizations are reluctant to let
>established procedures go although there is really no fundamentally
>logical reason to hold on to them. I think this is normal since it hard
>for us to change our habits. If however the goal is to try and make SAP
>behave contrary to it's nature as defined by the data dictionary then
>I think it becomes a higher risk venture.
oh...my...god... if thinking like this is what SAP is all about I'm suprised
that ANYONE would buy it. Make the business fit the software? This cant
even be defined as a misplaced focus, I remember attitudes like this from
the days of propriatary operating systems.
Jeff
===================================================
Jeff Schasny | DoD# 1735 '87 Yamaha FZ700
jsc...@rmii.com | http://rainbow.rmii.com/~jschas
===================================================
Jim Hall
<comments about implementation successes snipped>
>The R3 system I think is the the closest to an open system if there is one.
>The point of the original poster that of using SQLFORMS violates the
principle
>of open systems firstly. Also as a long time user of Oracle, Informix,
Ingres
>and Progress I think Oracle is the worst interface.
I'm curious how you derived your opinion that SQL*Forms violates the
principle of open systems. Could you please explain this? And I think the
point here is that while SAP touts their "openess" due to the utilization of
Oracle - you cannot use Oracle tools to access/manipulate the data in the
database in an "open" manner (i.e. restrictions on both reads and writes
done outside of the SAP tools).
Sanjay Mazumdar
implementations of FI, MM, SD quite painlessly. My fastest was 8 months to
a live system. I use the term painless relatively. There were times during
the implementation that I probably did not think so. There are parts of the
system that I think could be improved.
The R3 system I think is the the closest to an open system if there is one.
The point of the original poster that of using SQLFORMS violates the principle
of open systems firstly. Also as a long time user of Oracle, Informix, Ingres
and Progress I think Oracle is the worst interface.
I am not affiliated to SAP or any of the other database companies. The issue
I think is that SAP is an extremely complex system. If you do not subscribe
to the SAP model then you should not buy it. If the goal is to operate a
corporation adequately with an integrated system and are willing to
re-engineer your business model after examining the business practices then
you have a very good chance of success.
In my experience very often business practices develop over time around
limitations of existing systems and organizations are reluctant to let
established procedures go although there is really no fundamentally
logical reason to hold on to them. I think this is normal since it hard
for us to change our habits. If however the goal is to try and make SAP
behave contrary to it's nature as defined by the data dictionary then
I think it becomes a higher risk venture.
--
Sanjay Mazumdar
mazu...@netcom.com
Disclaimer:
The views expressed are mine and mine alone.
Jim Hall
In article <mazumdarD...@netcom.com>, mazu...@netcom.com says...
>
>Jim Hall (jeh...@access.kw.us.com) wrote:
>
>: I'm curious how you derived your opinion that SQL*Forms violates the
>: principle of open systems. Could you please explain this? And I think
the
>: point here is that while SAP touts their "openess" due to the utilization
of
>: Oracle - you cannot use Oracle tools to access/manipulate the data in the
>: database in an "open" manner (i.e. restrictions on both reads and writes
>: done outside of the SAP tools).
>
>Jim SQL*Forms is a proprietory interface and not a standard adopted by
>the industry. SAP R3 runs on a variety of S/W and H/W systems from
different
>manufacturers and that list grows longer every year. Just because you do
not
>use Oracle's proprietory interface in their system does not mean that
>they are not open.
I feel that since I cannot use Oracle's tools to access and manipulate SAP
data stored in an Oracle database used by SAP that SAP is NOT open in any
real sense of the word. Just my opinion, but it would seem reasonable to be
able to access and manipulate the data. That fact that SAP closes me off
from doing so bothers me excessively.
>
>Anothger point is that R3 is an application running on a database. If
Oracle
>is an open system (which they claim to be) then I should be able to run
>other user interfaces on it. However I cannot for example run Ingres's ABF
>(a significantly superior one IMO) on it. That is because none of these
>are accepted industry standards.
I can run SQL*Forms against a variety of back-ends. Is it Oracle's or
Ingres' fault that ABF doesn't run against Oracle? Other vendors and
applications (i.e. PowerBuilder) can run against Oracle. Anybody who wants
to write code conforming to the ANSI SQL standard can run against Oracle.
Conformance to a standard would seem to be to be part of the definition of
"open".
Let us also extend your argument here to SAP. SAP uses Oracle (at some
sites). If SAP is open, which they claim to be, I should be able to use
other tools to access the data (as you state). However, since I can't even
use Oracle's tools to access SAP data in an Oracle database, how can you
consider SAP to be open?
>
>IMO SAP refers to itself as an open system solution since it gives you a
choice
>of vendors in H/W and S/W including IBM, HP, DEC, Microsoft, Oracle,
Sybase,
>Informix etc. A system that can run on O/S's as diverse as UNIX, VMS, NT
>is quite "open" as far as I see it.
I see. You then also consider WordPerfect to be an open system since it
runs on IBM, HP, and DEC hardware platforms utilizing Unix, DOS, NT, and
VMS. I'm surprised. I always thought that "open" refered to cooperation
and sharing of resources. I apologize for my simple minded
misunderstanding. If "open" means simply being able to run in a proprietary
and closed fashion on a number of different hardware platforms and OS's then
SAP is indeed open.
My-Phuong L Tran
>
>: I'm curious how you derived your opinion that SQL*Forms violates the
>: principle of open systems. Could you please explain this? And I think the
>: point here is that while SAP touts their "openess" due to the utilization of
>: Oracle - you cannot use Oracle tools to access/manipulate the data in the
>: database in an "open" manner (i.e. restrictions on both reads and writes
>: done outside of the SAP tools).
>
>Jim SQL*Forms is a proprietory interface and not a standard adopted by
>the industry.
Hi Sanjay,
Do you mean that SQL*Forms is proprietary software? I don't know what
you mean by a 'proprietary interface'. Perhaps you mean that SQL*Forms
produces applications (i.e. a GUI front end) that will not run
independently of Oracle. If this is what you mean, then I agree.
However, in terms of GUI standards (i.e. the 'look and feel'), I think
a SQL*Forms interface is totally(?) compliant with Microsoft and CUA
standards. Microsoft as a standard - interesting double speak.
>
>Anothger point is that R3 is an application running on a database. If Oracle
>is an open system (which they claim to be) then I should be able to run
>other user interfaces on it. However I cannot for example run Ingres's ABF
>(a significantly superior one IMO) on it. That is because none of thes
>are accepted industry standards.
I'm not sure what an 'open' system is in terms of a user interface is,
but Oracle is a relational database. Are there 'open' standards for
relational databases? SQL is an open standard. I would think Oracle is open i
in this sense. You can use OCI API functions to access the database. Perhaps so
someone else with more knowledge can say when a RDBMS is 'open'.
>IMO SAP refers to itself as an open system solution since it gives you a choice
>of vendors in H/W and S/W including IBM, HP, DEC, Microsoft, Oracle, Sybase,
>Informix etc. A system that can run on O/S's as diverse as UNIX, VMS, NT
>is quite "open" as far as I see it.
That's not what 'open' typically refers to.
Best,
Ted Karas
Sanjay Mazumdar
<snip>
: oh...my...god... if thinking like this is what SAP is all about I'm suprised
: that ANYONE would buy it. Make the business fit the software? This cant
: even be defined as a misplaced focus, I remember attitudes like this from
: the days of propriatary operating systems.
I just was pointing out from my experience what happens when people try to
make modifications in the SAP without understanding the full impact. Making
the business fit the software is not as ridiculous when you you consider
the amount of flexibility that the R3 system has. And considering the
value of the tools provided it is a relatively small price to pay.
If you consider this a misplaced focus that is your prerogative. However
there is a difference between an application information system and
an operating system. The two kinds are not comparable.
Sanjay Mazumdar
: I'm curious how you derived your opinion that SQL*Forms violates the
: principle of open systems. Could you please explain this? And I think the
: point here is that while SAP touts their "openess" due to the utilization of
: Oracle - you cannot use Oracle tools to access/manipulate the data in the
: database in an "open" manner (i.e. restrictions on both reads and writes
: done outside of the SAP tools).
Jim SQL*Forms is a proprietory interface and not a standard adopted by
the industry. SAP R3 runs on a variety of S/W and H/W systems from different
manufacturers and that list grows longer every year. Just because you do not
use Oracle's proprietory interface in their system does not mean that
they are not open.
Anothger point is that R3 is an application running on a database. If Oracle
is an open system (which they claim to be) then I should be able to run
other user interfaces on it. However I cannot for example run Ingres's ABF
(a significantly superior one IMO) on it. That is because none of these
are accepted industry standards.
IMO SAP refers to itself as an open system solution since it gives you a choice
of vendors in H/W and S/W including IBM, HP, DEC, Microsoft, Oracle, Sybase,
Informix etc. A system that can run on O/S's as diverse as UNIX, VMS, NT
is quite "open" as far as I see it.
--
Christopher B. Browne
Sanjay Mazumdar <mazu...@netcom.com> wrote:
>Jeff Schasny (jsc...@rmii.com) wrote:
>
><snip>
>
>: oh...my...god... if thinking like this is what SAP is all about I'm suprised
>: that ANYONE would buy it. Make the business fit the software? This cant
>: even be defined as a misplaced focus, I remember attitudes like this from
>: the days of propriatary operating systems.
>
>I just was pointing out from my experience what happens when people try to
>make modifications in the SAP without understanding the full impact. Making
>the business fit the software is not as ridiculous when you you consider
>the amount of flexibility that the R3 system has. And considering the
>value of the tools provided it is a relatively small price to pay.
I'm of two minds about this; on the one hand, it *does* mean that
users are virtually *required* to make their business fit the software,
and not the other way around. Which definitely has some problems with
it.
However.
a) There are a lot of business processes that are pretty generic across
a lot of industries. Accounts Payable processes are pretty similar,
whatever company you may be at, for instance. FASB accounting
requirements will be true for all US companies.
b) Some of the convergence is becoming increasingly necessary. If you're
using EDI, you probably need to have processes and models that are pretty
similar to those your suppliers/vendors/customers are using, otherwise
it's going to be a pain to get the data translated from one form to the
other. In other words, conforming to SAP's model may be painful, but
the pain was a given because there was some conformance that was going
to be necessary by virtue of business relationships.
c) The SAP business model does have quite a lot of flexibility within
it. You can set a lot of parameters that will have significant effect
on how well it fits the way your company is used to doing things. While
you're having to conform to "their model," it's not a *really* rigid
model.
Some companies will find the enforcement of SAP's model requirements
acceptable (e.g. worth the pain); others will find it overly intrusive.
--
Christopher Browne - Email:<cbb...@io.org>, WWW:<http://www.io.org/~cbbrown/>
"I believe OS/2 is destined to be the most important operating system,
and possibly program, of all time." -- Bill Gates
Mark Schultze
>From: cbb...@io.org (Christopher B. Browne)
>Subject: Re: SAP vs. BPCS vs. Master-Pack vs. Oracle-Manufacturing
>In article <mazumdarD...@netcom.com>,
>Sanjay Mazumdar <mazu...@netcom.com> wrote:
>>Jeff Schasny (jsc...@rmii.com) wrote:
>>
>><snip>
>>
>>: oh...my...god... if thinking like this is what SAP is all about I'm suprised
>>: that ANYONE would buy it. Make the business fit the software? This cant
>>: even be defined as a misplaced focus, I remember attitudes like this from
>>: the days of propriatary operating systems.
>>
>b) Some of the convergence is becoming increasingly necessary. If you're
>using EDI, you probably need to have processes and models that are pretty
>similar to those your suppliers/vendors/customers are using, otherwise
>it's going to be a pain to get the data translated from one form to the
>other. In other words, conforming to SAP's model may be painful, but
>the pain was a given because there was some conformance that was going
>to be necessary by virtue of business relationships.
I find it interesting the direction this thread has taken ...
I would like to discuss the concept of having the business change to fit the
software. This topic is not only related to SAP R/3, but to any software
installation in general.
I started my career with one of the Big 6 Accounting/Consulting firms. My
first assignement (in 1983) was to write a custom Accounts Receivable system.
What a waste of time. I don't know why the customer didn't just by an off the
shelf package. What strategic advantage could be gained? The custom
implementation methodology emphasized user input. This assumes that (1) the
user is competent in their own area, (2) the user has some general idea how
their area relates to other areas (helps with BPI) if you want to realize big
benefits, and (3) the analyst/programmer can effectively take the requirements
and turn them into a functioning application. My view is that most customers
now purchase standard Financial applications, set a few parameters, but in
general adapt to fit the financial software.
The next part of my career was spent on custom logistics applications. Some
how it was viewed that taking an order and shipping a product was unique to an
organization and could provide stratgeic advantage. I was a project leader
for a design project that took a shipment file and printed an invoice.
Somehow I ended up with 10 people and just the design took 1.5 years. Talk
about being overly complex. As much as the user thought they were
reengineering the business, my observation was that they ended up automating
their current jobs. Now, logistics software is getting pretty robust and
customers are choosing to purchase standard Logistics software.
I see one of the greatest benefits to an organization is installing an
integrated application (Finance, Sales, Logistics, Manufacturing, Field
Service). And yes, the organization may have to change to fit the package in
some areas. And yes, some may areas may have to take a step back. But what I
have seen is that this one step back allows the organization to take two steps
forward.
Also, picking an application software package these days is a lot more
difficult. In the old days, functionality was probably 75-80% of the
requirements. In general, the application was required to run on an IBM, in
English, in the US.
Now there are an entire set of other issues to consider: open systems,
open networks, character vs. GUI, language, multi-currency, scaleablity,
portability, support, etc ... in addition to functionality.
We are in the process of rolling out an integrated business system in the Asia
Pacific and Latin America regions. Our requriements are a lot more complex.
It needs to support local statutory requirements and support local languages.
We also need local support in each country with someone on the other end of
the phone that speaks the local language. We didn't find a lot of software
vendors that could meet these requirements. Functionality was very important,
but if the vendor couldn't meet our other requirements, they didn't make the
cut. W did select a vendor with an integrated application that met our other
requirements as well. This did require some of our users to change the way
they do business.
A whole other topic for discussion is "Do you modify source code during an
application software installation?" To ensure upwards compatibilty, minimize
IT overhead, etc ... we did not purchase source thus not allowing
modifications. So again, we have decided to fit our business to the software.
Our assumption being that the sum of the parts (an integrated system) provides
greater beneifts than a "best of breed" & modifications approach.
Christopher Browne had another good point that I hadn't thought of before when
he talked about the "convergence" of the customer/supplier relationship.
These closer relationships require a sharing of information. The less data
consistency issues, the more seamless the integration.
Another reason we take the "change the business" approach is for reaons of
"Time to Benefit". We can't be working on multi-year implementations for a
sibgle site. Our project schedule calls for complete 4-6 month
implementations per location. We are running 3-5 implementations
concurrently. Our goal is to complete implementations in the A/P and L/A
regions in 1.5 years. If we had gone to each location and asked them how the
software doesn't fit we would still be working on our first location.
Instead, our goal is 80-85% fit with manual work arounds.
Because we are seeing a common infrastructure of systems going in quickly, we
are now adding a strategic layer of applications on top of the standard
software, using standard data. i.e. Supplier Managed Inventory, Integrated
EDI, Global Sales Analysis, Point-of-Sale, etc ...
Conclusion: My comment is the degree an organization is willing to
change to fit a package is based on how big the project scope is. If the new
system is for a single functional area at a single location, the willingness
to change is probably very low. In our organization, our goals are common
global integrated business systems that meet local, regional, and global
objectives. The real projects for discussion are the ones that are
cross-functional and maybe multi-site.
Comments, questions, etc ...
Mark Schultze
mrsc...@mkelan5.remnet.ab.com
Ph: (414) 382-3116
Fax: (414) 382-2627
Christopher B. Browne
>
>: I'm curious how you derived your opinion that SQL*Forms violates the
>: principle of open systems. Could you please explain this? And I think the
>: point here is that while SAP touts their "openess" due to the utilization of
>: Oracle - you cannot use Oracle tools to access/manipulate the data in the
>: database in an "open" manner (i.e. restrictions on both reads and writes
>: done outside of the SAP tools).
>
>Jim SQL*Forms is a proprietory interface and not a standard adopted by
>the industry. SAP R3 runs on a variety of S/W and H/W systems from different
>manufacturers and that list grows longer every year. Just because you do not
>use Oracle's proprietory interface in their system does not mean that
>they are not open.
Feel free to pick a standard adopted by the industry.
In the "Oracle World" that could reasonably include any combination
of PL/SQL, SQL*Forms, Pro*C, those being the interfaces provided by
Oracle for interfacing to Oracle RDBMSes. The fact that they're
proprietary just means that since Oracle is a proprietary product,
you've got to hit a proprietary interface at *some* point.
>Anothger point is that R3 is an application running on a database. If Oracle
>is an open system (which they claim to be) then I should be able to run
>other user interfaces on it. However I cannot for example run Ingres's ABF
>(a significantly superior one IMO) on it. That is because none of these
>are accepted industry standards.
Supposing we changed it to "ODBC," which is a somewhat more "open"
database manipulation system, how does that change things?
ABF and SQL*Forms may be "proprietary" in a sense; they are in
this case merely specific representatives of the database interfaces.
The general principle is that for any of these RDBMSes, you
cannot use tools appropriate to the RDBMS to modify data being
managed by SAP. You have to use SAP's proprietary interfaces
to do so.
>IMO SAP refers to itself as an open system solution since it gives you a choice
>of vendors in H/W and S/W including IBM, HP, DEC, Microsoft, Oracle, Sybase,
>Informix etc. A system that can run on O/S's as diverse as UNIX, VMS, NT
>is quite "open" as far as I see it.
IMO "Open Systems" is a way that mainframe software vendors can
use UNIX without admitting to using UNIX.
d_au...@interramp.com
<mazu...@netcom.com> writes:
>
> Jim Hall (jeh...@access.kw.us.com) wrote:
>
> : I'm curious how you derived your opinion that SQL*Forms violates the
> : principle of open systems. Could you please explain this? And I think the
> : point here is that while SAP touts their "openess" due to the utilization
of
> : Oracle - you cannot use Oracle tools to access/manipulate the data in the
> : database in an "open" manner (i.e. restrictions on both reads and writes
> : done outside of the SAP tools).
>
> Jim SQL*Forms is a proprietory interface and not a standard adopted by
> the industry. SAP R3 runs on a variety of S/W and H/W systems from different
> manufacturers and that list grows longer every year. Just because you do not
> use Oracle's proprietory interface in their system does not mean that
> they are not open.
>
> is an open system (which they claim to be) then I should be able to run
> other user interfaces on it. However I cannot for example run Ingres's ABF
> (a significantly superior one IMO) on it. That is because none of these
> are accepted industry standards.
>
choice
> of vendors in H/W and S/W including IBM, HP, DEC, Microsoft, Oracle, Sybase,
> Informix etc. A system that can run on O/S's as diverse as UNIX, VMS, NT
> is quite "open" as far as I see it.
>
> Sanjay Mazumdar
> mazu...@netcom.com
>
Aren't you talking about 2 different things? SAP has a high degree of platform
flexibility, so if I want to switch DBMS's (unlikely), O/S's (perhaps less
unlikely) or H/W (least unlikely), this flexibility is worth something to me as
a customer. However, if it is true that I can not get at the SAP data in my
Oracle database other than by using the SAP tools, then in that respect the
environment is somewhat closed.
Once I have bought and implemented the software, I would think that data
openness is arguably more important than platform flexibility.
David Aungle
d_au...@interramp.com
Keith B. McKendry (contractor for Don Heggem)
> My view is that most customers
>now purchase standard Financial applications, set a few parameters,
but
>in general adapt to fit the financial software.
<cut his reasoning and current situation>
This was in reference to the "Change the business/Change the software"
discussion that has been going on.
I felt it time to put in my $.02. Where I agree that in the Financials
area most companies do things similarly, I have to disagree with the
indication that "most customers ...". I see things varying all over
the board when it comes to modified vs 'canned' packages.
If a company is buying a new system because of a need/want to improve
how things are done, they are more likely to look for a package that
competitors or similar business are using to their advantage. The
thought being "If it helps them it should help us." In this situation,
I agree most are adapting to fit the package.
If a company is buying a new system because the old system does not
have
the speed or flexibility they need/want (Not enough digits, can't
handle the year 2000, can't load flat files (EDI, etc), doesn't have
Graphic capabilities, not C/S, etc.), they may go either way. They may
feel that they _do_ things better than any of their competition, so why
change how they do things.
Some companies are changing systems because they want a more easily
modified environment. They are not likely to change their business to
meet the software.
Some companies are changing because they have looked at their business
and have decided that certain changes need to take place. They are
likely to look for a system that matches their needs 100% and failing
that will buy and modify the system.
To tie all this in with the latest purpose of this thread: if SAP is
flexible enough to meet the 100% of the last example or is used by the
better working, similar company, then it is a 'fit' for those
companies.
If SAP cannot then it is not the fit. SAP is not the package for the
company that is/can/will not change the way they do business to fit a
package.
To tie all this in with the original purpose of this thread: I have
dealt with companies that had SAP on their 'short list' and chose a
different package. But this does not say SAP is worse than the other
packages, rather, that the other package was a better match. Also,
none
of my clients chose any of the packages in the subject line.
--
McKendry's Uncertainty Principle:
At any given moment, one cannot be certain that any opinion is mine--much
less SSC's or any client's.
Keith McKendry | 73071...@compuserve.com
SSC, Inc. |
Henry Harrison
: <cut>
: I find it interesting the direction this thread has taken ...
: I would like to discuss the concept of having the business change to fit the
: software. This topic is not only related to SAP R/3, but to any software
: installation in general.
: <cut>
: Comments, questions, etc ...
I would suggest that the real answer is that we need to have it both
ways. No company, in my opinion, can or should hope to be the best at
absolutely everything that it does. It should hope to have good people
doing things, but most of these people aren't going to be that great at
designing wonderful new ways of doing things, and for this reason
implementing a commercially available system can actually prove to be a
benefit. Assuming that you choose a system produced by a vendor who
THINKS about the world in the same way that you do, you're going to get a
whole lot of new ideas and possibilities opened up to you, based on the
work of people whose jobs are to go out and look at 'best practices'
being used out there.
However, every company that hopes to survive had better have hopes of
being the best at SOMETHING! What it is that they want to be best at
isn't necessarily business process related - they may for instance simply
be the best at understanding what the customers in the market that
they're addressing want - or alternatively they may be business process
related, such as being the best at manufacturing something at the lowest
cost.
Even if what a company sees as its 'core competency' (ie what it hopes to
be the best at) is not business process related, it probably makes sense
for that company to try and design the best possible processes in the area
where their core competency lies, whilst they will probably in other areas
be happy to be led in what they do by what others do.
So this leads us to suppose that the ideal situation is where you acquire
systems to support the majority of your business, and build them in the
particular areas where you feel you can really add value.
This is the area where our current architectures really fall down. In
this thread we have also been talking about 'open' systems, and
discussing the fact that if you implement SAP you can't go manipulating
the data with third party tools. Irrespective of any of the questions
about SAP's data formats (which I can't comment on, never having seen
SAP), I can say that NO commercial systems vendor I know of would
recommend manipulating the data used by their system without going
through the system.
In my view, the extent to which systems are 'open' today is for reads -
we can in general use a third party query tool to read the data produced
by another application.
The next challenge out there is to build architectures that are open for
writes also. There are various approaches emerging, I think - three-tier
CS, 'active databases', DCE, CORBA, COM...My current leaning is that we
won't get ther until we can implement true 'component ware' based on an
underlying object interoperability standard like CORBA or COM. Then we
can buy completely encapsulated objects for the 'standard' areas of our
business and build them for our 'add value' areas.
Henry Harrison
Gordon Hooker
>Jeff Schasny (jsc...@rmii.com) wrote:
><snip>
>: oh...my...god... if thinking like this is what SAP is all about I'm suprised
>: that ANYONE would buy it. Make the business fit the software? This cant
>: even be defined as a misplaced focus, I remember attitudes like this from
>: the days of propriatary operating systems.
>I just was pointing out from my experience what happens when people try to
>make modifications in the SAP without understanding the full impact. Making
>the business fit the software is not as ridiculous when you you consider
>the amount of flexibility that the R3 system has. And considering the
>value of the tools provided it is a relatively small price to pay.
So what you are saying is change the way we do business because a
software product doesn't support the way we do business at the moment.
You have to be kidding....
>If you consider this a misplaced focus that is your prerogative. However
>there is a difference between an application information system and
>an operating system. The two kinds are not comparable.
>--
>Sanjay Mazumdar
>mazu...@netcom.com
>Disclaimer:
>The views expressed are mine and mine alone.
-----------------------------\ooOoo/-----------------------------------
Gordon Hooker MACS PCP ,--_|\
25 Clarke Street, Ripley, Queensland, 4306, Australia / \
gor...@acslink.net.au \_.--._/
mobile: 018883835 phone: 61-7-2889716 V
-----------------------------------------------------------------------
"We're just two lost souls swimming in a fish bowl year after year"
Pink Floyd
Mark Liversedge
Christopher B. Browne <cbb...@io.org> wrote:
[context deleted!]
>The general principle is that for any of these RDBMSes, you
>cannot use tools appropriate to the RDBMS to modify data being
>managed by SAP. You have to use SAP's proprietary interfaces
>to do so.
FYI, SAP have committed to implementing some CORBA functionality
into the SAP R/3 system in 1996/97. SAP are members of the OMG.
For R/3 3.0 all tables are, allegedly, transparent (Aug? 95).