Modeling and Planning with PowerPivot

Part 1-OverviewArguably this could be a very short article. Power Pivot does not support write-back of data to the model nor shared access to the model except in read-only mode via SharePoint. Most business planning applications such as budgeting and forecasting require a collaborative effort and the software to support it. However for an individual user preparing a plan or a numerical business model Power Pivot does have something to offer. For almost any Excel-related application Power Pivot provides a more robust and arguably less error-prone environment in which to create table relationships and manipulate data than a worksheet does. Even for larger planning projects, Power Pivot may be a good tool for prototyping parts of the initial design.

Part 1 explains some of the pros and cons of using Power Pivot for financial planning. Some of the issues related to this topic pertain to financial and management reporting applications in general. More detailed explanations and examples will be added in subsequent parts.

Linked TablesData entered in a range (of modest size, say < 2,000 rows) in an Excel worksheet can be uploaded to a Power Pivot data model using a Linked Table. Any changes made to the range can be quickly applied to the model. This provides a way to enter modeling assumptions such as interest rates, gross margin percentages and the like.

You can also load budget data this way but there are some caveats. Commonly the user interface for budget data entry has time periods (months say) across columns. This layout needs to be rotated or transposed to a vertical layout for import into Power Pivot. This can be done by a variety of means including with cell references, VBA macros, copy/paste-special-transpose, none of which is covered here.

Budget data that a user might input in the layout left needs to be transformed into a table like the one on the right.

When you update a Linked Table the whole Power Pivot table is updated; you can't append data to what is already there (unlike Paste-Append when manually pasting data into Power Pivot). So this makes it more difficult to load data incrementally; if you receive the budget data from the Elizabeth Restaurant several days after receiving Lizzie's Diner budget they must be updated together if you use Linked Tables.

If you import the data from Excel workbooks it is possible to import each business unit budget into a separate table which can be related to a consolidated table, as will be explained in more detail in Part 4. If these tables are related to the right dimension tables (also called Lookup tables) then they can be analyzed with one PivotTable. More on this in Part 5.

Accounts, Measures, and Calculated ColumnsWhen manipulating a table of financial data (this also applies to statistical and other forms of numerical data) in a database or in an Excel worksheet you have some choices as to how to bucket the numbers. What does that mean? Here are two examples of number bucketing:

On the left, what I call Narrow Form, accounts (Sales, Cost of Sales, Overheads) are treated as a dimension ("Accounts" or similar); on the right (Wide Form) acounts are treated as measures (columns of a worksheet). These are the things you can drag into the Values section of a PivotTable. In the narrow form there is only one measure, Value. Part 2 explains the benefits and drawbacks of these two forms.

Part 2-Balanced and Unbalanced Hierarchies

Following on from Part 1

The wide form is usually best where you have:

relatively few measures (not a chart of accounts) there are calculations based of off several measures there are no chart-of-accout style hierarchies except very

simple ones created using calculated measures

The narrow form is suitable for financial or accounting applications that involve a chart of accounts. A chart of accounts typically includes a hierarchy in which the number of levels above or below a level can vary.

In the extract below on the left from the Microsoft AdventureWorks accounts dimension, Other Assets has no levels below, Property,

Plant, Equipment has 1 level below, and Current Assets has up to 2 levels below.

Example of an unbalanced hierarchy

In Power Pivot the DAX language has several functions (such as PATH and PATHITEM) that help you navigate such hierarchies.

Alternatively you can create your chart of accounts in Power Pivot as a balanced hierarchy (see above, right) and repeat the levels as necessary to fill up levels that don't exist in the unbalanced form. Then the members at the bottom of each branch (Cash, Trade Receivables, Other Receivables etc) are all at the same level.

Example of a balanced hierarchy

Microsoft Analysis Services Multidimensional supports Calculated Members in addition to Calculated Measures. These are calculations within a dimension such as these:

[Account].[Gross Profit] = [Account].[Sales] - [Account].[Cost of Goods Sold]

Calculated Members are not supported in Power Pivot nor MSAS Tabular.You can create a measure called [Gross Profit] using a somewhat similar definition but its placement in a PivotTable is restricted to the Values section

So why the fuss about narrow/wide table formats and balanced/unbalanced hierarchies?

The upshot here is that if you are going to perform some degree of financial planning or modeling in Power Pivot, you should use the wide form of table and use Power Pivot's calculated columns for your modeling calculations and simulations.

If you are doing your financial modelling outside Power Pivot and prior to importing the data then the narrow form approach may work better for you. Part 3 explains how you can introduce assumptions into your planning model.

Part 3-Adding assumptions to a planning model

You may have some standalone assumptions that you do not expect to change over the life of your plan. Or else you would put them in a Linked Table that included members from your planning time table (perhaps the planning time table iteself). Your planning table will likely be less granular (perhaps monthly) than the time table you use to track actuals. But for the moment assume that Sales Tax or VAT rate and Staff Bonus rate are fixed for the planning period. You can add a Linked Table to your model that looks something like this in Excel and Power Pivot:

This table does not have a relationship with any other tables. Rob Collie of PowerPivotPro refers to this as a disconnected table. Here are two ways (there may be more) that you can access within your model the assumption values from your assumption tables:

1. Using a measureCreate a new measure in the measures grid section of your model or use the New Measure (Calculated Field in Excel 2013) button on the Power Pivot tab (active when you are clicked on a PivotTable). This screenshot shows the latter:

It doesn't much matter which aggregation function you use here (MAX, MIN, SUM, etc). There is only one value. You can use this measure in a PivotTable or reference it in your Power Pivot model like this:

The slight downside of referencing a measure from a disconnected table in a PivotTable is you'll likely be prompted with a Relationship may be needed warning as shown on the right. If you click on the Create button, you'll get a message No relationship detected and the warning goes away until the next time. Alternatively unclick the Detect Relationships button on the Power Pivot Home tab.

2. Using the LOOKUPVALUE() functionThis is the method I have used to retrieve the Staff Bonus rate assumption.

Here the parameters of the function are:

[column to return], [column to search], [value to look for]

and the function supports multiple search columns and search criteria. This does not trigger the Relationship may be needed warning but its downside is that it does not make available a measure that can be used in your PivotTable and reports.

In Part 4 of this series I will explain how a small business with a couple of business units might consolidate the business unit budgets each stored in its own table (for easier updating).

Part 4-Consolidating BudgetsIf the budgets of each of your business units are consolidated in another system (possibly your budgeting/planning or ERP system) or in a database, then you can import them into Power Pivot for Excel to analyze along with actual data. However the subject of Part 4 is how to input directly and consolidate your budgets using Power Pivot.

As I already mentioned in Part 1, Power Pivot for Excel is not well suited for any serious budgeting/planning process; it lacks write-back capability from Excel to the model and is a personal BI tool that, by design, does not support collaboration. For enterprises with more complex needs there are many other budgeting and planning tools available including the Excel-centric ones such as IBM/Cognos TM1, PowerOLAP and Palo for Excel from Jedox.

A small business with one or two business units might benefit from entering plan data into a model so that it can be analyzed, compared, and reported on with actual data. The business unit budgets could be consolidated into one table or entered in the model using Excel/Power Pivot Linked Tables (adding Data Tables to the model in 2013 parlance).

Option 1: Budget data for all business units is in one table

Putting the budget data of all business units in one table requires less maintenance to the model when a business unit is added or removed. But updating a Linked Table is an all or nothing process; the contents of your table in Power Pivot is completely emptied and replaced, when you update from the linked Excel table. You can't input the budget data from one business unit on Monday and incrementally add the budget data from a second business model on Wednesday. You must input the budget data of all business units with each update. This means that tweaking a number in one budget requires that all budgets are reloaded.

Option 2: Each business unit has its own budget table

Here you have a Linked Table for each business unit. Each corresponding business unit table in Power Pivot must be separately related to the dimension tables such as time, planning chart of accounts, and business unit. This may be acceptable with 2 or 3 business units that don't change frequently.

The example described below is based around a small restaurant business with 2 units:

The Elizabethan - a cloth napkin restaurant Lizzie's Diner for cheaper fare

Planning is done by month for sales, cost of sales, and overheads. As already mentioned, budget templates in Excel commonly have time periods on columns like this:

For Power Pivot the format needs to be a vertical format like this:

There are numerous ways to get the data into this format such as VBA, simple cell references, using the INDEX() function, copy/paste-special-transpose. Or you could set up you budget templates to be filled out in this narrow, vertical format.

Choose what works best for you, is easiest to set up and maintain, with the least likelihood of errors.

Use Excel totals as a check that all the data in the horizontal (input) table ties to the data in the vertical table.

The two Excel tables above (without data) might reside in a workbook that you copy and send out to the business units to be filled out. Then as they are returned, you paste the data from the second table into you master workbook model.

When updated to the Power Pivot model, Lizzies Budget table looks like this:

There is a calculated column called Month Key that I'll explain when detailing the PlanningMonths Table.

Part 5-The Powerpivot Model Schema and Time IntelligenceIn the previous screenshot you can see a tab for the Elizabethan Budget table. There are also tables for PlanningMonths, BusinessUnits, and PlanningChartOfAccounts. While you can get away without these tables (users of regular PivotTables have done this for years) these dimension or lookup tables as they are called will provide a much richer schema with which to analyze your data, combine business unit data, compare data with actuals, and create multi-level hierarchies.

In the case of actual data stored daily in your model, you can take advantage of Power Pivot's built in time intelligence to calculate "to-date" aggregations for week, month, quarter, and year as well as do same-period-last-year comparisons.

In this schema diagram notice how each business unit budget table on the left is related to the three dimension or lookup tables on the right. If you add another business unit, its budget table must have similar relationships added resulting in a little extra, one-time maintenance.

Time Intelligence

Here is the Excel-side PlanningMonths table and the corresponding Power Pivot-side table. Like the budget tables, the latter also has a Month Key calculated column that I use to relate the tables together.

It is also used to specify that months are sorted chronologically and not alphabetically. You can see the DAX formula used to create the key which is a 6-digit integer representing YYYYMM.

Having a table with columns for months quarters and years allow you to take advantage of Power Pivot's multi-level hierarchies as shown here in the Y-Q-M hierarchy.

In this case the name of the level, Quarter say, is the same as the field (Quarter) but need not be:

I'll talk about combining budget data with actual and computing variances in in Part 5 of this series.

Meanwhile here is a very simple PivotTable sourced from the budget data of the two business units:

Part 6-Comparing Budget Data with Actuals

In this example, I have added a (linked) table of daily actual data. As already mentioned, actual data is

commonly more detailed than budget. In this case actuals are daily whereas the budget is monthly. However the chart of accounts (sales, cost of sales, and overheads) are the same. In reality it is likely that actuals would be stored in a general/nominal ledger or ERP system by detailed account code at a minimum.

I have also added a (linked) table for Time that has days as its most detailed level.

In the new Powerpivot Database Schema Notice that the Actuals table has relationships to the Business Unit and Planning ChartOfAccounts tables (just as the Budget tables do); instead of being directly related to the PlanningMonth table

Actuals is also related to the Time table at the daily level using a Time Key field (more on this shortly). Comparing Actual and Budget is only meaningful at the month level (or quarter or year) since there is no budget data at the daily level.

To allow side-by-side Actual vs Budget comparisons you must link the lowest common time level (month) in the Time table to the corresponding level in the PlanningMonths table.

When creating relationships to a date-related table with day-level detail, I like to use key fields that are Calculated Columns (Calculated Fields in 2013 parlance) that contain integers. The DAX functions are almost identical to the Excel functions. In this model:

Time Key =YEAR([Day])*10000+MONTH([Day])*100+DAY([Day])

I use a similar function for the Month Key that relates the Time table to the PlanningMonths table, except that I do this in the Excel table:

Month Key =YEAR(DATEVALUE([Month]))*100+MONTH(DATEVALUE([Month]))

The reason for this is I like to use this key as a Sort By column in Power Pivot. If I create this function in DAX, Power Pivot complains of a circular reference (to the effect that I am trying to sort the source data column (Month) by the results of a function on that column).

Excel can handle this but Power Pivot for some reason cannot. So for date 02/17/2014 the Time Key is the integer 20140217 and the Month Key would be 201402. Integers are good for creating relationships between tables because they can result in faster queries, typically more noticable with larger tables.

So here is an example of a PivotTable that compares Actual (Sales, Cost of Sales, and Overheads) to Budget for any time period in the year/quarter/month (Y-Q-M hierarchy) and for either business unit or both (Ctrl-click on both Lizzie's and Elizabethan slicer buttons). I also added some quick-and-dirty conditional formatting. If you want more precise formatting and report placement you can convert the PivotTable to a cube formula report (PivotTable Tools - Options tab (Analysis tab in Excel 2013) click OLAP Tools - Convert to Formulas).