Hyperion Planning
The Challenges of Hyperion Support - Part 1: Metadata Management – Governance is the Key
The Bean Consulting Group
Introduction
When we were approached by the RMOUG to write something for the quarterly SQL Update publication, we felt that the unique challenges of supporting a Hyperion application environment would be an appropriate topic – particularly given that Hyperion applications are becoming more and more “enterprise applications,” supported from within the IT department, rather than departmental information silos, which have traditionally been managed from within finance or accounting. In addition, we thought this topic might provide some insight to help bridge the gap between the IT and application DBAs who typically support enterprise applications and the finance and accounting groups that typically support Hyperion applications.
Supporting Hyperion environments involves a unique approach to critical thinking and problem solving that requires an understanding of not just the technology being used but also of how the technology is being used. And, as with any system, troubleshooting issues in a Hyperion environment requires an identification of the primary issue, or root cause, before taking any action; however, this is particularly true when Hyperion environments are involved since an identified symptom can potentially have several different causes, and the solution to the problem can vary depending on the root cause. So, it becomes imperative that the people supporting the Hyperion environment understand both the technical aspects of the Hyperion system and how the system is used from a functional perspective.
With that as a “backdrop”, we decided that there were several key topics that should be addressed, and that a series of articles would best serve our goal of providing a better understanding of what is required to support a Hyperion system. These topics include Metadata Management, Smart View and User Support, Process Management and Workflow, Data Integration, Ownership, and Security, and Reports and Reports Studio.
Why did we choose metadata management as the first topic? Because metadata forms the building blocks for any Hyperion / EPM application, and it therefore made sense to us for it to be the first, and perhaps most important, topic we address related to the maintenance and support of Hyperion applications. Metadata, as we’ve all perhaps learned recently, thanks to news about the collection of telephone records, is defined as “data about data.” However, as Wikipedia notes, “the term is ambiguous, as it is used for two fundamentally different concepts. Structural metadata is about the design and specification of data structures and is more properly called ‘data about the containers of data’; descriptive metadata, on the other hand, is about individual instances of application data, the data content.” Metadata in the context of Hyperion applications and environments is considered structural metadata and it defines the dimensional hierarchies that are used to store, and more importantly, retrieve data from the Hyperion applications. As an example, the dimensional hierarchies for a Hyperion application might include Accounts, Periods, Years, Scenarios, Departments, and Products as shown below:
These structures are then used to store data defined by the “intersection” of the dimensions.
Furthermore, we believe that governance of structural metadata is of primary importance in a Hyperion environment. Wikipedia defines the process of governance as “a theoretical concept referring to the actions and processes by which stable practices and organizations arise and persist.” Put another way, specifically related to metadata management, the process of governance provides a mechanism for maintaining and controlling the data structures that define the enterprise applications. And, when these data structures are “tainted” in any way, such as through redundant members or inconsistent business terminology, the result can be incorrect information coming from the system being used to make enterprise decisions.
We have identified four (4) primary methods for managing and maintaining a Hyperion environment’s structural metadata. There may of course be other methods, but we believe the four methods we have identified encompass the best methods depending on the specifics of the environment.
Classic
Hyperion has been a powerful business tool for well over a decade, so perhaps a brief definition of “Hyperion” would be helpful at this point to make sure we are clear. Hyperion for our purposes is a suite of products, typically used by finance, that include Essbase, Hyperion Planning, Hyperion Financial Management, Hyperion Profitability and Cost Management and a several of other related, “edge”, products. When these products are used in a “classic mode”, the structural metadata is managed within that “product silo”. This makes it much more difficult to share that structural metadata across multiple applications.
Enterprise Performance Management Architect
Enterprise Performance Management Architect (EPMA) is a feature of Oracle Hyperion Foundation Services that integrates with Hyperion Planning, HFM, Essbase, Profitability and Cost Management, and Data Relationship Management. EPMA enables administrators to manage, create, and deploy Hyperion applications within one graphical user interface.
This provides the ability to make changes to a dimension and have it carried through to all applications which use, or subscribe, to that dimension. This, of course, can save a tremendous amount of time if there are multiple applications. Additionally, EPMA allows metadata management across product offerings such as Planning, Essbase, Profitability and Cost Management, and HFM. So, as companies realize the benefits of having multiple Hyperion products, metadata management can become more and more complex utilizing classic applications. With a graphical user interface and platform for updating metadata across multiple applications, Enterprise Performance Management Architect can be a very good choice.
Enterprise Resource Planning Integration (ERPi)
ERP Integration Adapter for Oracle Applications (ERPi) is a module of Oracle Hyperion Financial Data Quality Management (FDM); furthermore, it is an interface that sits atop Oracle Data Integrator (ODI) and leverages ODI as its processing engine to handle large amounts of data and metadata. At a high level, ERPi is a tool for centralized data and metadata that creates a seamless integration from source systems into several different types of EPM applications, including Hyperion Financial Management, Hyperion Planning – Classic, EPMA, and even Public Sector Planning and Budgeting – and Oracle Essbase. Supported source systems, include the following:
-
Oracle E-Business Suite 11i and 12
-
PeopleSoft Enterprise Financial Management 9.0 & 9.1
-
PeopleSoft Human Capital Management
-
J.D. Edwards General Ledger system
Data Relationship Management
As defined by Oracle, Data Relationship Management “is an enterprise change management solution for building and retaining consistency within master data assets despite endless changes necessary to support underlying transactional and analytical systems.” The key difference between DRM and some of the other tools discussed is that it acts as a central hub for maintaining chart of accounts, cost centers, legal entities, reporting structures, and analytical dimensions. It unifies cross-functional perspectives to a single master record by collapsing separately maintained structures into one structure. Validations and business rules that enforce certain enterprise-wide policies as well as user and object security all facilitate consistency and integrity with master metadata. Flexibility also remains a key feature. Users can create and manage alternate hierarchies through Versions and even Blend various elements of two or more versions to meet different reporting requirements. All related additions, revisions, and any other update is then synchronized with subscribing downstream systems, including BI/EPM applications, ERP systems, and even Human Resources Management systems.
Metadata Management Options in Hyperion
Classic
Essbase is a multidimensional database that provides a platform for building analytic applications. In a classic Essbase application, metadata management occurs in Essbase Administrative Services (EAS) which is a java based, graphical user interface.
EAS offers many benefits in terms of metadata management, but one of its most powerful tools are Rules files. In EAS, you can build two types of Rules files: Data Load Rules and Dimension Build Rules. In the case of metadata management, an Essbase administrator would use Dimension Build rules to build large hierarchies that have a significant number of members. The other option is to add members individually though a manually process, which may also require management of member properties on an individual, member-by-member, basis.
Hyperion Planning is a budgeting and forecasting tool that integrates financial and operational planning processes to improve business predictability. In a classic Planning application, metadata management occurs through the Dimension editor, which is a central location within each Hyperion Planning application. It offers a graphical interface for managing dimensions for that application, and that application only.
The Dimension editor allows the application administrator to manage hierarchies, member properties, performance settings and evaluation orders. In addition, administrators can manually add members to a hierarchy and update member properties. If there are large numbers of members to add to the Planning application, use the Planning Outline Load utility, Oracle Data Integrator (ODI), or Data Integration Management (DIM) adapters for Planning. As with any Planning update, after modifying metadata, refresh the Essbase database outline.
Hyperion Financial Management (HFM) is a consolidation and reporting tool that provides managers with the ability to rapidly consolidate and report financial results, meet global regulatory requirements, and reduce the cost of compliance. HFM operates as a multitier system, and its configuration contains three logical tiers: a database tier, application server tier, and client tier. In a classic HFM application, metadata management occurs in the client tier though the Load Metadata feature as shown below:
Once the application is open, perform one of the following actions to change metadata:
-
Save the Application files and load them into the Financial Management application from the Web or Win 32 Client
-
Make the modifications directly within the XML or APP files and load them into the Financial Management application
Similar to a classic Planning application, metadata management in a classic HFM application is specific to the application, which results in more maintenance and less consistency.
Enterprise Performance Management Architect (EPMA)
EPMA consists of three modules: Dimension Library, Application Library and Calculation Manager. Metadata management within EPMA occurs in the Dimension Library and the application deployments occur in the Application Library to sync any changes to the metadata back to the application. Updates to hierarchies and member properties may occur in two places, depending on the requirement – either in the Shared Library or with an application level “over-ride”.
If an administrator needs to add a member to a dimension used in multiple applications, such as scenario, the change would likely occur in the Shared Library. On the other hand, if the modification is to a specific property relevant strictly to the application, the change would occur at the application level. If multiple members are being added or a significant number of property updates are occurring, using Import Profiles with an ADS file is a more efficient method. An ADS file specifies parent/child relationships and related properties for multiple members.
E-mail: info@thebean.co