This chapter explores the components of SAP Business Intelligence (BI) reporting, and how to integrate SAP BusinessObjects into an SAP BI environment. In this section, gain insight into the overall SAP BusinessObjects portfolio and its subsequent frontend tools, including SAP BusinessObjects Explorer (SAP BEx), SAP BusinessObjects Web Intelligence (WebI), SAP BusinessObjects Xcelsius, and Crystal Reports. Also find out how integration changes can affect roadmaps and strategies moving forward with the overall SAP process.
Table of contents:
Integrating SAP BusinessObjects into BI environments
Choosing tools for an SAP BusinessObjects-BI integration
The basics of SAP Xcelsius software
Using Crystal Reports and SAP BEx in an SAP BI environment
Chapter 9: Integration of SAP BusinessObjects Components into the BI Environment
This chapter discusses the current and future components of the BI reporting frontend. The current BI reporting tools have been around for 10–12 years in one shape or form. A significant leap in functionality occurred from the 2.x version to the 3.x version in both the BEx Analyzer and the BEx Web Analyzer. Another significant jump in functionality occurred from the 3.x version to the 7.0 version, including improvements in documentation, Web reporting, formatted reporting, BI portal integration, Excel integration with the BEx Analyzer, the use of distribution methods for reports, and authorizations.
The next phase in SAP technology evolution is the integration of the BI NW Reporting components with the BusinessObjects (BOBJ) components. This is a similar process that we went through for the Planning and Consolidations process where we started out with SEM-BPS (Strategic Enterprise Management-Business Planning and Simulation) and moved to BI-IP (Business Intelligence-Integrated Planning), then we moved to BPC (Business Planning and Consolidation), which was an integration of the old OutlookSoft software. So, we are going through integration between the components of BI that are very familiar to us and the components of BOBJ that we need to get comfortable with and familiarize ourselves with as soon as possible. These components consist of the combination of Business Objects (BOBJ) and the SAP Business Intelligence and its platform (NetWeaver). If I look at the actual components we will be discussing they are the BusinessObjects Web Intelligence (WebI), Crystal Reports, BusinessObjects Xcelsius, and the BusinessObjects Explorer. These are the current official naming conventions for each. This integration has been going on for awhile now and we are definitely well into the integration of each of these components directly onto the NetWeaver platform that we are all very used to at this point. As with all new components we will be experiencing some growing pains on the way but shortly all of these frontend reporting options will be fully integrated into the SAP BW or BI platform.
This chapter is intended as an overview of the BOBJ components. It does not provide details about the configuration or design of reports or dashboards, but instead gives you a feel for the functionality, positioning, and features of each component. When you do decide to move forward with the BOBJ components, the overview provided in this chapter should make the detailed configuration easier.
Overview of the Integration and Positioning Process
The entire group of BusinessObjects frontend tools is currently called the SAP BusinessObjects portfolio (or BOBJ for short). This group includes the SAP BusinessObjects Explorer (formerly SAP BusinessObjects Polestar), SAP BusinessObjects Web Intelligence (WebI), SAP BusinessObjects Xcelsius, and Crystal Reports. These naming conventions are subject to change as SAP makes adjustments to the functionality or repositions certain tools.
With any new functionality in the SAP space, our first concern is how the changes affect our road map and strategies moving forward with the overall SAP process. With all the new frontend components, figuring out what component does what and where the overlaps in functionality exist is a bit of a challenge. But the big question in most shifts such as this, where an entire reporting frontend is shifted from the BEx approach to the BusinessObjects approach, is why? In this case, the question has a number of answers, and we will discuss a few from the system and business user point of view.
With the acquisition of Business Objects in 2007, SAP has made a shift that combines best-in-class business and industry applications with best-in-class solutions for business users. To integrate these two components, SAP Business Suite and the SAP BusinessObjects solutions, SAP has used the NetWeaver Business Warehouse (BW) Enterprise Data Warehouse (EDW) platform. For customers that have invested in BW, this has been considered the fundamental building block for their enterprise business intelligence (BI) capabilities. This gives the business users access to additional capabilities and tools that will allow them to extend and deliver business intelligence to almost any part of the organization. As in many cases with new functionality and toolsets, some companies have had little or no exposure to the new BOBJ components and need guidance and assistance for integrating the "new" products into their existing NetWeaver and BW landscape and also understanding of the going forward road map for SAP integration.
Two primary cases need to be addressed when planning an implementation of BusinessObjects solutions as an additional reporting component to the BW system. The first is the case where a new implementation of BW 7.0 is being deployed, or an older version of BW is being upgraded. At the simplest level, the migration of key business functionality from current systems and platforms to BW 7.0 makes maintaining the status quo with regard to BI capabilities a challenging process because current interfaces will begin to change as data moves over time from existing platforms to BW 7.0. Existing data extraction and loading processes, report templates, and most every other facet of the current reporting and analytical capabilities throughout the enterprise will likely require maintenance on functionality at some point during the rollout or migration. Beyond the simple "the interfaces will change" argument, however, a widely accepted best practice for ECC (and by extension, BW) rollouts is that organizations should not simply re-create their respective existing collections of reports to accompany the new environment but instead—even taking risk and complexity factors into consideration—any ECC and BW implementations should be viewed as an opportunity to rationalize the end-to-end BI framework and adopt an updated approach to reporting and analytics; one guided by the increasing need for timely, actionable, high-value insights for decision making and in support of work processes and operational reporting.
In the case of a BW implementation, BW or BI typically provides the catalyst for the organization to review its BI process and build on and deploy a new generation of BI capabilities. In most cases, the implementation will touch all corners of the enterprise. Further, by design, BW is architected around multiple components to achieve the best possible balance between uniformity, consistency, and flexibility, with individual business units or functional areas given a certain degree of flexibility to tailor the information and system to their particular business needs. This multiple-component approach is widely recognized as a best practice to serve multiple business groups and users across a large, complex enterprise; not only in the transactional realm, but also in the informational and analytical realms and concepts. The point is that although there are always multiple approaches that could be implemented for customers, a key factor to defining the overall strategy is the need to support multiple business user groups across the company. As the saying goes, information, and therefore BI, is one of the most critical factors in the success of your company and growth in this economic environment.
Another closely related principle to the preceding ones is the necessity to follow sound migration practices as the current "as-is" state slowly evolves to the future "should-be" end state. Migration best practices often involve components such as interim bridges and "reverse bridges" between legacy and new components; the "sprucing up" of existing components that—even though they will eventually disappear—need to be enhanced for a short duration to support iterative migration; and thorough integration and interface testing. In many cases, this "short period of time for support" turns into years of effort and needs to be looked at in this light. The business needs to develop a road map and work to be as consistent and practical as possible, but there are some situations that come up that will not allow the business to follow that particular road map. A case in point is the current (2008–2010) economic environment, in which many companies have had to redirect their attention to other, more critical issues in terms of driving sales and growth simply to survive. So, the BI process and projects are then moved from six months to two years in scoping and if these bridges for the current/future view of the reporting strategy are not consistent throughout your company, you will be dealing with other survival issues including the ability to generate useable reports.
One of the points I made in the migration chapter (Chapter 8) is that you look at new functionality and components with an eye on how this will support our company and not jump from the frying pan into the fire by just adding an additional layer of reporting components to a system that may need some help and is possible broken. It looks great for a time but the issues are still there, just the reports look better and more dynamic. But the underlying data and consistency issues are still there. So, an enterprise's pursuit of a new era of business intelligence and the resulting timely, actionable, high-value business insight should take advantage of leading-edge core technologies and products but at the same time, the mission-critical nature of what business intelligence should be necessitates being careful and methodical when implementing leading-edge BI products, components, and capabilities, as well as their associated architectures.
BI strategy and architecture teams have a duty to look critically at selected core technologies, products, product families, and architectural frameworks to develop an overall BI architecture and BI road map that is heavily driven by existing, proven technologies and at the same time can support and architecturally evolve toward technologies that are in the pipeline. Most importantly, the teams should be looking to match technologies and products with the BI strategy and documented needs from the business users and community. For example, if it is found that most business processes and analytic needs can easily be satisfied now and in the future by batch-oriented data, the BI strategy and architecture teams should not recommend that real-time data flows dominate the BI architecture. Basically, the recommended solutions should be neither over-architected nor under-architected with regard to likely current and future business needs and requirements.
"Business intelligence" means different things to different people and in a very similar way the concept of a "dashboard" has evolved—locking down a definition of a dashboard is as difficult as getting one definition for business intelligence. All of us have come to understand it in different ways, and we have been witness to customers where we only discovered well into the meeting that when we used the phrase "BI," one group was talking about a particular product, whereas another group was talking about it in terms of a concept or knowledge area. If such confused conversations are taking place even among business users or groups in the same company, implementers should be very aware of the likelihood that both our customers and other members of the project team have had no prior exposure to the SAP BusinessObjects solutions, and how we have conceptualized business intelligence.
Components of SAP BusinessObjects (BOBJ) for Reporting
I have found that during the process of getting acquainted with the numerous components of BOBJ that I was having difficulty understanding where each one fits. I'm sure it was the same issues that I faced with BI before but I'm guessing that the confusion was so long ago that I forget that there was any. So I initially needed to understand where each one of the components fits into the landscape before we can start to understand the functionality, flexibility, and configuration of each. As we mentioned, we will be looking at each of these components at a very high level and even though the configuration of the required source of data to each of these is critical, we will not be looking at items such as Universes or Data Federator in SAP BusinessObjects. Yes, these are critical and in most cases required before we can build any of the reports from tools such as Web Intelligence or Xcelsius but the development and process of configuring a BusinessObjects Universe is for another book. As a matter of fact, and you are probably tired of me pointing this out, but the configuration and development of the full set of these BusinessObjects reporting components would definitely fill another book. So, we need to align each of these components based on their functionality and use, and then discuss some additional basic information around each component.
What we want to avoid, and what is the underlying point from the previous discussion, is that the implementers of the BOBJ project should be aware that they may be in a BI "green field," and it can be useful to schedule a meeting with various stakeholders to discuss some common terms and approaches. The last thing anyone wants is to find out deep in the project that the customer "didn't know what they signed up for" or "didn't understand what it was we were going to deliver." These discussions should be a fact-finding process and a development of a practical BI approach. There are other aspects of the project that a meeting of this nature would benefit and allow everyone to flush out questions that may not have been considered by the stakeholders such as basic project type activities and milestones.
- Define report requirements Discuss the requirements gathering process. Instead of asking general questions such as "Which reports do you want, and what should be in them?" ask specific questions such as "What are you trying to achieve?" and "What are your business goals?"
- Explore ad hoc querying This may be an entirely new concept to some customers, and universes (semantic layer for the sources of data for the BOBJ-BI components) that are made available for such ad hoc activity should be designed with the end-users in mind. The universes should be easy to use and should cover a particular business process.
- Discuss security Many times the customer is only thinking about data security, which is governed by existing roles and security inside BW. However, none of that covers which universes and reports are visible to which users and groups, or which rights a user has in the InfoView portal (component used for business user viewing of reports, very similar to the BI portal) and what actions they can and cannot perform. This could mean ad hoc querying, as opposed to only viewing or refreshing reports, but would also include the ability to export report contents or schedule particular reports for their own business area or department.
- Plan scheduling and report distribution Most customers have not yet considered this in detail, so as the consultant, you need to be able to articulate what the options are and how scheduling may help reduce the load on BW during peak hours if a lot of users need to access the same report and information. Not every report has to be run interactively, which is a key point to make with customers.
- Discuss report design and visualization (including dashboards Many things are possible, but the selected approach should be what is best for appropriate information delivery in the given use case. On the other hand, those who are most comfortable in BEx might need additional time with all the different possibilities and options available in BOBJ. You should have a comprehensive discussion about what makes sense in report design, which metrics comprise good items to display on dashboards, and which ones do not. Again, this means that dashboard and report design needs to line up with business goals—a novel idea but one that seems to escape many developers as they go through the process of developing these busy dashboards.
All of these points are still quite tactical. However, they will help to set the stage for the project, and in many cases the customers will not understand what they are getting until they see the first reports and dashboards, a point at which it is probably too late to make substantial changes. You can mitigate this risk with an upfront rapid scoping session and/or a pilot implementation. The advantage to this approach is that, fundamentally, it tends to be business focused rather than IT focused, and it aligns with a simpler implementation. Realize, though, that "fudged" demos on static data can leave customers with an impression that the complete implemented solution will be more responsive and faster than is realistic. Nevertheless, it can certainly help to provide the customer with a hands-on visualization of what things will look like in a full implementation.
In all cases, there should be a point to doing business intelligence, just as there was a reason for a customer to invest substantially in products and services to put a BI framework in place. That is, BI should be part of a larger business strategy to enable more efficient, consistent, and targeted use of information assets captured in the SAP systems, legacy systems, and other relevant business data. A lot of reporting is very tactical, whether it is operational reporting or regulatory and from an industry perspective, that is not really considered "Business Intelligence," but rather a simple representation of only its most basic components. We need to move the corporation to the next level, which is to encourage further analysis and provide ad hoc querying capabilities beyond a set of standard reports. Ideally, though, a BI strategy ties such analysis in with existing or new business processes, where BI plays a role both in discovery (Q&A) and monitoring the effect of policies and business initiatives.
Most customers will have some sort of BI strategy defined. Even exclusively operational reporting will have a thought behind it. In many cases it is directly related to a business initiative that is very specific, while in other cases it may be a desire to really change the organization and its business processes. It may not be always highly sophisticated, and if that is the case, you should help refine it further and propose a solution based on experience, as well as the customer's business needs. Recognize that customer resources will usually have done their research, but may misrepresent certain product features or misunderstand concepts that are very familiar to experienced consultants, so always clarify what they mean with what they say.
Formulate the strategy and seek approval from the customer. Where possible, try to get buy-in for a Business Intelligence Competency Center (BICC) to make sure there is a group that functions as a guardian of the BI solutions and applications post-implementation. The BICC members should not only drive best practices and system governance, but also ensure that the actual implementation aligns with the BI strategy. The BICC over time should help refine the strategy and drive it to ever further sophistication. We have all seen this process go astray with all of the other system-specific activities around the go-live and the post-go-live processes including critical issues with performance, business user additional needs, or just running out of budget or time but please look to drive this effort so that the BW system and the BI concepts can continue to proactively impact the corporation. We have to keep in mind the critical position of information within our corporations.
It is very important that you educate the business user or your customer on using the right tool for the right job, as the wrong choice is more likely to lead to implementations that fall short of the initial success criteria. You will have to manage not only which tool is more appropriate, but also the expectations with the customer, and what current product capabilities need to be considered when guiding the tool choice. Even if the right choice is made, diverging expectations or lack of support for certain features may still lead to problematic implementations. It is also clear, and this is the normal process with all new products, that a number of product changes have been, or are in the process of being enhanced, so all of these elements need to be taken into account when deciding on the right tool for the job at hand. The SAP BusinessObjects components have some well-established guidelines on selecting tools based on both the existing customer landscape and business user information or what SAP calls a "use case scenario." In the process of analyzing the various categories of issues reported by the companies and business users—apart from identified certain product issues—the analysis shows some classifications that clearly indicate incorrect tool choices, which lead to misaligned expectations of the solution.