Customer level in IBP S&OP

[Former Member]

Customer level in IBP S&OP

We are trying to get the correct definition in place what a customer should be in IBP S&OP. The background is that we don’t have (or will get) forecast on end-customer level, but only forecast for a specific country or region. And in the S&OP process it’s highly unlikely that we look at
customer data on anything other than country or even region (like EU, APAC etc) level.

We know all the talk about the speed of HANA and that it really does not matter that data is stored at lowest disaggregated level even though we only look at it on aggregated level. But what is the recommended strategy / best practice:

1. Should we create customers at lowest level in IBP S&OP (i.e. what they are in ECC)
   • Add the following attributes
     • Country: taken directly from the customer in ECC
     • Region (EU, APAC,etc): mapped via some kind of custom mapping where the country is mapped to higher level region (similar to the current BW solution)
   • Load forecast data on aggregated level (like EU region) and let IBP disaggegrate data down to the actual customer level
   • And try to teach the users that they should not care about the customers and only the country / region and that it’s a only a technical thing having the actual customers in there
2. Or create customers in IBP on a higher level which represent a country or even a region
   • So have one customer per country (or even region)
     • Add the region as an attribute to the customer
   • And then load the forecast directly to the “country”-customer and work on this level with no disaggregation

Focus right now is
IBP &SOP, but what if we look ahead at to the other IBP modules (Demand, Supply etc) – what are the thoughts about a common data structure between all the IBP modules?

Any input or experience would be much appreciated?

Br., Peter

[Alecsandra · Accepted solution]

Hi Peter,

As it is less likely that you will ever plan at the lowest granularity - end customers, I would recommend option 2.

Here are some drawbacks I can see for option 1:

a) You can only load transactional data at the base planning level. Loading data at an aggregate level requires a so called "landing" KF which is defined at the aggregated level. Then you would need to define a split factor KF which disaggregates the values from the landing KF to lower granularity.

b) Operators (e.g: Heuristics) are executed at the lowest granularity.

c) Having much more combinations, sizing would be impacted

Even if you go in the future for Demand module, the forecasting would still be executed on an aggregate level - country level, correct?

Regards

Alecsandra

[Former Member]

Thanks for fast response Alecsandra! And yes forecasting would probably still be done on aggregate level in the S&OP process.

I see your points and we will go that way.

Best regards Peter