Many organizations seem to be confused in how to implement a master data management (MDM) program. The MDM program is complex given that it truly is an enterprise level program especially if you are considering customer data. Not that product data is not a great challenge, however, customer data has greater touch points culturally, organizationally, externally, and application environments. While as an industry, we have been implementing MDM programs for over 2 decades, if you are just starting one in your company it can be a daunting and risky effort.
Over the last few months I have been asked a disturbing question by a few companies. “Which project do you recommend we do first, master data management (MDM) or data governance?” “We have pressure to do both.” My answer in all cases has been “why do you believe you need to choose. You should do both as one project.” The reality is that while you can implement a data governance program without doing an MDM project, you cannot implement MDM without doing a significant bit of data governance. The two efforts are not mutually exclusive. All business programs require good data, and all data needs governance.
I hope my answer has not surprised you. One of the most significant business use cases for data governance is the implementation of an MDM program. We see MDM used in two different types of business use case approaches to justify data governance. MDM can be a business offensive approach (to generate greater sales), or as an efficiency approach (to reduce the cost of operations). We often see the efficiency use case discussed, and hence the technology team is put in charge. Yet, to be successful business data governance activities must be included in the implementation. Let’s explore both use case approaches and how data governance can be leveraged for MDM success.
My first business glossary implementation was in support of an MDM “offensive” revenue generating business case. These use cases may include clarifying and consolidating the customer base, identifying customer touch points and customer interactions. Often this includes defining what each business unit considers to be a customer or prospect, yet the objective is to identify, define and implement the data, people and processes that can generate additional revenue. This approach is generally driven by a business executive or even the CEO.
MDM can also be implemented to reduce the systems and cost of creating and maintaining product, reference or customer data. This is often the use case where an organization has gone through many mergers and acquisitions (M&A) over the years. The same customer may have the same data in many siloed applications that have point-to-point interfaces to share that data and metadata. About four years ago, I worked with an organization that had 72 separate applications that created and maintained customer data. Multiple applications performed the same business functions with what seemed like the same customer data but not necessarily with the same rules.
We often see this use case driven by the technology organization as this use case is a technology problem. Hidden in this use case is often a large problem with reporting and analytics quality and consistency.
So why should we consider the above MDM implementation cases as data governance use cases? Why MUST one do a bit of data governance in every MDM project? Let’s look at what resources, processes, data and metadata is needed to make the MDM project successful. And, of that, what should be provided by your data governance processes and resources?
Simply an MDM implementation requires the following data governance activities:
- Agreement on the business and technical resources that will be accountable for the mastered data. It is necessary to have one resource (person, business unit, or committee) to be accountable for the data in the MDM “golden record”. This is a data governance activity and the results should be maintained in the business glossary.
- Agreement on the data that will be mastered and the associated metadata (data length, type, etc.). The decision may not be a simple one as all business unit functions and usages of the mastered data must be considered. This is often a technology decision and may impact existing application systems. This too should be maintained in your business glossary.
- Consensus for the business terminology of the data being mastered (customer or vendor or employee). This terminology is business terms and should be maintained in the business glossary.
- Agreement on the business rules and policies that will be enforced for the management of the “golden record data.” The business rules that govern the creation, management, archive and disposition of the customer data may vary by the legacy application and business unit functions, as well as regulations that govern and individual business unit. These rules and policies need to address all of the needs of all business units. These rules should be maintained in the business glossary.
- Consensus on the data quality rules for the golden record data. This one can be a challenge given that all application and business unit usages must be factored into the decision. Defining data quality and the thresholds are a data governance activity. Agreement on the profiling rules and sources for determine the quality level is also a data governance activity. Data quality metrics should be maintained in the business glossary, so all data consumers are aware of the level of quality prior to their usage.
- Agreement on the technical data integration and consolidation rules. There must be rules for the consolidation of like data into the golden record. The data from one application may take precedence over the same data from another application. This is also a data governance activity, determining the best data for the organization to use. The metadata of the merge/purge functionality must be maintained and provided to all data consumers. This is known as traceability and data lineage. Again, the rules and operational metadata should be maintained in the business glossary.
- Agreement on the resources that will function as data stewards to maintain the mastered data and validate merge/purge records to maintain the best data in the golden record. Yes, these are the data governance resources in both the technology and business teams. You may need stewards from many business units to manage customer MDM data. The roles and responsibilities, as well as policies from data governance should be used by the governance resources.
- Consensus on the processes and standards that will be used to manage data issues for the MDM data. Management of data issues is functionality that the data governance team should provide to the MDM program.
- Agreement on the measures and metrics that will be used. These may be metrics in the progress of the MDM implementation, metrics for data quality, metrics for data issues, or metrics for the governance of the MDM data. Again, this is a critical deliverable from data governance and the metrics should be maintained in the business glossary.
- Agreement on all associated reference data that will be used with the mastered data. We see the increased importance of reference data in both product and customer MDM implementations. Many consider reference data as a type of MDM implementation. It is a core set of data that the data governance team must address as early as possible. Reference data is one of the data domains that must be considered as enterprise data and has significant value to the MDM program and all other applications in the enterprise. And yes, your reference data should be maintained in the business glossary (not that you would question that by now).
- Lastly, the MDM implementation should leverage the data governance ability to communicate, education and promote the critical data projects that impact everyone in the organization that uses data. And, today who does not use data!
Hopefully, I’ve made my point. There should not be a question of doing an MDM project or doing data governance. It is not a question of which but a question of when do we start the MDM project so we can further the adoption of data governance. It is not two efforts but just one that has significant benefits and value to the organization. Yes, MDM is more than data governance and data governance is more than MDM. But the MDM program should be considered as an implementation of both practices. And, as always, stay calm and allow your data governance program to prosper.
