HyperionPlanning Plan Type Data Sharing

HyperionPlanning Plan Type Data Sharing

NoMadBanker
NoMadBanker

May 3rd, 2012, 12:32 pm #1

We are attempting to leverage plan types for different portions of our P&L and I wanted to know how I can share data between plan types. Can anyone help explain how we can accomplish this? Also is the sharing "real time" or is it a process we need to execute to "push" the data between plan types?

Thanks in advance for your assistance
Quote
Share

Joined: November 26th, 2001, 10:15 pm

May 3rd, 2012, 2:11 pm #2

You define the source of the account (one PT) and make it available to others. It automatically gets XREF'd as a dynamic calc. Of course performance can fall right off a cliff if you have lots of these. I often will go through and make them all stored members and then force their valuation through a business rule.

Here's something I wrote long ago and really need to work into a full blog post:
<snippet>
Chop the Accounts
When I build a Planning application with more than one Plan Type, I like to create upper level Account parents that segregate by Plan Type. This makes security and dimension builds as straightforward as possible. Yes, this does require extra dynamic calcs in the target (really, it’s the master) Plan Type to pull the XREF’d data from the source Plan Type(s), but I think it’s a small performance penalty to pay for clarity. I reserve the right to bin the above approach if it doesn’t work for a particular application, dear client(s), so please don’t consider the above set in stone.

Mythical application example -- Account
To do this, name and order the Accounts like the below to split security by Plan Type:

Accounts
|--Wrkforce Accounts
|--Consol Accounts

NB -- Wrkforce, the source of employee expenses, is ordered before target Income Plan Type so that there are no forward dynamic calcs.
</snippet>

The issue with shared members across PTs is that they can get REALLY mixed and cause a lot of noise in the hierarchies -- remember, what you see in Planning/EPMA isn't what really translates to Essbase but of course that's where everything happens. I like to segregate the shared members as much as possible hierarchically and then move data around as needed. I also try to keep the scope of XREF'd data as small as possible.

Regards,

Cameron Lackpour
Quote
Like
Share

NoMadBanker
NoMadBanker

May 3rd, 2012, 4:59 pm #3

Cameron just to be clear for my pea brain...
The "Master" cube would have the consolidated account member and the plan type would have the details::
ie
Salaries and Benefits (Master)
>Salaries (Plan Type1)
>Benefits (Plan Type2)

Given this very simple example.. the information in PlanType1 can be worked on independent of PlanType2, and when someone looks at the "master" they would get the information for both the PlanTypes that are the feeders of the details.

Is this an accurate assumption/characterization of the model you are describing?
Quote
Share

Joined: November 26th, 2001, 10:15 pm

May 4th, 2012, 10:34 am #4

I've never seen an "Employee" (there have been and still are Employee apps even with WFP around) database split across two Plan Types. Are you sure you want to do that?

What's a lot more common is something like:

P&L (still has its own data)
|_Employee
|_Some other category of Expense

Where the P&L PT has its own expenses, Employee has a bunch of them but they come across as one or two salary-related expenses, and the third PT (if used) has yet another category of expenses.

The thing that splits the PTs apart is dimensionality that only makes sense to a given PT. Employee by name or position or whatever only makes sense when considering Employee expenses, so it lives as a custom dimension in its own PT. Capital Projects follow the same rule.

Common dimensions like Entity (you're forced to use it in all, although what goes into what PT is up to you) and maybe a custom dimension like Business Unit are unique to a PT.

Many customers also throw an ASO reporting cube on top of the Planning application and feed it in various ways. These applications are NOT part of the Planning application, require separate licensing (full Essbase or whatever it's called nowadays), separate security, etc.

Regards,

Cameron Lackpour
Quote
Like
Share

NoMadBanker
NoMadBanker

May 4th, 2012, 11:50 am #5

OK.. One last question..
Would you see a reason to split a planning application between revenue and expenses by plan type? This is a suggestion we have received that in my mind does not seem like a good reason to create multiple plan types if the dimensionality is exactly the same between plan types.

Any thoughts?
Quote
Share

Joined: November 26th, 2001, 10:15 pm

May 4th, 2012, 12:02 pm #6

Is that what the master Plan Type is all about?

I guess if you had a *lot* of accounts (Blocks Too Big), or had really big dimensionality elsewhere (Too Many Big Blocks) splitting it could make sense. But sooner or later revenue and expense have to come together, right? Is that in a separate ASO reporting cube (I am thinking transparent partitions into the ASO cube to give you instant data)?

Again, that the above Planning + reporting cube is a moderately common scenario, but I think that is more a function of Too Much Data In Planning and treating a Planning application as a reporting platform which it really isn't (although I have built simple reporting out of it quite successfully).

What were the consulting company's reasons? How big is your block? How many Entities?

Regards,

Cameron Lackpour
Quote
Like
Share


Confirmation of reply: