MUFI Rating & Risk – SAP Business Objects
MUFI: Maintainability, Usability, Functionality, Implement ability
Vendor: SAP (Select For Vendor Profile)
SAP with SAP BI, SAP Crystal Reports and SAP Business Objects is the largest BI vendor in the world. However, this leadership position is not based upon SAP’s product quality. Business Objects as an independent company was making good headway against SAP BI/BW, and the acquisition was driven by a desire to remove a competitor in the landscape and never had any strategic or “synergistic” reason beyond this. While there were a great number of promises made by SAP regarding what it would do with Business Objects, customers of Business Objects are worse off in every way since the acquisition. However, SAP continues to use the name recognition of Business Objects throughout much of its product line, including attempting to shore up very weak applications – such as the SAP PLM “application” that we cover in our PLM application section.
Business Objects is a once proud application that has fallen on hard times since being acquired by SAP. Business Objects used to have the very strong word of mouth among users, however, SAP’s lack of development combined with letting the bottom drop out of service, means that SAP Business Objects is now below average in buyer satisfaction. In fact, the reducing in buyer satisfaction is one of the most severe declines that we have recorded, and it all began when Business Objects was acquired by SAP. So all of the journalists that thought the acquisition of Business Objects was going to be so great for customers have some apologizing to do. Furthermore, Business Objects has had complexity creep, and this has reduced the usability and functionality of the application. Overall, a purchase of Business Objects pre-2007 SAP acquisition is an entirely different picture than a purchase of Business Objects today.
Business Objects is a flexible but difficult to use and high maintenance solution that every year looks further and further behind the competition. Along with the other large acquired BI vendors like Oracle BI and IBM Cognos, Business Objects that have received little investment since their joint 2008 acquisitions, Business Objects is on the wrong side of the self-service continuum.
SAP Business Objects has a reasonably efficient data builder.
It allows many data elements to be brought together quickly.
Much of the hope for Business Objects hinges on many promises that SAP has made to move applications to Hana, but we are skeptical that this will improve Business Objects or any other SAP application as much as SAP is touting. SAP has a marketing strategy of proposing something new and different every few years to keep companies from focusing on what they are currently offering. It is a distinct and observable strategy, and we are one of the very few media sources that write on it. The last major concept was NetWeaver, which did not change or improve anything concerning SAP or its capabilities. Buyers should not accept the excuse that poor performance in SAP applications will be fixed by the magic bullet of Hana – although this is what SAP is shooting for.
Beyond ever doing anything with Hana, SAP cannot seem to address persistent performance issues with Business Objects. Of all the BI applications that we cover Business Objects seems to be one of the least efficient regarding how it addresses hardware resources.
SAP has not added significantly to Business Objects, a software vendor it purchased in 2008. As such, SAP Business Objects it has an old design, performance issues. The Business Objects acquisition was one of the most mismanaged acquisitions we have ever analyzed. There was a great deal of hyperbole regarding how Business Objects would be integrated with SAP BI/BW, but aside from a few initiatives like the Business Objects Explorer (which turned out to have a great number of performance bugs), little to nothing has come of these promises by SAP. Business Objects is still not substantially integrated to SAP BI/BW, with most of the effort expended by SAP in integration between these applications being consumed in marketing.
Soon after the acquisition, the support for Business Objects began to drop off significantly. SAP did three things, which dramatically changed the value proposition of Business Objects.
- Reducing the Support
- Increasing the Price
- Considerably Slowing or Halting the Development
The Conceptual Benefits Between BO and BW
Even since SAP purchased Business Objects the question of how the two solutions would be integrated has been discussed. Prior to the purchase of Business Objects (BO), BO was considered one of the better report creation and data mining tools. SAP has a data warehouse product called Business Warehouse (BW). So the natural integration between the systems is to have BW serve as the backend data repository and for BO to serve as the front-end.
At one client I am familiar with the future state design is for the data to be simply copied from BW to BO and then for BO queries to be performed on this data. The advantage of this design is it leverages the best of what BW and BO have to offer, but the downside is obviously latency.
Business Intelligence Confusion at SAP
One of the confusing things about the term business intelligence is it an emergent property that requires several different capabilities that tend to reside at different vendors. In fact, according to the official definition business intelligence is the activity that takes place after the step of transformation. It has nothing to with data warehousing. Although it may rely upon a data warehouse as a data source, or it may not. A report generated from a set of data maintained by one person on their computer in a .txt file is still business intelligence.
It is not necessary to try to get both capabilities from one vendor as they are different software capabilities and it would be unlikely that one vendor would be the best in each (or that one vendor would meet your industry and company needs in both areas).
However, in general practice, the data backend is a warehouse. The data warehouse is populated with data from multiple applications, or from multiple application databases. A data warehouse is all about designing software to manage large amounts of data to support many parts of the organization from one source (unless a data mart approach is taken).
The second part of the data reporting infrastructure is report creation and data mining, which is about the interface and search algorithms and ways of viewing the data. In between these two layers is the transformation layer, which is the tools and methods used to get the data out of the data backend, and to represent it properly in the front end.
Software Selection Strategy for Reporting
It is not necessary to try to get both capabilities from one vendor as they are different software capabilities and it would be unlikely that one vendor would be the best in each (or that one vendor would meet your industry and company needs in both areas). However, even though this is known to veterans, the vendors have a way of tricking buyers into giving them all their business rather than using a blended approach.
As Pentaho, an open-source data warehouse points out.
“BI Standardization” has emerged as a key marketing theme for proprietary BI vendors over the last decade. The idea behind BI standardization is that by selecting one vendor to address any and all BI projects within large organizations, that organizations will be able to use BI more strategically, and will reduce the costs associated with BI. The presumed incremental costs associated with deploying multiple different BI technologies are usually attributed to redundant training costs and skill-sets, reduced “volumepurchasing” power, redundant hardware, and other items. – Pentaho – A New Business Model to Drive Business Intelligence Acceptance and Adoption
SAP often labels its BW product as a leading data warehouse, however, data warehouse experts do not agree. Most see it as essentially living off of the sell in capability of the rest of the SAP suite.
What Are the Benefits for Customers of the BO Acquisition?
However, several years since the acquisition of Business Objects by SAP, and while Business Objects is thrown into many marketing documents, the integration of BO into SAP products remains weak. Several products are so buggy that they are not really additions to SAP’s stable of usable products. For instance, I still have to use BEx because the highly touted Business Objects front end to the BW, while showing some potential, is so buggy has not been usable. Thus the purchase has not lived up to the hype.
However here are a few examples as well…
Comment 1: I am getting worried about the whole SAP takeover. They kept saying it will remain a separate company and nothing will change. Now with this support issue, no conference this year, and our reps have been really bad to responding to us! I think BO will never be the same now that it’s under SAP
Comment 2: Being an IT professional how can anyone even think of finding excuses. Have you not heard about testing, QA, Pilots, integration testing. Is this the first mass migration anyone has ever attempted?
How would you like to be manufacturer of a product and do something where your customers have no way to service the product? remember this was DONE by BOBJ and not an accident
SAP Business Objects is not the worst of the BI offerings from the major BI software vendors, but there are many other better offerings in the market. The logic, frequently employed by SAP that SAP customers should buy Business Objects does not hold any water as Business Objects is still only loosely integrated with the rest of SAP. Buyers would be giving up a lot of functionality and would be paying top dollar for an aging application with extremely poor support.
All scores out of a possible 10.
Vendor and Application Risk
Business Objects has implementation challenges related to user adoption and report creation productivity. This must be adjusted for by applying more consulting and support resources. The Business Objects’ value proposition changed significantly after they were acquired because although the product has stagnated the prices for everything from consulting to training increased quite significantly. Another risk is that Business Objects has self-service pretentions, but it is quite far away from that, and in fact requires a great deal of IT support.
Likelihood of Implementation Success
This accounts for both the application and vendor-specific risk. In our formula, the total implementation risk is application + vendor + buyer risk. The buyer specific risk could increase or decrease this overall likelihood and adjust the values that you see below.
Risk Management Approach
Business Objects requires a higher than average allocation of resources that can train and support business users. As a high maintenance application, Business Objects will maintain a high support load post go-live – therefore it makes sense to hire Business Objects resources permanently. This will be much more cost-effective than relying on consultants – as they will need to be in for the long haul.
Finished With Your Analysis?
Once complete, go to this link to see other analytical products for SAP Business Objects.