The BPC in “SAP BPC” stands for “Business Objects Planning and Consolidation”.
As such, its primary use is by business teams in organisations in order to conduct Financial and Operational Reporting of actuals (both legal and management) and collect, construct and report the financial forecasts and budgets.
The level at which this data is reported is often at a summarised level and not at the fully granular level found in the company’s main transactional/ERP systems.
But how far could BPC’s use be stretched and could it be used as a fully-fledged BI tool?
Typically BI tools are used by organisations to report on all manner of items that an organisation may wish to report on. The source data can be extremely granular and BI tools are designed to handle extremely large volumes of data.
Is BPC such a tool? Can it be configured and used to support such granular level reporting?
There are various aspects of BPC that need to be considered before coming to a conclusion on this idea, and organisations that are thinking along these lines should carefully weigh up the pros and cons of adopting, or attempting to use, BPC as a BI tool.
Organisations like the BPC product because it offers all the benefits of a controlled data environment i.e. a database with user security and rules of operation, with the flexible and widely-used reporting offered by the Microsoft (MS) Office suite, specifically Microsoft Excel. End users are extremely familiar with these MS products and this factor alone can lead an organisation to choose BPC as its financial reporting tool of choice.
But what happens next? Can BPC be used more extensively?
The clues to the answer perhaps lie in the way BPC stores the data that it holds. Each datapoint is defined by an intersection of the dimensions that define the model and its purpose. In order to hold a piece of data (e.g. units or monetary amount) then the members of the dimensions that define that datapoint must already exist in the database (e.g. entity, category, time period, account). In financial terms these items tend to be relatively static: Charts of Account do not alter that much nor do entity structures.
Once you start considering other data items e.g. invoices (both AR and AP), inventory items, the asset register and so on, then you are faced with different scenarios as these items, depending on your business, can have significant volumes and frequent changes. These would be described as rapidly changing dimensions. The challenge then with BPC is keeping the master data in the dimensions sufficiently up-to-date (e.g. nightly updates via automated interfaces) so that the actual datapoint can be held against these master data elements. The “accounts” type dimension can explode in size in order to hold the various key figures that you organisation wishes to report. For example, if BPC is to be used to report Goods Received Not Invoiced then BPC would need Supplier details in one dimension, Purchase Order details in another and then accounts dimension would need additional lines e.g. Purchase Order (P.O.) Quantity, P.O. Value (net and gross of tax?), Received Quantity, Received Value, Invoiced Quantity and Invoiced Value. At what level do you hold this data? Purely at P.O. level or do you have to go down to line item (SKU) level? Someone in your organisation will always want the next level of detail whatever level you decide to hold, and you already hold this low level granular detail in your source system(s). Do you really want to duplicate it all in BPC?
Building and maintaining the required dimensions and interfaces to use BPC as a BI tool would undoubtedly require extra resources with broader business knowledge. The desired business outputs need to be fully understood and translated into functional and technical requirements for the ERP/DW/BPC team to deliver. “Such is the case anyway” you might say, but such skills are likely to be required from beyond the “normal” BPC scope of the organisation’s Finance team, the ERP GL tables and a broadly simple ETL process. And then you are faced with questions like how often to run the update and load processes. Given that master data needs to be updated before the main data load, these processes are likely have to be scheduled outside of normal business hours so that Business As Usual activities are not adversely impacted. Would such a refresh and update schedule be acceptable to the business users requiring the information? At the very least they will need to be fully aware of when they will be able to use the data they require and have their expectations managed accordingly.
So what is the answer?
In my view, for BPC versions up to and including 11 in the Standard configuration, the answer is probably yes, it can be used as a BI tool but you need to be very careful and really think about what you want to report and how you want to report it before totally committing to heading down this path. For what your organisation requires it may be better to use BPC for its primary purposes and consider a bespoke BI solution for your other reporting (clearly there are cost implications with this approach too).
As for BPC versions in the Embedded configuration, this could be really very different as data duplication is not an issue and the data structures are completely different. However, the skills required to set up and then manage and maintain an Embedded solution may well be an issue as the emphasis seems to be back with IT as opposed to being with the Business.