Slashdot Mirror
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."
if ORACLE's TCO is 48% lower than SAP, just how many small countries' budgets does SAP charge for a small installation?
An old-timer with old-timey ideas.
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.
my sig's at the bottom of the page.
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.
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.
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.
autopr0n is like, down and stuff.
"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.
Religion for nerds. Stuff that really matters
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.
Lurking at the bottom of the gravity well, getting old
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....
"Consider how lucky you are that life has been good to you so far. Alternatively, if life hasn't been good to you so far
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.
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).
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.
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.
lucm, indeed.
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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/ )
i live on an alternate planet
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.
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
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:
Save Maine's economy: write stuff down. All comments are exclusively my own, not my employer.
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.
"If all the American people want is security, let them live in prisons." Eisenhower
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.
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.
You better watch out, there may be dogs about . .
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.