Introducing Full Flexibility in IBP Design

date 05/30/2023

Even if you are not a consultant or a developer, this article is for you, particularly if you are from the customer side. It may help you to establish some design principles and governance to ensure that the solution you are being delivered and you massively investing in includes best practices.

The Background

When designing a solution, I do not hardcode anything if possible! If you are a developer or a consultant, you understand what I mean.

“Daniel, can you explain what is this hardcoded thing by the way? “
“Hardcode is simply a fixed data, like a given string or value, a special code, a determined element that is placed in a solution design. It is often a quick workaround that defines a solution behavior. “
“Humm…? Can you give an example?”
“Say for instance, in IBP, you wish to set a rebate of 10% for any customer being in Japan, and 15% for any other country. Typically, in the formula that drives the rebate key figure, you would likely state: “

This is what I call quick and dirty!

Quick because writing is straight forward, it does not cost much, and dirty because the value in yellow above, JAPAN, 10%, and 15% are internal constants to the formula. They cannot be changed easily, except going in configuration again, changing values and re-activating the IBP planning area.

Now let’s imagine you have 10, 20, 50 of these quick hardcoded things, disseminated in the design that includes maybe 500 to 1,000 key figures, you end up with a solution that is difficult to maintain and evolve.

Even worse, if your customer tells you, “We wish to rapidly change 10 to 12% for JAPAN and 23% for others”, this simple business request, full of sense, becomes a CR!! An IT change request, to be validated, tested, budgeted etc.

You probably see where I am getting at. With such definitions, you have successfully and efficiently created a frozen IBP design that can only be changed by means of IT tasks. The exact opposite of an agile solution business people request.

Flexibilize Your Design

Let’s now imagine we do not want the values above to be fixed anymore. We wish to introduce parameters that can be maintained separately by you, the consultant, and even business people. If the latter decided to change something in future, it would not be an issue.

That sounds interesting, doesn’t it?

Going back to the previous example, we transform the given formula as follows:

At the same time, we state in a simplistic parameter table accessible to you and the business:

With this new setup, JAPAN receives 10%, others 15%, and if business decides to change country and rebates, they simply maintain the table entries. No change of key figures in the formulas, no transport, no nothing except testing indeed!

This is what I call a more agile design, although ideally, the genuine agile solution could also be business people directly maintaining the formula. But this is another debate.

What Does SAP Propose?

Nothing yet in this regard. IBP being closed for any specific development (not cool), there are no ways to complement that gap with a robust custom development and a Ztable as often done in ABAP.

I have placed an Influence item to ask SAP to introduce a standard global parameter concept in IBP to avoid workarounds. Let’s see how it goes here.

How to Get Around This?

From this point the article becomes technical!

For the time being, let’s get around the gap. Below is the solution I suggest to close this gap, even if it is not ideal.

Important statements are:

“We want the ability to create many parameters, which should be usable in formulas, and maintainable by any authorized person.”
“Formulas are made of operators and operands.”
“Operands can be key figures, attributes or constants.”
“We don’t want any constant (not agile).”
“We can use key figures or attributes to make our design more agile.”
“Oops, key figures are only numeric, so we will not be able to set a value = JAPAN.”. I suggested to SAP to allow string-based key figures. Rejected. “
“Ok, we now have the attributes option left, which will make our day (isn’t it Clint Eastwood?).”
“But attributes are linked to planning levels and master data types!”.

So, adding attributes is a touchy option, particularly if the IBP implementation already exists. That means changing master data types and integration jobs. Each solution has a cost; however, the proposed idea keeps this change as small as possible, although opening your design for 10, 50, 100 flexible parameters.

Adding attributes is not global to a planning area. Attributes are attached to master data types like product, product-location, etc.! Obviously, if we need a parameter that depends on Product Master, we can add this as an attribute to the Product Master.

Basically, we now have two options to extend a global design with many parameters.

Option 1 – The Robust One:

We create a new master data type (MDT), say PARAM, made up of the many attributes we need as parameters, plus a key attribute.

Example based on previous figures:

ParamKey
Customer
Lowrebate
Highrebate

With the Manage Master Data Fiori app, we maintain one single record of this MDT.

We insert the new PARAM MDT in our planning area, and we assign all attributes (parameters) to all our planning levels. Warning, we set the ParamKey of the MDT as a root attribute in all planning levels. If we do this in an initial IBP design it should not be an issue, although a little more to do. If this is for an existing implementation that also means a lot of change as all planning objects (PLOBs) have to be reconsidered with the ParamKey. As we have only a single record of PARAM, the root for ParamKey is unique and does not multiply the number of PLOBs.

From this point, all key figures in this design can use the parameters freely. Job done but costly!

Option 2 – The Smart One:

With this option, I don’t wish to alter the PLOB structure (root) of the many planning levels. I wish to keep things slim.

The question therefore is: Which dimension is the most used one in IBP? Product, indeed!

What if I attach to the Product MDT just one additional attribute to be ParamKey identical to the one defined in the MDT Param?

What if I attach to all planning levels, the parameters defined in MDT Param; however not changing any root?

If you do so, the planning area activation fails with “PLOBID blabla ….failed” ☹

The trick is to create an intermediate Virtual MDT between Product and Param MDT, then attach to the planning area the Virtual MDT, not the simple MDT. By doing so, the root resolution is working and active. Full success!

Cherry on the cake, the ParamKey can be multiple, defining different parameter sets, without adding any additional PLOB.

Step by step

I am sure you need a step-by-step guide to see things happening.

Step 1 – Create a new Master Data Type (simple), say DLEPARAM made of one key attribute and many parameter attributes.

Going back to our example: DLEPAREAID (key), COUNTRY, LOWREBATE, HIGHREBATE. You have no limitation and are free to add many other attributes with each one representing a functional parameter (alpha or integer, don’t use decimal). In the below example, I badly named the parameters Param1, 2, 3, 4. Better, you give them explicit names to help in reading the formula later.

Step 2 – Once activated you can already use the Manage Master Data Fiori App to maintain your parameters. Pay attention to creating records, at least one:

Step 3 – Add also the DLEPAREAID attribute to your Product MDT and set it as mandatory.

Step 4 – Create a Virtual MDT that links Product and Param MDT. Here, its name is DLEPRODPARAM. Because this is a Virtual MDT, IBP will automatically establish the link between products and parameters. This is the trick! As shown below, product and parameters are linked with the DLEPAREAID attribute.