Managing Chartfields and Trees Across PeopleSoft and Hyperion

Posted by: Brent Martin in Utilities

Tagged in: DRM

Brent Martin

If you’re implementing Hyperion applications to complement your PeopleSoft Financials application, one decision you’ll have to make relatively early is which tool to use to manage your core dimensions and their associated hierarchies.  Here are the options:

  • Native Functionality
  • Hyperion EPMA
  • Hyperion Data Relationship Management

So which one is the right choice?  Based on my research and discussions with Christopher Dwight, a member of Oracle’s Master Data Management practice, here’s what I have learned:

The native functionality basically means you’ll maintain your dimensions in each application separately.  So if you want to add a department, you’ll have to add it to PeopleSoft, then Hyperion Financial Management, then Planning separately.

Hyperion EPMA provides a robust, single point of administration for EPM applications.  It allows you to create a dimension library which allows several EPM dimensions to be centrally stored and re-used across multiple EPM applications.  Basic dimension editing capabilities are provided.  Individual dimension elements ("nodes" or "members") can be flagged for use within a specific application, supporting slightly different application requirements while promoting dimension re-use.  Although this feature has potential, each member must be individually flagged, limiting the usability for large dimensions.  EPMA is intended to support only Hyperion EPM applications, and to be utilized by system administrators, not the typical end user.

DRM is different in that it was conceived from the start as an agnostic enterprise dimension management platform, and not beholden to Hyperion EPM applications alone.  As such, DRM can be deployed to support financial metadata and dimensions in a myriad of systems, ranging from PeopleSoft to GEAC to SAP to Cognos to Teradata to Hyperion and many more.  It was also design to support not only system administrator users, but also to allow business users to become direct contributors into the dimension management process.

 

DRM goes beyond a simplistic dimension library and provides rich dimension management capabilities.  Each of the following features are unique to DRM and go beyond what EPMA can provide.

•             Extensible attributes - the ability to define any number of attributes, and then assign these attributes to user-defined node types (so that an account member might have different attributes than an entity member)

•             Logical attribute behavior based upon calculations, business rules, or inheritance - the ability to intelligently set or default attribute values, so that the vast majority of attributes will be system derived without user input.

•             Configurable business rule validation - the ability to enforce any Hilton specific rules for account segments, value lengths, uniqueness constraints, etc.  (for example ensure that every asset account is six digits and starts with the digits "85".)

•             Configurable export profiles - the ability to publish any number of alternate application-specific "perspectives" from a single master hierarchy

•             Granular security - the ability to segment user interaction by hierarchy, node and even attribute ,allowing multiple stakeholders to participate concurrently in dimension management activities without edit conflicts, and ensuring that stakeholder each operate within their respective area of responsibility.

•             Workflow / pending changes / approvals - the ability to require one or more levels of approval for certain changes, as well as the ability to capture origination via a web portal (such as new cost center request).  The pending changes capability allows changes to be captured and validated using any configured business rule validation, ensuring that once approved, pending changes will be valid.

•             Multiple version management - the ability to manage any number of current and/or future "what-if" versions, and to share changes across versions.

•             Historical perspectives / rollback - the ability to capture historical snapshot across time, and the ability to roll back to any point in time "on demand."  This allows any or all dimensions to be restored to any prior state, and also supports historical comparison capability (see below).

•             Comparison - the ability to compare hierarchies and/or attributes across any two points in time, and to highlight changes, as well as the ability to compare hierarchies and or attributes across two different hierarchies (for example, compare a cost center hierarchy by legal entity to a cost center hierarchy by business function.)

•             Audit log / change history - all user interaction within DRM is logged and tracked, allowing full visibility into who changed what when, and what the prior value was.

The reason to consider deploying DRM before (or in parallel with) your EPM deployment is because DRM provides a robust facility for rapid EPM prototyping  EPM applications are largely driven by hierarchies, and with DRM, you have the ability to "spin off" hierarchy variants with incredible ease, all the while maintaining a comprehensive history of every prior hierarchy version.  This means the EPM project team will be able to freely experiment and prototype applications, with the ability to revert back to any point in time.  It also means that key EPM stakeholders will have the ability to "try before they buy" multiple EPM application variants and provide rich, meaningful feedback to the EPM project team.  This approach is not only faster, but more likely to result in an EPM application design that suits business requirements and business user expectations. 

Deploying DRM will absolutely take some effort, but this effort is usually more than recouped by the time savings provided during the EPM implementation. 

 

Trackback(0)
Comments (0)Add Comment

Write comment

security code
Write the displayed characters


busy