Creating new line items for each year instead of using native time?

cbrookes
cbrookes
in Modeling

Hi All, 

I recently took over a few models that make use of a month list and separate line items for each year instead of Anaplan's native time functionality. I was told the models were built this way because end users didn't find the dashboards to be intuitive and this was a means to improve the user experience. 

Here's an example of the end result:

cbrookes_0-1638380758605.png

 

I've completed L3 model building and don't remember seeing any mention of this type of model design. I'm curious what Anaplan's stance is on this design? While I do agree that the above view provides a nice user experience, it seems to be at the cost of maintainability.

The Anaplan ecosystem at this organization is still in its early stages, but growing fast, and I'm worried if we don't move away from this type of model design the maintenance will become unmanageable.

Tagged:

Answers

  • JaredDolich
    JaredDolich

    @cbrookes 

    I'm definitely leaning in your camp. Not sure hardcoding a line item, especially the name, is wise or sustainable. Breaks a lot of PLANS suggestions too. I will, however, denormalize values by using the OFFSET function, for example, creating a line item for last year sales to show up in the current period. This allows me to compare TY and LY if I don't use native versions. But that is sustainable since the changing of the calendar will automatically update these line items. 

    I would strongly urge your colleague to consider using OFFSET, LAG, LEAD, MOVINGSUM, etc. instead of hardcoding line items. Or, at least, try to understand better what the plan is when the model calendar needs to rotate. That might be rather persuasive!

  • MarkWarren
    MarkWarren

    Your instincts are right here and I agree with what Jared is saying.
    Ideally we try to build models with this methodology:PLANS - This Is How We Model

    The design has to consider performance and maintainability, whilst balancing auditability and usability; your model may be skewed towards only considering usability.

     

    Consider how the model will scale and is the current design capable of that, how much extra work would it need, when you move to a new year for example. Which I think you are doing 👍

Categories