Forum Discussion

kmd's avatar
kmd
Contributor II
6 days ago
Solved

Anyone doing planning at a proxy member?

Hi all,

I'm just trying to get a feel for how common this use of proxy members is these days.  I've worked for multiple organizations and typically, if we were planning at any level higher than the most granular level of data, we would plan a number representing a group of members, at some 'proxy' member created specifically for planning purposes.  That is, we would not use some random existing base member that held actuals.

For example:
If our dimension hierarchy looks like the one below and we were planning at the Region Level:
I would not plan for the entire RegionA by loading my planning data to "South3".
Instead, I would create a unique member (say, "RegionA_Plan") and load my data there.
Wondering how many companies out there would use the first method rather than the second method and what advantage there would be to this?
Thanks in advance for your thoughts on this.
RegionA
     North
        North1
        North2
        North3
     South
        South1
        South2
        South3
     East
        East1
        East2
        East3
     West

  • In cases such as this where extensibility is in use already and the requests to plan at whatever level whenever, which is hard to reflect in a consistent and easy to understand data model, or a new dedicated planning cube with a planning model will not be implemented, I only see the use of proxy members in the projects I am involved in. Using a random base member in the data model suggests possible purpose for new users later on (as you say, it can be a revolving door). This makes the data quality in the system really bad so a proxy member is much preferred IMO. Also, when people start applying AI models to their planning data, having all data against e.g. Denmark will not make any sense to the model and highly distort the outcome of the forecast. 

    Long answer short, yes, proxy members are still in use for planning if other solutions are not feasible, rather than using a random base member.

4 Replies

  • Henning's avatar
    Henning
    Valued Contributor II

    Hi, in OneStream, this is a great use case for extensibility. RegionA would be the base member in a top cube or a given scenario type. The details below are in an extended dimension below RegionA which is then a parent that can be used for other use cases, data collection, planning, etc. I do realize that this does not always fit, but it should be the first solution to be considered in the circumstances that are described here.

    • kmd's avatar
      kmd
      Contributor II

      Hi,
      My apologies - I probably wasn't clear enough in my ask.  We already use extensible dimensions extensively (no pun intended).  In this case, a region with their own cube is planning  at say, a 'regional' level.  Let's say that region has 4 children and each of those 4 children has 500 members.
      So really my question is, what makes more sense?  To load your planning data to some random member of the 2,000 base members OR do you create a 5th child under the Region top parent and that child is used strictly as a planning base member (I do realize that if you had a cube view or quick view, you simply pull at the Region parent for the planning scenario in question).  The ask from our user(s) is due to succession planning (especially since planning is often a revolving door personnel-wise).  i.e. why are we planning at member XYZ instead of member ABC? 
      I'm really just looking to get an idea of whether other companies tend to use a proxy member specifically created for planning purposes or whether they just dump the plan data at any base member (assuming they are planning at a non-granular level)

      Hopefully that question makes more sense?

      • Henning's avatar
        Henning
        Valued Contributor II

        In cases such as this where extensibility is in use already and the requests to plan at whatever level whenever, which is hard to reflect in a consistent and easy to understand data model, or a new dedicated planning cube with a planning model will not be implemented, I only see the use of proxy members in the projects I am involved in. Using a random base member in the data model suggests possible purpose for new users later on (as you say, it can be a revolving door). This makes the data quality in the system really bad so a proxy member is much preferred IMO. Also, when people start applying AI models to their planning data, having all data against e.g. Denmark will not make any sense to the model and highly distort the outcome of the forecast. 

        Long answer short, yes, proxy members are still in use for planning if other solutions are not feasible, rather than using a random base member.