Modeling and Planning with

PowerPivot

Part 1-Overview
Arguably 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 Tables
Data 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
Columns
When 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 measure
Create 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() function
This 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 Budgets
If 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 Intelligence
In 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([Mo
nth]))
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).