Showing results for 
Search instead for 
Did you mean: 

Advantages of BPC over BI-IP

Former Member
0 Kudos

Dear All,

I am new to BPC NW and would like your expert views on some of my observations on the much debated advantages of BPC over BI IP.

One of the benefits of BI IP was the integrated reporting capabilities with a common master data and combining the transaction data (actual and budget). However, as I understand BPC is intentionally not integrated with backend BW.

BW master data is different and separate from BPC master data, thus it is not possible to integrate BPC cubes with BW cubes. To view an actual vs plan comparison, data would need to be copied / loaded back and forth between the BW cubes and BPC cubes. However, it does not seem practical in scenarios where planning requires significant amount of actual data. Moreover, this would mean multiple reporting interfaces for the users.

BPC will be driven by Business users.

What is it that we are empowering the business users with? The ability to define his own dimensions / applications/ dimension members / Input schedules?

Usually planning requirement is not just a simple input enabled screen. There are many more functionalities that would be required which would need writing of logic, code etc. Loading of master / transaction data requires creation of transformation, conversion files and data packages. Obviously, these tasks would not be done by the business users.

To be honest, I am slightly concerned over giving the business user a free reign on creating objects in the system. Without proper training, things could get out of hand with duplicate objects popping up everywhere in the system. Another area of concern is possibility of modeling same data differently in BPC and BW. It might cause complexities while integrating the data between the two

BPC seem to be targeted to facilitate financial planning. However, we require planning for areas outside finance (headcount, volume allocation / distribution etc). I would have assumed that a reporting application of Type u2018Genericu2019 would have the flexibility to include only the required dimensions as opposed to having to include the standard dimensions of type A, E, T and C.

When compared to BI IP, I am not sure if BPC NW in its current form would be the best tool to deliver integrated planning in multiple areas.

Having said that, these are still early days for BPC NW. Hopefully we will see a tighter integration of BPC NW with BW and more flexible planning in non-financial areas in the future releases.

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos


I respect your opinions. BPC as you said, is not for financial planning only. It can be used for other plannings as well. I have used it for headcount, project planning etc.

You can definitely report on both actual and plan data. Either you put all the data in the same application or maintain 2 different applications. You can report on multiple applications. So, I dont see any challenge in that sense.

You are right by saying that business users, without proper training, should not be given access to the admin activities. However, the main advantage here would be that one of the business users can be trained and he or she can take care of the various objects. BPC admin is not very complex as designing in IP or BPS for that matter.

Hope this helps.

Former Member
0 Kudos

This is a reply to all the messages above. The first message by Meera Murali provides excellent points about IP vs BPC. IP is integrated with ECC & BI But BPC is not integrated with ECC & BI because (1) Master data can not be imported easily from ECC or BI into BPC. (2) Actuals in ECC and BI can not be compared easily with plans in BPC. These data must be extracted from ECC and BI, transformed and loaded into the BPC data structures (ie cubes, etc.). (3) This work requires significant IT expertise and effort. (4) Keeping the redundant meta data and data synchronized between ECC and BI and BPC would be a continual operational burden. (5) Claiming that business end-users can be made accountable for this administrative information management responsibility is unrealistic and preposterous. I would be very surprised that any business unit would want to turn a part of their department into a mini-data processing unit. If they do, then they have wandered far from their business mandate.

The two other messages by MercAMG and nilanjan chatte... simple assert contrary opinions about BPC but provide the reader no evidence or reasons to back their claims. To me these responses have no credibility whatsoever. I would hope that they would provide reasons and explain how they provide the integration between BPC and ECC and BI. Unfortunately, they do not!

Did they have to build the data providers from ECC and BI to populate and refresh the data in BPC? How much did it cost to build the BPC cubes and the ETL to initially populate them and to periodically refresh them? How often do they refresh them? How many active concurrent BPC users can simultaneously work with acceptable performance when there is no active refresh of the data occurring? How many concurrent BPC users can actively work with acceptable performance when the refresh of BPC is occurring? Do you only refresh at night? Have you had consistency issues with the meta data or transaction data between ECC & BI versus BPC? How do you detect the inconsistencies? How do you repair and resolve these consistencies?

Active Participant
0 Kudos

BPC is a nice tool for planning, it is well integrated with excel and business users doesn't have to learn a new tool other than excel to develope queries or input schedules.

In my opinion it can be a good solution for a greenfield project, expecially using to MS version.

I'm not sure in a different scenario: if you have an existing BW system you have to build many interfaces to pass the data to BPC. You can use BW data with BPC application (for comparing actual data and planning data, as requested) but it can be a lot of work, depending of your data modeling.

I mean, if you use a key figure model in your data warehouse, you have to transform it in an account model (and probably make an 'interface layout' in you DW, to make BW and BPC communicate). Other detail: BPC can't use compounding (so if you have more than one chart of account you have to think about it).

Also, working with the 7.0 version I had problem with performance using the scripting language, so I had to create the planning functions using ABAP.

Those issues are not impossibile to solve, but you need a lot of different skills; at the moment starting a BPC project means that you need a BW consultant, a Outlooksoft consultant and an ABAPer. And a lot of money.

Unfortunately SAP marketing is going to another way: take a look at this blog


It seems simple, doesn't it?

Former Member
0 Kudos

Thank you for your statement regarding the issues of using BPC in the context of BW. I very much appreciate your excellent comments.

Also thank you for providing the link to the statement about the advantages of using BPC because of the Excel user interface. It certainly does appear that SAP marketing is trying to get customers to move to Business Objects and BPC. Of course, it would be a strong advantage to be able to leverage the existing skills of Excel users.

We already own Integrated Planning and it appears to satisfy the immediate business requirements. We would have to pay for the software licences for BPC, which we don't currently own. Of course, we don't want to pay for these BPC licenses when we already own the IP licenses that will satisfy the requirements.

In addition, it indeed looks as though SAP is positioning BPC to use the Business Objects universe. Although we know that, eventually, we will probably have to convert to selected components of Business Objects for business intelligence, we don't want to have to once again make another substantial investment in SAP business intelligence when we so recently made such a large investment in the SAP Business Information Warehouse. We will have not yet earned our return on investment on the Business Informastion Warehouse.

Given the timing, we don't think it is fair that SAP expects companies to once again have to pay for the business intelligence software and to implement Business Objects, convert from the Business Information Warehouse to Business Objects, redevelop, retrain, and redeploy all the reports using the Business Objects tools. The customers will incur additional costs because of the reimplementation, conversion, redevelopment, retaining, and redeployment of the reports. Without this kind of consideration, in these economic times, it will be difficult for the installed base of companies to justify the conversion to Business Objects, and, consequently, for SAP to realize a reasonable return on its, not insignificant, investment in Business Objects.

SAP should provide an existing customer of the components of the Business Information Warehouse a migration path to the corresponding Business Objects components of comparable capabilities at no additional license fee as long as the customer is current on its maintenance. Of course, adjustments in the license fees and annual maintenance fees should be made if there are differences in functional and/or quality capabilities between the corresponding components of the Business Information Warehouse and Business Objects.

In our situation, we already and recently made a significant investment in the Business Information Warehouse and the Business Explorer (BEx) tools, implementation, and reports development. We don't want to have to pay to replace them with Business Objects. We thought we already paid big-time for the business intelligence tools and reports. We even paid for the BI Accelerator and have been very happy with its dramatic improvement on performance. We fear that a commitment to BPC may soon commit us to Business Objects, the latter of which, so far, carries a very large price.

Former Member
0 Kudos


In BPC Netweaver, Everything is possible that we have been doing in BI IP that is from:

1) Actual Vs Plan Comparison is possible and can be done.

2) You can develop headcount planning HR based, It does not have to be Financial, definately (100%)

3) The BI IP Data Slices CHar Relation, everything is there, It is just the way works is differemt

4) It uses the same Locking transaction of RSPLSE as in background.

My dear, all your queries that you have mentioned is possible. The only thing that is a problem is a integration with BW.