The Business Planning and Consolidation (BPC) 10.1 application running within a host SAP Business Warehouse (SAP BW) and an SAP HANA database provides numerous opportunities for efficient operations. The BPC application allows tailored selection of modeling paradigms to allow the best match to business requirements. The standard model allows for disengagement of the data model from the non-planning SAP BW community. The embedded model allows for significant reductions in data replication. Both models are provisioned with in-memory optimized function capabilities for fast calculations.

The SAP BW layer provides a portfolio of delivered integration content that simplifies access to SAP and non-SAP systems. Through the use of MultiProviders and virtual providers, BPC can easily consume information directly stored within SAP HANA.

SAP HANA provides a wide variety of techniques to efficiently process BPC/SAP BW information (i.e., predictive functions generating BPC forecasts). Data from external sources can be easily accessed using SAP Smart Data Access (SDA), SAP Data Services, and SAP Landscape Transformation (SLT) processes. This information can easily be virtualized into BPC/SAP BW for consumption or the information can be merged directly within the SAP HANA model.

In mid-2014, SAP introduced the 10.1 version of BPC that includes a second planning model based on SAP Integrated Planning (IP) technology. Through use of these two models, as well as through the use of several SAP BW- and SAP HANA-based techniques, you can now easily optimize your planning environments to efficiently incorporate multiple data types, access data from a variety of sources, and consume data in your planning process in many cases without the need for hard data replication processes.

To take full advantage of the capabilities of SAP BPC 10.1, this application is deployed within an SAP BW environment that is supported by a SAP HANA database (Figure 1). The SAP BW system hosts the BPC application and provides a convenient platform for data modeling, staging, and merging all the data required for the planning process.

Figure 1

SAP BPC 10.1’s two InfoProvider models: standard and embedded

SAP BPC 10.1 offers two InfoProvider models, standard and embedded. The standard model enjoys a protected technical name space, and all technical objects (i.e., tables and InfoProviders) are identified with the technical name prefix /CPMB/ (Figure 2). The standard model type can be used for data model segregation within the host SAP BW system, allowing department-level control of the dataset independent of all other SAP BW users and operations. The standard model can only access data from within this protected name space—any additional data needs require the loading of the data into the name space.  In contrast, the embedded model is not subject to any name space restrictions and has free access to data throughout the entire SAP BW system.

Figure 2

Screenprint of the technical detail from host SAP BW system for BPC 10.1 standard model and associated /CPMB/ name space objects

The SAP HANA platform stores the physical records associated with the planning application using in-memory technology for incredibly fast access, but SAP HANA also makes available unique function libraries that can extend the interpretation of the data. As an example, using the predictive functions delivered with SAP HANA’s Application Function Library, forecast data can be easily analyzed to develop statistically modeled and accurate forecasts. Textual data, such as feeds from Twitter, can be interrogated using SAP HANA text analyzer to provide insight into the future sales potential of the product. Reporting can take advantage of SAP HANA’s internal geospatial capabilities and provide mapping details of your operations, such as where the most profitable or highest counts of new customers are located.

SAP BPC 10.1 – The Basics

SAP BPC 10.1’s planning capabilities provide a one-version-of-the-truth environment for enterprise planning collaboration and development. Because BPC data is modeled within a host SAP BW system, BPC can access data from a multitude of SAP and non-SAP data sources using the thousands of pre-delivered SAP BW information extractors. In addition, the associated SAP HANA database also has several methods for modeling and accessing data, including information virtualization via table views as well as several sister products (i.e., Data Services and SLT) that can load a variety of data types directly into SAP HANA.   

A major innovation of BPC 10.1 was the merger of two prior independent SAP products: BPC and IP. BPC 10.1 has two models that can be used to create planning environments: standard and embedded (Figure 3). The standard model is based on the earlier versions of BPC (10.0, 7.5, and 7.0). In the standard model, a protected name space (e.g., objects are identified within the host SAP BW system with the prefix /CPMB/, as shown in Figure 2) with the host SAP BW system is carved out to store the data model. Data is brought into the host SAP BW system and, through the use of BPC data manager functions, is copied or replicated into the BPC-designated name space.

Figure 3

Screenprint from the BPC 10.1 web-based administration page showing the availability of the standard and embedded models

For many business users, this process was highly desirable since it provided department-level independence and control over the entire planning process. Specifically, control was valuable in the areas of master and transactional data definition and usage, independent security, and access controls. Simply stated, the standard model option provides the ability to invoke department-level control of the entire planning process.

The second model available in BPC 10.1 is called the embedded model (Figure 4). This model is based on the earlier versions of SAP BW IP, with in-memory functionality provided by the inclusion of the Planning Application Kit (PAK). This combination, SAP BW IP and PAK, provides integration between traditional planning capabilities, brought from the IP world, and the in-memory SAP HANA-based performance capabilities, brought by the PAK functionality.

Figure 4

The BPC 10.1 embedded model

The embedded model has a fundamentally different approach to data—it has direct access to all data from within the host SAP BW system without the need for replication of that data into a protected name space. This new BPC model paradigm, although allowing easy access to all existing SAP BW master and transactional data, has significant consequences: the data that is so easily consumed by the embedded model is common to, and potentially shared by, all host SAP BW users as well. Adding new master data essentials for some planning operations now needs to be coordinated with non-planning users of the same SAP BW environment. For example, planners may wish to plan a series of future products. If the product master data is updated to include these products, procedures may need to be put in place to prevent non-planning users from having access to these fictitious products.

A more positive example is that actual transaction records do not have to be replicated into a BPC name space before being consumed by the BPC embedded model—the embedded model is able to access the transaction actual records directly, in place, without data movements. This ability to access records by copying them is a key feature of this model. Data replication activities can cause information systems to become unnecessarily enlarged, can raise total costs by requiring larger systems to accommodate the inflated data storage, and can confuse the end-user community by presenting multiple, similar copies of datasets as potential query targets.

From a data replication perspective, the embedded model is obviously the superior solution and it also allows the direct use of a multitude of standard SAP BW data modeling and data manipulation tools (i.e., transformations, Data Transfer Processes [DTPs]). However, as you may have guessed, the standard model has a useful set of capabilities as well.

The standard model also has in-memory optimized planning function capabilities and is compatible with earlier versions of BPC. Keeping department-level control on the planning process may be a more important business priority than being able to reduce system complexity by allowing the sharing of data. If consolidation capability is required (the C in BPC) then (as of the current release [October 2014]), only the standard model can accommodate BPC’s extensive collection of built-in business logic functions that are used to perform management and financial consolidations. In the final analysis, there is no one right or best model. The decision for which model to use should be based on a thorough mapping of business requirements to each model’s characteristics.

To help with model selection, I have assembled a comparison matrix between the two models (Table 1).

BPC and SAP BW Integration

As can be deduced from the streamlined architectural view in Figure 1, BPC is hosted within an SAP BW environment. Technically, BPC components are ABAP add-ins installed within the SAP BW application environment. As a result of this intimate connection, BPC is positioned to enjoy the integration capability between SAP BW and SAP products (such as SAP Business Suite) as well as other non-SAP products.

Transactional and master data integration is illustrated by the many delivered SAP BW extractors, modeling content (including definitions for InfoProviders, i.e., InfoCubes and Data Store Objects [DSOs]), and InfoObjects (i.e., key figures and characteristic). The SAP HANA database associated with the SAP BW system allows ultra-fast DSO activation times, significantly reducing or eliminating data-latency problems. Data can also be replicated into the SAP BW environment using a variety of new generation data integration tools, such as the batch-orientated Data Services toolset or, for real-time data access, the SLT replication tools that are able to immediately replicate data from your ERP system directly into the SAP BW InfoProvider.

BPC and SAP HANA Integration

Both BPC 10.1 models enjoy a number of planning functions that, when called, are executed directly in the SAP HANA database. SAP calls these functions in-memory optimized. These functions are useful because they allow very fast execution. Less execution time means less operator downtime waiting and more time to focus and test alternative planning scenarios to optimize the overall plan.

These in-memory optimized functions achieve their speed by processing the calculation where the actual data is physically stored, as well as by eliminating bottlenecks in the database-to-application layer architecture. Prior to in-memory optimization, execution of planning functions called all necessary data to be retrieved from the database and placed into the application layer. The application layer (i.e., BPC SAP BW) then executed the planning function. Any modified or new records were then pushed back into the database. In short, conventional databases led to significant input/output (I/O) traffic between the two layers which, at times, could result in bottlenecks and slow system response (Figure 5).

Figure 5

A comparison of BPC 10.1 in-memory (SAP HANA) vs. conventional database function execution

BPC 10.1 offers the following in-memory optimized functions: dimension member formulas, top-down planning using SAP HANA, allocations using SAP HANA, copying, reposting, revaluating, deleting, deletion of invalid combinations, set key figure values, distribution by reference data, Generating combinations, reposting on basis of characteristic relationship, distribution with keys, and FOX formula are all delivered in-memory optimized functions. Refer to Table 1 for additional details about in-memory optimized functions.

How SAP HANA Virtualization Can Streamline Your BPC Process

SAP HANA has the capacity for creating virtual views of datasets that can be populated at run time to minimize overall data duplication and complexity. Using SAP HANA’s calculation and analytic views functionality, data is virtualized (Figure 6). These views provide the additional benefit of easy modification (e.g., no data sets to off load, then reload, during updates) to conform to changing business requirements (such as industry or government regulations). Using virtualized views eliminates the penalty involved with more permanent configuration structures, such as the added maintenance and administrative costs incurred by creating and maintaining these structures, as well as the data latency effects caused by waiting for non-virtual structures to physically load.

Figure 6

Using SAP HANA calculation views allow minimization of data replication

Data brought directly into SAP HANA can be easily exposed in the SAP BW application layer using the virtualization concept. Data stored within a typical SAP HANA table can be accessed using a SAP HANA calculation view on that table. The calculation view can then be directly linked into an SAP BW virtual provider so that the data can be consumed by the BPC application (Figure 7).

Figure 7

Use SAP HANA calculation views to expose data in SAP BW for consumption by a BW/BPC process

SAP HANA can also provide virtual access to external database information via SAP HANA’s SDA functionality (Figure 8). SDA allows SAP HANA to directly connect to a variety of external databases, both SAP and non-SAP. At run time, the information from the external database populates an internal virtual table which can also be exposed into SAP BW/BPC by creating a calculation view and SAP BW virtual table, as previously described.

Figure 8

Bring SAP HANA’s SDA information into an internal virtual table and expose it to SAP BW/BPC

SAP HANA Function Libraries and Engines and Your BPC Process

You can dramatically increase performance by executing complex computations in the database instead of at the application-sever level. SAP HANA provides several techniques to move application logic into the database, and one of the most important is the use of application functions. Application functions are database procedures written in C++ format and called to perform data-intensive and complex operations. These functions are stored in the SAP HANA Application Function Library (AFL).

A few main SAP HANA procedures and engines that can be used along with BPC/SAP BW data include:

• Predictive Analytical Library (PAL) – A collection of predictive functions that can be used to analyze data sets.
• SAP HANA Planning Engine – Provides in-memory optimized planning functions execution.
• SAP HANA Spatial Engine – Provides geospatial data-visualization capabilities.
• SAP HANA Text Engine – Provides text-analysis capabilities.

Examples

Why use predictive functions with BPC data (Figure 9)?

• To identify hidden revenue and cost-reduction opportunities in your plan.
• To improve your forecasting accuracy.
  

Figure 9

Using SAP HANA predictive functions on BPC data for improved forecasting

I created a video (for a TechEd 2013 workshop) in which BPC data was subjected to predictive functions initiated through a dashboard UI. The dashboard allowed the user to select a desired predictive function, set function coefficients, execute the function, and update the working forecast dataset with any new data generated. A screenprint is shown in Figure 10; click here to view the entire demo:

Figure 10

Use SAP HANA predictive functions on BPC data for improved forecasting

Not shown in the video are the SAP HANA predictive functions called and executed against the current BPC data. When the operator is satisfied that a good fit of the predictive model has been achieved, they can save the newly generated dataset as a new working forecast. Using these techniques, highly accurate forecast plans can be consistently generated.

In additional to the collection of delivered predictive functions, SAP HANA includes access to the R-function library that can be used to perform predictive functions external to the SAP HANA environment. The R language is widely used among statisticians and data miners for developing statistical models. The SAP HANA’s R capability provides convenient integration for many third-party statistical tools.

Using SAP HANA’s Data Virtualization

Through the use of virtual providers, calculation views, and SDA, BPC 10.1 is able to access data from a number of sources without the need for hard materialization of that data. By virtualizing these data flows, the planning application can be more nimble and easier to maintain, as well as providing a complete planning solution with minimal cost. The combination of BPC and SAP HANA provides this additional level of efficiency and flexibility. Figure 8 shows several objects that illustrate the data virtualization approach.

The external database has data that may be relevant for the BPC application. Instead of using the conventional approach (e.g., extract, transform, and load [ETL]), Figure 8 illustrates the use of SAP HANA’s SDA feature. The SDA feature allows for easy connection to remote databases (there are several common databases that are currently enabled for this service; please review the SAP HANA Administration Guide, section 6.1.1 “About SAP HANA Smart Data Access,” https://help.sap.com/hana/SAP_SAP HANA_Administration_Guide_en.pdf for additional details on which databases are currently enabled for SDA).

Figure 11

Creating a virtual provider based on a SAP HANA model (in this example, a calculation view)

Merging BPC with Non-SAP BW data

When SAP HANA is used to support SAP BW, a collection of tables and other objects are created to logically store the essential information in the database. The collection of these objects that support SAP BW is located in a collective structure called a schema. A database schema is a way to logically group objects such as tables, views, and stored procedures. The SAP BW schema contains all of the support structures for SAP BW. But SAP HANA can also store information that is not initially associated with the SAP BW schema. For example, you can have event-streaming data, such as process-machine data or real-time credit card purchases, continuously loading information into SAP HANA using SAP Event Stream Processing (SAP ESP). SAP Data Services provides one of many solutions to load data directly into SAP HANA and is illustrated in Figure 12.

Figure 12

Merging non-SAP BW data with BPC/SAP BW

Once data is physically using (or virtually using, as discussed earlier) SAP HANA’s SDA features, the data can be easily exposed within the SAP BW application layer for easy BPC access. As you have seen, tables in SAP HANA can be virtualized in SAP BW using calculation views and virtual providers.

An alternative method of merging SAP BW and non-SAP BW data in SAP HANA can also be used: merging the data directly in SAP HANA itself. SAP HANA has an Import feature (Figure 13). The Import function converts SAP BW models into a fully supported collection of SAP HANA tables outside of the SAP BW schema (Figure 14).

Figure 13

SAP HANA modeler screenprint (import an SAP BW model into SAP HANA)

Figure 14

Importing an SAP BW model into SAP HANA (exporting out of SAP BW)

Once the BPC/SAP BW model has been imported into SAP HANA, the tables can be joined to other tables with SAP HANA using standard calculation views. Analytical analysis is easily accomplished by targeting the generated calculation view with SAP BusinessObjects business intelligence reporting solutions.

Sheldon Edelstein

Sheldon Edelstein is a director within the SAP Platform Solutions Group specializing in SAP HANA, SAP HANA Accelerators, SAP Business Warehouse (BW), and SAP Business Planning and Consolidation (BPC). He has over 10 years of experience at SAP and currently focuses on business development opportunities across a wide array of industries and product solutions. Formerly an SAP Platinum Consultant and SAP RIG –Regional Implementation Group—Specialist, Sheldon has either directly implemented or provided architectural guidance for numerous large-scale projects. Currently, his primary area of focus is HANA, but previously he specialized in BW-IP (Integrated Planning), BW-BPS (Business Planning and Simulation), and SAP BPC. Sheldon is an active presenter at numerous events, a contributor to the SAP Customer Network (SCN), writes blogs on a variety of SAP topics, and is an author of many guides on SAP Service Marketplace for use by the extended SAP community.

You may contact the author at Sheldon.Edelstein@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.