Digging Deeper into SAP BPC Embedded

In a previous blog post, I covered the very basics underlying the SAP BPC Embedded solution and its background tied to SEM-BPS and BW-IP.  With that understanding of BW Characteristics and InfoCubes and how they relate to what happens automatically when we create the equivalent Dimensions and Models in BPC Standard, I’ll continue on with the next steps to creating a full-functioning BPC Embedded solution that end users can access from the front-end interface.

MultiProviders – Tying It All Together

As I alluded to in the previous post, there are a number of objects that must be created after the initial Characteristics and InfoCube is created in BW. The first of which is another InfoProvider – or more specifically, a MultiProvider.  The MultiProvider won’t actually store any data, it acts as a way to allow data from multiple source InfoProviders (i.e. InfoCubes, DSOs, etc.) to be read in a single query.  For example, an InfoCube may be created in BW for the purposes of sourcing GL data from ERP and because this source is intended to be kept ‘pristine’, no users should have write access to that InfoCube.  Therefore, a separate InfoCube is established for storage of Plan/Forecast data; but there is no way to combine information in a single report without first assigning both of these InfoCubes to a MultiProvider.

You can assign many source InfoProviders to a single MultiProvider; however, you need to relate the InfoObjects (Characteristics) to one another. For example, the system needs to know that 0GL_ACCOUNT that is used in the Actual InfoCube is related to ZGLACCT that is used in the Planning InfoCube.  Like BPC Environments, the same Characteristic could be shared between the two InfoCubes, in which case BW should assign them correctly to one another when the mapping is proposed.  Of course, there could be cases where the dimensionality of the InfoCubes assigned to the MultiProvider are not the same (e.g., Profit Center exists in Actual InfoCube, but not in Planning), in which case there would be no equivalent mapped.

There is really no direct equivalent to MultiProviders when considering BPC Standard functionality; reports from multiple Models can be performed from the EPM Add-in, so long as they are in the same BPC Environment.

Aggregation Levels – Define What’s Relevant

Next up on the list of to-do’s is to create an Aggregation Level on top of the MultiProvider. Created in BW Transaction RSPLAN, Aggregation Levels allow you to define which Characteristics in the MultiProvider are relevant for planning purposes.  For example, there can be a few dozen Characteristics in a MultiProvider; but users would be overwhelmed to have to choose a valid value (i.e. BPC Dimension Member) for each of these Characteristics, many of which are likely not relevant to what they are attempting to input data for.  The Aggregation Level dictates which Characteristics are expected to be planned to, while the remaining Characteristics would contain a ‘null’ value (commonly a ‘#’).

It is possible to create multiple Aggregation Levels on top of a single MultiProvider where different Characteristics may be relevant for different types of planning. For example, an Aggregation Level for expense planning may contain Cost Center, but an Aggregation Level for revenue may not.  Therefore, careful consideration must be taken when choosing the number of Aggregation Levels to be created – too many could result in added maintenance and added frustration of end users trying to figure out which ones to use, but too few could result in irrelevant Characteristics being required for end user input.

The comparison of this capability to BPC Standard, to me, is similar to determining the right balance between accommodating the planning requirements in a single Model versus setting up a separate Model. Detailed Revenue Planning by Customer and Material would typically be done in a separate Model from the GL-based “Finance” Model in BPC Standard; however, this could be done in a single InfoCube/MultiProvider in BPC Embedded, but using a different Aggregation Level.

Filters – Further Restrict Planning Data Set

As the Aggregation Level determines which Characteristics of the MultiProvider are relevant for planning, the Filter has the capability to further restrict the planning to specific values (i.e. Dimension Members in BPC). An example would be that the Version Characteristic is valid for planning (thereby included in the Aggregation Level), but the user should be limited to keying data to the Forecast Value, so it is therefore included in the Filter.

Filters can only be defined on Aggregation Levels (not InfoProviders) and are a requirement for the creation of Planning Functions and Planning Sequences (more on those in a bit). Filters can restrict the Characteristic using single values, value ranges, hierarchy nodes and variables.  I could do a whole blog itself on variables, but simplistically, they are a way to allow for a user to select value(s) that get passed to a Filter, Query or Planning Function to make it more dynamic.  An example would be that you could set up the Filter to be a hard-coded range of accounts, say 400000-499999, as those represent revenue accounts.  But a user would not be able to select an account that was not in that range when they run the Query/Input Schedule.  Instead, a variable could be set up that would allow the user to key in the range that they want to show up in the Query/Input Schedule so that they could set the range to whichever accounts they wanted to.

Similarly, for the example I gave above about limiting users to keying data to the Forecast value, this could be hard-coded into the Filter if that was the only Version that users should ever be keying data to via an Input Schedule or they could be prompted by a variable at runtime to select a single value from a list of Characteristic values.

Planning Functions – Basis for Data Generation

Now that the Aggregation Level has defined the valid Characteristics for planning and the Filter has determined what values for those Characteristics should be utilized, Planning Functions are created to assist with the generation of the budget or forecast. Similar in capabilities to out-of-the-box Data Manager Packages in BPC Standard, there are system provided Planning Functions in BPC Embedded for items such as Copy, Delete, Move (Repost), statistical-based Forecast using several methods such as trends and seasonality, and simple increase/decrease by a percentage (Revaluation).  For data generation not covered by the standard planning functions, customizable logic (FOX Formulas) can be developed in most cases.

An Aggregation Level and a Filter are required for the creation of a Planning Function. This means that the Planning Functions may not be quite as flexible as the out-of-the-box BPC Standard Data Manager Packages – yes, Variables could be introduced to the Filter to make them more dynamic, but this may not always work depending on what is required.  For example, if a given Aggregation Level and related Filter are to be applied to a Planning Function, as well as, be used in a Query/Input Schedule, then they must be set up with both use cases in mind and that may not always be feasible.  The alternative is that unique Aggregation Levels/Filters are set up to support Planning Functions in addition to those that will support a Query/Input Schedule, but this adds to maintenance.

Another item of note is that BPC Standard Data Manager Packages require no additional setup once BPC is installed – simply use the Copy Package to copy any data from one location to another. At least one set of Aggregation Level/Filter/Planning Function would be required to mimic this capability, and likely more.

Planning Sequences – Executing the Process

Budget and Forecast processes, or even steps within these processes, generally have many activities that need to take place in a specific order. Planning Sequences allow for the grouping of Planning Functions in a specified order that can then be executed at one time.  For example, a Planning Sequence could first have a Planning Function to copy Actual data to the Forecast version and a second Planning Function to automatically increase the values by 3%.  Rather than have the user run each individual Planning Function, they can run the single Planning Sequence.  The equivalent on the BPC Standard side would be Data Manager Package Links.

Characteristic Relationships – Connecting the Dots Between Characteristics

There are often cases where there are linkages between master data objects that would be beneficial to utilize the system to ensure that the transactional data stays in-line with those ‘rules’. For example, in many cases, Cost Centers are tied to Controlling Areas, Profit Centers, and Company Codes.  In a case where users are entering a Cost Center budget, wouldn’t it be nice if the system could post to the right Controlling Area, Profit Center, and Company Code for that Cost Center without the user having to make that selection in an Input Schedule?  Well, that’s what Characteristic Relationships allow you to do – utilize Attributes (Properties in BPC Standard) to make the proper postings.  In BPC Standard, we’d typically do some Excel magic to pull in Property Values for use in an EPMSaveData formula or store the data to a single “NO_” member and write a simple script to reclassify it to the right member in Default Logic when data is saved.

Wrap-Up

We’re nearly there when it comes to putting together the pieces of the BPC Embedded puzzle that would allow end-users into the system to create their budgets and forecasts. In this blog, we’ve covered the majority of the BW SAP GUI-based configuration, but we’ll save discussion of the remaining items that are handled outside of BW for another post.

Again, no real mention of SAP BPC Optimized for S/4HANA in this blog post, namely because the building blocks of that solution are the same as those we covered above for SAP BPC Embedded, it’s just that SAP delivers pre-built objects for customers in the Optimized version.

To learn more about transforming your finance department, read our white paper on achieving a faster financial close.