Ever wondered who should precede MDM or Data Governance? Here’s a solution which puts the battle to an end.
Several organization seems to be rather puzzled with the efforts to be taken to implement Master data management (MDM). The MDM program is mind-boggling given that it really is an enterprise level program particularly on the off chance that you are thinking about customer data. Not that product information is less than a challenge, but, customer data takes precedence over all because of the extensive 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 tedious and risky effort.
Over the last few years, we have come across many clients with a disturbing question. “Which project should be prioritized first, master data management (MDM) or data governance? Since both seem to be a top priority for us”. Our solution in all the cases has been “Why do you think you need to choose, as both the cases are not mutually exclusive and can be executed parallelly. All business programs need good data, and all data demands governance.
I trust my answer has not amazed you. One of the most efficient business use cases for data governance is the implementation of the MDM program. I see two unique categories of business cases to justify data governance. MDM can be used to generate better sales or to reduce the cost of operations. We often see the reduction in the cost of operation business case discussed and hence, the Technology team is placed in control. However, to be successful business data governance activities must be incorporated. Let’s evaluate how data governance can be leveraged by further investigating both the use case approaches.
Our first business glossary implementation consolidated of an MDM revenue generating business case. These use cases may incorporate clarifying and consolidating the customer base, identifying customer touch points and customer interactions. Generally, this incorporates defining what every business unit considers to be a client or prospect yet the goal is to identify, define and implement the data, people and processes that can secure an extra revenue. This approach is commonly determined by a business executive or even the CEO.
MDM can likewise be implemented to diminish the frameworks and cost of making and looking after product, reference or customer data. This is regularly the implementation situation where an organization has experienced numerous mergers and acquisitions (M&A) throughout the years. A similar client may have similar data in numerous siloed applications that have point-to-point interfaces to offer that data and metadata. There are organizations which have as much as 72 distinguished applications that create and maintain customer data. Numerous applications played out a similar business function with what appeared as same customer data but not necessarily with the same set of rules. I would usually consider this use case driven by technology organization as it is being observed as a technology issue. However, the real problem lies with reporting and analytics quality and consistency.
So, for what reason would it be advisable for us to consider the above MDM implementation cases as data governance use cases? For what reason MUST one do a touch of data governance in every MDM project? How about we take a glance at resources, processes, data, and metadata is needed to make the MDM project efficient what’s more to be provided by your data governance processes and resources.
Simply an MDM implementation requires the following data governance activities:
• Concurrence on the business and technical resources that will be responsible for the mastered data. It is important to have one resource (person, business unit, or committee) to be responsible for the data in the MDM “golden record.” This is a data governance action and the outcomes ought to be kept up in the business glossary.
• Concession to the data that will be aced and the related metadata (data length, type, etc.). The choice may not be a basic one as all business unit functions, and usages of the mastered data must be considered. This is regularly a technology decision and may affect existing application systems. This also ought to be kept up 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.
• Concurrence 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 an individual business unit. These rules and policies need to address the majority of the necessities of all business units. These principles ought to be kept up in the business glossary.
• Accord on the data quality rules for the golden record data. This one can be a test given that all application and business unit usages must be considered into the choice. Concurrence on the profiling rules and sources for deciding the quality dimensions is also a data governance activity. Data quality metrics ought to be kept up in the business glossary, so all data consumers know about the level of quality preceding their use.
• Agreement on the technical data integration and consolidation rules. There must be rules for the combination of like data into the golden record. The data from one application may outweigh similar data from another application. This is likewise a data governance activity, deciding the best data for the organization to utilize. The metadata of the merge/purge functionality must be kept up and gave 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 determining the data governance council which will comprise of resources that will act as data stewards to maintain the master data and validate merge/purge records to maintain the best quality of data in the golden records. You may also need stewards from different business units to manage customer MDM data. The roles and responsibilities, as well as policies from data governance, should be used by governance resources.
• Agreement on the processes and standards that will be utilized to oversee data issues for the MDM data. Management of data issues is usefulness that the data governance team ought to give to the MDM program.
• Concession to the measures and metrics that will be utilized. These might be the metrics in the advancements of the MDM executions, metrics for data quality, metrics for data issues or metrics for the governance of MDM data. Again, this is a critical deliverable from data governance and the metrics ought to be kept up in the business glossary.
• Concession to all the related reference data that will be utilized with the mastered data. I see the expanded significance of reference data in both product and customer MDM implementations. Many consider reference data as a type of MDM implementations. It is a core set of data that the data governance team must address as ahead of schedule as would be prudent. Reference data is one of the data domain that must be considered as enterprise data and has a huge incentive to the MDM program and all other applications in the enterprise. Also, indeed, your reference data ought to be kept up in the business glossary (not that you would question that by now).
• Ultimately, the MDM execution should use the data governance capacity to communicate, train and promote the critical data element projects that sway everybody in the organization utilizing data. And in today’s world who does use data!
Thus, hopefully, this excerpt has pitched our point. The question should not be whether to prioritize the MDM project over data governance but should be when do we initiate the MDM project to adopt data governance along the way. Yes, MDM and data governance bind together as one and should be considered a single project as an implementation of both practices.
Ameya Ghole, DTCC