Demand Planning - Creating Groups of SKU's

[Former Member]

Hi,

Our Business has a requirement to be able to create groups of SKU's within the same Sales Org / Dist Chanl / Business Area where the products are related in no way other than having similar sales patterns. They wish to assign these products to the same Statistical Model which they believe will reduce the statistical error.

It was first hoped that we would be able to create a Charactaristic Attribute called GROUP assigning the products with similar sales patterns to the groups (maybe 10 groups in total). In Interactive Demand Planning, we would create a selection profile to select the group and then select the model required for that group. This we hoped would retain the GUID which would be applied in the background job from then on. We have found however that a selection on a Characteristic Attribute does not retain the GUID therefore this does not work.

The only option we can see is we create a Key Characteristic called GROUP which retains the GUID when the statistical model has been selected and would be applied in a background job from then on. However these groups would be changing quite regularly and therefore would require realignment on a regular basis (possibly daily). Running realignment for the first time when the GROUP Key Characteristic has been maintained would take 1 month of solid execution for Germany alone as we find that it realignment only processes approx 75 CVC's per hour.

Does anyone have any suggestion on alternative ways to approach this problem or how we might speed up realignment.

Hope the requirement and issue is clear. If its not I would be happy to explain further.

Mark

Edited by: Mark Pedley on Dec 16, 2009 6:29 PM

[Former Member]

Hi Don,

Your understanding of our requirement is exactly correct.

I have also read a note that it is possible via a BAdi work around to enable Navigational Attributes to Store GUID's of the chosen Forecast Profile, do you know if this is correct and would you know the name of the BAdi?

Your answer was perfect and I need to go away and understand how it all fits together so thank you for the time that you took to send me a reply, I am very grateful.

Mark

[Former Member]

Hi Mark,

This sounds like a fairly straightforward demand classification exercise. There will be 10 different groups that will have their own specific statistical forecast profile, and all CVCs will fall into one of those groups based on a set of criteria determined by the demand planning management, right?

- - - -

OK, so here is ONE approach...

- - - -

1. Clearly define the criteria that will be used to separate out the CVCs into 1 of the 10 groups. You help yourself out if you use criteria that are along the same line as the standard tests that are defined in the /SAPAPO/LFORECAST program, because you can then call these native functions in your analysis. The tests determine if a table fo data has seasonality, trend, sporadic demand, etc. You can explore this code if you activate the breakpoint '/sapapo/ram_fcst1' using transaction SAAB, then execute a forecast interactively in /SAPAPO/SDP94.

- - - -

2. Use the Analysis Process Designer (trxn: RSANWB) to perform an analysis of the history values (using an ABAP transformation and the native tests mentioned above) and come up with a strategy to assign a group to each CVC that is processed. It's a little tough to analyze the liveCache data directly, but it's a piece of cake to analyze the data that is in an InfoCube or DSO. Once you have determined that, you can use the function modules /SAPAPO/MCPSH_SELECTIONID_LIST and /SAPAPO/FORECAST_PROFILE_SET to assign a specific forecast profile to the CVC. These forecast assignments will then be visible using transaction /SAPAPO/MSDP_FCST2.

- - - -

Like I said, this is just one approach. A BW-oriented person might approach this through Transformation routines, a DP configurator might approach this by using macros on liveCache data, an ECC configurator might do this with InfoSet queries and an ABAPer might approach this with custom function modules and reports. I like the Analysis Process Designer because it's pretty friendly to learn to use and because an analysis process probably wouldn't require users to get out of the planning area for fear of locking data.

-

---

The ABAP required for this is about mid-level, not really something a functional person would want to commit to. A good ABAPer probably wouldn't have much trouble stringing together the statistical tests in /SAPAPO/LFORECAST but they might have LOTS of functional-type questions.

-

---

This approach requires ZERO realignment, since it evaluates the history data, determines the forecast profile that should be assigned, fetches the selection ID and then executes a function module to assign the forecast profile to the selection ID. The only data that is changed is the forecast profile assignment in transaction /SAPAPO/MSDP_FCST2.

-

---

Hope this helps your thought process on this subject.

Dan

Edited by: Dan Hofstatter on Dec 18, 2009 2:21 PM