On PricewaterhouseCoopers' 2007 Budgeting and Forecasting Study

This morning I came across PricewaterhouseCoopers' 2007 Budgeting and Forecasting Study, a newly released report discussing the value to organizations in aligning financial plans to strategic initiatives. Without stealing thunder from the report, PWC research presents five key takeaways for us:

1. Budgeting and forecasting processes face significant transformation; linkage to strategy is top of mind.
2. Today's process is too granular and not focused on value-added activities.
3. Underlying technologies and applications lack integration.
4. Finance and operations must be more closely aligned.
5. Standardizing processes and systems is a primary focus of improvement efforts.

For those of us charged with positioning the business value of PerformancePoint, particularly in how the Planning features fit into the performance management picture (e.g., driver-based budgeting), I believe that objective, technology-agnostic reports like this are important.

What kinds of reports do you use to shape your arguments in support of PerformancePoint? Can anyone out there recommend further/better examples?

- Adrian Downes

On Metadata-Driven Analysis Management Objects (Part 3)

Enhancements to the CreateNewAggregationDesign Function

Most BI practitioners will be taking full advantage of multiple-measure group support in SSAS 2005 cubes (UDMs) for a variety of reasons including support for one of the many-to-many dimension design patterns eloquently positioned by Marco Russo in his work "The Many to Many Revolution". I have two successful implementations which build on his great ideas, and, it was during this phase of development that I came across an opportunity to enhance our code base for our modest Metadata-Driven-AMO “quiver of arrows” (to quote a good friend of mine).

In order to take better advantage of multiple measure-group support in SSAS 2005 cubes, using the code listings from Part 2 of the Metadata-Driven AMO posts, you will find that it is far more appropriate to leverage the MeasureGroupDimension class instead of the CubeDimension class when adding AggregationDesignDimension objects to the .Dimensions collection of the AggregationDesign object. As you may recall, we use the AggregationDesign object to define which aggregations we will store in our cube, based on counts of dimension key attributes found in the incoming data for our new partition. The reason for this change is simple: as you iterate through a collection of CubeDimension objects, you may come across a perfectly valid CubeDimension which is not associated to the measure group partition we are generating. By using the MeasureGroupDimension class, you ensure that you are only creating aggregations relevant to your measure group partition. Moreover, both the MeasureGroupDimension class and AggregationDesignDimension class share the same inheritance lineage, so we are able to take advantage of the .CubeDimensionID property without any fuss. In Listing 10, the minor changes can be found in Section 4.

Update (14-MAY-2008):
All Listings described above may now be accessed at the link below...



- Adrian Downes

On PerformancePoint Server 2007 Planning Features (Part 2)

Part 2 - Configuring the Application

In the previous post in this series , we covered the background story on the purpose of PerformancePoint Planning functionality. Among the key goals for PPS Planning applications is to enhance productivity (ease of use, familiarity, speed), transparency and accountability throughout the budgeting process. This post will initiate our conceptual overview of the key tools used to achieve these goals.

As the first post addressed, budgeting is an iterative exercise, with key budget areas being satisfied before one or more consolidations occur across business units. In order to better appreciate how PPS Planning fits in to such efforts, it may be helpful to consider key budgeting activities and how they align with PPS Planning tasks.

Table 2.1 – Aligning Budgeting Activities to PerformancePoint Planning Tasks

While we won’t repeat the details behind these key budgeting activities here, we can use them as the main drivers for crafting and implementing PPS Planning applications. As the title of this post suggests we will take a look at the first step in the list of PPS Planning Tasks shown above in Table 2.1.

PPS Planning provides two applications for defining and designing business models: Planning Administration Console and Planning Business Modeler. What follows is an overview of the Planning Administration Console.

2.1 Planning Administration Console (PAC)

Planning Administration Console (PAC), a thin-client (web-browser based) tool is the first port of call for configuring budgeting applications. Here, we are able to create and configure Application and Model Sites as well as define a master list of Users.

Figure 2.1 – Making the Initial Connection in the Planning Administration Console

2.2 Applications

An Application represents an aggregation of metadata types (referred to as a Business Type Library) representing Model Sites which themselves contain collections of Models (as SSAS 2005 cubes), Dimensions (such as Customer, Product or Account) and Member Sets (which are functionally sub-sets of dimensions).

Figure 2.2 –Application Configuration Page in Planning Administration Console

Each of these primary classifications themselves have sub-types which allow for a high-degree of flexibility in defining budgeting applications for a variety of organizations. From a budgeting perspective, you may find having separate applications for key business divisions most useful, while for smaller companies a single application containing models for specific budget areas may be sufficient. Under the hood, an Application is persisted partially as an SSAS 2005 database, and has both Application and Staging databases defined upon creation.

2.3 Model Sites

Model Sites reside within Applications and can be thought of as a hierarchy of models beginning with a Root Model Site—as we just discovered, a model is a really cube behind the scenes.

Figure 2.3 –Planning Administration Console Model Sites Page

Models are associated to a specific Application and Staging Database (related to the parent PPS Planning Application). These databases are important for loading (staging) the first or next batch of data prior to moving it into the application store. Once synchronized, the Model itself can be processed. The important thing to remember here is that the purpose of loading existing data into the staging area is to support forecasting and budgeting—here, we can use existing data to help us to determine what we can expect for our organization, and what we want to achieve in an upcoming business period.

2.4 Users

Users are also configured in PAC in the form of a Master User List—this list allows an administrator to authorize specific domain users to perform administrative and modelling tasks.

Figure 2.4 –The Master User List Page in PAC

As of CTP2, these roles and their permissions are summarized as follows:

Table 2.2 – Summary of PPS Planning Server Roles (CTP2)

Once we have used PAC to establish the foundation for our Planning Application, we can proceed to create business models for budgeting. In the next post, we will look at the features available for defining such models with PerformancePoint Business Modeler (PBM).

- Adrian Downes