Demystifying SAP BPC on HANA

Giuseppe_Dal_ColBy Giuseppe Dal Col
Solution Architect at Infogility

There has been a lot of buzz about the benefits of SAP BPC on HANA, but what does it all really mean and just how easy (or hard) is it to migrate your existing BPC implementation to BPC on the HANA platform. SAP HANA is SAP’s  in-memory database that performs at remarkable speed, and unlike other database management systems, processes both transactional and analytical workloads fully in-memory. SAP HANA provides not only a new database engine for SAP NetWeaver, but also introduces a shift of the processing from the Application layer toward the Database layer. This brings with it a lot of  capability, and when compared to BPC on a non-HANA database, the gains pretty much speak for themselves.

Data Accessibility, Performance and User Experience

The performance improvements mean that we can reasonably expect planning to be able to happen in real-time. Whilst this will not necessarily be relevant to all planning scenarios (as some are intended to be periodic), many planning cycles are conceived out of the need to push scenarios down through the business. With BPC on HANA, plans can immediately be disaggregated, and pushed down through the business in virtual real time. Furthermore, reporting on plan versions vs actuals in real-time finally becomes a reality – so as transactions are captured, the latest position can be reported almost immediately.

In other scenarios, many organizations simply don’t plan to much needed detail levels because of performance problems. While there may be valid reasons why you might not want a detailed plan, there are many scenarios where that might be really important, such as for retail customers or in supply chain optimization scenarios. With HANA high data volumes are very much a non-issue, opening the door to the type of detail level planning previously deemed unworkable due to performance constraints.
Still not entirely convinced that real-time planning is finally a reality…? Consider how the following gains will transform you current BPC experience:

  • Query performance up to 200x faster
  • Report refresh times up to 60x faster
  • Data input times up to 14x faster
  • Loading of data up to 11x faster
  • Driver based planning typically 2.4x faster
  • Allocations typically 2.3x faster
System Administration

System administration benefits from significantly shorter and less maintenance run times. Typical maintenance tasks such as Lite Optimization run up to 55x faster. For the foregoing, this is because with BPC on HANA there is no need to move data from the F-table to the E-table, as there is only one fact table in HANA optimized cubes. Only a DB table compression is needed, and with HANA this happens at the DB level and is extremely fast.

New HANA BPC Component BPC 10 on HANA introduces an additional ABAP software component, HANA BPC. This component is an accelerator for Planning and Consolidation and implements BPC logic/functions which can be accelerated by SAP HANA. The existing CPM BPC server component (which implements the general business logic) and the BPC client components remain unchanged.

In traditional BPC, lots of time is spent on the MDX layer for query parsing, calculation and aggregation. With a query on BPC HANA, the BW OLAP view is used, and neither model nor data replication is required, and measure calculations are pushed into HANA.

Migration without re-implementation

The beauty of it all is that it is possible to migrate without re-implementation, and (depending on the approach followed) this means minimal or hardly no disruption at all to existing scenarios.
There are several migration strategies that can be considered, each with their own pros and cons.

  • An In-Place Upgrade
  • A System Copy of the source system, then an in-place upgrade on the copy
  • A Fresh installation of BPC 10 on HANA system, and migration of the BPC content from the source BPC system
In-Place Upgrade

In this case, all components are upgraded to meet the requirements of BPC 10 on HANA, directly on the existing server. While this can seem attractive as the hardware is reused, it is also a potentially disruptive option as it means that the BPC system will be unavailable during the upgrade.
Pros:

  • Lower cost of hardware
  • Maintains customizations in BW that might not be related to BPC but nevertheless might be necessary for other usage.

Cons:

  • Could be somewhat risky, as it alters the original system
  • Disruptive – the system is no longer available from the moment the upgrade is started
  • Can potentially carry over some problems from the old system
System Copy and Upgrade

In this case a system copy of the source BPC system is done first, and the upgrade takes place on the copy. This option alleviates the risk and disruption of the in-place upgrade, while keeping most of the benefits of the in-place upgrade. It has, however, additional cost as extra hardware is needed.

System Migration

A new BPC 10 system is built directly on an SAP HANA database, and then BPC configuration and data is migrated from the source BPC system to the new BPC on HANA system.
Pros:

  • It is a straightforward, standard installation
  • There is no dependencies on outdated Operating System and database software as the system can be provisioned directly with versions that are supported by BPC on HANA
  • There is no impact on the source BPC system
  • As it is a fresh installation, no possible problems from an older system are carried forward

Cons:

  • Being a fresh installation, it will not contain prior customizations made to the source BW system
  • New hardware needs to be provisioned which has a cost

Each strategy has pros and cons, and their respective appeal will vary depending on the existing environment and ultimately on corporate strategy.

Irrespective of the approach followed, the end result is a step change in the way your organization does planning. Scenarios previously deemed unworkable due to performance constraints suddenly become achievable. The data lag you had to endure when comparing plan to actual suddenly fades away. The planning process shifts away from being reactive, and now becomes truly agile.

Now isn’t that just what the doctor ordered?