Integrated Planning is back! I have nothing other than deep respect for SAP’s marketing department as they are obviously capable of doing wonders only with a thesaurus: The newest release of the planning flagship BPC, version 10.1 SP4, offers two ways of putting a budget solution together. And the names of these solutions have just been changed from “Unified” and “Classic” to “Embedded” and “Standard”, respectively.
If we dwell for a moment on the linguistic part of the issue, the concepts of “Unified” and “Embedded” signify a sort of a connection, and the point here is nothing other than that the BPC Embedded model is interconnected with your BW system. You are tempted to use the expression “integrated”, i.e. as in “SAP BI Integrated Planning”. This is not accidental. If you have a look under the bonnet of the BPC Embedded model, you will find a BEx Query at an aggregation level that is built on top of a planning cube. In other words, it is BI-IP’s rebirth we are witnessing here, and the Embedded model is therefore fully integrated with the rest of your BW.
The opposite of interconnected is naturally non-interconnected. This is a rather negatively charged word, so let us use the somewhat more neutral “separate” instead. This is a very accurate description of how the BPC Standard model functions in your BW system: it functions all by itself in its own namespace, just like we know it from BPC Netweaver up to version 10.0. All master data and realised transaction data need to be copied to the BPC Standard model in order to be budgeted and forecast there. If you need budget follow-up – and, believe me, you will – the data must be copied back to BW (including the master data!). Thus the BPC Standard model is fully separated from the rest of your BW.
Embedded vs. Standard as time passes by. The disadvantage is that master data are shared with the rest of the company. As a rule, this makes it particularly difficult to budget for a new material, a new cost centre, a new project, etc. because they do not exist in the master data yet and are not so easy to create because of strict procedures (name conventions that needs to be followed, attributes that need to be filled, etc.)
BPC 10.1 is SAP’s attempt to tackle this disadvantage by giving the end-user access to creating master data directly from the front-end, which otherwise belongs to a new HMTL5-based type. This is a good step. Unfortunately, it does not solve the problem even a jot as it is not the possibility itself to create master data where the challenge lies, but, on the contrary, how you ensure that master data created by users in connection with the budget is standardised with master data that are created centrally. The solution to this challenge lies in the design of the budget application – and you are more than welcome to send me an email if you would like to know more about it.
The advantage of the BPC Standard is that users can design their budget solutions almost by themselves as it is easy to create new fields and master data for these. This results in immense freedom and it is users themselves who own the data rather than the centrally managed BW. The disadvantage is that both transaction and master data must be copied back and forth between the Standard model and the rest of the BW: if you want, for example, to base a forecast on realised data, you must first have hold of these by copying them to the model. Once the forecast is complete, you will naturally want to follow up on the realised data as time passes by and you will also have to copy forecast data back to your BW. Here you must make allowances for master data that are found only in the forecast, which results in the same problem as I described under the Embedded model above.
The magnitude of this challenge grows with the number of users since a consequence of the freedom to create fields yourself is that different people use different expressions for the same thing. It is people, you see, that we have to do with here. When you need to consolidate the budget of, for example, 10 subsidiaries or departments into a single budget for the whole operations, it is therefore necessary to standardise your concepts. And what do you do when the 10 departments have used their own code in the sales budget for a new product you are about to launch in 6 months’ time? You can solve this problem in the same way as the challenge with the Embedded model is solved above.
Which model should I choose?
If we need to spell it out, the above means that it is the BPC Embedded model that you should use when you need to prepare budgets and forecasts from a decentralised team (for example, departments scattered all over the world) which are consolidated into an overall central budget for the whole company – however, this requires that you have your BW in a HANA database!
The BPC Standard model should be used when you make budgets and forecasts for a single department or a single company – in other words, when there is no need to correlate with other data. If you need a solution for financial consolidation, it is also the BPC Standard model you should use, in part, because the result does not have to be integrated with other data and, in particular, because it is easy to create ledger entries and other entries at a later time. As a whole, the Standard model offers an ocean of financial consolidation functionality that currently does not exist in Embedded (such is currently on the drawing board).
In other words, we will see more functionality in the BPC Embedded model in the future. Does it need to change its name then again? I do not think so because we have, mind you, only “Integrated” left – and it is taken. But their marketing people do indeed have a way with words, and since the acquisition of BusinessObjects where they changed the name of the “Xcelsius” brand to the very functionally oriented “SAP Dashboard Designer”, I have always thought that if SAP were to take over, say, Coca Cola, they would probably, in this very same way, change its name to “SoftDrink”!