understanding planning solutions and scenarios

=[ ```

Planning, Budgeting, and Forecasting for the Office of Finance

Understanding Planning Solutions and Scenarios with Microsoft® Office 2010, Microsoft SharePoint® Server 2010 and Microsoft SQL Server® 2008 R2

Prepared for Microsoft by:

Jeffrey Wang & Kevin HsuKepion Inc.

Published: June 2010

For the latest information, please see http://www.microsoft.com/BI

This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2010 Microsoft Corporation. All rights reserved.


To comment on this paper or request more documentation on these developer features, contact SharePoint IT Documentation at SharePoint IT Docs ([email protected]).

mailto:[email protected]?subject=Customer%20Feedback:

http://www.microsoft.com/BI

Contents

Executive Summary..................................................................................................................................... 5

About the Authors.................................................................................................................................... 6

Overview...................................................................................................................................................... 7

Basic Planning Scenarios........................................................................................................................ 7

Benefits of Microsoft 2010 BI Platform..................................................................................................11

Scope of Solution.................................................................................................................................. 13

Solution Requirements.............................................................................................................................. 14

Skill Set Requirements.......................................................................................................................... 14

Product Requirements........................................................................................................................... 14

Building the Solution.................................................................................................................................. 15

Solution Architecture Overview.............................................................................................................15

Planning Data Mart.................................................................................................................................... 17

Schema and Layout.............................................................................................................................. 17

Models for Solution................................................................................................................................ 17

Creating Dimension Tables................................................................................................................... 19

Creating Hierarchy Tables.....................................................................................................................21

Creating Fact Tables............................................................................................................................. 22

Planning Modeling Concepts.....................................................................................................................23

Creating the Data Source View.............................................................................................................23

Dimensions & Hierarchy Considerations...............................................................................................23Dimension & Hierarchy Sizing and Recommendations....................................................23

Use of Dimension vs. Measures.......................................................................................24

Cube Modeling for Write-back...............................................................................................................25Cube Sizing and Recommendations................................................................................25

Use of Measure Groups...................................................................................................25

Use of Writeback Table and Considerations....................................................................25

Multi-User Writeback.......................................................................................................26

Use of Partitions and Cube Settings (MOLAP / ROLAP)....................................................26

Use of Proactive Caching................................................................................................26

Performance Considerations and Approaches......................................................................................28Design and configuration................................................................................................28

Form size, layout and usage...........................................................................................28




Support for remote users................................................................................................28

Data Import.....................................................................................................................29

Data Export.....................................................................................................................30

ETL Diagram...................................................................................................................30

Security and Roles................................................................................................................................ 31Complex Security............................................................................................................31

Cube Modeling with Excel PowerPivot......................................................................................................32

Modeling with PowerPivot..................................................................................................................... 32Connect to Relational Database......................................................................................33

Select Dimensions and Facts..........................................................................................34

Manage Table Relationships...........................................................................................35

Publish to SharePoint......................................................................................................36

Planning Functionalities............................................................................................................................. 37

Creating Reports and Forms.................................................................................................................37Connect to Data Model....................................................................................................38

Create PivotTable............................................................................................................39

Custom MDX Forms.........................................................................................................40

Design Layout.................................................................................................................41

Submit Plan Data.................................................................................................................................. 42Analysis Services Cubes..................................................................................................42

Excel PowerPivot Models.................................................................................................43

SharePoint Lists..............................................................................................................45

Workflow................................................................................................................................................ 46Workflow Actions............................................................................................................46

Workflow Diagram..........................................................................................................46

SharePoint Workflow Setup.............................................................................................48

Audit Tracking....................................................................................................................................... 49

Administration........................................................................................................................................ 50SharePoint Administration...............................................................................................50

Calculations........................................................................................................................................... 53On-sheet Calculations.....................................................................................................53

Cube Calculations...........................................................................................................53

Stored Procedures...........................................................................................................54

SharePoint List Calculations............................................................................................54

Additional Planning Functions...............................................................................................................55Add New Lines................................................................................................................55

Spreading.......................................................................................................................57




Deployment............................................................................................................................................... 63

Migration................................................................................................................................................ 63Overview.........................................................................................................................63

Migration Process............................................................................................................64

Recommended Setup......................................................................................................68

Maintenance.......................................................................................................................................... 69SQL Server Management Studio (SSMS).........................................................................69

SQL Server Business Intelligence Development Studio (BIDS)........................................72

Update Cube...................................................................................................................73

Update Dimension & Hierarchies....................................................................................74

Miscellaneous........................................................................................................................................ 76Corporate to Subsidiary Management.............................................................................76

Appendix A: Planning Modeling & Reporting Guide...................................................................................79

Data Source Views for Solution.............................................................................................................79

Configure Measure Group with Writeback Partition...............................................................................80

ROLAP/MOLAP Partition Settings.........................................................................................................82

Enable “Ad-hoc Distributed Queries”.....................................................................................................83Query OLAP from SQL.....................................................................................................83

Configure Pro-Active Caching...............................................................................................................84

Security & Role Setup........................................................................................................................... 85

Appendix B: Building Planning Functionalities Guide................................................................................87

Creating Planning Forms with SharePoint Lists....................................................................................87

Planning Workflow Setup (Single Level)................................................................................................88

Planning Workflow Setup (Multi Level)..................................................................................................91

Add New Lines...................................................................................................................................... 96Basic approach...............................................................................................................96

Advanced Approach........................................................................................................97

VBA for Analysis Services Dimension Processing............................................................98

Appendix C: Planning & Budgeting Calculation Examples........................................................................99

Cube Calculations................................................................................................................................. 99Base Pay Calculation.......................................................................................................99

Benefit Calculation........................................................................................................100

Total Compensation Calculation....................................................................................100

Stored Procedure Calculations............................................................................................................101T-SQL for Currency Translation.....................................................................................102




Executive SummaryOrganizations today are under considerable pressure to make informed decisions on a daily basis. This not only requires establishing metrics that assesses what’s happened in the past, but also requires an effective response to risks and opportunities by planning for the future.

Financial planning requires alignment with the rest of the organization to create plans that represent each business units’ perspectives. Today, many companies still rely heavily on spreadsheets to create and collect data specific to their daily function, but with no central data repository to plug into. Reconciling these spreadsheets manually can be a daunting task.

What Microsoft® Office 2010 and SQL Server® 2008 R2 offer is a suite of components and out of box functionalities that allow companies to address some of the tough challenges of planning, budgeting and forecasting. Planning functionalities that are included on the Microsoft platform include:

Centralized data model with SQL Server 2008 R2 Analysis Services.

Form & report authoring through Microsoft Office Excel® 2010 & PivotTables.

Data entry and What-If analysis through Excel 2010 PivotTables.

Dimensional data modeling with PowerPivot for Excel 2010.

Online document storage and collaboration with security and workflow for forms and reports through Microsoft SharePoint® Server 2010.

This whitepaper outlines the basic and sophisticated planning scenarios that Microsoft Office 2010 and SQL Server 2008 R2 can support and gives guidance and on the steps that should be taken when building a planning solution.




About the Authors

Jeffrey Wang is the president and co-founder of Kepion Inc., a Seattle based software and consulting company that provides planning, budgeting and forecasting solutions to mid-size and enterprise class companies. Jeffrey has over 5 years of experience developing financial planning applications at Microsoft. He was also an independent consultant, successfully architecting planning solutions on multiple enterprise projects for Fortune 500 companies.

Jeffrey combined his experience gained from working directly with customers, with his deep development experience in financial planning applications, to design the entirely web-based Kepion Planning & Reporting solution built on the Microsoft BI platform. Today, you can find Jeffrey busy deploying and expanding Kepion software capabilities and consulting services.

Kevin Hsu is the director of services and co-founder of Kepion Inc. Kevin has over 5 years’ consulting & account management experience on enterprise applications in product lifecycle management, supply chain and vendor collaboration for Fortune 500 companies. He was also an independent strategy consultant developing overseas distribution channels and product services for companies in the oil & gas, manufacturing and international trade industries.

Kevin continues to expand solution delivery services offering for Kepion with financial and implementation service partners in the Microsoft Partner Network.




http://www.kepion.com/

http://www.kepion.com/

OverviewThis whitepaper provides direction and samples for developing a Business Intelligence solution with planning, budgeting and forecasting capabilities for Finance, HR and other departments within an organization. The solution is architected to enable planning functions that include Write-back capabilities to SQL Server® Analysis Services cubes, SharePoint Lists and Relational Database. This document also demonstrates how the Microsoft® platform can be used in developing financial calculations and business rules to link forms and reports data through Microsoft Office Excel® 2010. Workflow and security are also included as functions to enable collaboration through Microsoft SharePoint® Server 2010 environment. Finally, building and maintaining a centralized data model will be covered as well.

Basic Planning ScenariosMicrosoft Office 2010 presents some interesting support for basic planning and data entry for organizations. Planning and data entry scenarios relate to the capture of data that does not normally exist in line of business (LOB) or enterprise resource planning (ERP) software applications and include:

Data relating to forward views (plans, budgets and forecasts) for an organization Ad hoc data that is prepared and captured manually

For many years now Microsoft Excel has been used extensively by Information Workers (IWs) to support both the above requirements along with more sophisticated and complex business modeling activities.

In this whitepaper the term basic planning and data entry relate to the relative complexity of the business modeling that is needed. Consider the following examples and categorization:

Basic Planning and Data Entry

Line managers need to provide data on the number of planned and forecasted new people hires Line managers need to provide data for their operational and expenditure (OPEX) plans and

forecasts Marketing product managers need to provide comparative data relating to market share, sales

volumes, pricing, revenue and financial numbers on competitors and competitive products Managers need to provide data for targets for organizational key performance indicators (KPIs)

Sophisticated Planning and Data Entry

An IW needs to build a business model to allow other managers to evaluate ‘on the fly’ the risk profile of how changes in business assumptions (e.g. sale volumes, raw material prices, etc.) can affect profitability, cash flow and financial stability




An organization needs to enable IWs to enter new capital expenditure projects subject to assigned capital allowances and limits, and have management approve the projects based on comparative calculated project criteria

An organization needs to enable procurement and plant managers to model the supply chain and production capacity based on worldwide demand sales volumes from the sales and marketing function in order to optimize profitability

An organization needs to have weekly sales forecasts entered by their worldwide sales force of 2,000 sales people with review and approval by the sales management team

Complex security requirements for hundreds and upwards of thousands of users. Large data submissions from IWs from hundreds of fact record updates to upwards of hundreds

of thousands.

Other Characteristics of Basic versus Sophisticated Planning and Data Entry

If we consider the above examples there are some other aspects that distinguish basic and sophisticated planning and data entry scenarios:

Basic Scenarios

These scenarios do not incorporate many business calculations and rules compared with the amount of data being entered

IWs are primarily entering data and do not need to generate calculated results based on the data entry

IWs are entering numeric data and not entering new line items, product details, project details, new hire details

The data the IWs are entering requires minimal or no review and approval process The model that is needed to support the data entry is a single model (typically a single sheet in

an Excel spreadsheet); or to say it another way, the model has limited dimensionality of between two to five dimensions with, relatively, few members or items in each dimension

The example below shows a data entry Pivot Table for exchange rates supported by a data model with 3 dimensions, source currency, destination currency and monthly calendar.

Figure 1-1: Example Exchange Rate Form:




Sophisticated Scenarios

These scenarios incorporate a lot of calculation rules and with higher complexities. A single change in a data entry value may spawn a recalculation of the entire model. For example, a change in the value for an item such as ‘Planned Sales Volume’ will require sales revenues, volume based discounts, cost of sales and expenditure items based off of volume to be recalculated. This in turn will then affect revenue levels, profit margins, cash flow, etc.

In sophisticated scenarios, IWs will often require a high degree of interactivity with calculated rules and results where they need to see calculated results as part of their data entry (What-if scenario)

In many situations involving people and project orientated planning, IWs need to enter not just the numeric data for the plan, but also add new people and projects and be able to change details, for example specifying a person’s grade level

Sophisticated planning and data entry scenarios will have an impact on the potential business and financial outcome of an organization and it is critical that these scenarios are adequately reviewed at the data level by the management of the organization

The modeling needed for sophisticated planning scenarios can have complexity that spans:o Multiple models, analogous to having multiple sheets in an Excel workbook and with

linked Excel spreadsheetso Having many dimensions (greater than five and upwards of ten or more) per model to

support the planning scenario together with dimensions containing members or items ranging from tens of thousands to upwards of hundreds of thousands.

o Varying granularity of hierarchies – for instance planning on product hierarchy at brand level and forecasting at SKU




Benefits of Microsoft 2010 BI Platform So what are the benefits and advantages of using Microsoft Office 2010 and SQL Server 2008 R2 for planning and data entry scenarios?

The critical capability that Office 2010 and SQL Server 2008 R2 provide is enablement of data entry to a centralized data model, specifically SQL Server 2008 Analysis Services supported by the SQL Server relational database tables. Why is this important?

It is usual even in the most basic planning and data entry scenarios that organizations need to have more than one person entering data in to the same data entry form or template (usually an Excel spreadsheet). The implications for this are

IWs need to create multiple workbooks to distribute to other IWs for their data entry Data is potentially duplicated within each individual workbook Making changes and updates to a distributed spreadsheet model can be problematic, manual

and time consuming There is no data level security within the workbooks Data is stored individually in separate workbooks with no central data storage capability Aggregating data from a number of distributed workbooks be problematic, manual and time

consuming The data collected from the process cannot be easily reused without manually manipulating it;

for example, through copy and paste to other applications Business rules and organizational structures and assumptions implemented in each workbook

adding risk to data quality

So what are the benefits of using SQL Server as the centralized data model?

As previously highlighted SQL Server 2008 Analysis Services provides a centralized data model which makes it easier to maintain and update (by technical users) vs. distributed spread marts

Data level security can be applied to the Analysis Services data model limiting which users get to see which data and control over where they can enter data

Analysis Services is the market leading OLAP engine and by including hierarchies within the dimensions, data is automatically aggregated

Analysis Services supports a wide range of tools and data connectivity so the data entered and stored can be re-used with other applications

Advantages for using Excel 2010 with Analysis Services for data entry and reporting:o IWs use the familiar Excel for data entry through PivotTable with write-back capabilitieso IWs can design their own data entry forms against a consistent and prescribed data

model. Note that in Excel 2010, creating pivot tables with a defined region for data




entry, such as input area for a specified range of time periods is not natively available and will need to be done with a customization.

o IWs can still use all the ad hoc capabilities that Excel offers Using SharePoint, document review and approval can be used for the process workflow




Scope of SolutionFor the scope of this whitepaper, we will design a solution around a set of planning scenarios for a fictitious company named AdventureWorks. The solution will be called AdventureWorks Planning.

The example companies, organizations, products, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, person, places, or events is intended or should be inferred.

We will demonstrate how the solution built on the Microsoft 2010 platform can meet the following business requirements for our fictitious company

Planning, budgeting & forecasting will support concurrent data submission from at least 10 IWs Data security must be applied by geography Forecasting done at monthly granularity, budgeting at yearly Fiscal year starts January of each year, Data entry for forecasting is done at product SKU level (Note that it is also possible to enter data

at various levels of a hierarchy, such as at product Brand level if the hierarchy is defined as PC through use of the ‘data member’ functionality of SSAS. In our solution, we will be demonstrating SKU level entry

Data entry done by different geographies and in different currencies Single financial view of organization in different currency types across all geographies. (currency

conversion) Load actuals from source system, forecast period to start after account period close and stretch

to fiscal year end. Account period close changes each month HR department to update pay rates by pay grade on an annual basis Line managers to use pay grade assumptions to adjust and allocate new headcount




Solution RequirementsSkill Set Requirements

Intermediate knowledge of SQL Intermediate knowledge of SQL Server® 2008 Integration Services for data integration Intermediate understanding of OLAP concepts including star schemas and use of fact, dimension

and hierarchy tables Advanced knowledge of SQL Server 2008 Analysis Services Intermediate knowledge of Microsoft® Office Excel® 2010 including on-sheet formulas and Pivot

Tables Intermediate knowledge of Excel 2010 with PowerPivot

Product Requirements Microsoft SQL Server 2008 R2 Microsoft SQL Server Integration Services Microsoft SQL Server Analysis Services Microsoft SQL Server Business Intelligence Development Studio Microsoft SQL Server Management Studio Microsoft Excel 2010 Microsoft SharePoint® Server 2010




Building the SolutionSolution Architecture OverviewWe will use SQL Server® Analysis Services 2008 (SSAS) as the data model to support the sophisticated planning scenarios as called out previously. Using SSAS, the solution will be able to manage data models with millions of fact records and complex business logic. IW’s will be able to open Microsoft® Office Excel® 2010 workbook templates from a central SharePoint® Server 2010 portal and use pre-configured Pivot Tables to read and update data back to the SSAS server. SharePoint workflow will be used to control the business process around planning. Security will be defined on the SSAS database using roles, with each user’s security privilege limited to a particular set of geographies that they belong to. Business rules will be created and deployed to the SSAS cubes for IWs to consume seamlessly within Excel 2010 Pivot Tables for reports and data entry forms.

Figure 3-1: SSAS Architecture:




An alternative approach to data modeling in SSAS will be using Excel 2010 with PowerPivot and SharePoint 2010 to create data models in a workbook and publish to SharePoint for IWs to consume. Data security will be over the entire data model. End users will submit their plan data by modifying the shared workbook and saving it to SharePoint. The PowerPivot model will be updated by creating linked tables associated to the PowerPivot model within the workbook. Collaboration on the data models will be maintained within the document library within the SharePoint environment. Note that this solution will best be suited for small teams of users, generally about five of so users who can manage all the updates to the centralized workbook. This solution is not suited for corporate wide audience.

Figure 3-2: Architecture overview for PowerPivot Modeling:




Planning Data Mart

Schema and LayoutThe data mart will be created with SQL Server® 2008 R2 relational server to serve as the single point of record for IWs, with all data coming into the data mart strictly controlled . The data mart will be used by the SSAS server as the central data source for all cubes, dimensions and hierarchies. Three types of tables will be needed to support the SSAS data model and include dimension, hierarchy and fact.

Note: It is possible for a cube to use more than one fact table. This can be achieved through partitioning on the meaasuregroup and also by using more than one measuregroup within the cube.

We will create the following models to support the data models needed for the planning process. These models will dictate the number of tables that we will exist within our data mart.

Models for Solution

Forecast: This model will be used primarily to capture data entry for forecast s of revenue and operational expense for the forward looking periods.

Account: The accout dimension will contain the chart of accouts, showing revenue and expense items for forecasting

Scenario: The scenario dimension will partition the data between ‘Actual’ and ‘Forecast’Time: The time dimension will determine the fiscal periods for the forecast.Geography: The geography dimension will be used to control the data entry process by each IW.

Individual IWs from each geography will perform data entry in their local currencies. Product: The product dimension is used to represent the full list of active and available products.

Revenue will be forecasted by product.

HR Budget: This model will be used by line managers to bugdet expected headcount for the fiscal year. IWs will interact wth this model by entering in expected hours worked and pay grade classification for each resource. A what-if analysis will be run to determine how much budget will be required for payroll based on changes in the assumptions.

Metric: This dimension will store members such as ‘Hours Worked’, ‘Pay Grade’, ‘Total Compensation’, etc.

Geography: The location that will receive the resource.Time: Budget for headcount to be done at the year level.Employee: A list of existing resources and new TBH placeholders.

Pay Rates: This model is used to set the base pay rates for the year. The pay rates information will be fed into the HR Budget model as base assumption data for use in calculations.




Time: Pay rates are entered at the year level.Pay Grade: A list of pay grades that will determine the base salary.

Exchange Rates: The exchange rate model is used to determine the currency conversion rates to use by month when converting data from the forecast model into the financial consolidation model. Since data is entered into each geography by its local currency, the exchange rate table will be used for currency translation rules and data flow packages.

Time: Exchange rates are entered in by month.SourceCurrency: The source currency of a conversion.DestinationCurrency: The destination currency of a conversion.

Financial Consolidation: The financial consolidation model is used for financial reporting using a single currency across all geographies.

Account: Consolidated chart of accounts.Scenario: Will contain ‘Actual’ and ‘Forecast’Time: The lowest level of granularity will be monthsGeography: All the geographies that have P&LCurrency Type: View the data either in reporting currency (EUR) or in the local currency,

in which case is determined by the currently selected geography in filter.

With a good understanding of the models that are needed, we can proceed to setting up the datamart. Here we will have five fact tables and the appropriate dimension and hierarchy tables. These tables will be arranged in a star schema with the fact tables sitting at the center and the dimension and hierarchy tables forming the outer points of the “star” schema. By defining relationships via foreign keys between the fact tables, dimensions and hierarchy in the data mart, we can quickly generate the data souce view in SSAS when it comes time to building out our cubes and dimensions.

Figure 4-1: An overview of the the data mart tables for the solution with a prefixed description for its associated usage in SSAS .




Creating Dimension TablesDimensions are the building blocks of any multi-dimensional database. Grouping a set of dimensions together will form the general basis for a cube. Dimension tables store data of a particular kind together. For example, you have a dimension table to store all your account members together, with each row of the table representing a unique account member of the dimension. Dimension tables can also store any related properties together via table columns. For example, on the Account dimension we have a column called ‘AccountType’ that stores the particular account type for the dimension member.

Figure 4-2: An example of the relational schema for an account dimension table.

Figures 4-3 illustrates the data that can be stored in a dimension table.

MemberId MemberLabel MemberName SortOrder AccountType ExpenseType

1 3100 Sales Revenue 100 Income n/a

2 3200 Other Operating Revenue 200 Income n/a

3 8100 Interest Revenues 300 Income n/a

MemberId MemberLabel MemberName SortOrder Input Currency Target Currency

1 SEA Seattle 100 USD USD

2 OLY Olympia 200 USD USD

3 SPK Spokane 300 USD USD




Recommendation:

It is recommended that the following fields be created for a dimension table:

Id: It is recommended that dimension keys be of integer type (TinyInt, SmallInt, Int, BigInt) versus any other type for optimal performance. Please refer to the performance section for further reading. Also, use the most appropriate data type based on the sizing of the dimension.

Label: Use a unique code for the caption/name display of a dimension member. Keeping this unique will allow you to author cube based rules using MdxScript that is human readable versus member specification using key value notation, such as ‘&[key]’.

Name: All too often the end users will want to see members of a dimension with a friendly name rather than the label code. For instance, in our solution we have account codes used in label which will makes sense when authoring calculation rules but will not have a whole lot of sense when displayed in a Pivot Table. Creating this property ensures you can easily update display names without affecting any underlying logic to rule definitions.

Order: It is a good idea to have a sort column that can be used by the dimension to determine the ordering of the dimension members.

Dimension tables for planning scenarios typically do not exceed more than 200K members. If you are working with dimensions that have become very large, it is recommended that you trim down the dimension. Any data associated to dimension members that are trimmed can be aggregated together and feed to other dimension members. As a general rule, the smaller the dimensions, the better the planning cubes will perform overall.

Note. Dimension columns and member properties are closely related.




Creating Hierarchy TablesHierarchy tables are needed when you use the Parent-Child (PC) hierarchy feature in SSAS. The PC hierarchy should use 3 columns, key (which represent a member of the hierarchy’s dimension), parent key (another member from the same dimension) and sort column for ordering of the members within a level of the hierarchy. Most PC hierarchies are supported by these 3 columns except when it comes to requiring custom member aggregation. For example, a chart of accounts will need custom aggregation to be defined. Account aggregations are determined by each account member’s account type and their respective parent account member. To support hierarchies requiring custom aggregation, we will need to create a 4th column. That column, the Unary Operator column will contain the following values, +, - and ~ with + meaning aggregate to parent, - meaning subtract from parent and ~ meaning ignore aggregation altogether to parent.

Figure 4-4: An example of an account hierarchy table. (Grayed out area is not required)

IdParent

IdSort

OrderUnary

Operator Label Name

1 102 100 + 3100 Sales Revenue

2 102 200 + 3200 Other Operating Revenue

3 103 300 + 8100 Interest Revenues

4 103 400 + 9100 Gain on Sale of Assets

Figure 4-5: An example of a geography hierarchy table.

Id Parent Id Sort Order Label Name

1 4 500 SEA Seattle

2 4 700 OLY Olympia

3 4 600 SPK Spokane

Level based hierarchies are created based on the columns defined on a dimension. The columns of a relational table can construct attribute hierarchies in SSAS. Defining relationships between attribute hierarchies will allow you to create efficient level based hierarchies. For the time being, including all the related properties of a dimension as columns on the dimension table will be sufficient when it comes time to level based hierarchies in SSAS.

For further reading, please see the following on Hierarchies and Levels




http://msdn.microsoft.com/en-us/library/ms188958(SQL.90).aspx

Creating Fact TablesFact tables store all the numeric data for a cube. The number of columns in a fact table will vary depending on how many dimensions are associated to the cube. For instance, the Forecast cube has 7 columns, with 6 columns representing each of the dimensions that relate to forecast cube and one to store the number value. The column that stores the numeric value is called the ‘measure.’ In our solution, we use only one measure for the fact table.

Each column other than the measure column is related to a dimension via its key. In the example below, we see that the HR Budget model has five dimensions relating to the fact table, and each row of the fact table represents a single fact record. It is good practice to avoid any duplicate values in the fact records on the dimension keys, for example if we have the same value across all the dimension keys on multiple fact rows. If this is the case, consolidate the value into a single row.

Figure 4-6: HR Budget “star schema” fact table

RowId MetricID GeographyID EmployeeID TimeID Value

1 2 15 1010 20100000 2000

2 2 15 1009 20100000 2000

3 2 15 1008 20100000 2000

Figure 4-7: Forecast “star schema” fact table

RowId AccountID TimeID ScenarioID GeographyID ProductID VersionID Value

1151 1 20100200 1 1 232 1 1391

1153 1 20100400 2 1 232 1 1124

1155 1 20100600 2 1 232 1 1322

Figure 4-8: Example of all 5 fact tables for sample solution.




Planning Modeling ConceptsCreating the Data Source View

Example of all 5 data source views used in the sample application are shown within Appendix A of this document. For more information about the Planning data warehouse, please see the Planning Modeling & Reporting Guide.

Dimensions & Hierarchy Considerations

Dimension & Hierarchy Sizing and Recommendations

The size of a dimension is dependent on the number of members and its properties. When creating a dimension, it is recommended to limit the number of attribute hierarchies as this boosts the processing performance of SSAS. Also, by keeping the members of the dimension to the minimally required for planning, resulting in small cube spaces, then better query performance will be achieved overall.

Sometimes it helps to combine two separate dimensions into one for both navigational and performance improvements. The combined dimension would then act as a valid combination of the two dimensions and a navigational hierarchy can be created to aid in filter logic. For example, take the two dimensions ‘Geography’ and ‘Department’. The combined dimension can be called ‘Geography Department’ and with a unique label code generated based on a combination of geography and department codes.

Figure 5-1: Shows the dimension hierarchies for Geography and Department and their respective members.




Figure 5-2: Shows the combined ‘Geography Department’ dimension hierarchy

Here you can see that the combined dimension can result in both an improvement in the navigational usage as well as in the dimensionality of the cube space.

When using parent-child (PC) hierarchies, it is recommended to limit the number of levels in the hierarchy. The more levels there are in a PC hierarchy, the more work the SSAS server must do when answering queries. This is because queries that require data from intermediate levels on the hierarchy will need to be calculated on the fly. The more levels there are on the PC hierarchy, the more calculations therefore need to be computed.

PC hierarchies however, are very useful for planning scenarios as each member can be easily be configured to show the full details of member properties across all the members of the hierarchy, as can be seen in the figure above for ‘Geography Department’.

Use of Dimension vs. Measures

For planning purposes, a single measure on a measure group is sufficient. Additional measures can be defined as dimension members that then act as unique slices for store further data in a cube. What are the benefits of a single fact measure?

Avoid need to change the fact table when adding additional measures Cleaner fact table design, one row of fact equals one fact record




Cube Modeling for Write-back

Cube Sizing and Recommendations

Properly designed cubes will have many considerations taken into account. These considerations will impact the size and overall performance of the cube.

Avoid putting all logic into a single massive cube using all available dimensions. Not only does this make the cube unnecessarily large but it also makes it very hard to maintain and difficult to consume by IWs.

Use MOLAP partitions for non-volatile data. Load data that is relevant to the planning process. Avoid loading all available data from a source

system into your planning cubes. Separate out the data that is needed for the core planning with what is needed in reporting. Planning cubes will need to perform many what-if scenarios and the smaller the cube, the better overall experience for all IWs

Pre-calculate fact data whenever possible so as to avoid needing MdxScript rules to run and calculate. Reporting cubes are ideal candidates for pre-calculating the result directly to the fact table. This technique will lead to better query performance and scale

Use of Measure Groups

Measure groups are useful to group data that have the same dimensionality together within a single cube. For instance, data in the HR Budget cube is distributed across two measure groups, one for the budget data that have dimensionality of ‘Geography’, ‘Metric’, ‘Time’ and ‘Employee’ while the assumption data has dimensionality of ‘Pay Grade’ and ‘Time.’ Keeping the data at the dimensionality will result in better cube design, better and easier to manage rules and increased performance.

Use of Writeback Table and Considerations

In SSAS 2008, writeback tables with MOLAP storage have been enhanced to deliver faster data updates from end user interaction. The writeback table will store a running delta for each cell update made by the IW. The writeback table will store all user updates to the cube including an audit trail of who submitted what and when.

To configure your measure group to have a partition for write back, setup a MOLAP partitioning dedicated for write-back scenario. (See Appendix A)

Figure 5-3: Writeback table with user submitted data.

Value_0 MemberId_1

MemberId_2

MemberId_3

MemberId_4

MemberId_5

MemberId_6

MS_AUDIT_TIME_7

MS_AUDIT_USER_8

82.27 1 20100500 2 12 210 1 11:11:34 PM CORP\jeffwan




82.27 1 20100500 2 13 210 1 11:11:34 PM CORP\jeffwan-

12997.73 1 20100500 2 14 210 1 11:11:34 PM CORP\jeffwan

Figure 5-4: The relational table as generated from the writeback definition. Note that the name of the table can be specified within the writeback settings dialog.

Multi-User Writeback

Multi-user writeback is supported out of the box with writeback tables in SSAS. The behavior of having multiple IWs writing data into the same slice is last person wins. All data entry by IWs will have their transactions audited by the writeback table.

It is recommended that the data entry process is configured in such a way that each IW submits and updates data in their own unique slice of data within the cube. This will lead to better data accountability and an improved user experience overall as data submitting by one IW does not appear to arbitrarily lost or overwritten by another IW’s submission.

Use of Partitions and Cube Settings (MOLAP / ROLAP)

MOLAP storage for partitions will enables the best query time performance in SSAS. MOLAP storage is ideal for data that is non-volatile, or to put in another way that is static and non-changing. Static data in this sense refer to the underlying fact values not changing from such processes as rule execution, data load and or user entry. Data that is ‘Actual’ and data that is considered ‘Historic’ are great candidates for storing together in a MOLAP partition. Static data can be processed once and will not requiring future processing unless there is a change to the partition’s data. This can be helpful when processing of large partitions can take considerable time.

Data that is volatile and require near real time data refreshes should considering using ROLAP as the storage mechanism for the partition. ROLAP will give the most up to date data when queried upon. You can configure the storage mechanism of each partition to be different depending on the kind of data that it will store, whether static or volatile.




Please see Appendix A MOLAP/ROLAP Partition Settings for more information.

Use of Proactive Caching

In planning solutions, data can be updated in a variety of ways:

End user data submission Data loads for new and updated data Updates from business rule calculations done at the relational level

Here we will explore a useful feature in SSAS that enables automatic data refreshes for the cube when data changes on the underlying data source. Proactive caching is a great feature that automates the process of bringing in new updates to the cube. We will show how this can be configured on a partition of the cube to detect changes from our SQL 2008 relational fact table through the use of change notification.

To configure pro-active caching for planning cube, see Appendix A of this document. For more information from Microsoft, please see proactive caching.




http://msdn.microsoft.com/en-us/library/ms174769.aspx

Performance Considerations and Approaches

Design and configuration

Keep the dimension sizes as small as is needed for the planning process Keep the number of dimensions used in a cube to the minimum required for planning Avoid MdxScript calculations whenever possible and make maximum use of client side calculations

such as on-sheet Excel and/or relational calculations that are scheduled to run on a periodic basis (i.e. currency conversion)

When using MdxScript rules, be thorough in checking not only logical correctness but also its performance. Sometimes the MdxScript statement can be modified to give huge performance gains by writing it in slightly different but with the same logical equivalence

Avoid PC hierarchies that are very deep Avoid complicated MDX queries when designing reports and input forms. Queries that contain

“WITH” statement and other calculated members will cause the SSAS server to use limited caching logic and thus result in less scale and performance

If working with a large set of data, create multiple partitions to best manage what static vs. volatile data

Avoid cell level security inside role security definitions as caching logic will be limited when cell level security applies

Form size, layout and usage

Design forms (PivotTables) which make use of filters/slicers to limit the number of cells and query for the form – i.e. do not design the form with all possible data entry visible but provide a filter/slicer so that the form layout (size) remains consistent from a layout point of view and is then pivoted by changing the slicer.

Having multiple PivotTables will increase the query and response time. Prescription is to limit the number of PivotTables both on the same sheet and in the same workbook

When designing forms and reports, default the filters to a lowest level member on the hierarchy – this will allow the default queries to forego unnecessary aggregations calculations on the cube

Do not keep large changes on client side (for example, within the writeback changes of Excel Pivot Tables) rather incrementally publish these changes to the server for optimal runtime performance of the SSAS server

Support for remote users

Remote users on WAN may have slower network connection and response times. To service remote users it may be preferable to: Provide them their own SQL/SharePoint instance in closer proximity to their physical location Provide them Remote Desktop Services access to Excel on a machine with a closer proximity to the

SQL/SharePoint server




For additional information, please refer to the SQL Server 2008 White Paper: Analysis Services Performance Guide

ETL Considerations

ETL is the process of extracting data from source systems, transforming that data and loading it into the data model. SQL Server Integration Services (SSIS) is Microsoft’s premier technology for working with ETL processes. Data integrators design SSIS packages using Microsoft Business Intelligence Development Studio BIDS which includes the following benefits

Access to a large library of built in ETL logic for such things as merging datasets, column lookups, error handling, etc.

Fast data transfers for data loading from source to destination UI to visualize the ETL process

Planning ETL packages can be decomposed into the following areas

Data Import for Dimensions, Hierarchies and Facts Data Export from Fact tables back to source systems

Data Import

For our solution, we’ll create a staging table for each of the dimension, hierarchy and fact tables that exist in our relational database. The staging tables will be used initially as the target table for loading data from the source system. It is possible to do ETL without using any staging tables at all, since SSIS has the capability of transforming most of the data in-memory and loading directly to the solution tables. However, the benefits of having staging tables include

Snapshot the tables and relationships from the source system to facilitate working off a version of the data without risk of losing future access to the source system or be subject to unexpected data changes

Easy audit of the staging data before pushing to the solution tables. For instance, you may choose to do a bulk load to all the solution tables only after someone checks over the staging tables for correctness

Once data is loaded to staging tables and the necessary transformations are completed, then the process of loading from the staging to the solution tables can begin. Using SSIS, loading from staging to solution tables can be as easy as mapping the columns from the source table to the columns of destination table. SSIS provides an incredibly powerful set of features for ETL, and the reader is encouraged to read further on the topic here, the whitepaper on SSIS

Tip – turn the SQL recovery model to simple when performance ETL. This




http://www.microsoft.com/sqlserver/2008/en/us/wp-sql-2008-integration-services.aspx

http://www.microsoft.com/downloads/details.aspx?FamilyID=3be0488d-e7aa-4078-a050-ae39912d2e43&displaylang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=3be0488d-e7aa-4078-a050-ae39912d2e43&displaylang=en

will boost performance as it will reduce the overhead of unnecessary logging on the database.

View of the staging tables in the solution

Data Export

It is typical in most scenarios that after a planning process is completed, the results will need to be collected and processed for export back to the source system where the data will be persisted and made available for reporting requirements.

In our solution, given that the data is already stored in the fact tables in a normalized fashion, preparing the data for export only requires some simple joins with the dimension tables.

ChallengesData export however, can become slightly trickier when the data you want to export does not exist in your fact table at all and rather, only exists as calculations on the cube. How to overcome this scenario? The answer is to use ad-hoc distributed queries against the OLAP cube. (See Appendix A for step-by-step)

ETL Diagram




Security and RolesSecurity should be defined on the SSAS database through security roles. For optimal performance, it is best to keep security as simple as possible.

The highest level of security is the database security and it is recommended that each IW that will require access to the data model have at least the ‘read definition’ allowed for the database.

The second broadest level of security is defined on the cube and this controls where individual cubes are read only or read/write capable or inaccessible.

The next level of security is defined on dimensions. You can choose to allow particular members of a dimension to be visible or hidden. It is recommended that you stop at dimension security in order to get optimal performance from the SSAS server.

Should you define security to the lowest level of access which is at the cell level, then performance will be negatively impacted as caching logic would be severely limited on queries from any user that have cell level security defined.

You can create security roles on your SSAS database by using Microsoft SQL Server Business Intelligence Development Studio (BIDS).

It is important to note that BIDS is capable of defining highly complex configurations to security and may require a higher level of technical expertise in order for an admin to setup and maintain. However, this can be a good area for customization where security may be defined elsewhere, either with a structured spreadsheet or linked table from SharePoint that then can be feed into a translation module and ultimately updates the OLAP security accordingly.

(See Appendix A Security & Role Setup Section)

Complex Security

Dynamic security for SSAS can also be setup for cases where out of the box SSAS roles are not sufficient to cover all the complex relationships that exist. The scenario arises when

Each IW requires access to a specific set of dimensions members There are not many overlaps in dimensional security requirements, i.e. there are many unique

combinations of dimension members assigned to different IWs

One method of setting up dynamic security can be found here




http://www.sqlserveranalysisservices.com/OLAPPapers/UsingUserNametoControlDataAccessandDefaultMemberinSSAS.htm

Cube Modeling with Excel PowerPivotModeling with PowerPivotAn alternative to data modeling in SSAS is to build the multi-dimensional model directly in Microsoft® Office Excel® 2010 using PowerPivot. PowerPivot provides the ability for IWs to build sophisticated data models from the familiar excel environment that most IWs are comfortable with. Some considerations to note when building PowerPivot models

PivotTables do not support writeback to PowerPivot models

Security is defined over the workbook and not on particular slices of PowerPivot data

No support for PC hierarchies

PowerPivot is designed for the power user group of IWs that want to work with their data directly. Assuming that IWs have access to pre-scrubbed data, PowerPivot provides the mechanism for self-modeling or self-service BI.

Let’s build the ‘Forecast’ cube with PowerPivot with the same dimensionality as the one we have for the SSAS cube. In order to do this, we’ll leverage a few of the tables that we have previously defined in our relational data model. These include the dimension and fact tables.

Note that we can essentially borrow the same multi-dimensional design from our SSAS based cube for use in our PowerPivot model, with the main exception being there is no native support for PC hierarchies. When we need to show a Chart of Accounts, we can leverage Data Analysis Expression (DAX) to emulate the proper account aggregations for use in the PowerPivot model.

The overview of the process to build a PowerPivot model off of the relational tables we have

1. Connect to relational database

2. Select the appropriate dimension and fact tables

3. Design table relationships

4. Publish to SharePoint® Server 2010




Connect to Relational Database

With PowerPivot Client Add-in installed within Excel 2010, launch the PowerPivot window under the PowerPivot tab. From the Home tab, click on “From Database” and then “From SQL Server” selection. When selecting a database connection, the wizard UI should look as follows




Select Dimensions and Facts

For our ‘Forecast’ model, we will bring in the following tables to our PowerPivot model

Dimension Tables

D_Account D_Geography D_Product D_Scenario D_Time

Fact Table

F_Forecast_CoreMG_Writeback

Figure 6-1: PowerPivot shows status of import data from relational data model




Manage Table Relationships

Next, we will define the relationships between our fact tables with all the related dimension tables. The MemberId columns are the primary keys on the dimension tables, whereas the fact table contains 5 foreign keys relating back to the dimension tables. The following shows an example of table relationship being created between the fact table and the ‘Account’ dimension table.

Provided below is a summary of the table relationships that are defined between the dimension tables and the fact table.




When the data model in PowerPivot is complete, you can immediately start to explore by using Pivot Tables. Here you can select what you want to see on rows, columns, slicers and data. A very nice feature in PowerPivot PivotTable is the slicers that allow you to quickly filter down the data that is relevant to you.




Publish to SharePoint

Using SharePoint 2010’s PowerPivot Gallery, IWs can store data models created by PowerPivot. With PowerPivot models, IWs can build dashboards, reports and scorecards. The same goes for building forms to support functions of planning, budgeting and forecasting. As called out previously, PowerPivot does not natively support many planning based scenarios such as Pivot Table writeback to the underlying data model.

Once the model is complete and ready to be published on SharePoint, the model can be saved directly to the URL of the PowerPivot Gallery location. IWs can consume the shared data model either by creating a workbook off the shared data model or directly updating the PowerPivot workbook.




Planning FunctionalitiesCreating Reports and FormsFinancial planning forms and reports can be created from multi-dimensional data models using Microsoft® Office Excel® 2010 Pivot Tables. Here we will define forms as planning PivotTables used in gathering plan data while reports are read only PivotTables and used primarily for reporting. Our focus here will be on plan forms. It is important to note that we have 2 types of PivotTables, one that comes natively in Excel 2010 and one that is part of the PowerPivot Add-in. Here we will look at the holistic benefits of Excel 2010, including both types of Pivot Tables. Benefits of forms and reports authoring in Excel 2010 include

Writeback enabled PivotTables allow IWs to publish updates to SSAS cubes What-if capability allow IWs to evaluate ‘on the fly’ changes against SSAS cubes Enable spreading and allocation entry against SSAS cubes PivotTable Sets for authoring of common axis definitions (row, column, etc.) for easy reuse in

other forms and reports Support for MDX against SSAS cubes when defining sets Publish to SharePoint for web reporting requirements Full access to native Excel formatting capabilities Familiar Excel environment for IWs to work in

However, some considerations to note

PivotTable writeback provides little control on what areas should be available for input. Designers may need to manually update regions on the PivotTable to show availability of input but cannot prevent data entry to those areas unless secured through SSAS security

Using security to define updatable data regions in Pivot Table can result in rather complicated and difficult to maintain security setups

Authoring of dynamic expressions for row and column definitions can be difficult. Single member select capability on dimensions can be tiresome and tedious

Lack of ability for IWs to view all changes currently made to data model can lead to confusion as to what is ultimately being published

No ability to submit annotations along with financial data updates

In this section, we will focus on authoring a sample form to demonstrate just some of the flexibility found within Excel’s Pivot Table designer. The outline of the creation of our sample form is as follows

PivotTable Creation

1. Establish connection to data model

2. Create PivotTable© 2010 Microsoft Corporation. All rights reserved.



3. Design sets using MDX

4. Design Layout

5. Publish to SharePoint

Connect to Data Model

Before we create a form, we first will need to establish a connection with our data model. Here we will connect to our SSAS server from Excel and view the available cubes that we can use for planning. For our sample form, we will connect to the ‘Forecast’ cube from the ‘AdventureWorks Planning’ database

We can also establish a connection to our PowerPivot model to build our form. First open the workbook file that stores the PowerPivot model, this can be from either your local client machine or from a SharePoint PowerPivot Gallery. Start by inserting a PivotTable at a desired location on the spreadsheet. Next, select Existing Connection, where we can pick which local PowerPivot model to create a form from. Once selected, we can begin building our form.




Create PivotTable

A PivotTable is created by defining its axis. The axes for a PivotTable include Row, Column, Filter and Data. We start by selecting from our data model, the appropriate dimensions and properties to place on each of our axis by using the PivotTable Field List selection. For our sample form, we have the following

Row Column Filter DataProduct.ProductGroup Time Geography ValueProduct.ProductSubGroup Scenario Product.MemberName Account

Considerations when building plan form

Use the Report Layout as ‘Show in Tabular Form.’ This allows for clear labeling on row headers and provided for a compact format for data displayed on the form

Use PivotTable sets for creating asymmetric layouts such as on columns, where ‘Actual’ is for the first three months followed by ‘Forecast’ for the remaining months of the year. Saving the column definition to sets will allow for easy reuse by other forms.

Use the PivotTable’s options for display to suppress empty rows by un-selecting ‘show items with no data on row’

As a general form design rule, it is usually a good idea to keep large contiguous input ranges together as opposed to having multiple sections broken out with large spaces in-between. This is especially true when the plan data has contiguous data regions with similar calculation logic. Why is this important? IWs will often use Excel drag and fill when filling our formulas on the sheet and by keeping contiguous input section together, this will allow for easier usage by IWs




Fig. 7-1: Revenue Forecast Plan




Custom MDX Forms

For generating more customized reports off the Analysis Service cubes, IT specialists can utilize MDX to develop a form through PivotTable Sets. We invoke PivotTable Sets by selecting Fields, Items, & Sets under Calculations of PivotTable Tools, and then select Manage Sets. Here we can create a new set for rows, columns and filters by pasting in our pre-defined MDX as shown below

Once we’ve finished creating our sets, we can go back to the PivotTable Field List and use these sets to define our Row, Column and Filter fields.




Design Layout

With PivotTable Design, we can build custom formatted forms that show the data in the most appropriate format for input. Here, for our planning scenario, we will color code with white the sections that are read only, apply yellow for sections that are for plan input and gray for sections that are calculated.

Excel 2010 provides a rich format editor that can be leveraged to perform a multitude of formatting capabilities. Below is an example of a form created with formatting applied to areas that are writable, read-only and calculated:

Fig. 7-2: HR Budget Plan




Submit Plan Data

Analysis Services Cubes

In Excel 2010, IWs are able to make updates to SSAS cubes via writeback enabled PivotTables. IW updates are strictly controlled by SSAS role security, with data input allowed only to regions that are write-enabled. To set your form to be write-back enabled, select “What-if Analysis” under PivotTable tools, and then select Enable What-If Analysis.

There is also an option for either manual or automatic re-calculation as IWs enter inputs to the form. By selecting automatic re-calculation, each change made on the form will trigger a ‘What-If analysis’ on the cube. This is useful when you want to see the immediate results of changing your values on the form but can have some performance impacts. It is recommended that should you have a multi-user plan process that this option should be set to manual so that less re-calculations are performed by the SSAS server, especially when the performance is already noticeably slow.

Changes in the PivotTable are tagged with a default dark red color triangle indicator, while the calculated change is tagged with a dark blue triangle indicator. When IWs are finished with their plan updates they can then publish their changes directly into the cube for writeback. Publishing the changes to the cube will result in storing the changes to a relational writeback table on the server.

To publish the changes, select What-if Analysis under Pivot-table tools, and then select Publish.




Data Flow Diagram

1) Excel Pivot table publishes data by submitting updates to the underlying SSAS cubes

2) SSAS will transform the updates into fact rows and store them to the writeback table

Excel PowerPivot Models

Planning models built using Excel PowerPivot can have their data models updated by using the feature of Linked Tables. Linked Tables can be thought of as relating to partition tables in SSAS cube. Thus, updates to the PowerPivot model can be accomplished by either directly updating an existing Linked Table or by creating a new one and linking it to the PowerPivot model.

The key advantage to using linked tables is that IWs can create forms and conduct analysis off multiple heterogeneous, refreshable data sources and still be able to extend that data model with adjustments that can be managed all within a workbook.

In order to setup the proper environment for this, we would need to build a separate table to feed the data to our PowerPivot model. Below is an example of where we’ve created a table within a separate sheet and used it to update our PowerPivot model.

Considerations Note that linked tables often resemble fact tables and thus is not always the most intuitive

structure for making adjustments to data models PowerPivot PivotTables do not support writeback, making it more difficult for an IW to update a

PowerPivot model




With the table setup, we highlight the section of data within the table and click on the Create Linked Table button under PowerPivot. Here we can select Automatic Update Mode for updates within the Excel table to automatically update the PowerPivot Model. With the data linked to a table within PowerPivot, we now have additional values that can be used in our form PowerPivot form authoring.

Data Flow Diagram




1) Updates to the Linked Tables are made via copy/paste or through cell references

2) Changes made to the Linked Tables automatically processed into PowerPivot model

3) Updated PowerPivot model can be consumed in forms, reports

4) Other data sources update to PowerPivot as normal

Publish to SharePoint

Once the planning forms are created, we need to setup a document library within their SharePoint 2010 site to publish the forms to the IW’s. The organization for which the document library is setup is dependent on customer requirements (i.e. by Business Unit, by Department, by Geography).

For PowerPivot reports, it is recommended to publish these reports to SharePoint’s PowerPivot Gallery where the report viewer has more interaction with the report. With SharePoint 2010, the following multiuser collaboration scenarios can be supported:

Multi-user Check-in / Check-out process for data submissions and approvals. Copies of or changes to the PowerPivot data model can be done within Excel 2010. Share interactive reports and analysis through PowerPivot Gallery




SharePoint Lists

An alternative to submitting plan data is with SharePoint List function. SharePoint list enable the capture of data via web browsers from multiple IWs across the organization. Since the lists are maintained in the SharePoint environment, Excel is not needed for its creation or maintenance. Although this allows for straightforward setup and functionality, there are some drawbacks to using SharePoint Lists vs. OLAP cubes as the data capture mechanism.

Advantages of Lists Drawbacks Versus OLAPQuick Setup & Access No Aggregation of Data

Straightforward Data Entry No Hierarchy DisplayBasic Calculations Limited Calculation Functions

Workflow and Security (SharePoint) Less Business Rule SupportLimited Data Security

Limited Filter Selection

To setup a SharePoint List for a sample planning scenario, see Appendix B SharePoint Lists section.

For planning scenarios, lists can represent input forms for Finance to collect data from line managers in different departments and business units. SharePoint lists can also integrate with the rest of the BI tools available on the SharePoint platform when building dashboards, scorecards and analytics.




Workflow SharePoint 2010 enables a fully functional workflow environment to enable collaboration and review throughout the planning process. Some considerations when using workflow for planning are

Workflow will control the state of the plan document in the SharePoint library, however it does not control the process of IWs' data being published to the data model. Use data auditing from writeback table to track data submissions.

Workflow can be customized to support complex approval chains, including programmability.

Here, we will describe a typical planning process involving three sets of users that contribute to the planning cycle.

User RoleContributor Analysts and Line Managers - responsible for entering plan and budget data for

Finance to interpret.Approver Line Manager and Finance department - responsible for approving plan and

budget data before final review with Management.Reviewer Management and Directors - responsible for reviews of up-to-date plans and

budgets to make informed decisions for change.

Workflow Actions

The following are three generalized workflow actions that are common in a planning process.

User RoleSubmit A contributor has finalized their changes and would like to submit to their

approver. With SharePoint 2010, newly uploaded forms can be sent through an Approval.

Approve An approver can finalize the state of the workflow after reviewing the plan data.

Reject An approver can reject a submission which then returns the contribution back to the original owner.




Workflow Diagram

ContributorSubmits

1st Level Reviewer

n-th Level of Approval

Final Level of Approval

1 2 3

Data flow Diagram: Multilevel Approval Workflow

1.) The contributor starts the planning process by uploading their form with their plan data to the appropriate SharePoint Document Library. Through the planning approval workflow, an email notification is sent off to their assigned approver for review. With the document uploaded, the approver is able to view pending tasks assigned to them through the SharePoint task list.

Note: For SharePoint Lists, the same workflow steps can be applied as well, with the workflow action invoked on IW's saves to the List.

2.) Here the approver can open the related content “Product Revenue Forecast” and review the submission. The reviewer can then open the workflow task and either approve or reject the submission.

Approvals can also be done by clicking on the workflow task directly in SharePoint. If approved, the changes will be passed along to the next level of approval. If rejected, the form will be passed back to the original contributor for additional changes.




3.) Once the planning form or SharePoint List is approved, the next level reviewer will receive a notification for approval needed. This can continue through several levels of review before final approval

4.) Once the planning form has reached the final level of approval, any what-if changes that are in the form should now be published to the data model.

Note: For planning scenarios, the contributor and approver should reserve the action of publishing changes within the Planning form PivotTable till the final approval has been completed. Since the what-if scenario function, “Publish changes”, cannot be included as a SharePoint workflow action, this must be done manually by the last approver. A note within the approval email notification can also serve as a helpful reminder.

SharePoint Workflow Setup

Within SharePoint® Server 2010, there is a SharePoint Designer application that allows users to design and build workflows through a guided creation process. This section will walk through the creation of a state-based workflow that provides an approval and rejection process, which is the basis for a planning and budgeting process. However more robust and customized workflows can be developed within Microsoft® Office Visio® 2010 or Microsoft Visual Studio® 2008.

Note: SharePoint designer must be installed and configured to the SharePoint server environment. See SharePoint Installation Guide for more details. To setup a sample workflow for a planning contributor & approval process, see Appendix B Planning Workflow Setup section.




http://msdn.microsoft.com/en-us/library/ee554869(office.14).aspx

Audit TrackingAudit tracking is automatically done by SSAS when using the cube writeback feature. All updates made to the underlying cube, such as from Excel 2010 Pivot Tables are fully audited with the authenticated user and time stamp for each row of fact data that is written to the writeback table. Below is an example as viewed from Microsoft SQL Server Management Studio.

Audit tracking is useful when it is recorded on the fact table as Administrators of the solution can quickly build audit reports to see who has updated what and when. These reports can then be used for the following

Track planning progress by the number of unique users who have submitted data Track back who has changed what particular line item in the fact table when unraveling the

change history of the plan Gather key statistics on usage patterns for the solution based on time stamps and user load




Administration

SharePoint Administration

One advantage to using SharePoint 2010 is its ease in administration of the environment. For the areas of which SharePoint 2010 is used in this planning solution, there are several methods for monitoring performance and progress throughout the budgeting process. The three key areas for administration include:

Libraries & Lists Management Security & Role Settings Workflow Status

Libraries & Lists ManagementAs a Site Administrator, we are able to manage our forms and reports for planning within Manage Content and Structure under the Site Actions menu.

This administration control allows us to manage and organize the appropriate structure and content within the containers that best matches our organization arrangement. For planning and budgeting scenarios, these libraries can be arranged by each business unit, budgeting period or process phase of the planning cycle.




Security & Role SettingsUnder Site Actions menu is a section called Site Settings. Within this, we can setup the appropriate users and permissions to the planning & budgeting site, as well as administrators to the site environment.

For the planning scenarios, it is recommended for us to use the appropriate contributors, approvers and reviewer categories for each user group definition. This way it can be easily referenced when using workflows for assignments of collection and review of data.

Workflow StatusMicrosoft SharePoint Server 2010 provides individual and aggregate workflow reports to enable you to assess the efficiency of your workflows and related business processes. You can use these reports to locate problems with processes or to determine whether a group or individual is meeting performance targets for a particular business process.

We can monitor workflow activities on two different levels within SharePoint 2010:

Site Collection Workflow Usage - a list of available workflows for the site collection, their usage summary (active or inactive), how many times these workflows have been associated, and how many instances of each active workflow are running.

Individual Workflow Reports - aggregate analysis of workflow history for each workflow instance based on activity duration and cancellation & error report




For site collection workflow report, navigate to the Site Actions menu and click Site Settings. On the Site Settings page, in the Site Administration section, click Workflows to display the Site Collection Workflows report.

For the individual workflow reports, browse to the list or document library that contains the workflow for which you want to view reports. Point to the item or document that is involved in the workflow, click the arrow that appears, and then click Workflows.

On the Workflows page, in the Running Workflows section, click the name of the workflow for which you want status. If no workflows are listed in this section, no workflows are currently running on the selected item.

On the Workflow Status page, in the Workflow History section, click View workflow reports. On the View Workflow Reports page, locate the workflow association for which you want to view the reports, and do either of the following:

To view information about how long it is taking for each activity within a workflow to be completed and how long it takes each instance of the workflow to be completed, click Activity Duration Report.

To view information about which workflows were canceled or encountered errors before completion, click Cancellation & Error Report.




Calculations

On-sheet Calculations

Spreadsheet calculations are well understood by most IWs who use Excel to perform their calculation needs. For planning scenarios, the core calculations can still be done in Excel via extra sheets against data stored in the centralized data model. Through the use of writeable pivot tables, on sheet calculations can then be copy and pasted into their respective regions for data update on the sheet – a publish of the changes will then persist back to the cube (data model) all the raw calculated values in the writeable region of the Pivot Table.

Cube Calculations

MdxScript is used to define calculations on the cubes. These calculations are defined once and are consumed by all IWs who query against the cube. The benefit of having the calculation stored in the data model versus the on sheet approach is the ability to standardize and maintain a single copy of the truth. Updating the MdxScript rules will naturally to be deployed and consumed by all user immediately while a spreadsheet method of updating rules will be typically manual, cumbersome and error prone.

For examples of calculations using MDX script to drive the HR model, please see Appendix C Model Cube Calculation Example section.




Stored Procedures

Stored procedures are a great way for performing financial calculations. These can be defined on the data mart of the planning solution. Stored procedures can also be invoked via SSIS packages that can also be scheduled for run using SQL Server Agent.

For our solution, an ideal business rule to implement as a stored procedure is the currency conversion rule. Since we have all the currency translation values stored in the writeback table of our Exchange Rate model, we can do simple T-SQL joins to get to a single consolidated currency value for use in reporting. (See Appendix C for Stored Procedure Calculation Examples)

SharePoint List Calculations

By using SharePoint Lists for a method of submitting planning data, we can utilize the out-of-the-box calculation functions available within Lists. First we would create a new column within the list view and set the column’s data type to Calculated. This will allow us to input our own calculations based on the previous column values, along with data format.




http://msdn.microsoft.com/en-us/library/ms189237.aspx

In this example, we have created a calculation to average the pay rates for the next four fiscal years. The added column, Avg Salary Cost, will be automatically calculated once the user has entered their values.

Additional Planning Functions

Add New Lines

When planning for new spending or headcount, the ability to add new lines becomes a critical functionality required by the IW. For example, the plan calls for an additional 2 headcount to be allocated for additional sales resources to the Northeast Division. There are two possible approaches that can be taken, one basic and one advanced. Note that these approaches center on having analysis services as the data model. (See Appendix B Add New Lines section)

SharePoint List using External Content Type

Use Microsoft SharePoint Designer to create your list off an existing relational table. You can do this by first defining an External Content Type on your SharePoint site and then creating an instance of a list off of it. Below is an example of our relational employees table being exposed via SharePoint lists.

New members can be added to the dimension by simply adding new members to the SharePoint list. Here, we have an example of the required fields that are needed in order to create a new member to employees for use in budgets.




Data Flow Diagram

1) From web browser, IWs update the external content type list2) SharePoint 2010 Server updates the underlying relational data table




Spreading

Cube SpreadingWhen working in Excel 2010, IWs can configure the method of spreading for updating cube data in Analysis Services through write-back enabled Pivot Tables. The options that are supported via the Excel 2010 are show below.

There are many spreading methods that an IW may want to perform. These can be broken down into basic and advanced scenarios:

Basic scenarios

Spread aggregate value across a defined range of time periods Spread an aggregate value evenly down a hierarchy, starting from any parent member of the

hierarchy Allocate evenly down hierarchy Increase or decrease by percentage down a hierarchy

Advanced scenarios

Spread based on previous year’s actuals Spread based on custom allocation percentages stored in relational data tables Spread down a parent-child hierarchy




Sometimes, the default spreading logic available in Excel/SSAS may not be enough. In such instances, customization can help. One approach is to leverage SQL 2008 relational engine to do the spreading via stored procedures. The process for the IW would be:

Update input members that are required by the stored procedure for spreading Run the stored procedure from excel

You can call stored procedures directly from Excel via macros. Spreads that are done at the relational level are ideal when the calculated values are all at the leaf level of a hierarchy, i.e. the lowest level of granularity for a cube. Once the calculations for the spread are complete, the cube will show the correct aggregated values along the hierarchy.

Also, spreading may be achieved via Update Cube statement in MDX. However, this will typically be beyond the skill set of most IWs.

Spreading Issues

When designing spreading logic, be sure to test out the end user scenarios thoroughly so as to provide the best guidance to end users when they are working on their forwarding looking processes. For instance, parent child hierarchies have known issues with spreads that may be seen by the IW as having unexpected behavior. For example, spreading down 1000 over the following parent child hierarchy can result in the following allocation:

A Spread 1000o Bo C

A – 1000 (aggregate) A - 333.333 (data member) B - 333.333 C - 333.333

In general, when designing for spreads by IWs, it is best to give clear guidance from the model designer as to what can and cannot be spread and what is the expected behavior that will result with each kind of spread. This is important as the IW will be unable to tell the difference between a pc hierarchy and a leveled hierarchy, yet the behavior of the spread will be different as called out above.

Performance Expectations

Spreading performance in Excel 2010 and SQL 2008 R2 is generally very good. We’ve performed spreading from the top member “All” of geography down to all the separate regions, with the value to spread entered by product SKU over the forecast periods. The resulting spread created over 50




http://technet.microsoft.com/en-us/library/ms145488.aspx

http://support.microsoft.com/kb/124218

thousand rows of fact in the writeback table of the OLAP cube. Publishing the changes back to the cube completed in a few seconds.

View of the spreading form:

View of the geography hierarchy:

These results were achieved on the following baseline:

Cube contains the following dimension and member count:

Account (77) Geography (14) Product (505) Scenario (11)




Time (66)

Hyper-V Virtual Machine Configuration:

3.5G of RAM 1 Proc 2.67GHz Intel Core i7

PowerPivot SpreadingHere we will explore some ideas around updating a PowerPivot data model with spreading values using native Excel 2010 functionality and PowerPivot linked tables. As called out previously, PowerPivot does not have native support for updates directly from Excel 2010 PivotTables, making spreading and other types of data updates a challenge. However, we will see that in certain basic scenarios we can achieve Excel level spreading and have the results pushed back into a PowerPivot model.

ScenarioLet’s understand a simple example of spreading that an IW would like to do:

IW wants to create custom spreads over time based on total revenue by product SKU using data from an existing PowerPivot model.

IW wants to incorporate the spread information back to the PowerPivot data model for use in other analyses

Approach Create a PivotTable to bring in aggregates to spread over time Create a region on the spreadsheet to hold the percentages to allocate over time periods Create a region on the spreadsheet to hold the dollar amounts that are reallocated On another sheet ‘PowerPivot Partitions’, create structured fact tables that can be linked back

to PowerPivot. Each table here can be thought of as a partition table for a SSAS cube.o For each time period that we use in the spread, we will create a table.o Create each table with the same dimensionality as that of the data modelo For each table, create relationships to the PowerPivot dimension tables

Create a DAX measure that will sum together the data from the partition tables into a single measure for use in reporting

The example below shows the pivot table with ‘Sales Revenue’ for the year by each product SKU. The region to the right of the PivotTable is used to capture IW input for how to spread the ‘Grand Total’.




To the right of the spreading percentage region, we have the calculated spread amounts by time period. These calculated values are then referenced by Excel tables to build the partition tables that will be used to link the table data back into the PowerPivot model. For simplicity of the Excel reference formulas, we will create a partition table for each time period.




Considerations When creating the partition tables for ‘linked tables,’ it is important to have the unique keys

that will identify the members. In our above example, we are using the ‘MemberId’ for each dimension when we are constructing the partition table

The above approach is ideal for situations where the filter selections will not change on the form. For instance, each IW may have their own Pivot Table with their own unique filter selection that they use to get their data linked back to the PowerPivot model.

Ensure enough buffer space is created in the Excel table for reference cell formulas to include spread data for new product SKUs.

The more linked tables that are created, then the higher the complexity of the workbook leading to less manageability of the PowerPivot model.

Key Takeaway PowerPivot is great in bringing multiple sources of structured data together. DAX shines in this

area with the use of calculated measures. Updating data directly in Excel can also update the PowerPivot model Creating input forms for IWs to update PowerPivot models is not trivial




DeploymentMigration

Overview

Migration is the process of taking a solution from a development environment and bringing it to a production environment. This typically will involve 3 environments and 2 migration phases:

Migrate from Development to Test Migration from Test to Production

DevelopmentDevelopment of the solution can typically be done on a single machine with all the required services, including SQL Server and Analysis Services installed locally. This is ideal as typically in development you want the following

Full control on the environment for fast turnaround on issues that are not specifically related to solution development

Simplified server setups Focus on solution design and requirements

TestThe primary purpose of the test environment is to validate the design in the development environment on an environment that will most closely match the production environment. The test environment will focus on the following:

Business logic validation Performance testing Security and access control

ProductionThe production environment is the go-live environment that will be accessed by the end consumers of the solution. This environment should have backups and redundancy built in so that there is no loss any significant data from IWs.




Migration Process

Migration of the planning solution will involve moving and reconfiguring the following assets from a source environment and into a target environment:

Planning database on SQL Server Planning database on SQL Server Analysis Services Excel Form Templates on SharePoint ETL Packages built with SQL Server Integration Services

Relational DatabaseMigration of the relational database can be performed using a simple backup and restore process. Make a SQL Server backup file by using SSMS:

The backup file can then be used to restore the database to the target environment’s SQL server. Once the database is restored on the target environment, we can begin with the restore of the multi-dimensional database.




Multi-Dimensional DatabaseMigration of multi-dimensional database can also be performed by using a backup and restore process similar to the relational database. Considerations on post database restore include:

Update role based security Update data sources

Update Role Base SecuritySecurity is typically configured differently between the various migration environments. For instance, in the development environment, there will be many more power users with the privilege to process and alter the multi-dimensional database than compared to that in a production environment. When setting up security, it is a good idea to take into consideration the necessary security rights required for users within each migration environment and to remove any roles that are not relevant for that environment.

Development Environment SecurityIt is recommended to create a single SSAS role that will contain all the power users for the development environment. This development role will have privileges that are elevated above most other roles in terms of interactivity with the multi-dimensional database – for instance database processing rights and ability to create/alter/remove database objects will be granted here. Creating a single role will allow the administrator to easily remove or update users in the role as it is moved from one environment to another. For improved manageability, use AD groups when adding membership to the role. This will allow IT to manage security without getting into SSAS at all.

Test Environment SecurityIn the test environment, our goal is to emulate the security setup that should be found in a production environment. When setting up security, there are a couple of considerations to take. Depending on the complexities of the security requirements, we can have:

role created based on each secured slice of data role per IW, each containing their own security definition

For the most part, it is acceptable to have the development role available in the test environment. Also, for users that will only exist in the test environment for purposes of user acceptance testing (UAT), it is recommended to create separate roles for them and have them be clearly identifiable. When moving to production, development and test roles will need to be removed.

Production Environment SecurityThe production environment should not contain any development or test roles. Remove these roles after a restore of the multi-dimensional database when in a production environment. Ensure that the security roles that are setup are only for IWs that should have access to the production environment.




Update Data SourcesOn the multi-dimensional database, be sure to update the connection string property for the data source to point to the target environment’s SQL server.

Ensure that the SSAS server has access to the relational database server. To test that everything is configured correctly, perform a database process to reload multi-dimensional database.




Excel Form TemplatesTransfer form templates from the SharePoint document library into another library created for the targeted migration environment. Update the connection string properties for the data connections used by the PivotTables and point them to the target environment’s multi-dimensional database.

ETL PackagesPackages written for data transfer between source systems and the planning solution may need to be updated as we move the packages from a source to target environment. Depending on how the configuration properties are setup within the SSIS packages, updates to the connection strings may be required by working with the following:

XML configuration file Environment variable Registry entry Parent package variable SQL Server




For further details on managing connection strings in SSIS packages, please refer to the following.

Recommended Setup

For production and test environments, it is recommended to have the following four machine configuration. The critical machine that require being on standalone machine is the SQL Server Analysis Services OLAP server. For SSAS based planning solutions, the core bottleneck will typically be from the SSAS server as it is primarily responsible for interactivity between the multi-dimensional data model and Excel 2010 PivotTables, including answering all what-if and other ad-hoc queries. In addition, many calculations will also be evaluated on the fly by the SSAS server when responding to query requests. Thus, it is typical to require both high computational capability and large memory allocation for the SSAS server. However, the exact machine configuration will depend on the complexity of the solution and its usage requirements by the IWs of the system.

Setup Diagram




http://technet.microsoft.com/en-us/library/cc895212.aspx

MaintenanceCube, dimension and hierarchy management is done using SQL Server Business Intelligence Development Studio (BIDS) and SQL Server Management Studio (SSMS).

SQL Server Management Studio (SSMS)

Use SSMS for the following:

Update dimension members and properties from dimension tables Update hierarchy tables for parent-child relationships Update fact tables Design schema relationships between dimension, hierarchy and fact tables via views Stored procedure development in T-SQL for business logic

o Currency conversion ruleso Custom spreading logico Data versioning (copying from one slice of fact data to another slice)




Update Tables

From SSMS, you can directly update data tables by

Right click the data table you want to edit Select “Edit Top 200 Rows”

Or you can choose to script out the updates

Right click the data table you want to edit Select “Script Table as”




Update Rule - Stored Procedure




SQL Server Business Intelligence Development Studio (BIDS)

Use BIDS for the following:

Develop SSIS packages for ETL Design OLAP Dimension, Hierarchy and Cube Design MdxScript rules within cubes Design data partitioning within cube OLAP security management via Roles




Update Cube

There are many things that can be updated within a cube and it is critically important for each type of update to require a full test before rolling out to production. Some considerations to note when maintaining a cube that is already in production:

Updating a cube’s model dimension usage in measuregroupo Removing model dimensions can break existing definitions for PivotTables and cause

existing MdxScript rules to fail. In addition, the fact table should be reviewed as to how to properly address data that is sliced by the removed dimensionality based on the requirement of the business.

o Adding additional model dimensions will typically cause less immediate breaks on the overall system; however there are still many issues to consider. The fact table will need to properly default the values for the new model dimension on existing values or else may require a full reloading. Pre-submitted data may need to be re-entered by IWs if this new dimensionality cannot be properly defaulted, potentially causing a large IW process change. PivotTables and MdxScript rules should continue to work, however it is best to review all MdxScript rules as the new dimensionality will most likely have altered how certain calculations should work, for example if there was a rule that requires all the dimension members to be leafs in the calculation scope.

Updating partitions within a measuregroupo Adding/removing partitions should typically have no functionality impact on the IWs as this

is a technical level change. Performance can be increased with intelligent partitioning scheme for the data and minimal impact should be experienced when unused partitions are removed.

Updating measuregroup usageo Removing a measuregroup can impact MdxScript rules and existing PivotTable definitions.

This is because there will typically be measures that exist on the measuregroup that is used in some capacity somewhere in the system, be it in rules or PivotTables.

o Adding additional measuregroups should have minimal impact on the IWs as this will only be adding new functionality without affecting existing behavior.

Updating MdxScript based ruleso Calculation updates will impact how the data is viewed by the IW. Once an update is made

to the rules that give the correct business logic, it is very important to test their performance characteristics. Rules written in MdxScript have the potential to cause




significant performance degradations that for the SSAS server if written in a non-optimal manner.




Update Dimension & Hierarchies

Dimension and hierarchies are often updated as new information is required by IWs to satisfy their business requirements. For instance, it is common to see the following requests:

IW require the addition of a new hierarchy view IW requires new member properties to show on their reports IW requires changes to existing hierarchies to reflect organizational changes

How do we address some of these of these scenarios and what are the impacts when making such changes? To start, any changes made to a production system must first be thoroughly tested out in a test environment in order to better grasp the full change impact. With that said, there are some changes that are more expensive to perform when compared to others and we will explore them here:

Updating dimension member propertieso Adding new properties/attribute should have minimal impact on existing functionality.

This is considered a low risk change.o Removing properties and/or renaming them should be avoided in production

environments. Pivot Tables, MdxScript rules and hierarchies that use the attribute in its definition can become broken.

o Updates to the dimension properties will impact any hierarchies that are built off of the related attributes. See below for further details.

Updating dimension memberso All dimension members can potentially have data stored against it in the cube. Thus,

deleting any member from the dimension should also properly handle the associated data in the fact table.

Updating existing hierarchieso Parent-child hierarchies

Be careful when moving hierarchy members around in a pc hierarchy as it is possible to move a member from the lowest level of the hierarchy and make it into a parent member and vice versa. The implication is that there might be data sitting at intermediate levels that may appear incorrect from an IW’s perspective as it does not appear to be the sum of the children members.

o Level-based hierarchies When the dimension table columns are updated with new values, then the

attributes that are associated with those columns are also updated. Here, the level hierarchy will be automatically updated based on the updated attributes after a dimension process in SSAS.




o General hierarchy change impact Updates to the hierarchy structure can cause PivotTables and MdxScript rules to

break. Review MdxScript rules to see how they are being used and if the changes to the hierarchy structure will require updating the rules. Also, review any PivotTables to see how these will be impacted.

Adding new hierarchies is low risk as it will be new functionality. Removing hierarchies will have the same implications as covered in ‘General hierarchy change impact’




Miscellaneous

Corporate to Subsidiary Management

Often is the case in large corporations that requirements for planning span multiple business units, requiring corporate to implement a centralized planning solution in the goal to have a more standardized, accurate and efficient process. With increased complexities from the requirements between corporate and subsidiary, a single monolithic planning solution may no longer be ideal and include such factors as:

Too many users accessing one system Too many complex models required to satisfy all subsidiaries Processes from one subsidiary can impact others Updates to one subsidiary can impact others More difficult to get changes through as the impact is company wide

In such scenarios, we can create multiple planning solutions with the corporate solution acting as the template for all subsidiaries, alleviating the stress put on any single planning solution.

How it worksWith the multiple planning solution approach, we will have a single solution per business unit, each with its own relational data mart and SSAS database. The corporate solution will act as the primary data source to all subsidiaries, sharing out the corporate view of the models, dimensions and hierarchies. The corporate SSAS database will act as the template structure to each subsidiary. Standardized business rules are implemented and maintained at corporate and copied to the subsidiary solution as required.

Minor updates made to the corporate solution should trigger sync with subsidiary solutions, for instance the adding of a new account to the ‘Chart of Accounts’ or updates made to fact data for shared models. Updates to dimension members and properties from the corporate solution can be auto-sync’d by




tagging the members in the subsidiary solution as belonging only subsidiary, allowing ETL to be easily defined for updates between subsidiary and corporate.

Major updates made to corporate may require a re-copy of the corporate template to each subsidiary.




Steps to create subsidiary data model:

1. Copy corporate solution’s relational database and restore to subsidiary environment2. Copy corporate solutions SSAS database and restore to subsidiary environment

a. Update data connections to point to subsidiary environmentb. Update user security roles on SSAS database for use by subsidiary

3. Create ETL packages to sync data between shared data models between corporate and subsidiary solutions

4. Apply subsidiary specific data to the copied corporate database. For instance, add accounts to the Chart of Accounts that are not part of the corporate hierarchy. Members added to the subsidiary should be appropriately tagged as specific to the subsidiary. This will allow for ETL to continue syncing corporate data with that in subsidiary.

5. Create subsidiary specific models for data capture and reporting.

BenefitsBenefits of multiple planning include:

Greater flexibility for each subsidiary to design and schedule their own planning process without impacting companywide processes

Changes to subsidiary planning solution has no impact on other planning solutions Potentially better performance – planning solutions can be geographically located to each

business unit’s primary user base. Simplified security model for each business unit versus a union of all IW belonging to

each of the business units, potentially in the tens of thousands

Sharing MechanismIn order to take advantage of the corporate solution and its data model, we’ll identify some of the items that can be shared:

Share fact, dimension and hierarchy tables from corporate to subsidiary Share corporate business rules on cube (MdxScript) to subsidiary Share stored procedures from corporate to subsidiary

Dimension, hierarchy and fact tables for the subsidiary solution can source its data directly from the corporate solution using ETL process. Periodic sync can be scheduled between the tables in order to get the latest up to date corporate data into subsidiary. Since data in corporate is already cleansed, ETL should be rather straightforward.

For standardized business rules, we can reuse the definitions from the corporate solution and apply it to the subsidiary. MdxScripts that exist on the corporate SSAS database can be copied and added to the




subsidiary’s SSAS database. Stored procedures can also be copied and applied to subsidiary’s relational data model using SSMS’s ‘Script Stored Procedure as’ feature.




Appendix A: Planning Modeling & Reporting GuideData Source Views for Solution




Configure Measure Group with Writeback Partition

1) Find the Solution Explorer and select the Forecast cube

2) Locate the tab “Partition”

1) Right click an existing partition and select “Writeback Settings…”




2) Specify the name of the table for the writeback that will be created on the data source. Keep the selection to MOLAP for optimal performance.

3) When you are finished with creating the writeback table, there should be a new instance of the partition that is grayed out.

After saving and processing the database, a data table will be created on the underlying relational database to store writeback data.




ROLAP/MOLAP Partition Settings

1. Right-click on partition2. Select “Storage Settings…”3. Select standard setting and drag slider to ROLAP/MOLAP




Enable “Ad-hoc Distributed Queries”

sp_configure 'show advanced options', 1 reconfigure

sp_configure 'Ad Hoc Distributed Queries', 1 reconfigure

Query OLAP from SQL

Select *From OpenRowset(

'MSOLAP','Data Source=localhost;Initial Catalog=AdventureWorks Planning;','select {[Measures].[Value]} on 0,

non empty {

{DESCENDANTS([Account].[IncomeStatement].[REV], 10000, LEAVES), DESCENDANTS([Account].[IncomeStatement].[EXP], 10000, LEAVES)}

*DESCENDANTS([Geography].[Geographies].[All], 10000, LEAVES) *DESCENDANTS([Time].[Monthly].[FY2010], 10000, LEAVES) *{[Scenario].[Scenarios].[Fcst]}*{[Product].[All_Product].members}

}on 1 from Forecast'

)

Ad-hoc Query




Configure Pro-Active Caching

1. Right click on a partition2. Select “Storage Setting…”3. Select “Custom setting” and click “Options…”

4. Specify the following: (TODO: determine the best options for this)

5. Select the SQL Server option for tracking changes to the underlying data table.




Security & Role Setup

1. Open Development Studio2. File->Open->Analysis Services Database and connect to your instance3. Locate the Solution Explorer pane4. Look under the database node for a folder names “Roles”5. Right click -> New Role

6. For our solution, we will create a role for each user and define their security within it. In the following example, we will create a security role for a particular user and have their security limited to read/write ability onto the Seattle region of geography. All other geographies will be inaccessible by this user.




7. You can define security on the cube level for broad granting of rights. For instance, here we are limiting data input for the Forecast and HR Budget cubes but not to the Financial Consolidation, Exchange Rates or HR Pay Rates cubes.

8. Dimension security can also be defined by selecting the members in the hierarchy using the check boxes to indicate what is included in the security definition.




Appendix B: Building Planning Functionalities GuideCreating Planning Forms with SharePoint Lists

SharePoint List is useful for capturing data from IWs. Data entered to Sharepoint List can be translated and loaded to other parts of your data model through an ETL process.

To create a SharePoint List, you must have the correct permissions for creating lists, documents, etc. From the main homepage of SharePoint, click on Lists, and then click Create on the Lists. We can select from a wide range of list type, but for our sample application, we will be using a Custom List.

Once on the main List page, we can start by creating columns for our form. Under Manage Views, we can click Create Column, and this will allow us to create the Title, Data Type, Column Settings and Column Validation rule.

Once all the columns are created, the list can be published and shared for users within a user group to collect data. In this example, we’ve setup a HR Pay Rate Plan that allows users to add new rows and forecast their anticipated pay rates for a position. The user would be able to enter the data through form based entry. SharePoint Lists also integrates with Microsoft Office InfoPath to create further customized forms for entry.




Planning Workflow Setup (Single Level)

Step 1: To create a new workflow, click Edit Site in SharePoint Designer within the Site Actions Menu. This will open the SharePoint Designer to its main page. Navigate to Workflows on the side navigation pane and click on Reusable Workflow under New.

Step 1a: For SharePoint Lists, workflows can be created in a similar method, but some additional steps are required. To create a new workflow for List, click Edit Site in SharePoint Designer within the Site Actions Menu. This will open the SharePoint Designer to its main page. Navigate to Workflows on the side navigation pane and click on Lists and Libraries. Under advanced settings, select the Require content approval for submitted items for changes to the List. Then we can create a new workflow by clicking on Create, under workflows for this Library Lists.

Step 2: Provide a name and description for this workflow.




Step 3: Starting with workflow Step 1 (Name: “First Level Task Assigned”), under Actions, you can select Collect Data from a User. By clicking on the highlighted Data, we step into the Task Wizard. We give this task a name & description, and add a custom field for Review Status. This can be setup as a choice drop-down for Approved and Rejected states.

We can also setup another field for Reviewer’s Comments, which can be set to multiple lines of text.

Step 4: After setting the Data field we can set Users to Approvers user group (or any other pre-configured user or group). We need to then create a new variable for collection output. For this example, we will use the name “Document Review ID” and leave the type as “List Item ID”. Once completed, we will set the workflow variables for Review status and Review Comments.

Step 5: For Review Status, we will click on Set Workflow Variable under Action. Then set “Review Status” as the variable name and select string value. For value, we will select the following:

“Association: Task List” as the data source “Review Status” as Field from Source “ID” as Field




“Variable: Document Review ID” as Value

Step 6: For Review Comments, we will once again click on Set Workflow Variable under Action. Then set “Review Comments” as the variable name and select string value. For value, we will select the following:

“Association: Task List” as the data source “Review Comments” as Field from Source “As String” for Return Field “ID” as Field “Variable: Document Review ID” as Value

Now that we’ve completed Step 1 for this workflow, we will create Step 2 (Name: “Final Level Approval”) for email notifications.

Step 7: We start by setting a conditional on step 2. For the first if clause we will set the following:

“Workflow Variables and Parameters” for data source “Variable: Review status” for Field from source

The equals will be set to “Approved” and then we will set an action of Send Email. The email is custom to any template desired. For this example, we will set the following within the template:

“User who created current item” on the To field “Current Item title” on the Subject field “The document has been approved” for the Body Text

Step 8: We will now setup an Else-If Branch for a new condition for Reject state. To setup the Rejected state, follow the instructions of step 7, but set the equals’ condition to “Rejected”. Within the email template, the body of the text can be change to reflect the Rejected state. In addition, we can add a lookup of the Review Comments variable to bring in the comments left by reviewer.




Step 9: We can now save this workflow in its finished state.

Planning Workflow Setup (Multi Level)In between the first initial approval step and final step (email notification), we can setup multiple levels of approval steps in between. This is useful when there is multi-tier approval process involved during the planning process.

Step 10: Setup a new step after “First Level Task Assigned” and name it “First Level Approval & Second Level Assigned”. First follow steps 7 & 8 to setup email notifications for the Second Level Approvers.




Step 11: If the Review Status is approved, then the submission is passed to the next level of approvers. We will now collect the approval status and comments for the next Approved state. Under the last action within the Approved condition, follow steps 3 through 6 to set the approval status and comments.

To collect data from the second level of approvers, you must have a user or group defined for this role. In this example, we setup a name and description for the new data set called “Second Level Manager Approval” from a group called “Second Level Manager”. We also setup new names for the custom form fields for the user to fill out:

- Second Level Approval: set as a choice drop-down for Approved and Rejected states - Second Level Comments: set to multiple lines of text

These two form fields are then used to set the Review Status and Review Comments if approved.

If the submission is rejected, the owner who committed the last submission would only receive an email notification. The contributor will continue to resubmit to the same level approver until it is approved.




Step 12: For additional levels of approval needed within this workflow, we can repeat steps 10 & 11 for the appropriate user and groups. One example of a 3 tier multilevel approval process is shown:




Note: The image above shows the generalized view of the steps. Details of the settings shown here are described within the preceding steps

Step 13: Once the Workflow has been added to available workflows within our SharePoint Environment, we can then select the workflow that we’ve created to our document library. Within the document library, we can go to Workflow Settings, under Library and add a new workflow to the library here.

Step 14: Select the newly created workflow, enter a unique workflow name and enable workflow to be started on all newly created documents. This will then invoke the newly created workflow on all documents within this library.

There are many components within the workflow that can be customized to a customer environment, but this example will provide a baseline for a typical planning, budgeting and forecasting process for approval & rejection cycle.




Add New Lines

Add new line is a common scenario for IWs when performing a budget. It is often the case that the input forms that are pre-configured do not adequately cover all the available inputs an IW would like to perform, for instance there may be a need to budget and plan for a few new headcounts for the upcoming fiscal year yet there are no areas on the input form to collect the data inputs. New dimension members ideally would need to be created on the fly, and added to the data model for the budget. Here, we will provide a brief overview of the pros and cons of taking two different approaches

Placeholders (Basic Approach) - no customization

Dynamic Members (Advanced Approach) - requires customization

Simple to implement More complex to implement

No processing of OLAP dimension required Processing of OLAP dimension required

No additional relational database changes Save to relational database new member information

IW must use available placeholders IW can add new members as needed

Cannot change the placeholders properties IW can add new members with associated properties

Basic approach

In our employee dimension, pre-create a fixed number of placeholder members. In the solution, we’ve generated a series of members starting with TBH (to be hired) for use in budgeting of new employee hires. You can view how the members are used on the input form for data entry below




Notice that only the valid employees for “Northeast Division” are being shown on the budget form. This is achieved by defining the underlying MDX to hide empty rows. Note that NED in our MDX query stands for Northeast Division on our geography dimension.

NON EMPTY { {[Geography].[Geographies].[NED]} *{ HIERARCHIZE (DESCENDANTS([Employee].[Employees].[All Employees], 0, AFTER),POST)} , {[Geography].[Geographies].[NED]} *{[Employee].[Employees].[All]} } ON ROWS

Because we are hiding empty rows, it is important that we put data to the placeholder members so that when the query is executed the placeholder member rows will also be returned.

Advanced Approach

The advanced approach calls for a customization to be built on top of the platform to satisfy the requirements of the IW. The customization will have the following components:

A SharePoint list based on an External Content Type to collect new employees and their properties. SharePoint’s External Content Type feature is great at exposing application data, such as dimension and hierarchy tables directly to the IW.

VBA in Excel to process Analysis Services dimension (note. The user will need processing rights on the Analysis Services database)

The IW will then do the following when adding new lines:

Go to SharePoint and to add new employee and their details From their Excel form, execute the VBA for dimension processing Continue budget from Excel Pivot Table

In our example, adding a new list item through SharePoint List will create a new table record on the dimension table from our data mart. Based on the setup of the hierarchy definition in SSAS, this new record will then be automatically processed to a member of a hierarchy after performing a process command on the SSAS dimension. In essence, we can allow IWs to directly make the necessary updates to records that they are familiar with that will then directly affect the way they see their data from PivotTables and other client tools.

It is important to note here that updates are done on a flat list of items with the SSAS hierarchy structure being derived from the property fields of those items. This is true for both pc and level based hierarchies.




http://msdn.microsoft.com/en-us/library/ee557704(office.14).aspx

VBA for Analysis Services Dimension Processing

Provided here is an example of processing new dimensions members from a macro defined within an Excel 2010 workbook. The macro will connect to an instance of SSAS server and issue an XMLA command for dimension processing. Notice that we used ‘ProcessAdd’ as the Process type. This is important as this is the fastest option when adding new members to a dimension. Avoid the need to ProcessFull as this will cause the related cubes to be processed as well.

Sub ProcessAddEmployee()

Dim connection As New ADODB.connection Dim xmlaCommand As New ADODB.Command

Dim ServerName As String Dim DatabaseName As String Dim DimensionName As String

ServerName = "kepion02" DatabaseName = "AdventureWorks Planning" DimensionName = "Employee_All_Employee"

connection.Open("Provider=MSOLAP;Data Source=" & ServerName _ & ";Initial Catalog=" & DatabaseName & ";" _ & "Integrated Security = SSPI;")

xmlaCommand.ActiveConnection = connection xmlaCommand.CommandTimeout = 120 ' 120 seconds

xmlaCommand.CommandText = _ "<Batch xmlns=""http://schemas.microsoft.com/analysisservices/2003/engine"">" & _ "<Parallel>" & _ "<Process>" & _ "<Object>" & _ "<DatabaseID>" & DatabaseName & "</DatabaseID>" & _ "<DimensionID>" & DimensionName & "</DimensionID>" & _ "</Object>" & _ "<Type>ProcessAdd</Type>" & _ "<WriteBackTableCreation>UseExisting</WriteBackTableCreation>" & _ "</Process>" & _ "</Parallel>" & _ "</Batch>"

xmlaCommand.Execute() connection.Close()

End Sub

This macro can also be associated to a button in Excel 2010’s Quick Access Toolbar. This allows the user to quickly and easily find the macro when planning and budgeting.




Appendix C: Planning & Budgeting Calculation ExamplesCube Calculations

The following is an example of how we can do some simple calculations in MdxScript for driving the HR Budget model:

Base Pay Calculation

Calculate the base pay for hourly employees based on the number of hours worked and the hourly wage rate as determined by the pay grade.

// All calculations on HR done at leaf levelSCOPE( [Employee].[All_Employee].members , DESCENDANTS([Geography].[Geographies].[All], 1000, LEAVES) , [Measures].[Value]);

[Metric].[Metrics].[Base] =

CASE [Metric].[Metrics].[PayGrade] WHEN 1 THEN [Metric].[Metrics].[Hours]/2000 *([Measures].[HR Pay Rates_Value], [PayGrade].[PayGrade].&[1]) WHEN 2 THEN [Metric].[Metrics].[Hours]/2000 *([Measures].[HR Pay Rates_Value], [PayGrade].[PayGrade].&[2]) WHEN 3 THEN [Metric].[Metrics].[Hours]/2000 *([Measures].[HR Pay Rates_Value], [PayGrade].[PayGrade].&[3]) WHEN 4 THEN [Metric].[Metrics].[Hours]/2000 *([Measures].[HR Pay Rates_Value], [PayGrade].[PayGrade].&[4]) WHEN 5 THEN [Metric].[Metrics].[Hours]/2000 *([Measures].[HR Pay Rates_Value], [PayGrade].[PayGrade].&[5]) WHEN 6 THEN [Metric].[Metrics].[Hours]/2000 *([Measures].[HR Pay Rates_Value], [PayGrade].[PayGrade].&[6]) WHEN 7 THEN [Metric].[Metrics].[Hours]/2000 *([Measures].[HR Pay Rates_Value], [PayGrade].[PayGrade].&[7]) WHEN 8 THEN [Metric].[Metrics].[Hours]/2000 *([Measures].[HR Pay Rates_Value], [PayGrade].[PayGrade].&[8]) ELSE NULLEND;

END SCOPE;




Benefit Calculation

Calculation to determine the estimated the benefits dollars based on the base pay.

// All calculations on HR done at leaf levelSCOPE( [Employee].[All_Employee].members , DESCENDANTS([Geography].[Geographies].[All], 1000, LEAVES) , [Measures].[Value]);// Benefit averaged out to 25% of base[Metric].[Metrics].[Benefit] = [Metric].[Metrics].[Base] * 0.25;

END SCOPE;

Total Compensation Calculation

Total compensation calculation based on base compensation and benefit dollars.

// All calculations on HR done at leaf levelSCOPE( [Employee].[All_Employee].members , DESCENDANTS([Geography].[Geographies].[All], 1000, LEAVES) , [Measures].[Value]);

// Total = base + benefits[Metric].[Metrics].[Total] = [Metric].[Metrics].[Base] + [Metric].[Metrics].[Benefit];

END SCOPE;




Stored Procedure CalculationsMany planning solutions require a currency translation rule that converts financial data into multiple currencies. Here, we’ll explore an example of a currency conversion rule implemented by a stored procedure. In order to perform currency translation, we’ll need the following:

Exchange Rate table holding to the conversion rates from a source currency to destination currency and by time period.

A fact table holding all the values that require translation

Since we have a model designed for storing exchange rates, we can use its fact table as the exchange rate table.

Exchange Rate Table

Below is an example of the fact table that will have its values currency converted. Note that with the below example, the source and destination currency will be determined by columns, ‘Input Currency’ and ‘Reporting Currency’ from the geography dimension table. It will be assumed that the fact table stores only input currencies and any currency conversion will be to the target ‘Reporting Currency’

Fact Table for Currency Translation




T-SQL for Currency TranslationSELECT

a.MemberName [Account],t.MemberId [Time],s.MemberName [Scenario],g.MemberName [Geography],c.MemberName [CurrencyType] ,g.[Input Currency],g.[Reporting Currency]

,Fact.[Value] ,ExchangeRate.Value [Exchange Rate] ,Fact.[Value]*ExchangeRate.Value [Calculated] FROM [dbo].[F_Financial Consolidation_CoreMG_Writeback] Fact INNER JOIN D_Account a ON Fact.AccountID = a.MemberId INNER JOIN D_Time t ON Fact.TimeID = t.memberid INNER JOIN D_Scenario s ON Fact.GeographyID = s.MemberId INNER JOIN D_Geography g ON Fact.ScenarioID = g.MemberId INNER JOIN d_currencyType c ON Fact.currencyTypeID = c.MemberId --- --- Currency Join --- INNER JOIN (SELECT

sc.MemberName [Source] ,dc.MemberName [Destinatation] ,t.MemberId [Time] ,[Value]

FROM [F_Exchange Rates_CoreMG_Writeback] ef INNER JOIN D_SourceCurrency sc ON sc.MemberId = ef.SourceCurrencyID INNER JOIN D_DestinationCurrency dc ON dc.MemberId = ef.DestinationCurrencyID INNER JOIN D_Time t ON t.MemberId = ef.TimeID

WHERE sc.MemberId <> dc.MemberId) ExchangeRateON ExchangeRate.Source = g.[Input Currency]AND ExchangeRate.Destinatation = g.[Reporting Currency]

Result of Currency Translation




understanding planning solutions and scenarios

Documents