Master Data Management
From 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?
What MDM is and is not
• 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
Why is MDM Important
• 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.
Benefits / Costs
• 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
Governance vs Management
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.
CBL (Common Business Language)
• Common language of Customers, Products, Companies,
Locations, Employees, Vendors, Assets and other businessmodel 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.
Requirements / Barriers
• 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
Key Strategies for Success
• 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.
Tools – Compare/Contrast
• 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
MDM
ETL
EPM
Native
DRM
Users
DRM
SOURCES
ODI
EPMA
Planning
Essbase
HFM
HPM
Other Tools
INFORMATICA
DATASTAGE
Other MDM (not BI)
Oracle “HUB” PRODUCTS
Tools – Compare/Contrast
• 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
Questions / Feedback
• Questions / Comments
• Presenter: Bill Reddy (BReddy@AnalysisTeam.com)
• www.AnalysisTeam.com