Oracle Customer Engineering & Advocacy Lab (CEAL) Blog covers Oracle Analytics Cloud, Oracle Analytics Server and...

Zero Based Budgeting (ZBB) Considerations within Hyperion Planning

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

    • 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

    • 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.

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.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.