Using SAP HANA, you can expand transactional applications through analytical functionality. Varied technologies and tools are available for this purpose, which—in many cases—allow you to add analytical functions with very little programming effort.

9Integrating Analytical Functionality

In Chapter 1, you learned that you can combine transactional and analytical functionality or add analytical capabilities to existing transactional applications using SAP HANA. This chapter describes this topic in more detail. From our point of view, this is important to avoid investments in the development of analytical functionalities that are already provided out of the box.

We’ll start by explaining important concepts and terms used in this context. Then we provide an overview of the SAP BusinessObjects portfolio and describe the options provided by the Analytic Engine of SAP Business Warehouse (SAP BW). Finally, we’ll introduce possible architectures that can be used to expand transactional, ABAP-based systems by analytical functionality, along with their advantages and disadvantages.

Due to space constraints, however, the presented technologies and tools can’t be explained in detail. Therefore, you won’t be able immediately to use all of the methods presented for integrating analytical functionality in transactional applications after reading this chapter.

9.1What Is Analytical Functionality?

To understand the options described in this chapter, you need to understand analytical functionality and how the integration of analytical capabilities in transactional applications differs from a data warehouse.

Analytical functionality is more than just reporting. Reporting helps you present and format data. Data analysis should then help you understand correlations and causes so you can determine necessary measures based on this information (insight to action). Ideally, these measures should have a positive impact for your organization (e.g., higher revenues, lower cost, improved customer retention). Figure 9.1 shows how these concepts correlate.

Figure 9.1Overview of Analytical Functionality

Reporting and data analysis tasks can be performed at different levels (Figure 9.2):

• Strategic level
  The strategic level deals with basic questions that have a long-term impact on an organization. Using the SFLIGHT data model from the previous chapters, possible strategic questions for an airline include the following: Which flight connections should be expanded? How should the miles program be enhanced?

• Tactical level
  The tactical level deals with questions that have a medium-term impact on the organization or individual areas within the company. Possible tactical questions include the following: How should ticket prices be adjusted starting January 1 of the following year if kerosene prices continue to develop as they have in the past three months? How will the operating result in the next three years be affected by the new air-traffic tax?

• Operational level
  The operational level deals with short-term questions regarding day-to-day operations. Possible operational questions include the following: Which duty-free products should be replaced due to lack of demand? Which customers should be approached to improve the business-class utilization of a certain flight connection?

  

  Figure 9.2Levels of Reporting and Data Analysis

While small time delays in data provisioning usually aren’t problematic for reporting and data analysis at the strategic and tactical level—and it may not be possible to avoid such delays, as data from different systems must be consolidated—latency-free data provisioning is often of paramount importance at the operational level. Imagine a travel agent who is on the phone with a customer who wants to book a flight. Ideally, the travel agent should not only know the current use of the desired flight but should also be able to offer alternative flights on other dates and possibly on better terms. The travel agent should also know the current status and bonus-mile count of the customer, the discounts granted, and so on. In this example, time delays when providing this data aren’t acceptable.

In addition to transactional systems for their business processes (e.g., SAP ERP), organizations often use separate analytical systems referred to as data warehouses (e.g., SAP BW). Transactional systems are systems for Online Transaction Processing (OLTP). As a synonym for analytical systems, the term Online Analytical Processing (OLAP) is often used. The latter isn’t entirely correct because OLAP describes multidimensional analyses based on a star schema, while data in a data warehouse can also be organized in flat database tables (in SAP BW, for example, in the form of operational data store (ODS) objects—see Section 9.3). Some background information on OLAP is also provided in Chapter 4, Section 4.4.

In recent years, SAP BW was used not only for strategic and tactical analyses in the SAP environment but often also for operational reports and data analyses for the following reasons:

• Load reduction on transactional systems

• No significant enhancements of Report Painter, drilldown reporting, Logistics Information System (LIS), and other existing reporting tools within transactional systems

• Extensive business intelligence (BI) content (i.e., preconfigured data transformations and information models for SAP BW)

This meant that the required data wasn’t always provided in real time for the end users.

Today, you have the option to implement operational reporting where it belongs: within the transactional systems. Analyses that could only be run during the night and after several data transformations in the past can now be done on the fly based on the original data and, for instance, using the tools of the SAP BusinessObjects portfolio.