US-Analytics | Documenting Your Hyperion Applications

US-Analytics | Documenting Your Hyperion Applications 1


Any good Hyperion admin knows documenting your EPM applications is important to successfully get your implementation off the ground. But great Hyperion admins know that thorough, accurate, and frequently updated documentation is key to making your organization successful now and in the future.

Being good is just enough to get by — enough to appear successful. But being great means leaving behind a legacy of information so your Hyperion applications, as well as the business processes surrounding those appli-cations, continue to thrive even after you’ve left an organization.

This eBook is about your legacy as a Hyperion administrator: the documentation that will live on after you’ve gone. We’ll give you all the tips you should know so that your Hyperion documentation is great — ensuring that you have a means to solve any problems that you or your successors may have.

Process ResponsibilitiesWhen it comes to documentation, you should start at the highest level. Knowing your organization’s structure and who’s responsible for what task will make it easier as you continue to document your Hyperion application and the corresponding processes.

It might help to start by capturing who at corporate, divisions, and entities is responsible for each step of the business process. Many companies create an Excel-based RACI (Responsible, Accountable, Consulted, Informed) document. This document will allow you to define responsibilities and every user’s role. You’ll then be able to understand who will be using your Hyperion applications and who will be receiving the reports that are created by the applications.

Responsibilities & Organizational Structure Questions to Consider:

1. What are the business process steps being supported?2. Who will own the various tasks supported by your application?3. At what level of granularity do users need to view data in your application?4. What does your typical data flow look like?5. What group(s) does your solution serve?

For more questions, download Checklist: Documenting Your Hyperion Environment.

http://www.us-analytics.com/checklist-documenting-your-hyperion-environment



Applications & Business ProcessesNo matter what Hyperion application you’re responsible for — Hyperion Planning, Hyperion Financial Management (HFM), Essbase, or one of Oracle’s cloud applications — you need a complete understanding of how those applications are being used. What you need to do is document all the key business processes and maintenance activities step-by-step with screenshots. You should also keep a schedule of when all your maintenance activities need to occur — be sure to doublecheck that those activities don’t interfere with any key business processes.

For example, if you’re maintaining a Hyperion Planning application, you need to make sure to conduct application maintenance (like variable and form updates) before the start of a new planning cycle. For the HFM admin, you’ll also need to install or coordinate patches for your Hyperion servers during the period right after close — and right before you start preparing for the next close. For each process, a checklist will help ensure you complete all the steps and not forget actions. Our HFM Patch Testing Checklist can help you get started.

In addition, be sure to document all your calculations, business rules, and load rules for every application.

Data IntegrationUnderstanding your data integration process is paramount to keeping your Hyperion applications running smoothly. You need to document where your data is sourced from, the frequency of your data loads, the volume of data that is loaded, and more.

Applications & Business Processes Questions to Consider:

1. What subject areas does your company address in your application(s)?2. Do you use an integrated business process?3. What are the steps to execute the business process end to end?


http://www.us-analytics.com/testing-oracle-hfm-patches-33-items-to-verify-for-hfm-admins-checklist



SecurityActive security management is key to the success of an application and process for a company. If it’s been a while since your organization has had an admin, there probably aren’t processes in place to validate data. Getting those processes down should be your first step in securing your application. The rest of your security mea-sures will mostly revolve around your users, their roles, and the groups they are in.

Understanding security is extremely important to maintaining your Hyperion applica-tion — there are a lot of things you can mess up. For example, applying security directly to a user is asking for a major headache. If you do it this way — and that person leaves — you’ll have to reapply all those security settings when a replacement comes in. Instead, use a group for every type of position, and document those groups with details explaining all of their security settings. This will ensure you won’t have any unnecessary work. That’s just one example of how you should be documenting your security settings. Use the questions below to get started.

Data Integration Questions to Consider:

1. Is your data sourced from ERP/LOB systems? What are they?2. Is data sourced from existing data marts? What are they?3. How often do you need to see refreshed data?4. How much history do you keep in your data warehouse?5. Are your data load steps documented? What are those steps?


Security Questions to Consider:

1. Have you documented all your users and their security access?2. Do you have custom roles? What are they?3. Do you have provisioning groups? 4. How often do you generate provisioning reports?





Maintenance Processes

Maintaining your applications is an obvious must. But keeping up with documenting these processes might not seem so integral. As a Hyperion admin, you have a lot going on, and the simplest performance tuning task could fall through the cracks.

And things have gotten more complicated over the years. For example, older versions of HFM required global per-formance tuning, but things have changed. Recent versions of HFM enable you to tune on a per app basis, which is important if you have multiple HFM applications and historical applications. Tuning globally is not enough for each application to function. Rather, you should document which apps need to be tuned on a per app basis —ensuring apps that consolidate or calculate get more tuning than historical applications.

In Hyperion Planning, most of your performance tuning involves your database connections. The default max connec-tions to Essbase or the database is 10, which can be a problem when you have more than 20 users trying to pull a lot of data at one time. You’ll end up with users trying to click through web forms and having to wait. You should create a schedule for checking these database connections so you can tune accordingly.

Performance Management ProcessesWhen it comes to an EPM implementation, it is easy for the lines between IT and Finance get crossed. The finance team might go in assuming that this is just like any other software or hardware implementation: IT will fix it up, and I will reap the benefits. Wrong! As the admin, it’s your job to understand those roles. Whether you’re implementing Hy-perion Planning and Essbase now, or you’re trying to complete documentation for an older application — your finance team plays the largest role in system development. Performance management applications are meant to evolve with the changing needs of the organization, so maintaining the process documentation will be critical!

Maintenance Processes Questions to Consider:

1. Do you ensure that all your mappings are up to date for each location before loading data to your target application?2. Do you have large data forms that need to be updated via xml format?3. What is your performance tuning schedule?4. Is your Essbase outline optimized for best performance of the cube (i.e. Largest Dense to Smallest Dense, Smallest Sparse to Largest Sparse)?




You need to look at your performance management processes, specifically your financial performance reporting pro-cesses. This will give you a better understanding of how your Hyperion Planning application needs to work and evolve.

Filling out this table will help you get started:

After getting a high-level understanding of your planning variance reporting, you can start to narrow in on the specific financial close and consolidation processes by answering the following questions:

• When are the books closed for actuals? Each month, quarter, or year?• Describe the different submissions required for your reporting and consolidation process:

– Balance sheet reports – Income statements – Disclosures – Intercompany transactions

• Are these part of distinct submissions with different validations and deadlines?• Who are the key employees in a given reporting process? What are their roles? What tasks do they

perform?• What are your internal reporting deadlines?• What high-level process does your organization perform during its reporting review cycle? How are

scorecards and reports used during this process?




Hyperion PlanningAs a Hyperion admin, you’re the bridge between finance and IT, understanding the businesses processes as well as the system. So before taking a deep look into your Hyperion Planning application(s), you should fully grasp your organiza-tion’s planning, budgeting, and forecasting process. Here’s a list of questions to help you get started:

• Which subject areas does your company address in planning, budgeting, and forecasting? – Profit and loss – Balance sheet – Cash flow – Capex – Products – Customers – Projects – Regions/Locations/Geography – Other

• Identify the level of involvement from different departments of your organization: – Sales/Marketing – Production – Human resources – Cost center budgeting – Other

• Describe the planning processes and differences between long range plans, budgets, and forecasts. You should include the differences in the level of detail and types of methods used, such as rolling forecasts.

• Describe the budget approval processes.• What are the key business drivers considered in budget preparation?


Single Planning Application

If you have a single Hyperion application, you are allowed three custom plan types and two modules: Workforce and Capex. Common plan types include:

• Core: GL Account, Entity• Revenue: Product, Customer• Salary/Workforce: Employee, Position• Capital/Capex: Asset Category, Projects, etc.• Sales: Customer, Sales Rep• Balance Sheet/Cash Flow

There are many benefits to using a single planning application. For the Hyperion admin, those benefits are having an easier system to manage and to document. Your forms and rules will be shared between plan types. The task lists, smart lists, personal variables, and more can also be leveraged across those plan types. Besides understanding each plan type, you can document almost everything once.

Multiple Planning Applications

However, there are many reasons for having multiple applications, such as use between separate operating units with disparate planning processes, the need for distinct processing windows, or running out of plan types.

All the modules will require customization, which you will need to take note of. Typical customization includes:

• Updating Smart List attributes for use within your organization• Modification to forms or rules to allow for budget and forecast processes that converge• Updating metadata: employees, asset category, etc.• Adding a requisition number input field

Implementing a New Application?

If you’re implementing a Planning application, it’s essential that you document in detail what it calculates, how, and why. As tedious as it sounds, getting organized with color coding, table structures, and naming conventions will serve your organization in the long run.

For instance, color coding your spreadsheets makes it easy to identify at a glance what is a formula versus a constant versus a link.


If you look at the first example below, there is no differentiation between an input and a formula. However, on the second sheet, you can quickly see that there are lots of formulas and much fewer inputs — this allows a developer to easily see what is happening on a sheet, saving time and money.

Spreadsheet without documentation

Spreadsheet with documentation


EssbaseThere’s much to document when it comes to Essbase, so we’ll start with square one. If you’re about to implement Ess-base alongside a Hyperion Planning application, you must first analyze and document your business needs by asking the following questions:

• Where does each department store their data?• Is the data in a form that Essbase can use?• Who updates the database and how frequently?• Does the data support the desired analysis and reporting goals?• Do those who need to update data have access to it?

Database Outline

Understanding the database outline is the key to understanding Hyperion Essbase. To define a multidimensional database, you design its database outline. The database outline contains the database organization (structure), the database members, and the database rules.

The components of your database outline include:

• Dimensions• Members• Attributes• Formulas• Aliases• Consolidations

Creating a Database Outline

You’ll need to create your database outline by considering what areas your company will analyze. Common subjects include:

• Time periods• Accounting measures• Distribution channels• Geographical regions

• Business units


Dimensions

Essbase supports an unlimited number of dimensions. It’s the most basic categorical definition of data within the database outline. With a dimensional structure, you can define any slice of data relevant to your application.

Members

Dimensions can contain an unlimited number of members, which makes documentation even more important. Be sure to document the following member types, and — if you have trouble remembering definitions of each member — we’ve provided the definitions for your documentation purposes:

• Parent: A member with a consolidation branch below it. • Children: A member with a parent above it.• Siblings: A child member of the same parent and on the same branch (same level).• Descendants: A member at any level below a parent.• Ancestors: A member of a branch above a member.• Generations: This term describes the branch number of a member. Generations count from the root

of the tree toward the leaf node.• Levels: This term describes the branch number of a member. Levels count from the leaf node (level 0) toward

the root (dimension name).

Attributes

Attributes characterize your data. With attributes, you can group and analyze members of dimensions based on their characteristics.

Formulas

Each database member can be associated with one or more formulas in the database outline.

Aliases

Making things even more complicated for your documentation purposes, Essbase supports alternative names (aliases) for database members. These can be useful when various labels are used for the same member in various worksheets. Aliases can also be used for more formal output name sets, such as account numbers.


Consolidations

Consolidations in Essbase applications are defined by member branches. The database outline will determine your consolidation paths. The determination is based on the location of members within a dimension. Indentation of one member below another indicates a consolidation relationship.

Defining Calculations

You should ask the following questions and document the results when you define an Essbase Calculation:

• Does the default calculation logic achieve accurate results?• Which members require Essbase formulas?• Which members require Essbase two-pass calculations?• Which members can be tagged as Dynamic cal?

Hyperion Financial Management (HFM)Dealing with user issues is a huge part of the job — there is the HFM golden rule that 9 times out of 10, the issue is related to the user having the wrong Point of View. But what about the other 10% of errors?

When you troubleshoot these issues, you shouldn’t overlook the obvious mistakes or errors. It’s possible that when a user ends up with the wrong result, it’s because they didn’t follow a process. To help you save time and rule out mis-takes, you should try to document and understand the workflow/processes of your users.

Documenting Issues and Resolutions

As a follow up to the previous tip, document the issues and how they were resolved. You don’t necessarily need to document every issue; common sense should dictate which ones you need to document. Issues usually recur, and having the documentation on hand to resolve them will save time and effort in the long run. This is especially true for processes that are run less frequently (e.g. once a year). Supplement your administrator’s guide or design document with these notes so that they can be easily found for future reference.

Documenting Financial Management Dimensions

Dimensions describe an organization’s data and usually contain groups of related members. Examples of dimensions are Account, Entity, and Period. HFM supplies eight system-defined dimensions and enables you to populate up to four custom dimensions that you can apply to accounts.


Dimension members are arranged in hierarchies. Like Essbase, upper-level members are called parent members, and a member immediately below a parent member is referred to as the child of a parent member. All members below a parent are referred to as descendants. The bottom-level hierarchy members are called base-level members.

The system-defined dimensions that you need to understand and document include:

• Scenario dimension• Year dimension• Period dimension• Entity dimension• Value dimension• Account dimension• Intercompany dimension• View dimension• Custom dimensions

Scenario Dimension

Your Scenario dimension represents a set of data, like Budget, Actual, or Forecast. For example, the Actual scenario might contain data from a general ledger, reflecting past and current business operations.

You can define any number of scenarios for an application and define attributes for Scenario dimension members, such as the default frequency, the default view, and zero data settings.

Year Dimension

The Year dimension represents the fiscal or calendar year for data. An application can contain data for more than one year. You specify a year range when you create the application and select a year from the Year dimension to process data.

Period Dimension

The Period dimension represents time periods, such as quarters and months. It contains time periods and frequencies by displaying the time periods in a hierarchy. For example, if the Actual scenario maintains data on a monthly basis, generally 12 periods of data are available for this scenario in a year. Financial Management supports years, months, and weeks for the period dimension. It does not support days for the dimension.

Entity Dimension

The Entity dimension represents the organizational structure of the company, such as the management and legal reporting structures. Entities can represent divisions, subsidiaries, plants, regions, countries, legal entities, business units, departments, or any organizational unit. You can define any number of entities.


The Entity dimension is the consolidation dimension of the system. Hierarchies in the Entity dimension reflect various consolidated views of the data. Various hierarchies can correspond to geographic consolidation, legal consolidation, or consolidation by activity. All relationships among individual member components that exist in an organization are stored and maintained in this dimension. Entities in an organization are dependent, base, or parent entities. Depen-dent entities are owned by other entities in the organization. Base entities are at the bottom of the organization struc-ture and do not own other entities. Parent entities contain one or more dependents that report directly to them.

You define attributes for Entity dimension members, such as the default currency and security class, and to specify whether the entity allows adjustments and stores intercompany detail.

Value Dimension

The Value dimension represents the different types of values stored in your application, and can include the input currency, parent currency, adjustments, and consolidation detail such as proportion, elimination, and contribution detail. For example, the Entity Currency member stores the value for an entity in its local currency. The Parent Curren-cy member stores the value for an entity translated to the currency of its parent entity. The Value dimension is useful for providing an audit trail of the transactions applied to data.

Account Dimension

The Account dimension represents a hierarchy of natural accounts. Accounts store financial data for entities and sce-narios in an application. Each account has a type, such as Revenue or Expense, that defines its accounting behavior. You define attributes for Account dimension members, such as the account type, the number of decimal places to display, and whether the account is a calculated, consolidated, or intercompany partner account.

Intercompany Dimension

The Intercompany dimension represents all intercompany balances that exist for an account. This is a reserved dimen-sion that is used in combination with the Account dimension and any custom dimension. HFM can track and eliminate intercompany transaction details across accounts and entities. You can also run Intercompany Matching reports to view intercompany transactions.

View Dimension

The View dimension represents various modes of calendar intelligence; for example, Periodic, Year-to-Date, and Quar-ter-to-Date frequencies. If you set the view to Periodic, the values for each month are displayed. If you set the view to Year-to-Date or Quarter-to-Date, the cumulative values for the year or quarter are displayed.

Custom Dimension

Four custom dimensions are available for analysis of detailed data. You need to document what additional details are stored in these dimensions along with what accounts they’re associated with, such as products, markets, channels, balance sheet movement, or types of elimination.


Documenting User-Defined Elements

Many elements of HFM are user-defined — and those are important elements to document. To help keep up with user-defined elements, the list below shows the minimum/maximum length for each element, the modules in which they are found, and additional restrictions.

Element Min. length

Max. length

Restrictions

Application ProfileLanguage 1 20 NonePeriod label 1 80 • Must contain only alphanumeric characters

• Cannot start with a number• Cannot contain spaces, symbols, or diacritical marks such as

umlautsView label 1 10 • Must contain only alphanumeric characters


umlautsView description 0 40 Cannot contain an ampersand ( & )

Period description 0 40 Cannot contain an ampersand ( & )

Create ApplicationApplication label 1 10 • Must contain only alphanumeric characters


umlauts Note: Application labels are not case-sensitive. For example, App1 and APP1 are considered the same application label.

Application description 1 255 Cannot contain an ampersand ( & )

Metadata ManagerMember label 1 80 Must be unique. The label can contain up to 80 characters, including

spaces, but cannot start with a space. Note: If you are using an Oracle database, member labels cannot contain spaces.

You cannot use the following characters in the member name:

• period ( . ) • plus sign ( + )• minus sign ( - )• asterisk ( * )• forward slash ( / )• number sign ( # )• comma ( , )• semicolon ( ; )• at symbol ( @ )• double quotation mark ( “ )• curly brackets ( { } )

Note: You cannot use ALL as the name of an entity.


Member description 0 40 Cannot contain an ampersand ( & )

Alias 0 80 Cannot contain an ampersand ( & )

SecuritySecurity class 1 80 None

JournalsJournal label 1 80 Must be unique. The label can contain up to 80 characters, including

spaces, but cannot start with a space.

Note: If you are using an Oracle database, member labels cannot con-tain spaces.

You cannot use the following characters in the member name:

• period ( . ) • plus sign ( + )• minus sign ( - )• asterisk ( * )• forward slash ( / )• number sign ( # )• comma ( , )• semicolon ( ; )• at symbol ( @ )• double quotation mark ( “ )• curly brackets ( { } )

Note: You cannot use ALL as the name of an entity.Journal description 0 255 None

Journal group 0 30 None

Journal line item de-scription

0 50 None

Load/ExtractDelimiter character 1 1 Must be one of the following characters and cannot be used in the file

or in the file name:

• comma ( , ) • tilde ( ~ ) • at sign ( @ )• dollar sign ( $ )• percent sign ( % )• ampersand (&)• carat ( ^ )• line ( | )• colon ( : )• semicolon ( ; )• question mark ( ? )• back slash ( \ )

Note: The ampersand ( & ) is not a valid delimiter for metadata .app files. You must use the same delimiter character throughout the file. Using different delimiter characters within the same file causes an error when you load the file.


Data gridsCell description 1 1900 None

Line item detail 1 80 None

Annotation 0 255 None

Decimal character 1 1 The following characters are invalid decimal characters for data grids:

• back slash ( \ )• forward slash ( / )• plus sign ( + )• minus sign ( - )

DocumentsDocument names (including folder and report names)

1 16 The following characters are invalid characters for document names:

• plus sign ( + )• question mark ( ? )• asterisk ( * )• back slash ( \ )• forward slash ( / )• number sign ( # )• comma ( , )• semicolon ( ; )• colon ( : )• at sign ( @ )• double quotation mark ( “ )• curly brackets ( { } )• line ( | )• less than sign ( < )• greater than sign ( > )• period (.) at the end of a document name.

Note: Document names also cannot contain trailing or leading white space.

HFM is a vast tool, which means your documentation will be vast. These tips hit the surface, but there’s much more to cover. If you’re filling in for an admin who’s left or you’re an admin with too much on your plate, schedule a free consultation with us. To help Hyperion owners improve operations and cut expenses, US-Analytics provides support services for day-to-day maintenance of the applications, hardware, and software — ensuring that you get the expert support you need, when you need it.

http://www.us-analytics.com/hyperion-assessment

http://www.us-analytics.com/hyperion-assessment


Migrating Oracle EPM CloudIf you’re planning to migrate to the cloud, documentation is extremely important because you have a lot of decisions to make. Fortunately, these decisions give you a chance to cleanse your environment and processes. A great example of this is migrating from Hyperion Planning to Oracle Planning and Budgeting Cloud Service (PBCS). Plan types and report scripts give you a great opportunity to streamline your processes and make documentation much more simple in the cloud.

Plan TypesThere’s a series of questions you’ll need to ask yourself before migrating your plan types:

• If you have multiple Planning applications, can you combine them into one PBCS pod?• How many total BSO and ASO plan types do you have?• PBCS has three BSO plan types and three ASO plan types. If you currently have too many, do you

need to convert or consolidate your BSO to ASO, or vice versa?

You also need to look at the dimensionality of your plan types. If they have an overlap in members, you can consoli-date those plan types. If not, you need to consider how you can fit your plan types into PBCS.

Report Scripts

Report scripts aren’t all necessary and allow you to streamline your processes since they do not exist in the cloud. Usually, report scripts are used for things like getting data off an ASO cube with no export command. So how can you do that now that report scripts no longer exist? You have several options:

• The first way is to use native PBCS utilities, which don’t automate your process but will extract your data quickly.

• You can also use business rules where you have a data export command. This isn’t a process documented by Oracle, but it does allow you to export data. Doing it this way puts your data into the data management outbox.

• Your last option is to use cloud-based data management or on-prem FDMEE, which will produce a flash file or go into a table with your ODI scripts.

Every cloud product is different, but the better the documentation of your on-premises application, the easier it will be to migrate. You’ll also have an easier time documenting and streamlining those new processes and capabilities.

Monthly UpdatesA huge benefit of the cloud is that you no longer have to install patch updates. The updates automatically occur every month during your chosen maintenance period. However, you have a huge responsibility to keep up with all of the updates. Fortunately, those updates are available to view on the Oracle Cloud website, and easily accessible on the US-Analytics EPM and BI blog every month.

http://www.us-analytics.com/hyperionblog


Overwhelmed with documenting your Hyperion environment?

We can help you. Schedule a free consultation with our Hyperion support team.

BOOK MY APPOINTMENT!

http://www.us-analytics.com/company/contact


About US-Analytics

US-Analytics is a full-service consulting firm specialized in Oracle Enterprise Performance Management and Business Analytics solutions. Applying decades of experience along with advanced degrees and certifications, our team of functional and technical experts have helped hundreds of the nation’s largest and brightest companies bridge the gap between business goals and IT deliverables.

To ensure end-to-end coverage of your technology, we provide a complete range of services: process and advisory, infrastructure, implementations, upgrades and migrations, training, and managed services.

Learn more at www.us-analytics.com.

Dallas, Texas600 East Las Colinas Blvd.Suite 2222Irving, TX 75039

Houston, Texas2500 CityWest Blvd.Suite 300Houston, TX 77042

[email protected]