On PerformancePoint Server 2007 Planning Features (Part 3)

Part 3 - Defining the Model(s)

In Part 2 of this series, we learned that PPS Planning provides two applications for defining and designing business models: Planning Administration Console (PAC) and Planning Business Modeler (PBM). While we glossed over PAC in the last post, this article continues with the conceptual PPS Planning tasks, focusing on the features available in PBM to help design business models for budgeting.

Table 3.1 – Aligning Budget Activities to PerformancePoint Planning Tasks

3.1 Planning Business Modeler (PBM)

With a look and feel reminiscent of the Scorecard Builder application in Business Scorecard Manager 2005 (aka. BSM Builder), PBM is the workhorse of PPS Plan allowing us to:

• specify the Model site we wish to build models in


• define Dimensions (and corresponding Member Properties)


• define Member Sets and Member Views


• define Models Sites and Models


• configure Roles and Users


• create Business Rules for performing calculations, allocating values as assumptions or exporting data


• implementing Process Management which controls assignments of Users or Roles for budget data entry (via Forms) against a specific model, and, automates approval workflows


• further automate either in- or out-bound data synchronizations

Visually, PBM is bound across the top region by a two basic menu bars, and is separated vertically by three main sections: the Workspace Browser to the left, the central Workspace Pane, and the Workspace Actions and Site Tasks menu panes to the right (See Figure 3.1). The Workspace Browser allows us to navigate our model site metadata at the summary level, by a specific model, dimension, forms (for budgetary inputs) and reports, process management (which helps us to manage specific task assignments and approval workflows during a budgeting cycle), business role definition, model security as well as association linkages between models for consolidation and distribution of data among models. The Workspace pane allows contextual management of a specific area of the model site (selected in the Workspace Browser), while the Workspace Actions and Site Tasks menus vary in function depending on the selections made by the user.

Figure 3.1 – PBM Model Site Summary Workspace

3.2 Models and Dimensions

In PBM, models are defined for a given model site in the Models Workspace (Figure 3.2). The distinction between a model and a model site needs to be clarified here. A model site, which contains metadata defining dimensions, member sets and member views, roles and security (known collectively as a business type library, which can be shared, although I’ll stick with the term “metadata” for simplicity), is used to define:

• one or more models, which are accessed via data entry forms and management reports


• process management associated indirectly to the model via forms( those being assigned to a specific role/user)

Model sites, as we learned previously in Part 2, begin with a root model site which usually represents an entire organization. Subsequent model sites can be defined which inherit specific shared metadata from the root model site, or another model site. It follows that a model sub-site inherits metadata from a parent model site.

Figure 3.2 – Creating a New Model in the PBM Models Workspace

Most every multi-step operation is handled in PBM with user-friendly wizards. Figure 3.3 illustrates the Create a Model Wizard which follows on unsurprisingly from clicking ‘Create a Model’ as shown in Figure 3.2 above.

Figure 3.3 – PBM Create a Model Wizard (CTP2)

For those of you relatively unfamiliar with OLAP based concepts (this time, apologies to the BI practitioners out there), a dimension is a collection of information aligned to a given measure (dollar figure, item count, percentage, etc.) in one or more facts. Dimensions themselves can be arranged in a hierarchy of multiple levels, or expressed as a flat list without any levels. The intersections of multiple dimensions’ levels and members with the fact measures ("data points" in multi-dimensional space) are essentially what constitute a cube. Again, in PPS Planning, a model is manifested as a cube behind the scenes. Dimensions also expose member properties which further qualify a given member of a dimension list or hierarchy. Typically, a member set may be defined solely by a sub-set of a dimension hierarchy, while dimension members with common member properties can be grouped together into a sub-set of dimension members, known in PBM as a member view. Figure 3.4 illustrates the Dimensions Workspace in PBM, where we are able to define and import data for our dimensions.

Figure 3.4 – Creating a New Dimension in the PBM Dimensions Workspace

The models defined in PBM can satisfy either simple or complex budgeting requirements; in the latter case, allowing a user to progressively add more dimensions (or member sets) as well as robust calculations for currency translations or consolidations.

Out of the box, PPS Plan provides a number of stock pre-populated dimensions for handling business processes, exchange rates, consolidations (for sharing of calculations between models), as well as other empty dimensions such as Time, Scenario (a de facto standard dimension for budgeting) and Account (reflecting hierarchical items in a general ledger) and Currency. PBM also has a number of pre-defined model types to support basic budgeting requirements with stock Scenario and Time dimension types (a Generic Model) as well as models which support assumptions that can be applied to a given model site, or shared across multiple model sites (Global Assumption Model).

Assumptions, for those who aren’t familiar with the use-case, represent an analyst or manager’s best attempt to predict the future in the absence of past data; while bias does play a certain role in this respect, from a PPS Plan perspective, assumptions can serve as baseline data for modeling.

More complex model types are available for tracking currency exchange rates (an Exchange Rate Model) and financial models for consolidation. It follows that some of the stock dimensions, such as Exchange Rate appear in stock model types like the Exchange Rate Model.

In order to support the input of budget data into our models (which we shall cover later in this series of posts), we will need to define specific business roles and assign them to a given model in question. Figure 3.5 illustrates the Security and Roles workspace in PBM, which allows us to perform such tasks.

Figure 3.5 –The PBM Security and Roles Workspace

Figure 3.6 –Defining a Business Role

3.3 Business Roles in PBM

Business roles can be configured to satisfy flexible groupings of users from the Master User List, which we define in the PAC. One can easily assign specific users (using the dialog box which appears in Figure 3.7 after clicking the ‘Add or Remove Users for this Business Role’ hyperlink in the Workspace Actions and Site Tasks pane) to “Contributor”, “Reviewer” and “Approver” groups (or whatever works for your company). As an example, you may wish to delineate your models by key business driver or budget areas such as Purchasing, Marketing Expense or Capital Expenditure. Thus, a business role for purchasing budget contributors could be given the imaginative name “Purchasing Budget Contributors”.

Figure 3.7 –Adding Users to the Business Role

Figure 3.8 –Specifying Model Access for the Current Business Role

Once we have used PBM to define our models for budgeting, we need to apply specific business rules to the model which determine how model fact data may be calculated, allocated and/or published. Next time, we will take a closer look at business rules in PerformancePoint PBM.

- Adrian Downes