Single hierarchy for multiple target systems

Question

Hi,
I have a version named "Account" with a hierarchy named as "Acc2013".
the hierarchy "Acc2013" is same across Oracle EBS, Oracle Fusion GL, and HFM.
how can i assign multiple node types to the same hierarchy so that i just need to maintain one hierarchy (this case account hierarchy) and select the properties pertaining to each target system?
i.e. i select the Oracle GL from the drop down and give the details for the Oracle GL then i select the HFM category from the drop down and provide the HFM related properties.
the reason why i am asking is, if i dont give the node type, all the unnecessary properties are showing up for other type of hierarchies. for e.g. there is another hierarhcy named cost center there its showing the account related properties.
to summarize, how i can utilize a single hierarchy to be used for different target systems? Appreciate your help. do i need to create different version and hierarchy for different types of target systems?

Answer 1

I'm late to respond to this, but I always preach to customers that it is critical for DRM to act as an enterprise view. This isn't a "System A" hierarchy, or a "System B" hierarchy, but rather it's an asset that is shared by both systems, and therefore attributes for both systems are valid. Since node types provide the ability to hide properties, many interesting options present themselves, not all of which lead to a good outcome in the longer term. If a user doesn't ever want to see properties for a particular system, it would be better to just remove their access to that property category in many cases. (They may already have read only access but they object to "being bothered" with seeing those properties.)
I've seen many DRM implementations head down the other path and end up with duplicate maintenance requirements, configuration challenges, or even having to do major reengineering efforts to transition DRM from a Finance department tool into an enterprise use case feeding a data warehouse. A current customer of mine used a scheme where a checkbox on each property category would make the properties disappear if unchecked...this worked great with a handful of node types, but unfortunately the number of node types needed to support all of these property category combinations was bound by factorial math principles. Consequently the maintenance for this solution went from unweildy to unmanageable as more "non-HFM" data was added to DRM.
DRM implementations should be guided by governance principles and maintenance business rules, rather than than how things appear in DRM. It's how they appear when published that is of primary importance. I think the new features related to Data Governance will help greatly in this regard. Users that are overwhelmed by the DRM UI can easily be limited to the attributes that are relevant to their specific workflows, and only the "Power users" will see everything.