Versions to compare latest plans

I want to be able to compare to earlier versions of the plan ( so when we can to month +1 i want to be able to compare ‘current’ plan to previous plan ( and also with earlier versions).
There is a solution in creating a seperate version and then bulk copying into it.
Is there a more automated , best practice or simple sokution for this standard planning requirement? Is there an app where i can see it in practice ? Thanks


Best Answer

  • Hi, 


    There are several ways I've approached comparative analysis like this.  The approach selected is largely dependent on how the client operates.


    1. The method you mentioned (bulk copying the version you want to compare to into a 'comparison' or 'prior' version).  Some clients operate in the context of 'current' and 'prior' forecasts, so this is ok for them because they are already using a (standard) 'prior' forecast.  This doesn't work well when there are multiple historical versions and a related need to compare to any of them (at a given time).
    2. If there is a limited/fixed number of historical versions, create all the variations in one or more variance modules.  A recent client always reports like this:  Forecast vs. Actuals, Forecast vs. Prior Forecast, Forecast vs. Budget... so we have a single module that ropes all of this in.  Works like a charm.  This is a variation of option 1.
    3. Other clients get a little squirrely (sounds like your case)... There is a requirement to be able to redirect the comparative versions frequently.  In this case, bulk copy can be annoying, not just because you have dedicated variance report version(s) (which use workspace), but bulk copying every 10 minutes is inefficient.  There are several ways to make this a little friendlier:
      1. If all of the versions you use exist in the model, then you can use a (sometimes lengthy) IF-THEN-ELSE statement tied to a version selector (either a list of or a boolean checkbox) to populate the appropriate version.  A recent client has a very fixed number of versions per year (budget and 12 forecasts), plus a limited set of variable versions (as the end of the year approaches, there are always a number of superceded forecasts).  We set up the Budget + 12 Forecasts, and also added ~10 variably named iterations of forecasts, then baked them all into the formula.  To allow for nice selection, we created a false versions list that mirrors the real versions, and then used that list as the format for two line items (Version 1 & Version 2) in a selection module.  The IF-THEN-ELSE looked to the selection line items for which versions to populate.  This works fine as long as the versions are predictible, and you have enough workspace to have some empty versions sitting there.  
      2. If you can't afford to have some empty versions in your model, then a similar selection approach can be set up with a list containing just two versions (Version 1 and Version 2)... tied to a module with a boolean selector to indicate which real version to align with the comparison version.  This is used on combination with Collect() to populate the correct versioned data.  While this takes up some space also, it permits the rapid swapping of versions in production.

    I hope this helps.  Let me know if you want more info on any of this and I'll try to work up some quick demos.




  • an related question is : 

    I want to compare forecast version with actuals ( also for the periods where the switchover already took place. it looks from comparing version in rows , that the forecast item looses its forecast values untill the swithcover period. ( looks like th forecast is overwritten by the actuals ). is my understanding correct and does anaplan 'loose' the forecast values before the switch over period ? If not , where can i find the forecast values for period that already switched over ? 

  • Paul, can you dig a bit deeper in your solution '2' ? how do i build such a module, especially for the previous forecast item line ? what's the formula to use for that item line ?  thanks a lot.

  • Hey amay - did you find a solution to #2 from Paul Ritner's thread?   Would also be interested in find out more.