Oracle DRM Blog

I have been busy on several projects and will be doing some catch up on blogging really soon. Having said that, the DRM tools section on this web site had been upgraded. I can’t tell you how many hours I have saved using this over the past few weeks. So just to let you know, it’s not there to look pretty. I actually use it.

Some interesting design questions I got over the past few weeks…

- Would you put the date dimension in DRM? It depends. I am not a big fan of building big massive date dimensions down to month, week, date, hours blah blah blah… If it’s gonna be used, then sure. You’ll also need to think about design considerations on how to control current date, current financial months, current quarter and flag them as required. Certainly don’t do it manually.

- How do you know which level of an ERP dimension you should bring into DRM? You should bring in only ones that your BI environment would actually use downstream for datawarehouses or Hyperion. Don’t bring over things that’ll be left idol on its own.

- How to do manage 2 business units wanting their own and maintain hierarchy rollup for the same dimension? Assuming you cannot group them down to one hierarchy, you should certainly decide which one is the primary. Look for the one that’s closest to the source such as the General Ledger or HFM. Now build both hierarchies but be sure to use shared node to ensure referrential integrity for leaf level members. For parent nodes, leave them distinct would be my suggestion.

- Importing member names or descriptions with symbol characters? DRM sets the default to disallow import of certain symbolic characters such as comma, double-quote, brackets etc, you can also turn them off by setting system preferences InvDesc and InvName.

- Synchronization between BI MDM and ERP primary tables? It’s always controversial over who trumps who. The ERP is a place for most of the master data at the beginning. But due to it’s inflexibility to deal with hierarchies/alternate hierarchies, DRM is a much better tool. You’ll need to set governance rules to determine the process to which master data should be maintained. As a general rule, always maintain them in one place.

- When to use DRM and when not to? Probably can be a future blog on its own… There’s a number of possible answers: 1) if the hierarchy is not being maintained well. For example, I see companies maintaining the same hierarchy in Access, Excel, EDW and somebody’s brain, than this would be a good candidate to centralize and manage under one roof.  2) if there’s SOX implication. 3) if it’s important enough to be measured/comp on. 4) if there’s multiple downstream system that will depend on it. 5) if you want to achieve single version of truth in your company.

- What about using Hyperion BPMA than DRM? Depending on your use. Personally I think DRM does a much better job as handling hierarchies and master data management that’s enterprise wide. BPMA I hear is great at managing Hyperion specific dimension builds. But you may have issues to grow beyond that.

That’s all for now… see you next time.