Often times as a consultant, I find that most clients are eager to put as much dimensionality as possible into their DRM application. I get it – it’s a high cost tool and they want to get a lot of bang for their buck – but this isn’t always the best road to take.
Often times, there are dimensions that will never change, or are very small and easy enough to maintain independently. For example: the Period dimension almost never changes after it is added to an application. The value of putting this dimension in DRM is very low. If you are not making changes or auditing the changes of a dimension… what is the point? Having a DRM consultant create the properties and hierarchies, and the exports, for these “easy” and “small” hierarchies is more money than it’s worth.
To help clients understand and determine which hierarchies should be maintained in DRM, I came up with some high level generalities. Now these are my guidelines, but I like the dimension must fit one or more of the following criteria:
- There is a high-volume of changes within a time period.
- The dimension crosses several EPM or other applications, and should be consistent between the applications.
- There is a high chance of audit on dimensionality changes.
- There is a large number of dimension members (i.e. more than 10 or 15 members to maintain)
Obviously there can be other factors as well, as every client is different, but this is where I like to get started when evaluating the design of a DRM application. Another quick scenario that I can think of would be that the business would like to build an alternative hierarchy. DRM is a great tool to assist in ensuring all the base level members are accounted for in the new rollup.
These are my guidelines… What do you think? Is there anything else you’d consider when putting DRM hierarchies in an app?