Disaggregation

GuruAP

Hi - I have five levels of hierarchy for one dimension and four levels for another dimension. The forecast is generated at these two dimensions at the lower levels of the hierarchy and the ask from the business is that they can input any level in the hierarchy - there are different types of inputs from different stakeholders, at region level or DC level. If the logic for disaggregation is based on the baseline forecast, what is the smart way of building it? I am thinking of break-back functionality but with different levels and to ensure the disaggregation happens based on the generated baseline forecast at the lower level, I should first need some data in the break-back line item in that proportions. Also considering inputs coming from different people and to record these inputs, I am not sure if the break-back functionality is something that becomes useful for me in this context. Is there no other way other than creating those number of modules at different possible levels and then write the disaggregation logics all by myself?

I want to understand from the community for any smart way of achieving the same. Also, I would like to know how complicated the disaggregation logic based on last three months average will become in relation to the disaggregation based on the generated baseline forecast.

Thanks for all the inputs,

Thanks,

Regards - Guru

esvensson

Hi Guru, is there any sequence of events with the inputs? For example, I've seen a top-level adjustment happen with breakback to generate a starting forecast, then the top-level output gets pushed down to the lower levels as "finance guidance" which can be overridden (ie disaggregation). I'd also be curious about user access with breakback. If multiple users are interacting with a breakback module concurrently and their access overlaps it could be confusing to see numbers changed. Happy to elaborate if you can provide a bit more detail

 

-Erik

einas.ibrahim

@GuruAP 

Wow, That's a lot of planning interactions.

You can certainly use break-back for top-down disaggregation. To answer your questions about how will Anaplan know how to "break-back" the total value of the parent if all the children have an initial 0 value, there are 2 ways:

1. The default way which basically divides the total (parent) value evenly over the children

2. You can use a separate seasonality module to determine how you want the parent value to be disaggregated. 

The first method is much simpler but the second method gives you more flexibility to disaggregate the values based on different seasonality profiles. (3-month average, baseline forecast, or any other configuration.)

 

Re-read the break-back explanation on Anapedia, there is a lot of information there to help with your situation.

Good Luck

 

P.S. you could also consider SPREAD if you are disaggregating over time

GuruAP

There are interactions coming from different stakeholders, from depot managers to regional managers to product category managers and inputs from the marketing team. Somewhere, all these inputs are to be captured, so thinking an easy way to get this done. Break-back doesn't seem to work for us in this scenario.

GuruAP

Hi - the first method is definitely not the option for me. I am only looking at any smart ways of implementing the solution if at all I need to disaggregate the data of a line item based on a different line item (say, baseline forecast). Like use a break-back line item, do an import action and populate the proportions of the baseline forecast into a break-back line item and run an overnight action to copy the manual inputs into this line item so the disaggregation will happen based on pro-rata (as per baseline).

But the challenge I see here is: how do I know what input to be prioritized i.e who has updated last at what level in the input line items? Or does it mean each time a manual input goes from someone, the user should also run the import action? Also the question remains: if I take three levels 1, 2 and 3 in a hierarchy (3 being lower) and 3 has four list members with a quantity of 100 each making the total sum at 2 as 400. Under 1, there is one more list member along with 2 which has a value of 600 so the total of 1000 is seen at level 1. Now, if a user modifies the total sum at level 2 from 400 to 450 and if we ask to run the import action, what sequence does the break-back follow - does it first copy 1000 at L1 to break-back line item and then copies 400 at L2 to break-back line item and so on? I see a problem here in whatever the sequence this functionality follows.

Thanks,

einas.ibrahim

Hi @GuruAP 

It is unrealistic to assume users can update Top-Down and Bottom-UP without having some guiding principals/rules.
For example, in Anaplan's finance demo model, we allow implementing Top-down and Bottom-up planning as follows...

Allow a top growth % to be applied over PY data to arrive at the organization's (top-level) goal. Say that it is to increase the sales to $100M this year. This becomes the guiding parameter for the lower level (say regions) targets.
If I have 3 regions then we can distribute the $100M amongst them using any method (based on PY sales, equally, # products sold in each region,....).

 

Now let's look at the Bottom-Up approach...
Consider the hierarchy level under Regions is countries and we want the countries to plan bottoms-up, then we again distribute the total Region $ share over all the countries using whatever method is appropriate then allow bottom-up planning for each country given that the country has to hit the target assigned for it.

 

Not to complicate things more but you can use the Hold and Override technique to change any of these allocations within the same level without exceeding the target.

 

To better understand my approach, download the model Planning, Budgeting, and Forecasting for SaaS from the App Hub and check the dashboard Annual Plan - Cascade Booking by Stream (screenshot) and study how they implement the hold and override. It's not the complete solution but it's a good start.

 

 

 

 

rob_marshall

@GuruAP 

 

Please try to stay away from using Actions as it could have concurrency issues.  Instead, model it out by using formula as well as your hierarchy.  Obviously, I don't know the ins/outs of the requirements, but treat it as a guided analysis for the end users where they are only entering data at certain levels. Then, at the lower levels, you can have the input from the above level or override it with what that "line level" person thinks the data should be.  

 

Again, whatever design you come up with, try to leave actions out of the equation.

 

Rob