Blog

That is the question that many SAP customers have been trying to answer when considering implementing a planning, budgeting or forecasting solution within their existing SAP landscape. SAP nailed its colours to the mast early on and has been advising its customers for some time that they should implement using their Business Planning and Consolidation (BPC) software solution based on the NetWeaver technology stack.

The vast majority of SAP’s BPC development effort over the last three years since its acquisition of OutlookSoft has been to build tighter integration with its corporate data warehousing platform Business Warehouse (BW). It also announced at the beginning of the BPC development journey the end of maintenance in 2018 of its Integrated Planning (IP) application which is delivered as an integral part of BW.

SAP’s strategy for Enterprise Performance Management is clear – BPC is the future of planning for its customers. So the decision for customers to implement their planning solutions using BPC is simple then. Well maybe not. I believe that the answer is not quite so straight forward – based on where we are today in the BPC development journey, the actual answer is that it still depends.

What Type of Planning Application is it?

This depends on a number of factors that should be considered carefully before you come to the same conclusion as SAP. Firstly and most importantly, what type of application are you trying to deploy to your business? BPC was originally designed specifically to support financial planning applications and has built in accounting intelligence and data models to support them out of the box. That’s great but if for example you want to build a non-financial application BPC still expects your data model to contain key accounting dimension elements such as account, category and entity as a minimum and be based on specific BPC application types – financial, consolidation or generic. It also only supports an account based data model using a single key figure.

Now I’m not saying that this precludes you from building non-financial applications but consider for example a supply planning solution where you require multiple units of measure depending on material type. You are going to have to work a lot harder to build that solution using BPC than you otherwise would using IP where handling multiple units of measure and on-the fly conversion is a given.

Excel or the Web?

One of BPC’s greatest strengths is its complete integration with Microsoft Excel – in fact BPC can really be seen as an extension of it. So if the application requires the use of the Excel UI and native integration with other functionality then it’s a no brainer. It also has very powerful features for building distributed planning solutions where users can chose to take their planning workbooks off-line and standard Excel input schedules can be generated which can be automatically collected and loaded back into BPC at a later stage.

If however, you need to build and deploy a zero footprint Web based solution for example through the SAP Enterprise Portal (EP), then IP currently offers the ability to develop a far more comprehensive and integrated solution. This is set to change with the next version of BPC which is part of SAP’s Enterprise Performance Management (EPM) 10.0 release due for general availability in Q1 of 2012. This delivers a completely revamped UI with a significant emphasis on a new Web client which has been long overdue.

Self-contained or Integrated?

BPC has a dedicated namespace for each application set within the BW environment meaning that all data objects, both master data and transactional, are independent of those contained within the rest of the data warehouse. One of BW’s strengths is the use of a shared data model meaning that key master data objects can be updated once and a common and consistent view of those objects is provided to all transactional data. When deploying a BPC application consideration needs to be given as to how much and how often master data and transactional data needs to be moved in and out of this separate namespace.

If the application is largely self contained and data is only moved in or out at specific points in a process then this does not pose a problem but what if we need data to be moved in and out more frequently (e.g. daily, hourly or near real time), then this becomes more of an issue for the overall application design.

What’s the Reporting Strategy?

This separated environment also influences the reporting strategy adopted. If a strategy of BEx Analyser or BEx Web Analyser has been employed which the business wishes to retain then again we need to move our data out of the BPC environment before we can report it. Currently it is not recommended to report directly from a BPC application using BEx due to technical constraints and the added complication of separate master data objects when wishing to present a combined view of transactional data from BPC and BW data sources.

Business Objects BI tools such as Xcelsius, WEB Intelligence and Advanced Analysis are supported by both BPC 7.5 and BW and this provides us with the best strategy for ensuring business users adopt a common UI for all but this obviously has additional license and implementation costs if adopted.

How big is it?

For me the key question which still needs to be answered is BPC’s ability to scale. If your predicted data volumes are large then do you really want to be confined to a single account based transactional data cube? BW-IP gives us a range of tools and techniques to design and tune our applications to handle high data volumes. SAP will address this in BPC through the use of their new High Performance Analytical Application (HANA) which BPC version 10 will begin to exploit but again this means additional cost to solve a problem which BW-IP can do out of the box.

Scaling in terms of user volumes however is a little more straight forward. As we have discussed previously, BPC offerers us functions and features to create a distributed planning application which will scale to many thousands of users but what about if we need an on-line application for the same user base?

Can you justify the initial cost?

One fact that cannot be over looked is the challenge in defining the business case in terms of additional license and maintenance costs for existing SAP customers with significant investment in BW.  Again I come back to looking at BPCs functional strengths and its key differentiators from BW-IP.  If the application which you are looking to deploy plays to the strengths of BPC then it is a relatively straightforward exercise to justify the increased costs of the initial implementation but if not then it must be seen as a strategic investmemt as much as anything else.

In summary, BPC is the future for planning applications within the SAP domain – SAP themselves have already made that decision for us but the question which must be addressed by existing SAP customers who do have an investment in BW is when does it make sense for them.