- SAP has told customers that they must use BW as a BI solution for HANA.
- How accurate is SAP on this topic?
SAP has been communicating to customers that they should buy BW4HANA for BI under the premise that SAP is not designed to integrate well with 3rd party solutions.
- Using BW means very serious productivity issues long term.
- BW is not effective where it is implemented.
- The idea that an RDBMS can’t connect effectively to anything but a specific BI tool is very odd. This brings up the question of what is an RDBMS. Overall, this topic needs to be analyzed. This is not to say it is not more difficult, but adapters can be written to any database.
This is pointed out in the following quote.
“HANA is widely SQL92 compliant, CDS views are an extension of SQL92. It may be an issue that third party BI vendors do not yet invest in HANA extensions and optimizations. Anyway, there is no CDS view that can only exist in S/4 or BW/4HANA. In the end it are native database artifacts that can be created via DDL statement.” – Dr. Rolf Paulsen
Could SAP DP or BW Survive as Independent Products from SAP?
From a fair competition perspective, the basic concept of an efficient software market is that a company makes a product which it then sells to other companies that find the product of value. The enterprise software market is different from most other markets, including the consumer software market in that the capabilities and performance of the product are not immediately apparent at the time of purchase.
In fact, companies that buy enterprise software don’t typically understand fully what they have until far after the time of purchase, past the design phase of the implementation and close to and sometimes after go-live. The enterprise software market is marked by a great deal of lock-in. That is once a purchase decision has been made, the company will typically not move away from the system for 5 or 6 years. The actual price paid for the license and support is a small component of the overall costs of implementing and supporting enterprise software (called total cost of ownership) and is enumerated in the post.
What The Successful Sales of SAP DP and SAP BW or SAP BI Prove in the Larger Context
Both SAP DP and SAP BW or SAP BI cause many issues with the companies that buy them. These products exist and thrive because they are tied to other products within a software conglomerate called SAP. These are not the only SAP products that have these issues. SAP Solution Manager, XI, SPP, the list is quite lengthy.
Both SAP DP and SAP BW or SAP BI use the same Data Workbench. However, the efficiency of these twin products is extremely poor. Both SAP DP and SAP BW or SAP BI have tremendous overhead, and when one looks at what is done in each application, the same activities can be performed in other applications much more easily.
- SAP DP is covered at Brightwork at this link.
- SAP BW or SAP BI is covered at Brightwork at this link.
Both of these applications are rated as the worst in class. They are the top applications recommended by the major IT consulting companies. Does this have anything to do with SAP DP and SAP BW or SAP BI taking the longest to implement and therefore driving the most consulting dollars to the largest consulting companies? TCO calculators for SAP DP and SAP BW or SAP BI are also available at the Brightwork site, and once again SAP DP and SAP BW or SAP BI have the highest TCO in each of their software categories.
Integration Based Competition in the Consumer Software Market
This is very similar to Microsoft gaining market share for its Internet Explorer (IE) browser, which was not a competitive product. At one time had over 90% market share because Microsoft had a monopoly in the operating system area, and bundled the browser with the operating system, and has made, it impossible to uninstall. For the longest time, Microsoft’s IE held a very high market share of the browser market and proposed to the Department of Justice that they were not engaging in monopoly behavior. However, one of the greatest proofs is the success of a product when restrictions are removed or reduced. People have come to know there are other and better browsers and have responded by moving away from IE.
I would be curious to hear what Microsoft’s argument would be now, that they never behaved like a monopoly software vendor. Microsoft has repeatedly used a monopoly in a bad operating system to bring out other software which would never have obtained the success that it did, such as SharePoint and SQL Server, without being connected to Microsoft.
SAP’s arguments are based upon integration and the logic that customers must use what they provide. That says nothing about what is actually effective or good.
The Necessity of Fact Checking
We ask a question that anyone working in enterprise software should ask.
Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?
If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.
In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our Other BI on HANA Content
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model