Monthly Archives: November 2011

Oracle Hyperion DRM Basics | Versions

Last week we looked at how to navigate through Oracle Hyperion Data Relationship Manager (DRM). This week we are going to go to the “Browse” section of the Home Page.
The upper section lists all the current versions present in your application. As you can see, each version has a name, a description, a type, a status, a saved flag and a load status. These are system properties associated to a version. Additional properties can be created if necessary.

In order to create a new version, we must click on the “Versions” menu then on “New”. Alternatively, next to the “Versions” menu is a shortcut to the new button.










Once we select new, Oracle Hyperion DRM will ask us to give the version a name and a description.






By default, Oracle Hyperion DRM creates all new versions that are not saved as loaded versions, with a status of “Working”.

First, I have to explain what the “Saved” flag indicates. A version is saved when it is written in the database. Oracle Hyperion DRM allows you to create versions without saving them. If you delete them or stop the server, no record is kept of unsaved versions. Unsaved versions can be useful for quick what-if scenarios or demonstrations, but in general, I strongly recommend saving your version as soon as possible. To do this, right-click on the version and select  “Save”.

As you save, Oracle Hyperion DRM will create a baseline of the version. You can open the baseline by expanding the plus sign on the left of your version.

You can see that the baseline has the type “baseline”. The baseline is simply a copy of your version as it was when initially saved. Oracle Hyperion DRM will now start logging any modification in the live version. The baseline gives the starting point, and by combining the starting point and the logs, Oracle Hyperion DRM will be able to rebuild “As-Of” versions. We will examine “As-Of” versions in a later blog but, in essence, this will allow you to generate a copy of the version as it was at a certain date.

You can also see that the baseline has a status of “Expired”. A version can have one of the following statuses:

  • “Working” – all users with the appropriate security settings can edit the version;
  • “Submitted” – only the owner of the version or the users with the “Data Manager” role can edit the version;
  • “Finalized” – no user can edit the version. The version is read only; and
  • “Expired” – no user can edit the version. The version is read only.

We will also go into more detail on security in later blogs. The important thing to remember is that the status can allow you to freeze the version or to limit the users that can edit the version.

Finally, a version can be “loaded” or “initialized”. A version that is “initialized” is saved in the database but is not loaded in memory. You will only be able to view the hierarchies in a “loaded” version. From a performance perspective, we recommend only loading the versions that you need to navigate. Unloading versions that are not in use will save memory and therefore increase the general performance of Oracle Hyperion DRM.

In the next technical blog, we will start looking at hierarchies and nodes, the core of Oracle Hyperion DRM. In the meantime if you have any questions please do not hesitate to contact our team.


Tagged , , ,

Oracle Hyperion DRM Basics | Navigation

In this blog, I’d just like to go through some very basic instructions on how to navigate DRM (v11.1.2) and how to add versions, hierarchies and nodes.

The first step is as always the log on screen.

Select an application and then enter your user name and password. Once you log in, you will see your home page.

On this home page, you can see in the top left corner the typical menus: Preferences, Help and Log out. “Preferences” will allow you to change your password and “Help” directs you to the Oracle DRM guides.

Just below these menus, you can see the name of the application you are logged in to and your user name. I have logged in as the system administrator user ADMIN. This is not recommended in any environment, as it impacts the audit log as we will discuss in a later blog.  In this example, I am working on in our test environment on a virtual machine so I know I am the only user.

On the left of the screen, you can see the home menu composed by the following links:

  • Browse –browse the existing versions and hierarchies;
  • Query – find nodes according to values of their properties;
  • Compare – understand the changes between versions. This can be useful to compare an old snapshot of your master data to your current master data.
  • Script – execute scripts which are lists of simple DRM actions in a specific version;
  • Import – create, modify or delete imports;
  • Blend – create, modify or delete blenders;
  • Export – create, modify or delete exports;
  • Audit – this page gives you access to the transaction log. All actions in DRM are logged with the user who executed the action, the date, the nature of the action, the value before and the value after; and
  • Administer – this page will list all the options required for the administration and development in DRM.

Note that in this example, I logged in with a user that has the full administrator privileges. If your user account is not a full administrator,  you may not see all the menus depending on what permissions your administrator had granted you as a user.

Next week we will start looking at how to create versions, hierarchies and nodes. As always if you have any questions please do contact us.

Tagged , , ,

Oracle Hyperion DRM Basics | An Introduction & Glossary

With the increasing recognition of the potential for masterdata governance, and in particular Oracle Hyperion Data Relationship Manager (DRM), to resolve fundamental business issues we thought we would create an beginners guide to Oracle Hyperion DRM.

We make no apologies for starting at the very beginning with a glossary of the key terms you need to know.  This blog series will provide a basic set of “how to” guides to enable you to start understanding masterdata governance and particularly Oracle Hyperion DRM.

Please be aware that this glossary is not meant to be exhaustive, but will give you a good basis to understand the remainder of the blog series:

Node – A node is a record. It represents a business concept as defined by your requirements. Each node is defined by its name which must be unique within a version;

Hierarchy – A hierarchy is made up of nodes organised in a tree structure, sometimes referred to as a set of parent / child relationships;

Version – A version is a collection of hierarchies.  Each version can be live or can be a snapshot of the business master data at a certain time;

Properties – Properties are attributes that can be associated to a node, a hierarchy or a version. They can be configured to be defined by the user, read from a source system or calculated according to other properties;

Node Type – The node type is a method of controlling the properties, the validations and the glyph / icon, associated with each node;

Shared nodes – Shared nodes are nodes that are present more than once in a version. If the hierarchy allows it, a node can be present more than once in the same hierarchy. They are denoted by using a suffix, such as  “…:Shared-XXX” where XXX is a three digit number.  Shared nodes will share global properties such as the name and description, so if you change the description in one hierarchy, it will update the node in all hierarchies where it is present;

Export – An export is used to extract master data from DRM into flat files or a database. Exports can be set up to deliver the information in the format required by the target system;

Import – An import is a tool to import master data from flat files into DRM;

Blender – A blender will allow merging a version into another or two versions into a new version;

Script – A script (or automator in previous versions) is a tool to execute simple DRM actions stored as a list in a flat file. A script can be very useful to execute long series of simple actions;

Validation – A validation (or verification in previous versions) is a tool to enforce business rules. For example, a validation to enforce the fact that all nodes of the type account should have a length of 5 characters. Validations can be real time (they are executed each time a user adds or modifies a node) or in batch (a user can trigger the validation of a complete hierarchy or the validation can be executed automatically before a given export);

That is it for this week.  Next week we will give an overview of how to navigate in DRM. In the meantime if you have any questions then please do not hesitate to contact one of our team.

Tagged , , , ,

Chart of Accounts Conversion | Common Pitfalls (Part 2)

Last week we looked at the fundamental challenges associated with chart conversion projects. This week we thought that it would be useful to identify the common pitfalls that we see repeatedly. These include:

  • Treating accounting policies and practises as an afterthought – Many organisations only consider accounting policy very late in the project cycle, when either looking at standardising month-end processes or like-for-like reporting.  However, even a small accounting policy change can have a fundamental impact on your standard chart of accounts. For instance, a small change to how overhead costs are allocated could impact on the chart design, ERP logic, month-end close process or EPM design. As such accounting policy should be agreed as one of the first tasks of your project rather than one of the last;
  • Defining code logic before understanding reporting requirements – Often we see organisations define their standard chart first, and then define their report requirements. This creates an iterative process as every change to report requirements has to be reflected in the chart. This gradually  invalidates the code logic and creates rework. Reporting requirements should be prioritised so that there is a definite understanding of requirements prior to defining the code logic, therefore ensuring your new chart is fit for purpose. Your report requirements should then be validated by the business, using real data, before creating your chart logic and codes; and
  • Big Bang doesn’t work – As mentioned last week, coping with the impact of change on your budgeting and consolidation systems is one of the major challenges of a SCoA project. A common pitfall is to attempt to change your chart in your ERP and EPM applications at the same time. This greatly increases the complexity of your initiative, puts increased pressure on your project resources and can create a highly iterative chart design process. Changes required to meet planning requirements drive changes to the chart design and vice versa.  This is a difficult cycle to stop and will prove expensive and frustrating.

If you would like to understand any more about our approach, methodology or company, then please give us a call.

Tagged , , , ,

Chart of Accounts Conversion | The Challenges (Part 1)

Standard chart of accounts (SCoA) conversion projects have the potential to be complex and risky. As such we thought it would be useful to investigate chart conversion over two blogs, starting this week with some of the following fundamental challenges:

  • Business Engagement – SCoA initiatives tends to arise when a legacy chart of accounts has become unwieldy through uncontrolled change whether dictated by mergers and acquisitions (M&A) or organic growth.  This change in business focus results in the need for better financial processes and reporting and often results in a SCoA project (although this is not the only option, but we will save that for a later blog).   The new SCoA needs to be ratified by multiple areas of an organisation, all fighting for their specific needs to be addressed.  Without careful management, this can become a very iterative process and the results can be an aggregated chart as opposed to a truly standardised structure;
  • Validation – Whilst it is an accepted fact that each area in the organisation will fight for its specific needs to be addressed, they are usually reluctant to sign off the chart until they see the impact on their reports and month end processes. In most cases, these numbers are only produced after a trial conversion to the new standard chart (with all the pain that accompanies that process). In our experience this is too late in the process and can result in many expensive iterations and trial conversions;
  • Satellite Systems Impact – A chart conversion will usually affect the interfaces between your various financial applications. In the worst case this can invalidate the design of existing consolidation, reporting and planning applications. Trying to change the interfaces and re-implement all of these applications whilst changing your chart of accounts dramatically increases the scope, complexity and risk of a SCoA project. Devising an effective approach to managing the impact of a chart conversion on your satellite applications is a major challenge for a SCoA project; and
  • Change Management – The existing financial applications continue to change during the CoA design and conversion process. This creates a challenging masterdata governance problem as masterdata created  during this period needs to be extracted and included in the design process. This creates multiple versions of the truth and can create a real headache for the design team. Similarly, managing multiple versions of SCoAs, report definitions, and mapping files is difficult.

Next week we will look at some of the common pitfalls of chart conversion.  If you would like to find out more about howSeismi helps our clients tackle these challenges, then please do not hesitate to get in contact.

Tagged , , ,