Zero based budgeting (ZBB) applications are becoming
increasingly popular as a way to develop a budget, especially for lower growth
organizations that are interested in cutting costs. The most significant difference between ZBB
applications and traditional budget applications are the level of details
captured. Where traditional budgeting
applications plan an expense item directly or using a price X quantity formula,
ZBB applications will plan every line item related to that expense. For example, when budgeting supply expenses,
a ZBB application will include values for each detailed line item, including
pencils, pens, paper clips, etc. Given
the level of detail required for ZBB applications, careful consideration needs
to be taken in order to have optimal performance within Hyperion Planning.
The following questions need to be considered before designing
a ZBB application within Hyperion Planning:
Does the additional ZBB detail require control
over how the data is entered?
If yes, then add a separate line item dimension.
If no, then supporting detail functionality
within Planning may be sufficient.
Does the detail have a direct relationship to an
account?
If yes, then smart lists within the account
dimension could be leveraged.
Is the ZBB detail relevant for the current
budget? The application should include
only those line items needed for the current budget and remaining line items
should be purged.
Do all accounts require additional ZBB
detail?
If no, consider having a separate ZBB plan type
to store line item information for the account subset.
As indicated above, ZBB applications tend to require a
separate line item dimension for storing the additional detail required. In addition, ZBB applications use smart lists
extensively to capture non-numeric driver values used to evaluate the proposed
budget items. The following lists the
design characteristics of a ZBB application within Hyperion Planning:
ZBB applications require planning at a line item
detail. For non-ZBB applications, supporting detail is usually
sufficient. ZBB applications, however, need more control over how the
line item detail is entered, making a sparse Line Item dimension necessary.
The number of line items for each account, which
are known as packages in ZBB applications, will vary. The supplies
account or package might have 5 line items while the travel account or package
might have 10 line items. As a result, the Account dimension, which is
typically called the Package dimension in ZBB, will need to be sparse to
account for the differences in the amount of line item detail for a particular
sub-account or sub-package.
ZBB applications typically store multiple
drivers, both numeric and non-numeric, for a particular sub-package to provide
sufficient justification for each budget line item. Since the bulk of the
ZBB values are calculated using driver values, the drivers are separated from
the sparse Package dimension and placed in a dense Driver dimension to ensure
the driver calculations are dense calculations. The Driver dimension is
also typically marked with the Accounts property
member tag.
The design of the ZBB application assumes that
all sub-package calculations are self-contained and have no dependencies on
other sub-packages. If the design does show sub-package dependencies,
then the customer’s definition of a sub-package does not follow ZBB best
practices and should be reviewed.
As described above, ZBB applications, unlike traditional
budgeting applications, tend to place accounts (known as packages in ZBB
applications) and account drivers in separate dimensions where the account
members are stored in a sparse dimension and the account drivers are stored in
a dense dimension marked with the Accounts property member tag. This design characteristic and the extensive
use of smart lists to store non-numeric account driver values have the
following performance impacts:
The main impact of the ZBB design from a PBCS
and Planning perspective is that the Driver dimension stores the drivers across
all sub-packages, and the drivers used for a particular sub-package is
typically unique. Therefore, the number of drivers populated for a
particular sub-package will be a small subset of the total number of drivers.
As a result, a given block of cells will always be sparsely populated for a ZBB
application, and performance could suffer by having PBCS and Essbase process
more data cells than is necessary.
Another impact is on reporting ZBB data.
The non-numeric drivers are stored in the Driver dimension as smart
lists. A ZBB application can potentially have more than 50 smart lists,
and each of these smart list items is typically queried in a standard or ad hoc
report. If each smart list is mapped to a dimension in an ASO reporting
database, the ASO database could potentially have more than 60
dimensions. However, the smart list reporting is typically mutually
exclusive where a particular report will typically contain members of only one
smart list dimension. Users do not typically perform analyses across
multiple smart list dimensions.
As
described above, ZBB applications within Hyperion Planning will tend to have
sparsely populated blocks as well as large numbers of smart lists that will be
mapped to a dimension in an ASO reporting plan type. Careful consideration will need to be given
when designing ZBB applications to
minimize the impact of these potential performance items.