MDM Recharge with Data Relationship Management (DRM)

Dears,


Many organizations struggle to provide master data for traditional business intelligence (BI) information, such as dimensional hierarchies and performance measures. While performance measures are not technically considered master data, they should be consistent and governed like master data. The traditional BI platform from products such as Oracle's Business Intelligence Enterprise Edition enable IT to control dimensional hierarchies and performance measures, but only for that (BI platform) vendor's reporting and analysis tools, and always downstream of operational systems. Increasingly, organizations will need to enable more business user control and accommodate rapidly changing requirements (such as alternate hierarchies and what if analysis). In addition, organizations will need master data portability where any application, not just the reporting and analytical tools, can access the master data for dimensional hierarchies and performance measures. A nascent market is developing for dimensional hierarchies, with products such as Oracle Hyperion Data Relationship Management (DRM), IBM Cognos Business Viewpoint, Microsoft's Master Data Management Services, Profisee's Maestro, and Kalido Master Data Management. These tools are not widely deployed, and most IT leaders are unaware of their functionality.

In an effort to learn about the experiences of early adopters, A leading Reach firm interviewed four customers using Oracle Hyperion DRM Product:

• Customer 1 is an electronic design automation firm.


• Customer 2 is a financial services company.


• Customer 3 is an energy services company.


• Customer 4 is a data storage company.

They have asked the following eight questions to each of these four anonymous customers. Their answers are provided below.

1. For what business problem is DRM meant to address?

• Customer 1. The original business problem we wanted to address was that we needed a central place to maintain a hierarchy, but in such way that we could distribute the maintenance over various places in the world (i.e., close to the source) so that people could only maintain their part of a hierarchy and with a set of business rules applied that would make sure people adhered to a set of corporate policies underlying that hierarchy.

• Customer 2. DRM was purchased several years ago to solve the business problem of inconsistent organizational hierarchies across business units. Numerous "alternate" hierarchies were maintained in each business unit using whatever tool (e.g., Excel, Access, etc.) they knew best. This led to many errors in their "alternate" hierarchies and many inconsistencies in their reporting to upper level management.

• Customer 3. Creating a single source of truth with respect to master data used in our internal and external financial reports.

• Customer 4. [Our] primary business problem is productivity loss due to resolving data discrepancies and inaccuracies in reporting, caused by misaligned, and multiple hierarchy inconsistencies throughout the enterprise.

Organizations face many valid reasons why different business entities need different dimensional or hierarchical organization of master data. In cases where no such support is provided by the tools, business units revert back to organizing hierarchies in silos using Excel, Access and so on. Providing the ability to govern the definition of hierarchies can bring the right balance between centralized control and business enablement.

2. How well does DRM resolve this business problem?

Customer 1. Very well. The initial deployment was for our sales hierarchy and we were able to distribute maintenance, while it enforces all rules of channel management. We have since extended it to many other hierarchies.

Customer 2. DRM solves this particular business problem extremely well. All business units have been very happy with the consistent organizational hierarchies and consistent reporting.

Customer 3. DRM along with our business processes has enabled us to be very successful.

Customer 4. DRM provides a foundation for an enterprise, business driven, single source of truth for hierarchies and reference data with effective management capabilities including change management, control and audit, and data governance.

While Oracle DRM has been an enabling technology to provide consistent organizational hierarchies, driving this consistency requires putting in place governance practices and organizational functions to deal with the ongoing life cycle and governance of the various hierarchies across the business. The governance and organizational structures for managing hierarchies and dimensions are very similar to those used in master data management for core entities. It requires strong business involvement from the various stakeholders to define and maintain the hierarchies.

3. Has DRM been applied to other business problems?

Customer 1. Most of our deployment deals with maintaining hierarchies, but we have in some cases extended the reach. We found, for example, that one hierarchy was a good basis for financial approvals (purchasing etc.), so we ended up not just maintaining the hierarchy itself but also all the approving positions for various purposes for each node so that we can send the hierarchy with all approvers for each level/node to the purchasing system as an approval hierarchy.

Customer 2. DRM has been used to solve various business problems. For example, the Legal Entity hierarchy was maintained manually and turnaround on the maintenance was several days. With DRM, turnaround is immediate. Also, the chart of accounts hierarchy was manually maintained in an Access database. With DRM, chart of account maintenance is ongoing DRM has also taken off in other various ways. Business units get very creative in their requests and we get very creative in helping the business units meet their ever changing hierarchy needs.

Customer 3 Sure. For creating derived and alternate hierarchies for our EPM [enterprise performance management] applications that are not available in the source system. In addition, we were able run some analytics on the master data as well.

Customer 4. DRM has been used to manage change of business master data across enterprise applications while consolidating and rationalizing structures across source systems. In addition, proliferation of corporate hierarchies are addressed by synchronizing alternative business views and providing alternative hierarchies to meet reporting objectives.

One of the common challenges organization face is the need to manage and govern the changes in hierarchies. The main requirements that drive change management on hierarchies are:

• Slowly changing dimensions: the hierarchy definition evolves over time and organizations need to have a hierarchy management system that allows them to adapt the definition over time and also to version it. Versioning becomes essential when trying to compare analysis over dimensions at different dates.

• Diverse teams have diverse hierarchy definitions to meet their various reporting needs.

• What-if analysis and scenario planning also require the ability to create multiple hierarchies.

4. Which hierarchies are managed by DRM? For example, cost centers, sales territories.

• Customer 1. Cost center hierarchies, functional area hierarchy, sales hierarchy, sales territory hierarchy, work location, management organization, product hierarchy, financial approvals, chart of accounts, various mappings that create relationships between accounts, cost centers, sales channels and product lines.

• Customer 2. Accounts, organization, legal entity, currency and product. We also keep all other Essbase dimensions (scenario, calendar, year, etc.) in DRM as hierarchies for consistency of dimensions going into Essbase.

• Customer 3. Profit centers (Geo based and BU [business unit] based), cost centers, accounts, customers, products, company, legal entities and other ancillary hierarchies.

• Customer 4. Currently nine hierarchies are managed in DRM including: accounts, currency, external geography, fiscal calendar, product, scenario, product revenue classification group and category, and sales districts for professional services. We will be implementing hierarchies in DRM for cost center this year.

5. Can you describe how users interact with DRM to manage hierarchies?

• Customer 1. Users just browsing a hierarchy are using the Web viewer portion of DRM, which we expose in the BI portal. There are a couple of possible interactions for people editing a hierarchy. In most cases users use the DRM client to enter new nodes or modify existing ones, for example a cost center or an account manager, in a hierarchy. Once they are done, they can publish the updated hierarchy and this should trigger updates in various downstream systems, typically within minutes. For some hierarchies, nodes are automatically imported from another system and become available for mapping in DRM, in some cases by inserting them in a node that contains all new members to be mapped.

• Customer 2. Users have access to manage their own alternate hierarchies in DRM. They also have access to manage various required user-defined attributes on all hierarchies.

• Customer 3. The source for the hierarchies are SAP. We extract it from SAP and load into DRM on a monthly basis. Only the DRM team and a few select super users have read access to DRM at this point.

• Customer 4. Business users interact with DRM for the ongoing maintenance of the hierarchies and reference data. The business is actively involved with enriching the hierarchies and reference data in DRM. The business manages access control to the user base and controls security, as well as all aspects of data integrity DRM.

Hierarchy definition requires business expertise. The client answers above demonstrate that business users typically own the responsibility of maintaining or creating hierarchies. Business users administering hierarchies for their business area act as data stewards in master data management (MDM) or data quality improvement projects. This further enforces the governance and organization principles used in MDM to support hierarchy definition.

6. Do you seek to master hierarchy data in downstream systems ( i.e., business intelligence) or upstream systems (business applications)?

• Customer 1. We do both. All hierarchies go into the data warehouse and some of our OLAP [online analytical processing] cubes. Some also are fed back to transaction systems (SAP, several Web applications, planning/forecasting apps).

• Customer 2. We feed only downstream BI applications.

• Customer 3. At this point only the downstream systems.

• Customer 4. We have DRM master of hierarchy data for both upstream and downstream applications.

7. Who is the primary business sponsor of DRM?

• Customer 1. Mainly finance, mostly because finance is tasked with maintaining many of the corporate hierarchies.

• Customer 2. Primary business sponsor is financial planning and analysis group.

• Customer 3. Finance and accounting organization (financial reporting systems group).

• Customer 4. The primary business sponsor of DRM is a finance BI senior manager within corporate financial planning and analysis.

8. Is DRM used to manage performance measures as well dimensional hierarchies?

Customer 1. We currently only use DRM to create or edit dimensional hierarchies.

Customer 2. We do not use DRM to manage performance measures.

Customer 3. We maintain custom performance measures and align with hierarchies managed in DRM.

Customer 4. Currently, we are not using DRM to manage performance measures. We use DRM for standard dimension hierarchies with single parent-child relationship.


Miles
Organizations need to include governing dimensional hierarchies as part of their master data management initiative. This becomes more important as the need for multiple hierarchies increases. Part of the MDM strategy needs to reconcile the single, static hierarchy provided by most business applications with the multiple and often ungoverned hierarchies manifesting themselves in numerous downstream OLAP cubes. Look to leverage these types of tools for downstream and upstream applications. Try to position them as a change management solution in your organization that builds consistency between operational and analytical systems by maintaining relationship maps among the most complex web of data relationships.

Moreover, leaders of MDM initiatives can enable a wide variety of data managed as hierarchies. The customer references highlighted above are a testament to the neutrality of tools like DRM to facilitate hierarchies from multiple data management subject areas. Although all the business sponsors mentioned above were associated with the finance department, that doesn't mean the scope of the project needs to be limited to just finance. Notice how most of the references above included hierarchies such as cost centers, chart of accounts and fiscal calendars; but they also included customers, products, legal entities, sale channels and so on.

Unfortunately, based on the customer experiences outlined above, it doesn't appear that organizations have extended the idea of analytical MDM to include governing performance measures. While there is a clear need to ensure organizations have a consistent and reliable set of performance measures available to all business applications, there doesn't appear to be a technical solution to this problem yet. Customers indicated this could be possible with DRM, but it isn't a clear application of DRM and not something they were considering in the near term. This means most performance measures will continue to be defined within the BI platform semantic layer and performance management applications for the near future.

Its time to Recharge your MDM

Loving P&C
DC*