Profitability and Cost Management

Get Involved. Join the Conversation.

Topic

    Aamir Zaveri
    Driver DimensionAnswered
    Topic posted November 18, 2019 by Aamir ZaveriRed Ribbon: 250+ Points, last edited November 18, 2019, tagged Trace Allocation 
    36 Views, 3 Comments
    Title:
    Driver Dimension
    Summary:
    Considerations for adding a driver dimension to Metadata
    Content:

    Hi,

    What are the considerations for adding a driver dimension to metadata, whereas we can maintain drivers in Account dimension pointing to a statistical account. Only reason I can think of is traceability, if end user want to know which driver has been used for this allocation. 

     

    Appreciate any suggestions.

     

    Thanks

    Best Comment

    Alecsandra Mlynarzek

    Hey there John, Aamir,

    We generally navigate around the summing up to total Account by ignoring the Driver node using the consolidation operator of: (~).  Also if your Account dimension is Label only and the top Account node is your Expense + Revenue total, then the "Account" total should be accurate without any further work.

    If you need drivers by accounts (in case you have account to account allocations) you will be forced to have a separate Driver dimension.

    But if you don't and your app is already fairly large, adding another dimension may not be the best option. So weigh in your volumes of not just metadata members in a dimension, but also number of dimensions and data granularity, and then make a choice. 

    Finally, one more aspect to consider - check your integration options. Is it easy to add a driver column to the source of data, if you add a Driver dimension, or will separating the Driver in a new dimension negatively impact your existing integrations?

    Just some ideas to consider when you perform your analysis.

    Best of luck!

    Alecs

    Comment

     

    • John Sturgeon

      We also chose to separate out the drivers from accounts.

      I agree that traceability is important, and the other reason we chose to separate out driver data from the account dimension was to better segregate data for more intuitive analysis by users across our firm - a guiding principal for our implementation. For example, by only having account data in the account dimension a user can pull up the parent member of that dimension and immediately know the sum of (in our case) costs for the given period, rather than having to filter out the stat accounts.

      The separate dimension also gives you the ability to input driver data by account in the future if needed, which wouldn't be an option if both data types were contained in the same dimension.

      Only downside we could think of was that it adds another dimension to the application, which we deemed minimal since users could always use the "no driver" member when querying costs.

      Hope that helps!

    • Alecsandra Mlynarzek

      Hey there John, Aamir,

      We generally navigate around the summing up to total Account by ignoring the Driver node using the consolidation operator of: (~).  Also if your Account dimension is Label only and the top Account node is your Expense + Revenue total, then the "Account" total should be accurate without any further work.

      If you need drivers by accounts (in case you have account to account allocations) you will be forced to have a separate Driver dimension.

      But if you don't and your app is already fairly large, adding another dimension may not be the best option. So weigh in your volumes of not just metadata members in a dimension, but also number of dimensions and data granularity, and then make a choice. 

      Finally, one more aspect to consider - check your integration options. Is it easy to add a driver column to the source of data, if you add a Driver dimension, or will separating the Driver in a new dimension negatively impact your existing integrations?

      Just some ideas to consider when you perform your analysis.

      Best of luck!

      Alecs