SAP vs. Oracle, Battle Royale

Mark Brunelli writes "As the battle for business application supremacy heats up, Oracle users are standing by Larry Ellison and Fusion while SAP customers say NetWeaver will lead the way to victory." From the article: "Zoellner, who says he has worked with both Oracle and SAP users throughout his career, believes that the Nucleus Research study cited by deHenry is right on in its conclusion that Oracle's average three-year total cost of ownership (TCO) is 48% lower than SAP's. The business analyst said that the TCO issue is particularly important to companies in developing areas."

Comments

wow

[caffeinemessiah]

if ORACLE's TCO is 48% lower than SAP, just how many small countries' budgets does SAP charge for a small installation?

Re:wow

[Anonymous Coward]

It depends upon the country. If your talking western Europe, then maybe one and a half or two. If your talking eastern Europe, then its half a dozen or so.

Re:wow

[tyler_larson]

if ORACLE's TCO is 48% lower than SAP, just how many small countries' budgets does SAP charge for a small installation?

Costs vary (particularly installation and configuration costs), but as a rule of thumb, if your business's income isn't enough to make your state government envious, then SAP is not for you. If all you need is a "small" installation, then you really don't need SAP.

Though I am interested in hearing what Oracle has to offer; I had thought that SAP was the only player in this field, which is why they can charge so much for such a horrible product.

Re:wow

[Avogadro65]

I don't know how much my company spent on its recent upgrade to mySAP, but initial SAP installation a few years ago cost $28 million. $3 million for the software $25 million to install the sucker That's for 4 large plants, a general office, and countless sales offices across the continent.

Re:wow

[Anonymous Coward]

At a $4B manufacturing firm we were looking at a $200M SAP installation. I didn't stick around to see how it turned out.

Re:wow

[dunkelfalke]

actually, the cost for a sap implementation has killed many companies.

Re:wow

[supersnail]

I have not much experience with Oracle ERP impelmentations. But my experience of both SAP and Peoplesoft is this:-

It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse, and, then you pay license fees.

The main problem is upper IT management are sold on the "we implement best practice you dont have to change anything" idea. Which collides with the
real world of "we dont do it that way here" of the business managers.

The only way to implement these products quickly and cheaply^H^H^H^H^H^H for merely outrageous cost is to implement the vanilla package and change the way the business is run to suit. This usually involves sacking/losing half your business management to force the changes through.

Re:wow

[Fedarkyn]

that's true. they say that with SAP you don't need do code, only customize. But instead of 1000 coding man hour, you will need 1000 customizer man hour (more expensive than coding). Here in Brazil a lot of companies are doing small erp-like systems... all crap, but better than SAP since you have access to the code

Re:wow

[Bloke down the pub]

they say that with SAP you don't need do code, only customize. But instead of 1000 coding man hour, you will need 1000 customizer man hour

Fact is, there's only so much you can do with customising - it's analagous to slotting lego bricks together. You can't make settings for what isn't there - that tends to put an upper limit on how much of it you can do.

Hacking code around is more like carving your own bricks. Or just carving. There's no end to what you can create - useful or not, needed or not, justified in business terms or not. Duplicate every report that existed before, even though half of them were control reports to check the sales against inventory after the overnight interface run? Sure.

Anybody who's worked on an SAP implementation (i.e. actually knows what they're talking about) knows that.

Re:wow

[al_broccoli]

It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse, and, then you pay license fees.
Wow, that's such impressive FUD. Do you work for Microsoft?

My team of 12 (internal employees, not consultants) can have a freshly installed system (takes me 1 day to install) configured in under a month. You couldn't write a product in any language or tool with the same number of people in under 2 years. And even then, it would be cripped compared to SAP's ERP product.

Re:wow

[molarmass192]

configured in under a month.

This would only be possible in a VERY small company rollout and with absolutely no customizations, no legacy data, or legacy workflows. I guarantee you, and yes, I've done several Oracle Apps rollouts, that a company with 1000+ employees has no hope in hell of rolling out a system in anything under 6 months. The average being well over a year. The longest part of these rollouts are getting people to sign off on workflows, the tech piece is a relatively small part of it.

Re:wow

[hey!]

It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse, and, then you pay license fees.


Well, it depends. Look at it this way, management is the customer. Your internal IT group is one vendor, SAP is the other. Does the customer really understand what he wants or needs? Probably not; they're focused on other areas. So as a vendor you need to have a market position -- an "elevator pitch". SAP's is pretty good: "we implement best practice you dont have to change anything". This is garbage to the developer's ears, but music to the customer's ears. What they are saying is the customer doesn't have to become an expert in the IT area, they can stick to their knitting and SAP will take care of the strategic IT direction. Lazy? Maybe. Sometimes Lazy == Efficient; knowing when this is so and not so is not a science.

The next thing on the customer's mind is risk. Can the vendor do it? Well, looking around, pretty clearly a lot of people are have some degree of success with SAP's products. Can the same be said for you? No. While it may not be your fault, clearly the vendor you work for has not solved whatever problem it is to date, so in the customer's mind you're asking for a second chance. Unless you can convince them you're not their father's IT department, forget it. What you need is the one service that as an internal vendor you're not allowed to have: marketing.

The thing that's never on the customer's mind is how much trouble it is for you. If another vendor makes the decision easy, offers apparently lower risk, then the fact it makes your life hell by making highly paid technologists do dull configuration work, well it doesn't matter. The customer would get rid of you if he could, but he can't figure how, so he may as well put you on work he understands, which is underwriting a safe bet.

Re:wow

[Nelson]

Am I the only one that is just utterly amazed that they can actually come up with quantifiable numbers that they can compare between the two? Isn't that what they built Deep Thought for in H2G2? People write PhD thesis' on that crap and don't even start to answer it, they just raise more questions.

Re:wow

[Anonymous Coward]

It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse

You are joking, right?

But my experience of both SAP and Peoplesoft...

You ARE joking indeed.

Re:wow

[dwandy]

My team of 12 (internal employees, not consultants) can have a freshly installed system (takes me 1 day to install) configured in under a month. You couldn't write a product in any language or tool with the same number of people in under 2 years. And even then, it would be cripped compared to SAP's ERP product.

Oh yeah? well, my team of one can have a freshly installed system (takes me 1 day to install) configured in less than a week. Of course then the organisation spends 3+yrs fighting over business process and we bring in 100+/- consultants to converge the existing business with the ERPs implementation.

Re:wow

[icebattle]

It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse, and, then you pay license fees.

Sorry, but you don't know what you're talking about. I've installed complete PeopleSoft systems, including creating DB2 and/or Oracle DB backends, in less than a day. And I'm not even a PeopleSoft guru, just a techie who did some training.

Writing a complete system, to do everything that one of these products does, would take a considerable amount of time.

Which is not to say that I'm a fan of these behemoths - I just have to share the ecosystem with them.

Re:wow

[al_broccoli]

True, I am referring to basic functionality. But for many, this is just fine. I can't speculate as to how much time it would take for customizations without defining those ahead of time. Of course, my management seems to be able to. :)

Re:wow

[al_broccoli]

Of course then the organisation spends 3+yrs fighting over business process and we bring in 100+/- consultants to converge the existing business with the ERPs implementation.

Hard to blame any application vendor for that.

Re:wow

[dwandy]

Hard to blame any application vendor for that.

Wasn't blaming the vendor, just pointing out that unless you are in the extraordinarily unlikely position of having a business that lines up 100% with the vendors "best practices" installing the software is the cheap and easy part. 'Cause after that, you get to either customise the software or re-write your current busines processes. Typically it's a little from column-A and a little from column-B.

So! The point was that depending on how much or how little you pick (in total!) from both columns it may well have been cheaper to simply write an ERP that exactly matches your current business and be done with it...

Re:wow

[Bloke down the pub]

unless you are in the extraordinarily unlikely position of having a business that lines up 100% with the vendors "best practices"

The inflexibility of SAP is a bit of a myth, to be honest. If you think installing SAP means there's only one way to do it, you're simply plain wrong. When they talk about customising, that's basically plugging a range of preprogrammed behaviours together. But it's surprising just how many variations that can give. In my experience 90% of the times SAP "can't do it" it can, but people just don't or won't understand that it does it a different way to the old sytstem. Most of the rest don't make sense to start with and with hindsight the old system wouldn't have been written that way - not that they'd admit that.

Of course there are companies where SAP really doesn't fit. But if they did a proper analysis they ought to find that out before they go live.

Re:wow

[Hognoxious]

>>But my experience of both SAP and Peoplesoft...
>You ARE joking indeed.

Experience as a data entry clerk is still experience.

Re:wow

[Hognoxious]

Interesting. Last time I looked at SAP (today, actually) I had access to application code. Not the kernel, but what use would that be anyway?

Re:wow

[al_broccoli]

Agreed, but any SAP implementation project I've been associated with has taken the stance that, where the customer's business processes differ with the way SAP automates things, the business processes will change (where possible), which is why it's so common to have a business process re-engineering in association with an SAP implementation. The reason for this is, of course, the expense associated with customizing and maintaining the SAP system on your own. Virtually all companies do this, and it's reasonable to think that most will continue to do so. SAP didn't define these business processes, after all, they simply automated what customers and consulting partners were already doing. And they have always been good about taking input on what could be done differently.

Re:wow

[Hognoxious]

If, as you suggest further up, you can spend 3 years arguing internally it would seem you're not even 100% aligned with yourselves.

Re:wow

[Hognoxious]

It takes more effort and man hours to customise and install these products than is does to write an equivalent system inhouse

If I thought that to be true I'd be making a nice income going to companies and helping them do just that. So if you think it's true why aren't you?

This usually involves sacking/losing half your business management to force the changes through.

You say that like it's a bad thing.

Re:wow

[NateTech]

"Some degree of success with SAP products"... what, they bought it?

Who here's ever seen a wildly successful SAP deployment in any medium to large sized company? I haven't.

I know someone who's made a second career out of consulting to a specific small companiy that wanted to "act like the big boys", on the implementation of SAP.

That person had been through the hell-on-earth that the larger company's SAP implementation had been and become over the years, so that gave them enough insight to go in and try to patch the hundreds of procedural holes that SAP had caused in a smaller organization.

As best I can tell, the folks doing the SAP installation and consulting get wads of cash -- and the shareholders of any company installing or attempting to clean up a failed setup of SAP -- are getting bilked.

And even better some moron CEO can claim, "We spent 20 million dollars improving our IT infrastructure for YOU!" to his customers and shareholders alike, but if pressed - how many could give a measurement of HOW MUCH that 20 million dollars had saved him/her vs. not having installed it in the first place? None can.

The best anyone comes up with is "the staff can now access information instantly" about whatever. In this case, I say... "Was the answer to whatever your customer's question was -- time-sensitive?"

Sure it's nice to have a fancy database with all of my personal information in it at every place I call, linked directly to their phone system so it can pull my ANI and have my account interformation right there in front of the agent (who took 30 minutes to answer in the understaffed ACD queue)... but wouldn't I have been just fine waiting for two days for an answer?

Additionally, no shareholders who buy via mutual funds and other "consdlidation investments" ever has to pay attention to the balance sheets of the companies they "own" in their mutual funds and/or index funds. T

hat's the true shame of it. (And those companies like it that way -- no accountability to anyone but the analysts and the institutional investors.)

Re:wow

[supersnail]

Admittedly my experience has been peripheral technical support for these projects. And I would add the caveat that these were both for very large and complex companies (everything needed to be multi-lingual and multi-currency).

But the projects took between three and five years to deliver and employed about 50 people each.
And as I had to use some of the front end applications I can attest to
the poor quality of the end user interface.

Speaking to the people involved more closely and listening to thier various war stories I got the inmpresion that this was a normal situation.

And if you need more than anecdotal eveidence for this you could look into the eceptionally well documented case of Hewlet Packards implemntation of SAP inventory control. This is extemly well documented as Carly had to explain to her board why they could not take orders or deliver kit to customers.

Re:wow

[Hognoxious]

Admittedly my experience has been peripheral technical support for these projects.

Translation: I'm a helpdesk monkey.

these were both for very large and complex companies (everything needed to be multi-lingual and multi-currency). But the projects took between three and five years to deliver and employed about 50 people each.

I'll go out on a limb and assume that this was in the US. That would break down as one year explaining what another country is, one explaining what another currency is, and one explaining what other languages are.

And as I had to use some of the front end applications I can attest to the poor quality of the end user interface.

Well there I can agree. The sapgui started out as a nephew job and hasn't improved much. Unless you're complaining that it looks dull (which is true, but nothing to do with usability). It's a business system written by Germans, FFS, do you expect it to look like - Myst? Barbie's virtual beauty salon?

Carly had to explain to her board why they could not take orders or deliver kit to customers.

In sharp contrast to everything else that happened while she was in charge, all of which went off like a military operation. I can imagine her still being there when she retires.

Re:wow

[supersnail]

Translation: I'm a helpdesk monkey

Actually the day job is as a middleware guru.
Various other posters have commented on the lines
of "why don't I get a job consulting on this if I know so much"
the answer is that I get paid more than a SAP consultant and
the work is much more rewarding and interesting.

Re:wow

[Anonymous Coward]

Sniff sniff, what's that smell ... bullshit!

Re:wow

[Anonymous Coward]

Brocade Communications had 1,200 employees spread over the US and Europe when it implemented Oracle Applications. It was completed in 6 months. Yes, it was a vanilla implementation.

Oracle v. SAP? Huh?

[ameoba]

It seems illogical to compare TCO of SAP, an established ERP platform, with Oracle, a Database that's in the process of buying the pieces to start their own ERP suite. Maybe in another 5 years when Oracle has their product line put together it would make sense to compare the two.

Even at that, in the Enterprise market, where 'quality' is judged by 'longevity', Oracle's going to be at a major disadvantage.

wikipedia says sap is...

[r00t]

2. A small, blunt object used as a weapon, often constructed from a bag filled with loose, heavy objects such as lead shot or coins.

5. Colloquially, a sap is a weak or gullible person. Also known as dupe; see confidence trick.

TCO

[Anonymous Coward]

Why isn't Net present value used as the benchmark for comparing two IT projects? It really is the only one that makes sense because TCO doesn't take into account the interest rate.

Re:TCO

[the_womble]

Why isn't Net present value used as the benchmark for comparing two IT projects? It really is the only one that makes sense because TCO doesn't take into account the interest rate.

Because everyone (i.e. including management) knows that NPVs are very uncertain thanks to all the assumptions that have to be made in order to calculate them.

As non-IT people are less familiar with TCO they are less likely to be suspicious about the numbers.

Re:TCO

[Anonymous Coward]

TCO isn't the only statistic that should be examined. It doesn't include the cost of Oracle projects that failed. Or the cost of projects that were supposed to go company wide in stages, only got half way there, the company found out Oracle wasn't the right tool for the job and corporate management declared victory with half legacy system and half Oracle. This is from personal knowledge, I have no info on SAP.

Re:TCO

[afabbro]

Exactly. For most things, NPV is complete bullshit. I buy NPVs when you use the risk-free rate, because yes, you could take your money and buy a T-bill with it and that's a valid comparison.

But most companies use internal rates of 12-15%. Let's say they're weighing a $500,000 computer upgrade. Using a 12-15% number employs the fiction that they could take that $500K and invest it in a worthwhile project that would yield 12-15%, so they're computing the tradeoff of that (fictional) project vs. the upgrade to see which yields more over X years.

But that's BS...most companies don't have a limitless capacity to deploy capital, nor do they have a pent-up queue of projects waiting for funding. It makes some sense in a construction/development or finance company, where your capital really is the limiting factor. But for most firms, NPV is too abstract.

Disclaimer: IANACFO.

Re:TCO

[deltx]

NPV is extremely valid when comparing two projects. The assumptions you reference can cause differnt results if they are not applied consistently to both projects. When done in the same organization, with the same assumptions affecting the factual situations, they are a valuable tool. NPV is not an absolute number but a method of ordering different alternatives. Your post is correct if you compare NPV of two projects computed with different assumptions by different individuals.

SAP == CRAP

[autopr0n]

Seriously, how many people have ever had a chance to glimpse into the dark heart of SAP? It's very ugly. Hedious even.

It might run business well, but it's hardly very extendable or flexible. Given the price you're better off writing your own system, IMO.

Re:SAP == CRAP

[Anonymous Coward]

So is Oracle. Its the support that makes it worth it.

Re:SAP == CRAP

[Anonymous Coward]

My experience with SAP has been from the point of view as the accountant where a client has a SAP installation.

Our opinion is that it produces some good management reports, and is great for materials management and all that. However we do not think the financial information (for accounting purposes) is reliable in any way, shape, or form. And we have many questions still over the way the system processes data before we will ever be confident with the package.

The problem with any software like this is you have programers writing the software who don't understand accounting, and accountants who don't understand programing. Now I'm sure the managers of the firms who implement programs like SAP also have problems where the programers don't understand questions about inventory, sales, accounting, quality control etc etc too.

And I'm not even going to start complaining about the "consultants" who don't know anything about anything!

Re:SAP == CRAP

[Anonymous Coward]

Write your own system ? Have you really had any exposure to SAP's Netweaver world ? I don't think so!

Re:SAP == CRAP

[Big Nothing]

"you're better off writing your own system, IMO"

Please e-mail me your name, so I can tell our IT dept, economy dept. and human resources dept. to NEVER EVER EVER hire you or consult you or even talk to you. Please.

Re:SAP == CRAP

[Anonymous Coward]

Please e-mail me your name, so I can tell our IT dept, economy dept. and human resources dept. to NEVER EVER EVER hire you or consult you or even talk to you. Please.

Bill Gates

Re:SAP == CRAP

[Anonymous Coward]

"Anonymous Coward"

'Nuff said.

Re:SAP == CRAP

[jools33]

"Seriously, how many people have ever had a chance to glimpse into the dark heart of SAP? It's very ugly. Hedious even.It might run business well, but it's hardly very extendable or flexible. Given the price you're better off writing your own system, IMO."

5 years ago I think this comment was valid.
Having worked in SAP for over 10 years I can partially agree with your comments. Historically SAP has been slow to adapt its central ERP system (R/3). However thats not where the battle is being fought at all - and I think you've missed the point of the article. SAP's new platform - Netweaver really isn't one single system - its a complex architecture not a single platform any more. Its this architecture that Oracle is competing against by acquiring as many of the competition as possible and then trying to integrate them into a single solution. SAP have had a smarter approach where they have mostly not bought out the competition (althought thats not the case with MDM or Toptier). SAP have instead realised about 5 years ago the direction where things were heading and I really believe they are several steps ahead of Oracle now in terms of building a full blown Enterprise Services enabled architecture. In my opinion SAP have neglected updating the central (legacy) ERP system (R/3) in favour of building an enterprise services / integration architecture around the old central product - so much so that the old legacy R/3 system isnt really central anymore - the systems around it such as business intelligence, CRM, APO, Xi, solution manager have taken a much more prominent role - and each of these new systems - whilst running on the same base kernels really are completely reworked in terms of the architecture and APIs on offer.
SAP still have a long way to go - and they could really do with reworking some of those older "hideous" code libraries - particularly on their R/3 platform. With Netweavers Enterprise service architecture - SAP looks to be truly flexible and extensible and leaving its old "hideous" code behind - and I suggest the previous poster take a read on http://sdn.sap.com/ for a more up to date understanding of what SAP today is all about.

Re:SAP == CRAP

[master_twig]

SAP is actually an acronym.

Suffering And Pain.

God how it hurts.

Re:SAP == CRAP

[Associate]

Hardly very extendable or flexible? You could try throwing countless dollars and developers at it like IBM did. It took a few years, but many of the wrinkles have been ironed out.

Re:SAP == CRAP

[Anonymous Coward]

Interesting to read of SAP from the inside. Actually I think that it is worse from the outside. I used to work for an oil company (as a tech) where they were told (by central office) that we had to deploy SAP. When I mentioned this to my brother (who also works for an oil company, but way high up in admin) he got very animated and basicly gave me a long diatribe about how much extra work it has made for him (I probably shouldn't mention dutch shell here). Anyway the implimentation went ahead. All those who were to use SAP were sent on a 5 day course (this included all us offshore techs) at great expense. It was quite unsettling to see the crane tech struggling with some of the concepts which were necessary to understand how to use the system! Before this us techs had a facility to fax small value material requirements straight to a supplier, with the proviso that we said a copy of the fax to a discipline engineer, who then got a single signature on the sheet. This was a simple convenient and low cost system. Most of all it was fast. After the introduction of SAP it took hours to order those resistors, and weeks for the system to perculate the order through purchasing (who were expanding to meet the extra work! There were multiple pages of forms, special numbers for each vendor to be sought (these were our companies contract numbers which changed periodically). Actually some people never managed to order anything for the company again. It is estimated that it took at least £200 per order. Fortunately the company has now left our sector (for some reason profits were down), and the new owners immediatly booted SAP out of the window. OK that is my experience of SAP. Is there anyone had a good experience from the user end?

Re:SAP == CRAP

[Tyrekicker]

At my work it is known as: "Slow And Painful"

Re:SAP == CRAP

[Anonymous Coward]

"The problem with any software like this is you have programers writing the software who don't understand accounting, and accountants who don't understand programing."

Not entirely true. While I guess in accounting, this problem may arise, you won't be hired as a SAP application developer without economic background. Believe me, I tried.

Re:SAP == CRAP

[wannabgeek]

C'mon now, Larry! We know who you are

Re:SAP == CRAP

[wimme]

SAP stands for

Schreck Angst und Panik
or
Software Aus Pakistan.

They're using it here at work for almost everything. Looks like a relic from the stoneage (Sapgui). Impossible to support with newer software, interfaces with close to nothing.

Re:SAP == CRAP

[smooth wombat]

I can't claim to have glimpsed into the dark heart of SAP but having had to work with/around it for over two years I can tell you this: SAP is a slow, bloated, inflexible pile of pig waste. Some examples:

Users had to print a form. They selected the form and printed it. The information was squished on the page (horizontally). After pointing out the issue and providing samples the response was, "The printouts worked in testing. We have no plans to go back and redo the forms. Have the user choose a closer form value so the information prints correctly." In other words, the user has to pick a form design which either has a sufficient number of rows or a sufficient number of columns, but not both at the same time, to have their information print out in a reasonably correct manner.

When inputting the time you work (which has to be done every day) the initial starting date is always the first of the year. You have to manually change the date to sometime during the current pay cycle to input your time.

If you get paid by several different funding agencies (as I was at my previous location) you have to manually (every day) input your time breakdown for each agency. You cannot simply put in one general code and have the system break it out for you in the background. In my case I had seven different values to change.

When the budget year changes (July 1st) you, the user, have to go in and manually change a single digit in the funding code value so it knows to put your salary in the correct budge year. The system will not change it for you. If the pay cycle spanned a budget year you had to input your funding values twice. Once with the current year values and again with new year values. In my case that represented 14 lines of values I had to input.

If you take time off in the middle of the day you have to consult a cheat sheet to manually adjust how much time to allocate to each funding agency. The system will not do it for you in the background.

If you access the system through the web interface and want to print something you have to use Adobe Reader. If you access the system through the login pad you can print something by selecting the correct printer name and printing like normal.

SAP is not ADA compliant (so says someone else in an email I kept when we roled this thing out).

These are just the items I am aware of. I know of other situations where someone wants to print a grid of information but was told the screen isn't desinged to be printed and there are no plans to implement such a feature (how hard is it to throw a form in the background?)

Someone who sat in on a SAP meeting told me that they weren't allowed to ask questions about SAP. The consultants would tell them that asking questions wasn't permitted and would not help morale when rolling out the product (or words to that effect). Ever see those commercials that SAP has out now where the people are standing and clapping at the SAP consultant? Apparently that's how the whole meeting was. No answers, just cheerleading.

The parent is correct. SAP==CRAP. I know of someone who worked at Hershey Foods when they switched to SAP. Hershey lots tons of money during the changeover because the SAP software couldn't handle their distribution system information. In fact, several distributors told Hershey they wouldn't be dealing with them until Hershey got their act together and fixed the issues.

I don't know specifically how much Hershey lost as a result of moving to SAP but I hear it was enough to affect their quarterly financial statement.

Re:SAP == CRAP

[Bloke down the pub]

Have you looked into the linux source? Not exactly beautiful and tricky to modify unless you really know what you're doing.

It may run your apps well, but it's hardly extensible or flexible. You'd be better off writing your own operating system, IMO.

Re:SAP == CRAP

[Anonymous Coward]

Sorry Ass Program

Re:SAP == CRAP

[Anonymous Coward]

I know of another food company (Sorry, cannot identify due to an NDA) that put in SAP and didn't realize that they did not bill any of their customers for several months. The SAP people just kinda 'missed' that important piece. Dumb fuckers. WalMart turned around and refused to pay the late bills (They have a draconian policy along the lines of "If you don't bill us in 30 days, we don't pay. Don't like our policy? Don't sell your product through us anymore.") So cost the company quite a few million dollars and nastily affected their quarterly statement.

SAP is horrible. And no localization of the database table/field names. Just bizaare stuff like AJKHAS that are apparently acronyms for German words.

Re:SAP == CRAP

[Gibberlins]

When inputting the time you work (which has to be done every day) the initial starting date is always the first of the year. You have to manually change the date to sometime during the current pay cycle to input your time.

Where I work we use SAP and I have to disagree with you on about everything you have to say. I input my time once a week and when a new week comes along it automatically goes to it.

If you get paid by several different funding agencies (as I was at my previous location) you have to manually (every day) input your time breakdown for each agency. You cannot simply put in one general code and have the system break it out for you in the background. In my case I had seven different values to change.

Again, once a week I enter my time. Depending on what project I work for, there are different numbers to input. However, SAP provides a list of the numbers I have used within the last couple of weeks and provides the functionality for me to copy them right to where they need to go.

When the budget year changes (July 1st) you, the user, have to go in and manually change a single digit in the funding code value so it knows to put your salary in the correct budge year. The system will not change it for you. If the pay cycle spanned a budget year you had to input your funding values twice. Once with the current year values and again with new year values. In my case that represented 14 lines of values I had to input.

It sounds like whoever implemented you SAP system doesn't know how to do it. I do not have to do such things.

If you take time off in the middle of the day you have to consult a cheat sheet to manually adjust how much time to allocate to each funding agency. The system will not do it for you in the background.

If I take time off, either sick leave or annual, I simply enter the number of hours I took for the day I took them. I work 9 hour days. So if I take 2 hours for a doctors visit I would put in 7 hours for whatever project I was working on. You need a cheat seet to do simple math?

I can't comment on the rest of your rants other than to say your company is screwed, not SAP.

http://www.ridiculism.com/

Re:SAP == CRAP

[smooth wombat]

I work for state government so that probably explains many things.

As far as my time is concerned, the only way I can explain it is that it uses a grid to hold the information. Line 1 would have a certain funding code number for the agency which paid part of my salary. Line two would be a different funding code number for the next agency that paid part of my salary. A total of seven lines.

As far as taking leave is concerned, since each agency has a different percentage of funding allocated to it, each has a specific hourly amount I charge to them. For example, the first agency I had 4.2 hours (out of 7.5) charged to it. The second agency had .7 hours charged to it. The third was .4 hours. Each .1 value represented 6 minutes so a 1 value would be one hour.

If I took off leave you couldn't simply calculate the percentage of time used and deduct it from each agencies time. In some cases there were agencies who I wouldn't charge at all depending on how much time I took off.

That said, every time I or someone else asked why we had to split our time across the agencies rather than putting in one value and letting SAP do the split for us we were told, "That's the way it is."

I'm just glad that where I work now they only use SAP for when they take time off and not for daily time.

Open source

[Eightyford]

"My feeling is that the pricing from SAP is far too high," Zoellner said. "I know this has been a problem."

With so much money going into enterprise applications like SAP, why haven't we seen an open source alternative? Why wouldn't IBM, Walmart, and GM (for example) get together and create an open source version? They could share the costs with each other and smaller companies, while avoiding vendor lock-in.

Re:Open source

[blacklevel]

While this is not a full-scale alternative to the likes of SAP or Oracle, Compiere http://www.compiere.org/ does cater to the small and midsize market. This currently only runs on top of the Oracle database, but is in the process of being ported to Postgres.

Re:Open source

[bn557]

In a lot of cases, the responsibility in the case of financial transaction flaw, falls on the software developer.

TCO

[Ctrl Alt De1337]

TCO studies are hardly if ever conclusive because in some situations, one product will have a lower TCO in the long run and in other situations a different product will have the lower TCO. I think the reason why companies keep going back to TCO is the fact that it is nearly impossible to prove right or wrong (one case or even a handful of them does not make a rule), they hope lazy managers will believe them on the subject without thinking it through, and they are run by weasels.

Re:Oracle v. SAP? Huh?

[TopSpin]

in the process of buying the pieces to start their own ERP suite

Oracle had a successful ERP platform years before they bought PeopleSoft. ERP is old hat for Oracle. The recent "fusion" work is their attempt to produce a new platform to replace the now rather mature Oracle ERP platform and provide a road for their recently acquired PeopleSoft and JDE customers.

As far as TCO costs go, I wouldn't be surprised if Oracle was cheaper. The stack is, while highly proprietary, fairly streamlined compared to SAP.

I've been there for a 1:1 comparison

[marcushnk]

and Oracle financial won hands down time after time after time.
Where it was let down was in the procurement and maintenance sections... where BOTH sucked fetid dingo kidneys.

That was 3-4 years ago now.. so I hope Oracle have picked up their game....

Re:I've been there for a 1:1 comparison

[Anonymous Coward]

I used Oracle Manufacturing. Fetid dingo kidneys is a good description. I expect the JDE acquisition was to help them in that area...

Article makes no sense, unless...

[Anonymous Coward]

it's a carefully placed advertisement from the Oracle PR machine. 48%? Gimme a break, no one can determine TOC figures for something as complicated as SAP to that degree of precision.

Re:The way to Victory

[MrFlannel]

It's always been that way (in the IT section).

Hardware: The Nuts and Volts of News for Nerds.
Linux: Don't fear the Penguins.
Politics: Politics for Nerds. Your vote matters.

Duel of the Fates

[geofferensis]

Duel of the Fates was playing when I clicked onto Slashdot and saw this article.

Strangely appropriate music for the article.

So which one is Darth Maul? I say SAP because Darth Maul has horns and SAP is german.

Re:Oracle v. SAP? Huh?

[Anonymous Coward]

Oracle has been in the packaged applications (ERP, CRM, HRMS, SCM) business for more than 15 years. Not quite as long as SAP, but your post indicating that Oracle is moving from the database business into the enterprise software space is showing that you're not really familiar with this part of the software business.

Battle Royale

[Anonymous Coward]

SAP and Oracle will resolve it once and for all by putting Japanese schoolboys and girls on an island and letting them fight it out? CooL!

SAP : Oracle :: American Jobs : Indian Jobs

[reporter]

There is another angle to the controversy of SAP versus Oracle. I agree that Oracle products are probably slightly more cost effective than SAP products. The reason is that Oracle has an aggressive, Darwinian work environment in which workers are pressured to produce. During performance reviews, the manager subjects all her workers to a Bell curve.

By contrast, SAP has a kinder, gentler work environment that is subject to Germany's rules supporting a slightly socialist economy. The German products may not be as good as the American products, but at least, the German workers are happier than their American workers.

In the SlashDot forum, many participants rail against the brutal competition posed by Indian workers who work for a fraction of the pay and benefits that American workers enjoy. If you are such a participant, then surely you prefer buying SAP products over Oracle products since SAP treats its workers far better than Oracle.

On the other hand, if you believe that Americans should reduce their salaries to the level of the Indian salary and that Americans should dramatically increase their working hours to the level of the average Indian engineer's working hours, then surely your must prefer Oracle products. After all, the ends (i.e. cheap, high-quality products) justifies the means (i.e. brutalizing the workers).

Re:SAP : Oracle :: American Jobs : Indian Jobs

[teaDrunk]

well, this is a new angle, atleast from what I know.
I believe SAP has a lot of work done out of India too, exact ratio not known.

Re:SAP : Oracle :: American Jobs : Indian Jobs

[gotak]

That's hardly the reason to pick one product over another because that company's nicer. Also one can argue that one company over charge you so they can over pay their staff while the other is working to improve the lot of developing country engineers.

Re:SAP : Oracle :: American Jobs : Indian Jobs

[Anonymous Coward]

So you are seriously suggesting that American products are of a better quality than German products?

Re:SAP : Oracle :: American Jobs : Indian Jobs

[painQuin]

I worked at SAP America for six months, good times. They really do focus more on treating their employees well than anywhere else I've worked for except my current job (<100 person company)

and to anyone who says that's a bad reason to pick a company, think of it as encouraging that sort of business practice - "mean" companies get boycotted for "nice" companies, there are less "mean" companies around

that's good, right?

Re:SAP : Oracle :: American Jobs : Indian Jobs

[osgeek]

I would really have to disagree with your premises:

• Expecting employees to perform well for the money that they're being paid is "brutalizing" them? That's just silly.
• Americans would need to dramatically increase their working hours to match India's? I worked in India for some months, and the only people consistently in the office late at night and on weekends were the other Americans.

Hire a few people and pay them with your savings to do a job for you. See how far your "gentler" workplace perspective lasts when you realize that you're about to write a $2000 pay-check to some person who hasn't been doing his job; and that $2000 is the last of your money, meaning that you'll be on ramen noodles for the rest of the month and may have to sell something, possibly even your car.

Re:SAP : Oracle :: American Jobs : Indian Jobs

[Anonymous Coward]

As someone who has worked as a manager at Oracle in product development, I can say that I never subjected a worker to a Bell curve... In fact, I don't even know what one is.

Re:SAP : Oracle :: American Jobs : Indian Jobs

[Darlock]

That's right folks! If you buy Oracle instead of SAP you are ANTI-American and most likely a terrorist.

Re:SAP : Oracle :: American Jobs : Indian Jobs

[Anonymous Coward]

theoretically, happier workers will work smarter

Re:SAP : Oracle :: American Jobs : Indian Jobs

[Anonymous Coward]

Insightful?

It would be insightful if TRUE but there is no appreciable difference between the amount of development done "overseas" by these two companies.

Further, having worked for both of these companies, I have to say that they are, like all software/service vendors I have seen, incredibly competitive internally and externally.

Sorry folks, but Oracle is not Microsoft and SAP is not Google. These are just two companies that are head to head in a high stakes business and they are playing for keeps using whatever methods they can.

Re:TCO Why no open source alternative

[Anonymous Coward]

Its too risky for a big corporation or organisation to develop one... You would need auditor sign offs etc. And the Oracle and SAP systems are top end... for large organisations milllions of transactions a day. Scaleable systems at that size are not built quickly and people want to have a vendor to blame. There are legal issues as well to ensure Sarbanes-Oxley and Basel II compliance. I have tried to get my company to look at building an open source System to replace Peoplesoft instead of Fusion... but there is no interest

If anyone does want to start one though - Im in !

Re:The way to Victory

[Anonymous Coward]

Always? Thanks for that, Mr 700,000+.

Re:TCO Why no open source alternative

[bit01]

Its too risky for a big corporation or organisation to develop one... You would need auditor sign offs etc.

No, this is no different from any business software. ERP is just lots of little packages working together to organise a business.

And the Oracle and SAP systems are top end...

Only in the sense of "big money". The actual software itself is bottom end. As pretty much anybody who's used it will tell you.

for large organisations milllions of transactions a day. Scaleable systems at that size are not built quickly

FUD. Google, with one of the largest setups on the planet, uses open source software and doesn't seem to have any trouble. Scalability is just a design issue. Like everything else.

and people want to have a vendor to blame.

Sigh, more FUD. I'm quite sure that there are plenty of open source companies that would be happy to step up to the plate for an extremely good value maintenance contract (by SAP/Oracle standards) for any set of software a business wanted.

There are legal issues as well to ensure Sarbanes-Oxley and Basel II compliance.

No different from any piece of business software.

I have tried to get my company to look at building an open source System to replace Peoplesoft instead of Fusion... but there is no interest.

At your company.

Open source ERP is potentially a large investment that could take a while to get payback on but it is also an area that could be done incrementally. There are a number of open source workflow packages that could form the nucleus of an ERP and there are many open source packages that could be adapted to perform various ERP functions. I'd suggest open source companies interested in this area pick some element of the ERP puzzle and specialise in it. By using open standards your software can then work with other ERP specialists and cover a larger part of the ERP space.

If anyone does want to start one though - Im in !

Glad to hear it.

A big hurdle an open source ERP package would face is to find a businesses where the software could be tested in real life. Very few businesses would be willing to risk their core processes on something untested. Again though, it could all be done incrementally. Likely to be more cost effective and safer than many "big bang" SAP conversions.

---

Don't be fooled, slashdot has many lying astroturfers fraudulently misrepresenting company propaganda as third party opinion. FUD too.

Above the numbers

[lucm]

Until now I was sure that the only thing with a higher TCO than Oracle was a Sea Stallion helicopter (38 hours of maintenance required for every hour of flight). I guess I never thought about SAP TCO because most of the SAP rollouts I heard about failed.

Those projects are so incredibly expensive, I have no idea what kind of scale they use to calculate the TCO. Teradollars? I can imagine a board meeting (CIO: "Hey guys, we must make room for 317 Teradollars in the next budget for this SAP thingy. So I guess we'll have to forget about the Winzip licenses for now.").

Seriously, a friend of mine is convinced that SAP is part of a secret plan to crush the western economy.

Re:Above the numbers

[canfirman]

Until now I was sure that the only thing with a higher TCO than Oracle was a Sea Stallion helicopter (38 hours of maintenance required for every hour of flight). I guess I never thought about SAP TCO because most of the SAP rollouts I heard about failed.

But all we hear about is SAP projects that failed - we hardly/never hear of any successful ones. I've been doing software rollouts for PeopleSoft/Oracle for 4 years now, and I can tell you that while Oracle's product may have a lower TCO, it's usability sucks. It's probably the most cumbersome product I have ever used. In addition, it's security setups are so old, it's a surprise that they still use it. From what I've seen with PeopleSoft and SAP (though I admit I haven't seen SAP as extensively as PeopleSoft), their usability and security is LIGHT YEARS ahead of Oracle's. IMO, TCO cannot be the only reason that a company looks at an ERP suite. Fit and usability are a better indicators.

Re:Above the numbers

[Anonymous Coward]

reminder ... Oracle owns Peoplesoft

The answer

[SuperKendall]

The reason you have not seen an open source SAP is because it's so big and monsterous and hard to figure out what it does, that no-one knows if there's already an open source SAP or not. There could be several right now.

Only half kidding.

Re:The answer

[tsm_sf]

What the hell is it? I get a different answer every time I ask.

Re:The answer

[birder]

That's because it does so many things. Consider it a framework that has modules for all the business related functions and then some; Material Mangement, Sales, HR, Finance, etc. They're all tied together and are able to share the information as needed. To tie it all together is a built in programming language called ABAP which is like 1908's BASIC + some SQL commands. It's meant to replace all your various in house programs into one intergrated product. A lot of companies jumped on board during Y2K in order to replace their legacy mainframe systems.

The beauty is it requires a database to run and for most larger sites, this is done with Oracle. So, Oracle gets a nice cut from their competition.

Re:The answer

[marcosdumay]

If you are still half kiding, I am completely serious. As far as I can see, SAP sells the same customization capacity of gcc. It can become anything, and so, it needs a complete program to become something.

The reason you don't see some open source SAP is because FOSS people don't have a marketing department, so they normaly create software that in fact does something, or follow the specs and write a compiler.

Well, ok there is a big library with the SAP package (the framework thing), but those we have at FOSS too.

Re:Oracle v. SAP? Huh?

[rshimizu12]

Both Oracle and SAP have their own inherent propietary problems. Oracle believes in the don't touch Oracle the Java code let us do it all for you. Some Java people have commented that Oracle's Java implementation is a sloppy non oop code. Besides all this Oracle refuses to certify it's code as j2EE compliant. SAP on the otherhand claims to be more modern by implementing SOA and Netweaver. So supposedly this will ease development for SAP. The problem still remains that SAP want's you to let them do it. Personally I think the industry will migrate over to OSS ERP.

Re:The way to Victory

[Anonymous Coward]

You forgot the hidden subtext: ...News for Nerds (with jobs) and Stuff that Matters (to your CTO)

and with regard to SAP... It is what (sh)IT is

  Zoellner, who says he has worked with both Oracle and SAP users throughout his career, believes that the Nucleus Research study cited by deHenry is right on in its conclusion that Oracle's average three-year total cost of ownership (TCO) is 48% lower than SAP's.

Wow. A real /. scoop. Excuse me, I was looking for News for Nerds and Stuff that Matters When did it become It is what IT is. ?

the way to Victory? Shoot, ya cain't miss it, it's a couple miles down the road then turn left at the crossroad and follow the signs

Re:Oracle v. SAP? Huh?

[ameoba]

You've got me on that - if they're seriously & heavily invested in the market, I've not been exposed to it. The fact remains that Oracle doesn't have much publicity as a major player in the market.

It's not that I didn't think of Oracle as being involved, I just figured them as more of a infrastructure/platform vendor. I've been exposed to a fair bit of Oracle stuff but it's always been in the DB/dev tools world.

Oracle's lower TCO's reported against SAP

[alchemistkevin]

on an Oracle affiliated site! Oh, it's very transparent and connects to well document studies, doesn't it? No? Anyways, we'll just take their word and say SAP's TCO is almost double that of Oracle's similiar offerings!? Similiar? Does anything from Oracle even stack up close to SAP's offerings? Nope! is the one word answer, no matter which camp you belong to, you cannot bring up a product that seamlessly brings together all aspects of a business as SAP does.

All the modules can be individually customized and presented to the customer for his choosing whenever he wants to use that part of the package.

No, it's not a battle royale, Fusion, never was and will never come close to where SAP is in the market today.

High Costs!?!

What's that, do you say a piece of code is costly just because it initially costs higher!?

Have you ever worked in a company where SAP was implemented, do some costing for such a company and then come back and post on the cost savings they've had in their departments after implementing SAP, yes a few implementations do go pear shaped but this is generally not the case.

I don't know about Zoellner's previous jobs but certainly can't find anything on google relating him to know anything that he claims to know about SAP.

(Disclaimer: I'm an SAP Tech. Consultant)
(home: http://alternateplanet.net/ )
(blog: http://alternateplanet.blogspot.com/ )

Re:Oracle's lower TCO's reported against SAP

[rhnk17]

> What's that, do you say a piece of code is costly just because it initially costs higher!? This isn't the point, TCO is not initial cost. Now the only thing that matters is what services are provided for the cost. I can write a "Hello, world! \n" program that costs significantly less than Oracle's Fusion. It also delivers less, but I really promise it will cost less... So isn't there some comparaison in terms of productivity gain instead of raw cost ?

What about Salesforce?

[Anonymous Coward]

It seems while Oracle and SAP tries to duke it out in the traditional ERP arena, they are loosing ground to Salesforce in the SaaS (Software as a Service aka On-Demand) arena. On-Demand really seems to make a lot of sense for small to medium size companies, and it is these companies that makes up the majority of the American economy.

Re:The way to Victory

[SmittyTheBold]

As long as there's been an IT section, it's had it's own customer tagline. Don't forget that the different sections of Slashdot are a relatively new invention in the grand scheme of things.

Re:The way to Victory

[SmittyTheBold]

"custom" not "customer"

Silly Arguments

[Trojan35]

Guys, SAP has stuck around and will stick around because it's very hard to learn. You don't realize that sometimes it's more painful to fix a broken system than to live with its quirks. There are good reasons why businesses stick with SAP.

Further, let's just drop all this OSS nonsense. I believe it would take 10+ years of development for anyone to seriously consider it. Let's say you develop a system. Who is trained on it? What major companies have successfully run it?

Look how long it's taken Linux to gain acceptance, and Linux is something you can incorporate one server at a time. To move your whole company over to a new database system is not something anyone wants to do unless there's a proven, stable solution. This is just one of those areas where OSS can't compete effectively IMO. OSS isn't the answer to every question, as much as some would like it to be.

Re:Silly Arguments

[big dumb dog]

I think OSS has a place with in the ERP model. I don't expect to see an OSS financials package taking off any time soon, but the opportunity exists for OSS projects to gain ground in other areas like an HR package.

This is especially true with Oracle. As it aggressively purchases other products, like People Soft, I expect efforts made to increase scale and extend compatibility between product lines. One of the simplest ways to extend compatibility without creating a ton of other issues is to extend the APIs and IFACE tables.

Although I'm not an expert on e-Business, People Soft or SAP, I have written a few applications that feed data through the IFACE tables into e-Business. Improvements in this area will open up tons of options for businesses of all sizes, including the possibility of adding modules from OSS projects.

Re:Silly Arguments

[dwandy]

Compiere

Re:Silly Arguments

[Anonymous Coward]

When the right replacment for the big boys comes along, it won't take that much training; that's how you'll know it's the right replacement. Besides, any business knowledge you have will transfer -- it's not like all your training was just on SAP or Oracle quirks? Right? Was it?

I have to admit, though, the big vendors are kind of growing on me. I mean, how else can you get a giant faceless corporation to fork over Teradollars? It's the next best thing to an Internet bubble!

Open Source's Big Weakness

[simon_hibbs2]

Ever noticed how all the biggest, most successful OSS projects are basic computing infrastructure projects? They're software written by techies, for techies. Things like compilers, operating systems, networking infrastructure, web server platforms, languages, databases. To write these things all you need to know is protocols, fundamental software architectures and how to program. They are areas where competent techie developers have a large amount of 'domain knowledge' - experience and in-depth understanding of the problem at hand.

Open Source doesn't work well when the problem domain is an area that few techie developers have knowledge of. Then you need to bring in experts in the required area of expertise who have the time and motivation to contribute to an Open Source solution. Now this does happen, but it's much rarer. Take my employer. We produce engineering modeling design software for cellular mobile telephone networks. Our development team includes a group of very knowledgeable and experienced radio network engineers who do testig and write specs and requirements, include experts in 3G radio technology of which there are not many in the whole world. Without their contributions over the last decade, our software wouldn't be possible. You see a similar thing happening with computer games, which require a considerable, high-quality contribution of art assets.

Techies have an innate interest in developing technological solutions to problems - if they have an itch it's likely to be a technical one and they are likely to want to develop technical methods of scratching it, which often means software. Artists, radio engineers and specialists from many other disciplines such as accountancy, human resources, etc don't have the same compulsion to develop or contribute towards software based solutions to their problems. It seems to me that corporate integration platforms like those offered by SAP and Oracle fall into the same category. They aren't the sort of problem you average techie is likely to feel any compulsion to solve, and those specialists you'd need to have involved in the development process aren't likely to be interested in doing so. This is where heavy ammounts of corporate funding is required to bridge the gap.

Now of course this doesn't exclude OSS from the party. For example groups of companies could collaborate to fund an OSS solution to their common problem, but these are likely to be competing companies. We're talking about huge investments of cash here, invested over time spans of 5 to 10 years or more. I think OSS will eventualy start to penetrate into these areas as the software industry matures but I expect this will happen over the long term, like my lifetime for example.

Simon Hibbs

Re:Open Source's Big Weakness

[Anonymous Coward]

This is my #1 fault with OSS and I agree completely. Everytime I read about someone running Linux or BSD on some wireless router or gaming machine I wonder why all that energy isn't diverted into something truly useful like an OSS ERP/CRM systems (http://www.tinyerp.comhttp//www.sugarcrm.com). These are mature solutions that should be taken seriously.

However, I do agree that more investment from the community by people with SME should be given to these serious solutions. I can only see another OSS Office clone, browser, paint program, etc. so much before I start to think a lot of energy is being wasted on commodity solutions.

Re:Open Source's Big Weakness

[Anonymous Coward]

astroturfing! chugga chugga

Battle Royale is a film

[Anonymous Coward]

http://imdb.com/title/tt0266308/

You have to see it.

Re:TCO Why no open source alternative

[markhb]

FUD. Google, with one of the largest setups on the planet, uses open source software and doesn't seem to have any trouble.

Cool! Where can I download the sources for PageRank, their database schema, and their search front end?

Seriously, while you make some good points regarding the viability of building an OSS Enterprise app suite, I see two pitfalls to this approach:

• Typically, ERP is designed to be customized by an army of consultants, which as others have pointed out is where the real money is. If we assume that the plain vanilla OSS package won't meet the needs of most prospective users, a third party would need to be able to recruit, train, feed (i.e., pay), and mobilize such an army on some scale. It seems like it would be extremely difficult to put together the seed capital to do that and build it into a viable business in a reasonable amount of time. I would be interested to see if the piecemeal market you envision would develop; if I were the customer and I heard that approach, I would anticipate boatloads of acrimony and finger-pointing.
• As someone else alluded to above, SAP and Oracle will warrant the financial reliability of their systems, or at least they are legally-constituted entities capable of being sued. What third-party would think it smart to do that with OSS? At the very least, they would have to vet the source of each new release of the code they implemented, which adds professional costs and throws a big hurdle in the way of "release early, release often."

Larry & Henning, be real men!

[Anonymous Coward]

Maybe Larry Ellison and Henning Kagermann should just have an honest fist fight about it, like real mean ;-)

Our SAP Installation

[Slavinski]

Without going into too many details, our installation of SAP is horrible. Getting to the data in our particular installation seems to be a trial of the most monumental proportions. I am encouraged to see some competition and alternatives. I'm not the biggest Oracle fan but I'm less of a fan of SAP.

New markets

[Tzinger]

The challenge for both SAP and Oracle seems to be that the current market is basically saturated. How do these companies move down to smaller customers and up to bigger customers?
Both products were built on a classic client-server model. A single central server supplies data and function. In a really large institution (think Army, VA, etc.) the central server cannot provide the performance needed.
Both Oracle and SAP are going after this type customer now and that is driving some of the changes.

Smaller customers need a lower-cost engine and have much less to invest in supporting costs. It is unlikely that the same architecture is going to suit both ends of the spectrum.

Re:New markets

[Anonymous Coward]

Oracle was not built from a client server model. The applications started as character mode, running on VT terminals.

***SAP IS A HUGE WASTE OF MONEY***

[Anonymous Coward]

SAP is nothing but a huge waste of money.
My former company previously had an in house IBM mainframe based inventory / sales system. After it was bought out, there was a push into SAP to match what was done in Europe.
It took 6 years and over $100 million to implement and it still wasn't as good. The "old" system cost about 5 million a year to host and mainatin, much less then what SAP does now.

Someone mentioned it before and it is certainly true, it costs MORE to customize SAP then it does to create an in house system, pluss you have the SAP license costs.
Thank God the German SAP designers are only designing software and not cars. Of course that would be good for GM and Ford if they did.

Re:***SAP IS A HUGE WASTE OF MONEY***

[Anonymous Coward]

My former company previously had an in house IBM mainframe based inventory / sales system. After it was bought out, there was a push into SAP to match what was done in Europe. It took 6 years and over $100 million to implement and it still wasn't as good.

Maybe that's because your company employed 'tards like you? The kind who insist of tweaking SAP into a bad copy of their old sytem because they're too dumb to learn and too arroganrt to accept that you can get the same result a different way.

Re:Oracle v. SAP? Huh?

[Anonymous Coward]

The problem still remains that SAP want's you to let them do it. Personally I think the industry will migrate over to OSS ERP.

Such as?

Re:Oracle v. SAP? Huh?

[Hognoxious]

Oracle had a successful ERP platform years before they bought PeopleSoft.

Bizarre, I never heard of it.

SAP Sucks

[Anonymous Coward]

That is all.

netweaver

[Anonymous Coward]

Bo ha ha ha ha ha...Anyone who has seen or messed with it knows exactly what
I mean by that..

did you just wake up from a 12 yr coma?

[Anonymous Coward]

because I was in financial systems at GTE (pre verizon merger) when we evaluated Oracle Financials (& SAP) in 1995!

General Electric (you may have heard of them) has been on Oracle Financials for almost 10 years (may be 10 by now).

it's one thing to say they stink (they certainly did in the early years) but please do not make such idiotic, factualy false statements.

Re:The way to Victory

[Bloke down the pub]

And its not it's. At least one of them, anyway.

Never let the facts get in the way

[cdub4au]

Oracle is currently on version 11.5.10 of it's ERP system. You might want to Google Oracle e-Business Suite or Oracle Applications before casting them off as a n00b in the field.

http://www.oracle.com/applications/home.html/

Re:Oracle v. SAP? Huh?

[Anonymous Coward]

Great insider tip there, what's next?

You gonna post how Microsoft is contemplating putting out an operating system to compete with apple & linux?

I also here that Nvidia is getting into the graphics chip business, and Dell is gonna start putting out PCs and servers.

Re:TCO Why no open source alternative

[pzs]

This is tangentially ontopic. Mod me to hell if you like.

> Don't be fooled, slashdot has many lying astroturfers fraudulently misrepresenting > company propaganda as third party opinion. FUD too.

For this to be true, somebody would have to be trying to influence somebody of importance and think that astroturfing Slashdot is the right way to do it. If so, these people would come from one of two categories:

(i) Fanatical Support: ("I love Apple! I worship my suite of Apple products every night!") which is possible, but you'd imagine that these weirdos would not be very convincing.

(ii) They're employees of the company. In this case, they'd have to be astroturfing either off their own bat (does anybody love their employers that much??) or being paid directly to astroturf.

In the most insidious of these categories, the "paid to astroturf" brigade, do those with the purse-strings *really* believe that Slashdot is inhabited by people who are influential enough to make it worth *paying somebody* to win them over?

In conclusion: your comment was very interesting, but you .sig sounds a bit like it might be from the tin-foil-hat category.

Peter

Re:Oracle v. SAP? Huh?

[rshimizu12]

Compiere (http://www.compiere.com/ ) comes to mind as the one of leading contenders. This is because it is Java based thus allowing components. Here is some other OSS ERP projects (http://erp5.org/ ) (http://community.igalia.com/twiki/bin/view/Fister ra/WebHome ) (http://www.google.com/url?sa=t&ct=res&cd=6&url=ht tp%3A//www.itjungle.com/tlb/tlb022106-story01.html &ei=cT0NRO3oH4KAqwLc2rxa&sig2=5uLzyeFbC38zn2tar4EL jw ) (http://www.google.com/url?sa=t&ct=res&cd=7&url=ht tp%3A//www.ofbiz.org/&ei=cT0NRO3oH4KAqwLc2rxa&sig2 =vrPeV4du9fR0FCBlgci8xg ) OSS ERP article (http://searchsap.techtarget.com/originalContent/0 ,289142,sid21_gci1102271,00.html ) There does seem to a be a lot of projects suprisingly enough.

So much fud

[al_broccoli]

If all of the people that had no experience in implementing or supporting SAP or Oracle ERP systems refrained from responding to this article, it would be very quiet in here.

The fact of the matter is that SAP is a complex beast. I've been working with it, both developing and administering, for about 12 years now. I have no experience with Oracle's ERP product (though I am an Oracle DBA), but I'm sure it's just as sizeable. The issue with most "failed" SAP implementations that I'm aware of, and there have been many, is this - incompetence. Incompetence abounds in the technology industry. It's not isolated to SAP, either. I routinely interview job candidates for Oracle DBA positions, SAP Basis Administration positions, SAP BW Developer positions, and SAP ABAP developer positions. I find one very common thread among the candidates - very few of them know what they're talking about. If you hire them, either as an employee, or as a consultant, and they are the senior technical people on your implementation project, you are bound to fail. Whether it's implementation of the ERP product itself, or an implementation of new functionality. That's not SAP's fault, it's yours.

In the end, the decision to go with Oracle or SAP should be based upon which product fits best in your environment, if either of them do. Interfaces are a significant part of this decision, and both SAP and Oracle have their strengths which need to be evaluated and prioritized. Supportability is, as well. If you are not willing to pay your senior developers and support staff more than $100K per year to maintain the product, then don't bother, you will likely fail. If the evaluation is done well, and the implementation is managed well, and you take care to hire the right people and retain them, then you will succeed.

Re:So much fud

[dwgranth]

Dang, that is right on man. I've been an Oracle DBA and Basis Admin before... and there certainly is that issue. If you don't hire a competent person and are willing to pay that person for their skills, they will flounder and that part of your implementation will suffer (and if Basis suffers everyone does).

Re:So much fud

[Anonymous Coward]

I have been implementing SAP for close to 10 years. From a 1.5 billion dollars to "only" 1 million dollar project. I have observed many things that make the project succeed or fail. SAP is no different from any other software except the project burn rates are so much higher and failures can be on listed in the annual report to stockholders.

This is an old article I give all my clients. You could almost erase SAP and pencil in Oracle or any other large footprint project.

Top ten reasons SAP projects fail

10. Believing the journey is complete at "Go Live"

Too many companies see their SAP implementation as a distinct project with a start and finish, says Clive Weightman, a Deloitte Consulting partner who heads client services for Deloitte's large SAP clients. "We say treat the day your ERP project goes live as the start of the next phase of your journey, not your finish."

Paul Krant, a principal with Diagonal Consulting in Berwyn, Pa., tells of a recent client who failed to plan for post-go-live and wound up having to pay for an extra six-months of on-site services from its consultants. "We'd normally expect three-to-four weeks of post-go-live support before self-sufficiency," says Krant. "It was as though they'd planned for the wedding as opposed to the marriage."

9. Failing to develop a business case

Don't start an SAP project just because you, the CIO, think you need new software. It's just too expensive and complicated to risk going forward on that basis. "The decision must be value-driven. There must be a specific business case," says Mark Willford, leader of Accenture's SAP practice in the U.S.

The risk of not having a business case is that you'll treat this as just another software implementation without redesigning your processes to maximize SAP's business-improvement potential. "At the end of the day, if all you do is implement the same processes you had before, all you've done is paint cowpaths," says Michael King, leader of the SAP practice at BearingPoint North America [formerly KPMG Consulting] in Radnor, Pa.. "You have a newer system but you didn't attack the business problems that existed." Meanwhile, all the business benefits you promised the CEO never appear.

8. Failing to staff your implementation team with "A" players

King says he often sees SAP projects become a dumping grounds of people the client doesn't know what to do with. But if you're going to redesign the processes for your company, you need the best and the brightest from all segments fo the business. They're the last people anyone wants to give up, but they're the ones who will help you get the project delivered on time, on budget and with the optimized processes that most closely match the vision. "It's amazing the fights you get into with clients to make them understand how important this is," he says. Worse, warns Weightman, if you have a bad team, you'll never get to the endpoint. "A company can easily end up abandoning a projecte halfway through," he says.

7. Creating a solution that's incompatible with the company

For example, Weightman tells of a global chemical company who operated in a decentralized manner. It tried to become centralized via SAP and suffered a total failure in implementation. The technology was perfectly capable of centralizing the company, "but that's only half the problem," says Weightman. "The other half is the company's culture, where senior staffers were used to making decisions for their own companies and areas of operation. They weren't willing to give up those responsibilities. The moral here is never to use technology as a vehicle to change your culture."

6. Using inexperienced consultants

"A lot of [consulting firms] will put in people through 'the academy,' where they take a training course and get sent straight out to the client. That won't work," says Krant, who advises that your consultant team be a balance of new and old. "Make sure ahead of time that there are experienced people on the team, and get

Re:Oracle v. SAP? Huh?

[birder]

Oracle Financials. Not many used it hence Oracle's need to "buy out" the competition.

Re:Oracle v. SAP? Huh?

[afabbro]

Zillions use Oracle Financials...in the late 90s, moving off mainframe apps to Oracle Financials on a Sun E10K was such a popular move that whole companies did nothing but consulting/support for these sorts of environments.

The short, utterly useless answer:

[BitterAndDrunk]

It's an Enterprise Resource Planning suite.

A somewhat longer answer is:
It's your accounting system of record. If you're audited, that's what gets audited. IT holds your chart of accounts. It holds all data necessary to develop your Balance Sheets and P&L statements.
That's the "core" module, and both SAP and Oracle have commonalities here, with an Accounts Payable, Accounts Receivable, and General Ledger module that is typically considered a "core" installation.
After that, you start getting complicated, as there's dozens of modules in both SAP and Oracle to extend your capabilities within the system. The big selling point of the additional systems is they're integrated with your GL. Makes the bean counters happy. And, to be honest, the integration is really a snap. . . unless your business departs from the "best practices" (aka this is how we coded it to work) at which point it gets a little more complicated. Some customizations are easy to do, some are hard, some are hideous. Oracle's current marketing campaign focuses on the fact that customisations are all Java (which is BS - they have a proprietary forms language that accomplishes most customizations within the ERP) whereas SAP is all ABAP (their own language). I haven't touched SAP in an implementation role since 1999/2000 so I'm unsure what's changed.

I do know this - if you implement serious changes in either system you're going to pay the piper. You'll need at bare minimum a contractor to be able to come in and fix them when broken, and more likely you'll be retaining one on a full-time basis.

I veered a little bit. Other modules for both software packages include their manufacturing sets (SAP -Materials Management, Purchasing, Production Planning Oracle: Inventory, Supply Chain Planner, Purchasing, Bill of Materials) and other suites, such as Order Management, Projects, CRM, etc.

It's all designed very modular so you can pick and choose. Also so it's easy for a sales guy to break it down to the Big Three (GL/AR/AP) and sell them that w/a rapid implementation cycle that may or may not be right for the company. Once they're in though, you've got a captive customer, and it becomes easier to sell them the other modules as SAP doesn't play well with Oracle. (one exception is the Oracle backend, which is a popular choice on SAP applications, which I'm sure drives SAP apeshit)

In terms of open source solutions, I highly doubt anyone's gone that route. It's such a big undertaking, I don't think OS has even come up with a reasonable, scalable accounting suite.

Re:The short, utterly useless answer:

[Bloke down the pub]

In terms of open source solutions, I highly doubt anyone's gone that route. It's such a big undertaking, I don't think OS has even come up with a reasonable, scalable accounting suite.

I think it's not so much that open source couldn't, but it just wouldn't want to. Accounting is boring - it's not even mathematically interesting - and all this double entry nonesense sounds very inefficient. Business majors are so square. Sales is for teh luz3rz in 5uitz.

What would 99.999% of geeks rather do - research & develop a routine to validate Belgian bank account numbers, or shave a few picoseconds off their homebrew sort routine (which is about half the speed of the standard one, but better...)?

Re:TCO Why no open source alternative

[Anonymous Coward]

I have tried to get my company to look at building an open source System to replace Peoplesoft instead of Fusion... but there is no interest.

when OSS came up at a recent meeting, the boss quipped that OSS wouldn't be considered as it couldn't involve a proper kick-back...I only hope they were kidding

posting AC for obvious reasons... :(

Employee Evals at Oracle

[Anonymous Coward]

I worked as a manager at Oracle (posting anon in case they don't like ex-managers posting info like this) and I was never asked or pressured to use a bell curve for evaluations.

Oracle is a big corporation, though, and other parts of it may have had such policies in place.

Regarding how Oracle treats its employees. I felt very well treated as an Oracle employee. I was warned by friends when I took my job at Oracle that it was a hard place to work, but I never found it so. Again, it's a big company, and things could have changed since I left, so other's experiences may be different.

Random thoughts on Oracle (And ERP in general)

[jjmdba]

Just to clarify a few things.

I'm an Oracle Applications Consultant (DBA) that specializes in performing (and supporting) the implementation and upgrade of the "Oracle E-Business Suite" (or "Oracle Applications" or "Oracle Financials" as the name has evolved over a number of years).

I first got involved with this product in 1993 when it was on "Release 9". I believe it originated 5-10 years earlier. This product has been around for quite some time.

In the early/mid 90's, as another poster mentioned, moving off the mainframe to a packaged ERP solution was the "big idea" that many companies had. The various players in this packaged market were:

-- SAP AG
-- Oracle
-- PeopleSoft
-- JD Edwards
-- BAAN
-- Lawson

There may be a few others, but those are the "majors" over time. From a market standpoint, it has generally been SAP vs. Oracle. Although, SAP has, admittedly, enjoyed a measurable lead (especially with larger companies).

From a functionality standpoint, which package is chosen seems to be driven (largely) by which department in a company has the most dominant personality. If it's accounting, Oracle and JDEdwards tended to be the favorites. If it was HR, PeopleSoft almost always won. If it was Manufacturing or Distribution, SAP, BAAN, or Oracle may have won out.

As far as custom development goes, the key to ANY successful implementation of ANY packaged product is "be as vanilla as possible". The reason for this should be obvious. If you customize it, you have to maintain it. This also means that, should the software vendor issue a patch that changes the data structure, you have to re-visit your custom code again. It's much easier to let the software vendor change their code.

Developers, in my experience, tend towards giving the users what they ask for. The problem with this is, it doesn't take into account the need for supportibility and tends to breed large-scale development efforts. Additionally, too few developers (and/or analysts) really press the users on their requests. There needs to be more back-and-forth discussion to truly probe the underlying reasons for the request. By probing these issue, the developer/analyst could best determine what the REAL requirement is and provide a best-of-breed solution that would both give the user what they really need and satisfy the requirements of the IT organization when it comes to maintainability. (The old adage of "Every piece of software in development at MIT will grow until it can read news and mail..." comes to mind).

Another bit on custom development. MOST companies are not in the business of developing software. Developing/testing/supporting software can be an extremely expensive proposition. Especially if you're REALLY in the business of making widgets. This is why so many companies chose to move off their custom-developed mainframe applications and onto a packaged solution. Is it better? Depends. (Typical DBA answer, I know) If you can control the user community and find a way to live with the package pretty much as it is, then yes, it can be much cheaper. If you insist on significant custom code? Then you're back in the business of developing software. (and you're totally sabotaging the benefits of a packaged solution anyway).

This is where configurability comes into play. Through the use of various configuration options (In Oracle, this would be things like "FlexFields", "Workflows", etc.), a company can modify the behavior of the application to suit their needs. This is completely maintainable and will (generally) survive patches and upgrades. These configurations are handled by the "Functional" team during the implementation process.

Obviously, there are certain customizations that may need to be done. However, in my experience, most companies should be able to keep them to a bare minimum. These tend to be things like a customized invoice (with the company logo on it) that, obviously, wouldn't be delivered by the packaged vendor.

An old saying

[tbone1]

The only problem SAP ever solved was "How do we burn through our budget before implementing everything?"

From the empirical evidence I've seen, this saying exists for a reason.

Re:An old saying

[tbone1]

Er, s/every(thing)/any\1/

I really did preview that, man; I swear to God I did.

Re:Oracle v. SAP? Huh?

[Hognoxious]

Compiere? Sorry, I have bills to pay. Think I'll stay with SAP, thanks.

Re:Oracle v. SAP? Huh?

[Hognoxious]

I suppose Sage is an ERP sytem too, then? Pacioli?

Takes a bit more than accounting to be an ERP system.

Re:Oracle v. SAP? Huh?

[grassy_knoll]

Oracle had a successful ERP platform years before they bought PeopleSoft.

They likely did have a product, but I quibble with calling it successful. We tried using Oracle's ERP platform two years ago. "Klunky" would be a compliment... ended up replacing it with an in-house product.

Admitedly it's a small sample size, but the thing was a beast and has turned off our ( remaining ) management from similar purchases.

Re:TCO Why no open source alternative

[Anonymous Coward]

Google runs Oracle ERP.

It's easy to design a scalable large system when it only needs to do one thing. It's quite something else when you need to design a system where a thousand different business and legal rules interact, and you don't know ahead of time which customers will have large volumes of data for which areas.

Re:Oracle v. SAP? Huh?

[MrCreosote]

http://www.oracle.com/applications/suites.html#OEB S

a bit more than just accounting.

Three-year TCO

[Shag]

Having worked in a big corp or two, I think a big part of the problem is that out-of-the-ass figures like "three-year TCO" are actually relevant, because companies try to swap out major pieces of critical software like Oracle or SAP about that often (or in some cases even more often). One dot-com I worked for, in less than three years:

1. Decided to stop using an outsourced system for e-commerce and back-end stuff
2. Blew millions of bucks on a content-management/app-development framework
      ("Look, a CD! And it only cost us 2 million dollars!")
3. Sunk millions more into hardware, developers, etc. to build a super-duper next-generation thing
4. Merged with another company that had a division working on its own thing to do the same task
5. Found out that the multi-million-dollar framework wasn't up to the task
6. Wound up canceling *both* pre-merger programs and starting from scratch.

Oh, what did they wind up using, you ask? Well, I suspect there was some Oracle
somewhere on the back end. The front end was Tomcat, JSP, stuff like that.

Oracle Financials

[c0d3r]

Cisco and Juniper both use Oracle financials for their ERP. Its not as thick and based on oracle technologies.

Re:The way to Victory

[SmittyTheBold]

Wow; I'm usually a nazi about that one. Not a literal Nazi, mind you, but I do find it grating when people over-apostrophize.

Re:Open source ERP ...

[gilberti]

We have been using Open for business (http://www.ofbiz.org/ for some time which is gettting there. Some modules are much more complete than others and we've had to supplement it with SQL-Ledger (http://www.sql-ledger.org/ for financials to get most of the functionality we need but the accounting module is under development and the order management sections are stable. It also has a manufacturing module (we don't use), a content management module and some contact management and CRM functionality. There are a few other projects which have been spun off the main branch which concentrate on different aspects.

HTH

Ian