Master Data ManagementFrom the Dark Corner into the Light

Bill Reddy, Analysis Team

August 24, 2012

About Analysis Team

Oracle Gold Partner based in CA, specializing in Essbase and Hyperion EPM. Implementation: requirements to rollout Strategic: to make BI/EPM a successful process

Strength: Business acumen + technical skill = relevant, high impact solutions

You can reach me at breddy@analysisteam.com.

Intro

“The goal behind master data management (MDM) is to create a single source of accurate and reliable information that can be used across business units.”-- DataFlux

We are used to talking about Metadata, not Master Data. So what’s the difference?

• Not Metadata• Master Data vs Metadata, the difference involves fuzzy math

– Master Data is the data within tables/structures that describes your business (nouns)

– Metadata: In Planning/Essbase/HFM, Dimension names are Metadata. A database’s block size is Metadata.

– Dimension members and their attributes are master data (eg. Consolidation operator, Alias, # of children, etc).

– An Essbase outline is full of ______ data.

• Metadata has more than 1 form (Kimble’s nuances):– Technical, Business, Process– Each has overlap (more fuzzy math)

What MDM is and is not

MDM tools address the management of Master Data: – EPMA– DRM– Essbase Rules &

Outline Editor– Oracle “HUB”

Products

What MDM is and is not

• Can directly (or indirectly) affect the bottom line, supporting broad business efforts such as:– Increasing efficiency (typically cost related)– Business expansion (acquisition or organic growth initiatives)– Increasing unit margins– Analyze customer profitabilty– Improving effectiveness of marketing spend, etc etc etc

• Completeness of hierarchies and attributes have significant impact to Planning, HFM and other BI systems– Master Data sync– Design considerations

Why is MDM Important

• Consistency across Functions, Time and Systems:– Example #1: Is Missouri in the EAST, CENTRAL or WEST region of your

sales structure? – Example #2: Attributes “Cold” and “Iced” in different systems – are

they the same?• One version of the truth

– Tired cliché, but parts of systems become a de facto subject area source of truth.

– Goal: Not one hierarchy, but having a collective system with agreed Master data artifacts

Why is MDM Important

• Common Understanding of meaning and context– Question: Is every location in the continental United States within a state? – MDM should have the answer and context.

• Examples where MDM can assist:– Example 1: A company implemented Planning & HFM, however there

was an EBS to Data Warehouse disconnect in how the country code was used.

– Example 2: A legitimate technical change of a product roll up in the inventory system doesn’t match the rollup in the promotional sales tracking system.

– Example 3: The Real Estate team requires a new store (to open in 2 years) to be added, but Finance doesn’t need it for current reporting or budgeting.

Why is MDM Important

• Tangible Benefits (these should be measurable)– Able to produce more accurate reports and do it faster– Helps with regulatory compliance– Common and transparent business rules– Reduce manual or duplicative MDM efforts– Reduce exception processing– Reduce time to integrate acquisitions– Reduce time to react or regulatory or business model changes (reorgs)– More accurate invoicing– Etc.

Benefits / Costs

• Intangible Benefits– Consistency– More easily achieve consensus across functions– Increased perception of one version of the truth, leading to high user

trust & confidence– Increased perception of data as an asset

Benefits / Costs

• Costs:– Additional cross-functional processes– Governance effort– Centralized management (* note, this doesn’t mean that manual

changes are not part of the process)– One-time setup costs:

• Process Changes, Software Implementation, Reporting

Benefits / Costs

Governance is having the right people and processes to make proper decisions about your master data across the affected enterprise.

– Awareness, Consistency, Good Impact Analysis– Don’t forget to talk about Security– Critical issues need to bubble up to Executive level– Software tools are not required but can help manage the workflows &

processes– Doesn’t mean the pace of changes are SLOWED down

Management involves the mechanics of maintaining / enhancing the various parts of your MDM processes.

Governance vs Management

• Common language of Customers, Products, Companies, Locations, Employees, Vendors, Assets and other business-model nouns. – Should be no confusion on what terms mean.– As easy place to see relationships of nouns.

• Centralized control over the definition of nouns and their context

• Metrics: naming and calculation methodology– Actual calculation formulas do not need to be stored in MDM. But it’s

definition and context should. Pseudocode would work.– Multiple versions are possible.

CBL (Common Business Language)

• Transactional relationships are better managed/analyzed in a tool like Oracle Endeca:– Example: analyzing the feature combinations of order-to-build computer

purchase transactions.

CBL (Common Business Language)

• Requirements (must-haves)– Data Quality is the backbone of good MDM– Clearly defined scope of the MDM challenge– Organizational buy-in by Senior Mgmt. MDM initiatives are cross-functional

and require consensus.– Must have an enthusiastic Executive sponsor.– Partnership understanding between parts of the business and IT– Assessment of tools and skills (an unflinching self-assessment)

• Barriers:– Scope of the MDM challenge is very large– Data Quality– Complexity of cross-functional integration points– Cost to purchase and implement/integrate an MDM tool

Requirements / Barriers

• Only pursue a formal enterprise MDM program if it will reduce or eliminate business pain, or there's a clear path to drive revenue or increase efficiency. It has to provide measurable benefits, the intangibles ones are not enough.

• Design MDM projects for quick wins by first addressing immediate pain or opportunities

Key Strategies for Success

• Internal Customers should work closely with IT partners to drive the program– Involve your Information Architects– Each MDM subject area will have different teams, different (enthusiastic)

sponsors– Team members may include Field Analysts, Accounting, Corp Finance, Supply

Chain Ops, Pricing Team, etc.

• Process changes require consensus to fix problems in the current state– A tool is not needed necessarily (but tools enabled easier management and

can force process change). Process changes required for various teams to work together and agree are the hardest work in MDM projects.

Key Strategies for Success

• Sensible governance based on your company culture it has to fit (as much structure as is required)

• Get a tool that fits the goals and governance structure• Identify owners in each MDM area:

– Central Owner (traffic cop) – could be the Process Owner– Business liaison to subject area – Data expert(s), System expert(s)– Information Architect

Key Strategies for Success

• Have a clear understanding of cross-system impacts (including timing)

• Impact has to be measurable. If you can measure the impact of the project, your have a much better chance of success and faster enhancement iterations.

Key Strategies for Success

• EPMA– For the Oracle Hyperion EPM Suite– Works with Planning, Essbase (ASO/BSO), HFM, HPM (Profitability)– Concept of shared dimensions, metrics– Can use SQL tools as part of importing hierarchies (EPMA Interface

tables)– Supports imports of hierarchies from existing applications or Excel files– Not designed as a hierarchy/Master Data exporter– Not recommended for high-volume solutions (very large hierarchies)– If you have just one application, EPMA doesn’t add value.

Tools – Compare/Contrast

• DRM– Can be leveraged by any system (EPM and other tools/applications)– Manage multiple hierarchies and versions. Flexibility for

divisions/departments to have varying definitions.• Make sure your governance process considers all hierarchies for changes.

– Multi-user with controls for governance.– Audit and rollback.– Reporting for governance is good.

Tools – Compare/Contrast

• DRM – Typical Usage:– Finance/Accounting Master Data such as GL Chart of Accounts,

Departments / Entities, Reporting hierarchies– For Backend Systems to align with Finance/Accounting Master Data

maintained in DRM could include Oracle apps, Data Warehouses/Marts and other EPM/BI tools. Supports ETL processes.

– Manage complex structures at corporate, country and divisional levels.– Assist with SOX & regulatory compliance.– Not intended for bill-of-materials type of applications (e.g. detailed

product master).• Essbase Rules & Outline Editor Primitives

– Manual or automated updates to Essbase only from file or SQL sources.

Tools – Compare/Contrast

Tools – Compare/Contrast

ETL MDM EPM

SOURCES ODI

DRM

EPMA

Other ToolsINFORMATICA DATASTAGE

Native

Planning

Other MDM (not BI)Oracle “HUB” PRODUCTS

DRM

Essbase

HFM

HPM

Users

• Scenario: Org changes for next year; need current structure for this year’s reporting, next year’s structure for budget– DRM can map from old to new– How do we deploy the new hierarchy? – Calculation issues especially if non-atomic members are used in

formulas?– Effect on source system reporting tools?– Governance process will need to assess impact and provide guidance

Tools – Compare/Contrast

• Other Related Tools– ODI (Oracle Data Integrator)

• Can assist in moving/transforming Master Data• Similar for Informatica PowerCenter and IBM DataStage, although ODI has

more EPM awareness– Oracle HUB products: Not intended for BI summary level; has workflows

and structures for managing customers, products, etc.– Star Analytics Integration Server: Export of hierarchies from Planning,

Essbase and HFM– Star Analytics Command Center: Can assist with automation

Tools – Compare/Contrast

• Questions / Comments • Presenter: Bill Reddy (BReddy@AnalysisTeam.com)• www.AnalysisTeam.com

Questions / Feedback