Skip to content

    • Custom Version Best Practices: Sales Forecasting and Planning Models

    in Modeling

    Hi all,

    I'd love to hear how you've successfully implemented custom versions in your organization. Please share your experiences or any resources you know of that outline best practices!

    I've seen two common approaches in the models I've worked in:

    Most common: Custom versions are a dimension in nearly every module. Most of the work is done in the forecast version then the data is bulk-copied into other versions as needed.

    Example: the FY24 plan is in the "forecast" version until it is finalized and FY23 actualizes, then it is bulk copied into the "plan" version.

    Less common (my preference): Most modules don't have versions as a dimension. New versions are created using a custom snapshot of all the relevant inputs/outputs. Only reporting and scenario analysis modules have versions as a dimension.

    One thing I've struggled with, regardless of the way custom versions are implemented, is sending data to other models. Using the example above, as of Dec-23 our planning models have the FY24 plan in the "forecast" version but the FY23 plan in the "plan" version. This is problematic because other models are expecting to receive all of this data in the "plan" version. There are plenty of ways to create workarounds for this, but I'd love to figure out a custom version architecture/workflow that doesn't require this type of workaround. Does anyone have any clever ways to address this type of issue?

    Tagged:

    Welcome!

    It looks like you're new here. Sign in or register to get started.
    Sign In

    Best Answer

    • Answer ✓

      @cbrookes I've implemented a a custom version that performs what you require. We had a list called Snapshots. Users could create monthly snapshots and scenarios. E.g. Nov 23, Dec 23, Scenario 123 but there was specific list item called "Budget" which would contain the current and previous FY planned budgets. The way it would work is as follows:

      1. Users would create a snapshot to model various scenarios for the next FY. E.g. Scenario 1.
      2. Once they are happy with a snapshot scenario they have created, there's an action they run that copies future FY years from the scenario to the Budget snapshot. Users don't need to enter the specific date range to be copied over. The rule is to copy the full 12 months of the next FY. For example, today's period is Dec 23 which is part of FY24 in Australia (Jul 23 to Jun 24). If I was to copy a scenario I created today to the Budget snapshot, it would only copy the period Jul 24 to Jun 25

      In your case, there are 2 options I can think of which you most likely have already considered

      1. Create a "Plan" custom version then in the Anaplan process you execute to create the FY Plan, e.g. FY23, add another set of actions that copy the 12 month period that covers the FY plan in to the Plan version
      2. Create a new module to report all Plans. Have the following line items:
        1. "Month FY". Format is Time Period Year. Use formula PERIOD(CURRENTPERIODSTART())
        2. "FY Plan". Format is your custom versions. I'm assuming there's a means for you to derive the custom version FY Plan via item a. above
        3. "Value to copy" Format is number. Formula is something to the effect of <Source module of FY plan>.<Source line item>[LOOKUP: FY Plan]

    Answers

    • @cbrookes

      have you read/seen this article?

      OEG Best Practice: To version or not to version?

      AnaplanOEG

    • Thanks @rob_marshall! That is helpful.

      To be honest, I've pretty much ruled out native versions because the experienced architects I've worked with said no one uses them anymore. Plus, I've never actually had a chance to work with any models that utilize them myself. But now I realize I should learn more about native versions and see if they could be the right solution for what I need.

    • @cbrookes

      Well, I have been at Anaplan for almost 10 years and still use them. It all depends on the use case and how they will be used. To say no one uses them anymore is flat out false.

    • That's good to know. I'll have to make sure I understand the functionality so I have it as a tool in my belt.

      I'd still love to hear how people deal with having their plans in two separate versions (ie FY23 Plan, FY24 Plan)

      I'm looking for the most elegant way to accomplish this:

      FY23 Plan + FY24 Plan → Plan

      The specific scenario is we have a bunch of recruiters that need our sales headcount plan in a headcount tracking model. The view is plan minus forecast. They don't care which plan version it is, all they care about is how they are hiring against the plan. As of today, they can view FY23 and FY24 time periods.

      There are a million ways I can hack this data together to give them the view they're after, but I'm searching for the best solution.

    • edited December 2023

      Here are the solutions I'm considering:

      • Create a custom "bulk load" that lets the user control which time periods to load
      • Combine the data in the target models using formulas

      I recall @rob_marshall saying something to the effect of "loads are often used as a crutch and most times formulas can accomplish the job more elegantly". This feels like it could be one of those situations. I don't like the idea of maintaining custom bulk loads, which would require me to create a new load action for every input line item.

      I was hoping to address this more seamlessly by changing our model architecture.

    Welcome!

    It looks like you're new here. Sign in or register to get started.
    Sign In

    Welcome!

    It looks like you're new here. Sign in or register to get started.
    Sign In

    Quick Links

    Categories