Glenn Ruskaup, Linium LLC - TEM Softwaretem-sw.com/library/OFA to Hyperion Planning Migration.pdf · Glenn Ruskaup, Linium LLC OVERVIEW This paper will focus on identifying the similarities

Oracle Business Intelligence – Hyperion Planning

1 Paper 1

OORRAACCLLEE FFIINNAANNCCIIAALL AANNAALLYYZZEERR TTOO HHYYPPEERRIIOONN PPLLAANNNNIINNGG MMIIGGRRAATTIIOONN

Glenn Ruskaup, Linium LLC

OVERVIEW

This paper will focus on identifying the similarities and differences between Oracle Financial Analyzer (OFA) and Hyperion Planning (HP). For users who are migrating, or thinking of migrating, to Hyperion Planning, strategies will be discussed to ensure their existing functionality can be replicated in HP. The paper is aimed at users who are familiar with OFA and/or similar multidimensional database applications.

The following broad topics will be discussed

• Similarities between OFA and HP

• Dimensionality requirements

• Comparison of OFA Financial Data Items to HP Plan Types (cubes)

• Hierarchies

• Attributes and Attribute dimensions

• Aggregations

• Dimension Member Formulas

• Solves vs. Calc Scripts and Business Rules

• Application Tiers and Personal Databases

• Hardware Architecture

• Customization

• Data Input

• Reports

• User Maintenance

• General Ledger Integration

• The Future

In general, HP has more out-of-the-box functionality compared to OFA and is easier to use from an end user perspective. However, most OFA implementations are customized through Express programming extensions, so OFA seems to offer more flexibility at the cost of higher maintenance. As you look at migrating from OFA to HP, you want to focus on migrating as much of your customized OFA functionality as possible using standard functionality available in HP and Essbase.

SIMILARITIES BETWEEN OFA AND HP

Even though the primary purpose of this paper is to discuss the differences between OFA and HP, you will find that these two products are more similar than different. Both OFA and HP are designed primarily to support the business planning process and allow for distributed budgeting and forecasting. Both are multidimensional applications that run on top of true


2 Paper 1

multidimensional databases. Data in both applications is organized and consolidated along hierarchies, and both include a powerful financial modeling and calculation engine. Existing OFA users will find it easy to migrate to HP because of these functional, structural and technical similarities; however, they will need to learn the navigation within HP because it is quite different compared to OFA.

DIMENSIONALITY REQUIREMENTS

Users familiar with OFA know that there are no limits or mandatory dimensions in OFA. HP on the other hand has certain dimensions that are required. Every application must have the following nine dimensions:

Period – Months, Weeks, Days Year – I'll give you one guess Scenario – A scenario dimension, Actuals, Budget, Forecast, etc. Version – Used for creating different versions of Budgets/Forecasts Entity – Typically the “Balancing segment” of the GL Chart of Accounts, such as a Company, Dept, CC Account – Typically the Natural Account segment of the GL, also known as Line Items Currency – Used for Currency Conversion (only applicable for multi-currency enabled applications) HSP Rates – Used for Currency Conversion (only applicable for multi-currency enabled applications)

Without these required dimensions, the application cannot be deployed. Each of these dimensions represents a specific "dimension type". Unique properties are assigned when these dimensions and their corresponding members are defined within the application. For example, a member of the Account dimension will have a value that allows you to identify an account as Expense, Revenue, etc. OFA has only 3 dimension types (normal, time aggregation, and time), none of which are required; however, the Account dimension in OFA did have an attribute that stored such information. This typically is not an issue, because most applications will naturally have all of these types of dimensions contained within their functional requirements. In addition to the required dimension types listed above, there is a "Generic" dimension type that can be used for additional “user-defined” dimensions that don't fit one of the types listed above.

One difference that may jump out right away to some OFA users is the way HP divides the "Time" dimension into separate Year and Period dimensions. While this design was sometimes used in OFA, it's not typical, and is different than the way the normal Time dimension operates. Again, this difference does not pose a problem for most applications. The HP application does allow for calculations to be defined that support time based analysis like moving totals, lags, leads, etc.

Another difference in how dimensions work in HP is the requirement for dimension member names and their associated Alias values to be unique across all dimensions. For example: you cannot have an Account member called "1234" and a Cost Center called "1234" even though they are members of different dimensions. It is very easy to overcome this uniqueness constraint, simply prefix the dimension member value with a letter (or letters) that identify its dimension. For example, the Account dimension member “1234” would become “A1234” and Cost Center “1234” would become “C1234”. Making Aliases unique is also easy, simply prefix the dimension member name to the member description. For example: “1234 – member description”. This was common practice in OFA and in most OFA applications that used the OFA-GL-Link this was automatically enforced through the OFA-GL-Link set up.

COMPARISON OF OFA FINANCIAL DATA ITEMS TO HP PLAN TYPES (CUBES)

OFA Financial Data Items (FDIs) are similar in many respects to HP Plan Types. However, other than the required dimensionality, there are a few other differences. OFA allows for the creation of distinct Formula FDIs, that don't store any data, but calculate values on-the-fly. HP planning allows for on-the-fly calculations, but they don't exist as separate logical cubes. Instead the formula is tied to the dimension members that are calculated on the fly. In other words, the Plan Type can be considered as a logical cube that contains both stored and formula data. There is also a function that can be used to access data from other Plan Types within and between applications or even other Essbase cubes. Similar to OFA, the formulas that


3 Paper 1

can be used are most efficient when used to perform simple mathematical operations. In OFA terms you can almost think of them as on-the-fly models.

Another difference is that while OFA allows for an unlimited number of FDIs, HP only allows for a maximum of 5 Plan Types. There are three standard plan types, plus one reserved for Capital Expenditures (Capex) Planning and one for Workforce Planning. This limitation isn't as serious as it first seems, because most data cubes will share the majority of their dimensions with the "main" data cubes. We combine this common dimensionality with what I call the "No" members in other dimensions to create smaller logical cubes within the main cube. The following example helps illustrate this technique.

Suppose you have a six dimensional main plan type with the following dimensionality and a "No" dimension member

Dimension "No Dimension Member"

Period No Period

Year No Year

Scenario No Scenario

Version No Version

Entity No Entity

Account <Typically don't have a "No" value.>

and suppose you wanted to create an “Overhead Rate” that applies to your base data, but this rate only varies by Year and Scenario. You would simply create a new Account dimension member called "Overhead Rate" and populate data against the following members:

Dimension Member

Period** No Period

Year Whichever Year is Appropriate (typically the Budget/Forecast year)

Scenario Whichever Scenario is Appropriate (typically the Budget/Forecast scenario)

Version No Version

Entity No Entity

Account Overhead Rate

**In practice you would use a value of "BegBalance" on a period dimension usually which would represent an opening balance, but for illustrative purposes you can think of this as "No Period"

By employing the appropriate "No" members, you can effectively mimic the reduced dimensionality of a 2 dimensional cube that you would create in OFA.

Essbase manages database sparsity in much the same way that Oracle Express does. When you create a cube and assign dimensions to it, you must decide which dimensions are dense, and which dimensions are sparse. It is the combination of your sparse dimensions in Essbase that are analogous to a composite dimension in Express/OFA. In Essbase the combination of your dense dimensions are referred to as blocks. A unique storage location is assigned and automatically created for each combination of dense dimension member inside the block. Sparsity is then controlled by only creating data blocks for combinations of the sparse dimensions that contain data.


4 Paper 1

HIERARCHIES

Before going too far in a discussion about hierarchies, it is worthwhile to take a moment to discuss terminology. All of the concepts used in discussing OFA hierarchies are present in HP, but the vocabulary is a bit different. References to the terms “children”, “parents”, “grandparents”, “descendants” and “ancestors” mean exactly the same in OFA and HP. However, the way you refer to “level” in OFA is quite different compared to HP. In OFA you typically refer to the very top level value of a hierarchy as the root node and the lowest level values as leaf nodes. Also, you usually refer to the top level of a hierarchy as level 1 (or level 0 if you are so inclined), and increase level number as you move down in the hierarchy tree. In HP/Essbase, you do the opposite, the bottom level of the hierarchy is referred as level 0 (in OFA this is the leaf level), and then work your way up the hierarchy tree. If you want to start counting from the top and work your way down, you start with generation 1 and increase the generation number as you move down the hierarchy tree.

In OFA the user can create an unlimited number of hierarchies for organizing data, and these hierarchies can pretty much look like whatever the user wants. In fact, the hierarchies don't even need to be consistent (as many have learned the hard way), such that a single aggregate level parent could exist in two hierarchies, and have two different sets of children. This forces OFA hierarchy administrators to be very careful NOT to reuse aggregate level parents in hierarchies or they could end up with incorrect results in these dimension members. In HP hierarchies are organized in "the outline", which is a collection of all dimension members organized into a single hierarchy structure. Each dimension in "the outline" is represented as the top level member of an integrated hierarchy that holds all members of that dimension. There is an outline for each cube in Essbase.

The Outline acts as an anchor for the dimensions that define the dimensionality of the data contained in its Plan Type. The dimension name (e.g. Account or Year) is also a dimension member and is the top member of the hierarchy. Data can


5 Paper 1

actually be stored, or calculated against this member. When you expand the hierarchy associated with a dimension you can see the individual members that make it up.

If there is more than one hierarchy it is integrated into the values under the base dimension member. Translated into OFA terms this means that the children of the dimension name (Account, Period, etc.) are the equivalent of an OFA root node.

The values under the first root node are part of the "Main" hierarchy; any other hierarchies are referred to as alternate hierarchies. The first time that a value appears in the outline, it is the actual base member, every other time that member appears in the outline, it is identified as a Shared Member. The data is only stored against the actual member, just like OFA, a dimension member represents only a single value. However, the shared members can be referenced just as if they were actual members. A shared member must be a level 0 member (leaf) in the alternate hierarchy. This prevents the possibility of inconsistencies in the hierarchy. Using shared members saves space and increases processing efficiency.

ATTRIBUTES AND ATTRIBUTE DIMENSIONS

Within HP there are two types of attributes; Attribute dimension, and User Defined Attribute (UDA). The User Defined Attribute is somewhat analogous to an OFA attribute in its usage only. Attributes are an area where HP really outshines OFA.


6 Paper 1

ATTRIBUTE DIMENSIONS

The first and most important type of attribute in HP is an attribute dimension. In OFA, an attribute is most commonly used as a selection criterion and sometimes in more advanced conditional calculations. However, outside of these two most common usages, attributes in OFA can't do much. In HP, you can assign dimension members to an attribute value, and an attribute can actually be used as a reporting dimension. That means, in addition to being a selection criterion, you can also subtotal data by attributes. So as you look to migrating from OFA to HP, you should review your OFA hierarchies to determine if it makes sense to turn your hierarchy into an attribute dimension or to leave them as a hierarchy. The following example demonstrates how an attribute dimension works in HP.

Suppose I have a "Geography" dimension which is made up of Cities at its lowest level, and is organized into the following Hierarchy with a market size attribute as follows:

Geography Hierarchy Sales

Market Size Attribute

Total US 3300

East 1775

Florida 800

Orlando 200 Large

Key West 100 Small

Tampa 500 Large

New York 700

NYC 600 Large

Albany 100 Small

Wisconsin 275

Milwaukee 200 Large

Madison 75 Small

West 1525

Texas 675

Austin 75 Small

Dallas 300 Large

Houston 300 Large

California 850

L.A. 800 Large

Sacramento 50 Small

You would then create an Attribute dimension something like the one described below:

Market Size

Large

Small

Now for reporting purposes you can think of your attribute dimension as an “optional” dimension that you can pull into your report. You can subtotal by “Large” and “Small”, and report that against all other dimensions, including your Geography dimension. This means you could create a report with a layout something like the following:


7 Paper 1

Large Small

Total US 2900 400

East 1500 275

Florida 700 100

New York 600 100

Wisconsin 200 75

West 1400 125

Texas 600 75

California 800 50

There is no similar way in OFA to accomplish this type of Attribute reporting. In OFA, if you create a separate dimension for Market Size, it will grow the size of the database and there is nothing to stop users from populating data against an invalid combination (e.g. Madison – Large, or NYC – Small). If you create an alternate hierarchy, to accomplish this reporting requirement, either you won’t get a combination of Large and Small at State or higher levels, or you have to create extra combinations for large and small for each state (e.g. Florida Large and Florida Small), resulting in an excessively large and unmanageable dimension and hierarchy.

Of course, there are some limitations on setting up attribute dimensions. First, the attributes must all be assigned at the same level of the hierarchy; otherwise you run into data consistency issues. Second, an attribute dimension can only be assigned to a sparse dimension. Finally, you can only assign a one-to-one relationship between the base dimension and the attribute dimension.

USER DEFINED ATTRIBUTES (UDAS)

The other type of attribute that is available in HP is the User Defined Attribute (UDA). The UDA is similar to an OFA attribute because it can only be used as a selection criterion. However, unlike an OFA attribute which is a relationship between two dimensions, a UDA is not technically a relationship between two dimensions. The UDA field is a free-form text field that can hold any valid text value. This can be handy for tagging dimensions with very specific information that wouldn’t necessarily work well as an OFA dimension (such as a date). Using a UDA is the only way to replicate the OFA functionality associated with a many-to-many attribute.

Multiple values are stored in the UDA field and any number of UDAs can be applied to a dimension member. Unlike OFA, when you query on the UDA field, you don’t query on a specific attribute, just the entire field. This means that you want to be specific when you assign values to your dimensions so that each member of each attribute is unique. Values like True/False or Yes/No should be avoided in the UDA field because of the possibility of ambiguity.

For example, suppose you work at an ice cream company, and you have a product dimension that you want to identify with a couple of Yes/No attributes called “Contains Vanilla” and “Contains Chocolate” to identify which products contain these ingredients. If you simply make your attribute values “Yes” and “No”, you have no way of querying these attributes separately. You can only say “Select all products where UDA is Yes”, which would give any product that contained chocolate or vanilla. Instead you should name your dimension values something unique like “Vanilla – Yes” or “Chocolate – No”.

AGGREGATIONS

Aggregations are another area where HP offers some advantages over OFA. HP planning offers both a choice of aggregation operators for use within a hierarchy as well as different on-the-fly calculation (Dynamic) options for dimension members.


8 Paper 1

AGGREGATION OPERATORS

In OFA you simply have the ability to apply an addition operator as you aggregate up your hierarchies. In HP, you can apply any of the four basic mathematical binary operators (+, ─, ×, ÷) to a hierarchical aggregation. The ability to apply operators other than addition to a hierarchy are most useful in an “Account” dimension where the signage of your values may not naturally lend itself to addition (e.g. Profit = Revenue – Expenses). It can also be useful for putting rate or percentage type calculations into a hierarchy (e.g. Labor Cost = Average Hourly Labor Rate × Hours). In OFA these types of calculations need to be done in a model. If you applied a hierarchy to these types of equations in OFA, you have to be careful never to aggregate over that hierarchy. HP eliminates this concern. HP also allows you to stop the aggregation up the hierarchy by using the “do not aggregate” (~) operator. Any member that is flagged with this operator will be excluded when calculating its parent’s value. An example of a typical Account dimension hierarchy is displayed below.

Account Hierarchy Sales Aggregation

Operator

Profit 500 ~

Revenue 1500 +

Revenue 1 800 +

Revenue Detail 1 200 +



Revenue 2 700 +



Expense 1000 -

Expense 1 550 +

Expense Detail 1 250 +



Labor Cost 450 +

Avg. Hrly. Rate 15 +

Hours 30 ×

DYNAMIC AGGREGATION

HP offers another feature that was more difficult to implement in OFA, and that is on-the-fly (Dynamic) aggregation. In OFA if you wanted to calculate a value on-the-fly instead of calculating it in a solve or Copy Data Profile (CDP) and storing it, you would need to create a formula FDI with custom Express Code behind it to do your calculation or using the very complex “skip-level” aggregation. Essbase handles this differently by allowing you to define a dimension member as a “DynamicCalc” which will apply the aggregation operator or a Member Formula (discussed later) at run time. By tagging a member as “DynamicCalc”, no data is ever stored against the member; the member is calculated on-the-fly every time it is needed. Obviously there is a performance trade off between using a DynamicCalc member versus calculating the data one time and storing the result against the member. As a general guideline, DynamicCalc members are best when used in dense dimensions.


9 Paper 1

“DynamicCalc and Store” is a slight variation of DynamicCalc. In this case the results for a “DynamicCalc and Store” member is calculated the first time it is requested and then the result is stored in cache, for use by all other users who access the very same value. However, the DynamicCalc and Store option can pose problems with data integrity unless great care is taken regarding the source data that is used as inputs to the calculation. Therefore, this option should only be used in very specific circumstances.

DIMENSION MEMBER FORMULAS

In addition to the aggregation operators mentioned in the previous section, Essbase and HP allow you to store more complex formulas against a dimension member. The formulas that can be written include just about any mathematical operator you would normally want to use in a financial application (and several more you would probably never use like the natural log or factorial). In some ways these are equivalent to an OFA model. The basic formula can be thought of as an equation made up of dimension members.

While it is possible to include more advanced logic in these member formulas (such as conditional logic), it is generally easier to use Calc Scripts (discussed later) to perform these types of calculations. Generally a member formula makes the most sense when an equation is not overly complex, and is true for every combination of the other dimensions. The member formula can either be calculated and stored, or dynamically calculated based on the data storage type. Just as with dimension aggregations, it makes sense to dynamically calculate members in dense dimensions and store the members that are used in sparse dimensions.

SOLVES VS. CALCULATION SCRIPTS AND BUSINESS RULES

In OFA the primary mechanism for aggregating and calculating data are solves. Solves allow users to define the dimensionality of the data they want to calculate along with which hierarchies should be aggregated and which models should be run. The OFA solve user interface is graphical; it is defined from within the OFA application, it employs the Selector tool, and can be easily understood by most administrators. In contrast, HP and Essbase use Calculation Scripts and Business Rules to calculate data. In addition to using the Calc Script and Business Rule for simple data aggregations, they are also the mechanism used for more complex calculations such as deriving values based on drivers or assumptions and performing allocations.

CALCULATION SCRIPTS

Calculation Scripts (or simply Calc Scripts), like an OFA solve, can be used to calculate all, or just a portion of a database. They allow more control than a solve in determining the order of a calculation, and will let you calculate data that is not defined in the outline. However Calc Scripts are created using a Calc Script language and the user interface is not graphical. In many ways the Calc Scripting language is not difficult to learn, especially for someone who has a background in Oracle Express. After the Calc Script is compiled, it can then be executed to calculate and store data values in the database.

BUSINESS RULES

Another way to calculate data in HP is to use a Business Rule. In most respects a business rule is simply a more powerful version of the Calc Script. In addition to the functionality in a Calc Script, a business rule will allow you the capability to prompt the user for input before running it. The Business Rule has a graphical user interface for creating rules, or the Business Rule can be written using the Calc Script language. Most administrators will probably want to become familiar with using the Calc Script language, because it provides more power and flexibility than the graphical user interface. However the graphical interface provides a good start for a beginner to learn to write Business Rules without learning the Calc Script language.


10 Paper 1

APPLICATION TIERS AND PERSONAL DATABASES

Within HP there are no database tiers that correspond to the Super DBA and Sub-DBA levels that exist in OFA. In HP all data is stored in a Plan Types, and each Plan Type represents a single Essbase database. Access to various structures is scoped by user or user group to control access to data and structures. If it was necessary to separate physical databases for security, network performance, or load balancing purposes in an HP application, it is possible to create separate applications and move or share data between them. This would be somewhat analogous to creating multiple Super DBA tiers in OFA and moving and sharing data between them outside of standard OFA functionality.

Another OFA concept that is missing from HP is the concept of a Personal Database. All data is stored in Essbase databases that are shared by users with appropriate access (similar to the OFA shared database). Metadata, Reports, Data Forms, Calculations, etc. (except data) are all stored in a common relational database repository. Typically users who need to create their own reports would use the Smart View Excel Add-In. They could create their analysis in Smart View (Excel), and then simply save the layout as an Excel Workbook to reuse it. If a user developed a particular useful report that should be distributed to other users, they could simply send the workbook to those users, or have an administrator write a report using Hyperion Financial Reporting Studio to distribute via the web.

HARDWARE ARCHITECTURE

SERVER SIDE

A typical OFA hardware architecture is usually simple and straightforward. You generally have Oracle Express Server (OES) and OFA Server software installed on a single server. The only other software required would be a web server if you are using OFA for the web. Of course it is possible to have Sub-DBA tiers installed on separate servers, but once again for each of these tiers you would only have OES and OFA server components installed on those servers.

HP is substantially different. The first obvious difference is since there is nothing equivalent to a Sub-DBA level, the entire database level resides on a single server. There are also several other components that need to be installed on multiple servers for a typical HP installation. These include:

Hyperion Shared Services Hyperion Analytic (Essbase) Server Hyperion Analytic (Essbase) Administration Services Hyperion Provider Services Hyperion Planning Hyperion Reporting & Analysis Services Hyperion Reporting & Analysis UI Services Hyperion Capital Expense Planning [optional] Hyperion Workforce Planning [optional]

Hyperion Planning also requires the following third-party software to function: Relational database repository (Oracle, DB2, MS-SQL Sever, etc.) Web Server (Apache/Tomcat, Oracle Application Server, WebLogic, etc.) PDF Generator (GNU Ghostscript, Adobe, etc.)

To go into the details about what these different components do is beyond the scope of this paper. However it is safe to say that a typical HP installation is significantly more complex, difficult and time-consuming than a typical OFA installation.


11 Paper 1

CLIENT SIDE

The OFA client had different Thin Client, Thick Client, Web Client, and Excel Add-In options and configurations. In contrast a typical HP application is primarily accessed via the web client or Smart View for Excel from the perspective of most users. When using Smart View, it is possible to install some optional functionality that will enable users to store data offline. This is somewhat similar to an OFA thick client that maintains a personal copy of the data on a users PC. This data can then be worked with off-line and then used to update data in the main stored cube when the user is connected to Essbase again. Access to the web based applications is managed through Hyperion Workspace that acts as a portal to all Hyperion web based applications.

HP application administrators will be required to install some non-web components on their PCs such as the Administration Services (Essbase) Console, Financial Reporting Studio, etc. for things like database administration and report creation.

CUSTOMIZATION

A big part of OFA’s success came from the ease with which you could customize your application using toolbar hooks, worksheet hooks, solve hooks and the Express language programs. For even more complex customizations, it was possible to create toolbar hooks that would run an executable such as a VB app that could extend the functionality of OFA when it linked back to the Express Database. While it is possible to create custom java extensions of HP, it is not quite as simple as it was with OFA.

ACCESS TO THE DATABASE LAYER

The simplest way to customize an OFA App was simply to enable Express Monitor and execute commands in the Express language directly against the database from within your OFA session. While this could be extremely powerful, it also had the downside of potentially doing spectacular damage to the database. HP doesn’t offer anything similar to Express Monitor; however it is possible to get a command line interface directly to the Essbase database. There are actually two command line interfaces. ESSCMD and MaxL are both command line interfaces that are similar to OESCMD for Express. These interfaces can be run interactively, or as part of a batch job. MaxL is the newer of the two interfaces and has two functional domains. The first is the MaxL Data Definition Language (MaxL DDL) which is used for updating the structural control of the database (e.g. Create, Alter, Drop commands).

APPLICATION EXTENSIONS

The HP application itself can be extended through the use of a java API. This provides a great deal of flexibility when creating extensions for the Application, but unfortunately requires knowledge of Java in addition to knowledge of Essbase.

DATA INPUT

Both OFA and HP have the same two similar ways to populate data into the database. Data can be directly entered into the database through a form, or it can be loaded through flat files, or a database link.

FILE / DATABASE LOADERS

In OFA it is possible to load data and structures into the database by writing a data loader program. Typically, structures would be loaded into a Super DBA or Sub-DBA workstation and then distributed to the corresponding Shared Database or Sub-DBA level. Data is normally loaded directly into the appropriate shared database. In HP structures can be loaded directly into the application database using Hyperion Application Link (HAL), Data Integration Management (DIM), or Oracle Data Integrator (ODI). Financial Data is loaded directly into the Essbase database using Essbase Load Rules. Because of the single tier architecture of HP, there is no need to distribute the structures or data to specific sub-tiers or users after it has been loaded.


12 Paper 1

HAL was the tool of choice until version 9.3 of HP, after which it was discontinued, and replaced with Enterprise Performance Management Architect (EPMA). EPMA is a business process management tool accessible via Workspace and employs relational interface/staging tables or flat files to define and populate an application view which is then deployed to as the HP application. DIM is actually Informatica Power Center under the covers. It is a full featured ETL tool and is accompanied with a HP Adapter and an Essbase Adapter to help facilitate loading structures and data into HP/Essbase. ODI is a new addition to the HP toolkit, and was added after Oracle’s acquisition of Hyperion. It is also a competent ETL product, and comes packaged with integration into the Oracle Applications (E-Buisness Suite) as well as HP. Unlike DIM, which is sold separately, ODI is included in the HP product stack. However, both DIM & ODI require skills outside of the standard HP skill set to implement. In other words, an ETL developer is required to successfully and effectively implement either DIM or ODI.

WORKSHEETS VERSUS DATA FORMS

For direct user input, HP planning uses Data Forms that are similar to OFA Worksheets. Data Forms are web based input sheets that are accessed through the HP application. Unlike OFA worksheet, Data Forms can only be created/modified by an administrator or power user who has been granted the appropriate privileges. Normal users are limited to data input only. Unlike OFA, if values are entered into an aggregate dimension member, the value will automatically be spread down to the level 0 members if they are in the Data Form. It is also simple to attach a Business Rule to the “Save” action on a Data Form, that can allocate data or run other calculations. To accomplish this same type of processing in OFA, you would be required to attach solves to the FDI, or to the worksheet, or use worksheet APIs. Similar to OFA, Users will only see the dimension values that they have been assigned access to in a Data Form.

In HP a version dimension member must be defined as either a "Target" version or a "Bottom Up" version. When inputting data into a Data Form, it is important to consider the type of version. In a Target version, the data can be entered into any dimension member at any level in the hierarchy. If the data is entered into an aggregate value, that data will be spread down to the lower level dimension members. In a Bottom Up version, all data must be entered into level zero dimension members. The exception to this is the Period dimension, in which you can enter values into non-Level zero members in both types of versions.

By default there are two Calculation Scripts that are associated with a Data Form. There is one that will recalculate the form, and one to calculate currency conversion. These scripts can be set to run when a user saves data in a Data Form.

REPORTS

Unlike OFA, HP reporting is done outside of the actual HP application. Reports are either built using Hyperion Financial Reporting Studio, Web Analysis or using Smart View for more ad-hoc type requirements. The typical normal user will not build reports using Financial Reporting Studio or Web Analysis, but will have access to view them in Hyperion Workspace via the web. In general, reports created using Financial Reporting Studio can be more sophisticated than those created in OFA. The ability to create more complicated asymmetric reporting and to combine multiple reports into a single document means that HP produces a more polished final report. Reports can also be saved to PDF, MS Word, MS Excel, and MS PowerPoint, so they can be easily distributed to users who do not have direct access to Hyperion Planning. Additionally, the Reports can be dynamically embedded into MS Word, MS Excel, and MS PowerPoint, so that documents & presentations are automatically updated as data changes in the source HP databases.

It is possible to create Data Forms in the planning application that are “Read Only”. These can act as a de facto report, but lack much of the formatting polish that you get when using Reporting Studio. It can also lead to user confusion when trying to access a Data Form that they are unable to write to.


13 Paper 1

As mentioned earlier, most Ad-hoc type analysis is done using Smart View. The Smart View Excel Add-In offers users access to a tool that is similar to the OFA Selector. Just like OFA, tiles can be arranged to control the axis of the report. The selection criteria that can be used in HP are not quite as powerful as the OFA selector, but, all the commonly used functionality is present. For example, all hierarchy, attribute, and text matching selections are possible in HP, but Exception and Ranking selections are not. However, since the data is accessed in Excel, it would be relatively easy to do your exception and ranking using normal Excel functionality.

USER MAINTENANCE

Like OFA, HP offers the ability to scope the access of individual users so that they have limited access to data. This scoping is done by dimension members and is based on a particular user account, or group association. This scoping also extends to Data Forms, Reports, Calc Scripts and Business Rules. However, HP offers the advantage of being able to setup different types of user authentication, where OFA was limited to authenticating against the server platform you are installed on or using Oracle’s Single-Sign-On (SSO) if you had an installation of Oracle Applications. HP can use the following types of external user authentication:

Lightweight Directory Access Protocol (LDAP) Microsoft Active Directory (MSAD) NT LAN Manager (NTLM) SAP Relational Database (Oracle, DB2, SQL Server) Native Server Authentication

Using these methods, it is possible to grant access by individual user or by user groups.

GENERAL LEDGER INTEGRATION

A big advantage of OFA has always been the tight integration that it has with the Oracle General Ledger (OGL). This integration will allow a relatively simple link between OGL and OFA to be setup in only a few hours. The link can be used to populate dimension and hierarchy data as well as financial data. The financial data also flows along a two way street so that budget data from OFA can be written back into the OGL. This integration is free and is included for owners of OFA and OGL.

At present there is no comparable integration for HP with OGL, however an easy strategy exists for integrating the two using Oracle’s Enterprise Performance Foundation (EPF). EPF is a shared repository of dimensional data and financial data that is tightly integrated with OGL. The tables in the EPF repository acts as a staging area for data that is moved between OGL and Oracle’s previous generation of CPM products – Enterprise Planning & Budgeting, Financial Consolidation Hub, Profitability Manager, etc. These tables lay out the dimensional and financial data in a format that is sensible for extraction to a multidimensional database such as Essbase. It includes information about dimensions, dimension members, hierarchies, account type, as well as financial balances.


14 Paper 1

After the data is moved from OGL to EPF, it becomes a relatively easy task to use an ETL tool such as Oracle Warehouse Builder (OWB), ODI, DIM, etc. to move the data from the EPF tables to a flat file that can be loaded into HP, or to EPMA staging tables. Another option is to simply write SQL queries against the EPF tables to extract the needed data. These extracts can be scheduled using Oracle Workflow to automate the extraction of GL data. However, one must keep in mind the additional requirements for the upkeep (back up, patches, etc.) of the EPF environment similar to the other Oracle Applications within that instance.


15 Paper 1

Unfortunately there is no comparable simple write back capability to OGL at this time. If budget data is to be moved back into OGL, it is necessary to write a custom extract of data from Essbase and then use a data loader to load it into OGL. The Essbase Adapter for DIM does provide a partial solution for extracting data out of an Essbase database without having to write custom data extract routines.

THE FUTURE

For most OFA customers out there that are considering moving to HP, the migration should be a step forward in terms of functionality. Most differences in functionality can be bridged today by simply employing the standard functionality that comes with HP. Many customized OFA features no longer need to be customized, because they exist as standard HP functionality.

Unfortunately, OFA/OES development has been virtually non-existent since 2002 when the last major release came out. The underlying Express technology has been migrated into the core Oracle database and is now known as Oracle OLAP and is currently used only for reporting. Meanwhile the technology that is part of HP and Essbase today has been continually improved during that time. Add to this that OFA is being de-supported at the end of 2010 (error correction support is ending in Dec 2009), it is probably time for most OFA customers to start looking to the future. HP represents a path forward that should not only preserve most customers’ existing OFA functionality, but extend it even further.

Documents

Glenn Ruskaup, Linium LLC - TEM Softwaretem-sw.com/library/OFA to Hyperion Planning Migration.pdf · Glenn Ruskaup, Linium LLC OVERVIEW This paper will focus on identifying the similarities