DP: Hierarchy in PlOb structure with hierarchy characteristic

[Former Member]

Hi all,

currently we have client in the Apparel+Footwear industry, and as always their requirements are complex.

In our to-be-designed DP solution we built up a simple plannign hierarchy with two dimensions, market and product. On the product dimension (and I am not talking technical dimensions yet!) we have one special requirement to model a hierarchy in one characteristic with an unknown number of nodes, therefore it is about possible to model it as usual in the CVC.

Question therefore is, if in this special case a characteristic hierarchy makes sense, also planning wise, and if so, how dis/aggregation works in this complex environment.

To get more into detail:

Market hierarchy: global -> region -> area -> sub-area -> customer

Product hierarchy: brand -> product division -> ... -> model (hierarchy) -> article

So model (hierarchy) is our problem, as there are, for different product divisions, different levels of models in parallel (conceptual model -> design model (1:n) -> planning model (1:n)....) therefore being a hierarchy with different nodes, the number changing depending on what division you look on. Planning should be possible on each level...

If not possible, we have to come up with a fixed max. number of model levels, that potentially blows our CVC.

As always, this is partly the as-is, so the to-be will experience simplification anyway. Just want to check the technical feasibility, as I haven't heard from anybody that this works... except in BPS

Regards, and thanks in advance,

Klaus

[Former Member · Accepted solution]

Thanks,

we also decided to model it using characteristics (lower level) and the other levels as navi attributes.

Thanks for your contributions!

[srinivas_krishnamoorthy]

We faced a similar problem in one of our client implementations. In situations of parallel levels, one should go for a seperate characteristics. I have heard of implementations where 18 characteristics have been used and there is no adverse impact on performance. In situations where you have 1:n relationship and the higher levels are just for viewing purpose (read no forecasting) then you may go for Nav attribute.

[Former Member]

would it work if you use navigational attributes for the Model(heirarchy) and fix all those nodes there?

this might help in the situation of your CVCs getting bloated.

Alternately, depending on your DP process, you can do the planning for models in a different MPOS and consolidate it back to the main planning area at a level with common characterisitics

[Former Member]

Dear Klaus,

Can you elaborate more on this scenario.

Is is that in the hierarchy, under a one particular division, there can be a "conceptual model", "design model" as well as a "planning model"? or one division always has only a particular model under it?

Regards,

Kedar