29 Jul 2010
Solving the MDM Problem is Not Easy.
Master Data Management is inherently challenging. Technology alone will not solve the problem – most of the root causes issues are process and competency-oriented:
- Organisations typically have complex data quality issues with master data, especially with customer and address data from legacy systems
- There is often a high degree of overlap in master data, e.g. large organisations storing customer data across many systems in the enterprise
- Organisations typically lack a Data Mastering Model which defines primary masters, secondary masters and slaves of master data and therefore makes integration of master data complex
- It is often difficult to come to a common agreement on domain values that are stored across a number of systems, especially product data
- Poor information governance (stewardship, ownership, policies) around master data leads to complexity across the organisation
MDM solutions are often perceived by business and executive management as significant and costly purely due to infrastructure improvement efforts lacking well-defined tangible business benefits. In order to avoid this, organizations should make sure to align this work with other initiatives that improve business processes, business intelligence, reporting and analytics, help reduce administrative overhead caused by redundant data entry, and provide other demonstratable benefits.
Data Quality Improvement requires more than Technology
Even a very sophisticated MDM technology solution cannot resolve data quality issues if proper standards and governance procedures are not in place. MIKE2.0′s open source solution for Master Data Management works in conjunction with solutions for Data Investigation and Re-Engineering and Data Governance to address historical issues, prevent new on-going data quality issues from occurring when possible and provide an enterprise exception processing framework for efficient data processing management.
July 30th, 2010 at 1:49 pm
Hi There
All very relevant points. You are quite right. Data quality cannot be solved by technology alone. Moreover, any enterprise that does not have in place the fundamental elements of a Function and Data architecture can never solve it!
So what are these fundamental elements?
The first is the Function Model. This defines WHAT the business OUGHT to be doing and is the starting point for all other architectural elements, including Process and Data.
The second essential architectural element for Data Quality is a Logical Enterprise Data Model that has been derived directly from the Function Model.
This basic architecture should also include the following two essential rules:
1. Data in any enterprise only exists to support the Business Functions of the Enterprise.
2. There are NO exceptions to Rule #1. Any data being held that does not support a Business Function should be deleted or sold off.
This is the reason that the main enabler of Data Quality is BFM – Business Function Management.
All data – Master Data, Transactional Data and Reference/Domain Data is defined by Business Function.
Read more on Business Function Management
Regards
John
Some notes on terminology for clarity:
a) A Business Function is NOT a business department but a CORE business activity.
b) Every step in a Business Process is a Business Function – so Business Functions must be defined first.
c) A Logical Data Model comprises Entities, Attributes, Relationships and Unique Identifiers – NOT Tables, Rows, Primary Keys and Foreign Keys; this is a Database Schema.
August 20th, 2010 at 7:33 am
I find this response more than a little fuzzy. My use of the word Function is much along the business lines, i.e.
Definition of Function: Management: Task-oriented block of related efforts (accounting, marketing, manufacturing, etc.) organized to produce intended outputs (financial reports, sales, products, etc.).
For me this means that a Function is truly a core concept that goes on all the time. I too distinguish between a Function, and a Organization Unit, as Mr. Owens does.
Again, for me, a Process is that part of a Function that has a beginning and end, and, in I.T. terms, transforms information / data. No transform, no Process.
A Process is made of a series of individual Activities that detail the sequence of atomic actions. Here we part company on terminology.
In Summary, Mr. Owens in his referenced documents appears to use Function to cover both the high-level continuous core level, as well as the detail-level Activity level. While both need to be considered in our work, I find the clear semantic distinctions much easier to communicate and use with both business and IT staff.
Just a thought from an old Information Engineering practitioner.