From MIKE2.0 Methodology
Solving the MDM Problem
Despite being a term that has only reached popularity in the last decade, Master Data Management (MDM) is really a new turn on an old problem.
Managing master data such as customer, product, employee, locality and partner data has always been a major challenge – ever since organisations have tried to share or integrate data across systems. For this reason, master management marketplace has grown significantly in the last decade and is predicated to continue to grow aggressively over the coming years. Organisations are spending very large amounts of money on their Master Management programmes and they want to ensure their investment is sound.
However, in most large organisations, managing master data is a very complex problem that technology alone does not solve. 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.
The majority of underlying 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 organization
• Initial business outcomes are not clearly defined in a manner which could be specifically measured.
• Each organization has its own “single version of the truth” which infrequently maps to vendor off the shelf solutions. Customization of these solutions results in creating yet another “instance of master data”. Another database to maintain, which is ill defined and becomes another silo and legacy system.
Another main contributing issue we see is the lack of understanding of the “how”s of MDM adoption, mainly in the technology division. As soon as we hear ‘MDM’, all the other buzzwords are thrown into the mix. Data Quality, data stewardship, or anything anybody is wanting to do but not getting funding for. Yes, data quality and data governance are imperative for the success of MDM, but first we need to know “when” and “how much.” For that we need to know “why.”
From the business side, many think an MDM solution is something we can simply buy and implement with some additional integration effort. And all the software vendors are happily supporting that view for their benefit. In reality, vendor software is 5-10% of the story. The industry is not yet matured in adoption of master data management. And it is a journey that takes many years (usually 3+ years) to find real benefits.
That being said, we believe that effective solutions do exist. They are the ideal combination of people, processes, and technology which achieve the desired business outcome leading to an improvement in your organization’s overall performance.
A Possible Approach to Master Data Management
First, the business side should be willing look at MDM as a strategic initiative rather than a software solution. Before asking “what’s the solution”, ask “what’s the business problem?”
Like enterprise Business Process Management, MDM should grow organically throughout the organisation starting with a manageable first steps project to get the frameworks in place and for the Centre of Excellence to be established. From that initial project a program of projects should then be formulated and prioritised to address the needs of the business. As the projects come online, the project teams build competency, the business is educated as to what is possible, and the technology is then proven.
a) Analysis - Adequate analysis needs to be done for the purpose of defining, categorizing and prioritizing data. This will fall out based on the scope of the business.
b) Decision Making Criteria - The flow of the data will fall out based on the decision making criteria. (Cost, resources, infrastructure, demographics, etc.)
c) Flow of Data - Organize the data flow into a logical hierarchy then define its level of sensetivity. (Private, Shared, Publc, etc.) Then define those levels. (BY law, by personelle, by position, by project, etc.)
d) Compliance - Make sure you are noting where compliance comes into the picture depending on industry standard. (PCI, CCB, HCCA, etc.) Incorporate relevant process to accommodate compliance and privacy.
e) Storage & Resources - Determine necessary space needed for data and the propensities in data growth. Do some research on data models to determine innate complexities involved with housing, manipulating and overall storage of similar data. (Bring a few examples to the table, chances are you’ll end up with some combination thereof.
f) Communication Strategy – Clear communication throughout the project is a necessity. You want to make sure that the powers that be are on board every step of the way and should be involved as champions. Remember that user acceptance is an ongoing process, not just an end state.
g) Vendor Selection - Research any hardware or software with an eye on your business case and ROI. The IS departments of today need to be accountable for how their efforts may and should increase return on investment and solve the MDM problem. The latest and greatest is not always what is needed. No software may be able to handle all your requirements unless you write down your strategic MDM needs and then map them to a shortlisted set of vendor products.
h) Other Considerations - Throughout this process keep in mind “tradeoffs” because of other technologies, Smart Phones, Pads, Hot Spots, and anything else you are able to think of that will fill a need without burdening a growable infrastructure.
During this process, always map your master data management objectives to a tangible business outcome. It is extremely difficult to determine the “benefits” of effective master data management, data governance, data quality or any other initiative unless the program is grounded in some expected business outcome. Remember that technology is not the answer- it is simply a means to the end. And without the process aligned to specific, desirable outcomes, the “win” is suspect and difficult to prove. Be sure to align your data/information requirements with the business processes that consume that data. It’s really the only effective way to establish a value proposition for improved quality and management of data.
