Consideration for no. of Plan types in HP

Question

Hi Expert,
Would like to inquire if there's any rules or guidelines to decide under what circumstances, we should structure separate plan types in an HP application?
I understand a typical rule would be if separate dimensions are needed for different set of data, then may need separate plan types, but want to further explore the following situations:
Situation 1:
Say for 1 set of data (say data set A), we need to have dimension 1, 2
For another set of date (i.e. data set B), we need dimension 3
For both data set, there are 5 other common dimensions that are needed by both
we are face with the option of either setup only 1 plan type, and setup members of dimension 1 & 3 into the same dimension, and webform to control for data set A, select dimension 1 tree, and data set B, select dimension 3.
Or we setup 2 plan types.
Want to check what would be the factors that we need to consider whether to separate the plan type or not?
Situation 2:
We have 2 groups of data, both groups require the same sets of dimension. But we anticipate the volumn of both groups would be quite large and although their dimensionality is the same, but the 2 groups of data are independent from each other.
We wonder if we should split them into 2 plan types, to avoid any performance issues, when more and more data are entered?
Say we have about 11/12 dimensions, in which the account dimension (which is dense), have about 500-700 for each group, then 4-5 dimensions will have about 500 - 1000 members each, and want to store about 5-7 years of data, in about 20 scenarios/versions combination. Is this large enough to justify / better to have separate plan types?
Want to know, what would be the limit / threshold of no. of dimensions / members to decide whether to have 1 or multiple plan types? or what other considerations?
Thanks in advance!

Answer 1

Hi,
I have took the below content from OTN. Please understood your requirement properly, based on that defined the Plan types.
A few points of clarification:
I have seen a fair number of clients use multiple plan types when it was probably not necessary. For example, I had one client create three plan types that were identical, with the exception of the Entity dimension. They were trying to achieve some type of workflow/approvals by passing data from one plan type to another . . . all because they didn't know about Hyperion Planning's Approvals features. We cosolidated their app down to a single plan type and saved them a lot of maintenance and aggravation.
Typically, you break an app into multiple plan types due to one of two reasons:
1) You have significantly different data granularity between the two databases.
2) You have a materially different subject area between the two databases.
A good example of point #1 is workforce planning. WFP includes granular employee level data, while your typical P&L cube does not. If you already have a P&L type cube, and you want employee level detail, it makes sense to create a separate plan type.
Another example of point #1 might be Actuals data vs Plan data. I've had clients that wanted to analyze their Actuals data down to very granular GL accounts, however they planned at a much higher level in the account structure. When running Planning business rules, do you want your Essbase blocks dragging around all of those granular GL accounts that you'll never use as part of a Plan? No. So it makes sense to break it out into a different plan type.
An example for #2 might be P&L data vs. Balance Sheet data. While many people can and do put these accounts all into one plan type, it can sometimes be more efficient to break them out. (Thus reducing the overall block size of each database.)
One final point . . . you CAN add Workforce and CapEx to your existing plan types after they have been created/deployed. However adding additional plan types (other than Workforce or Capex) would require you to recreate the app.
Hope the above examples helps you to understand the concept and define your plan types...
Thanks