A very astute reader commented on a past blog and suggested that it would be nice to dive into some details about MDM implementations because there are so many things uncovered during a detailed analysis. I wholeheartedly agreed! The devil is definitely in the details and MDM projects are notorious for being complex. There are also implications, resulting from the implementation, that aren't necessarily considered during the planning stages. With so much variance in MDM projects, how could I provide enough detail to be useful, while allowing for multiple factors affecting projects? After trying to consider all the possibilities, I was swimming in a sea of details. There had to be an answer, but what was it?
As I looked at a variety of projects, I noticed that the triggers for many MDM projects seemed to have some common themes. Implementation patterns sounded like a viable option. If we looked at common business problems that triggered the need for MDM initiatives, what were the common themes? At the conclusion of the implementation, were there any similar outcomes? In this installment, we examine three sample cases.
Case 1: Technically Challenged
The seemingly simplest case is where you have existing governance, data standards, and rules, but there are some technical barriers causing inefficiencies (i.e., IT solution is less than optimal). For this example, we will pretend that the data are managed in spreadsheets and the stewards are having issues with concurrent users trying to make updates, routing/approval of changes, and tracking updates. While trying to manage the master data, stewards are updating the spreadsheet manually and sometimes changes are overwritten.
This seems to be the perfect case for an IT solution (e.g., an MDM package or a database with a user front-end) that allows concurrent users and tracks each record that is entered or updated.
The new tool has been implemented. Stewards can enter records, route them for review, and manage changes. It's exactly what they needed, isn't it? After all, the only issue in this scenario was the tool, right? Perhaps, but moving from a steward-controlled spreadsheet to a central system may uncover some process issues and business rules that were not apparent. Were all of the exception cases considered? With the spreadsheet, stewards had full control over what to do when something out of the ordinary arose. Need a new column? Just add it. Need a new value entered for a pick list? Just add it. The data anomalies can prove to be a huge problem and need to be explored during the requirements gathering. Another thing to consider is whether the existing governance model will require changes. Are there new roles or responsibilities that emerge with the presence of the new environment?
Case 2: A Mixed Bag
A slightly more complex case is where you have a distributed model for the master data - attributes for the master data entity reside in multiple systems and need to be consolidated together. Each source system has an active steward and contains a unique set of attributes that will contribute a master data record.
In this case, we will pretend that duplicate records do not need to be reconciled/merged and each system has an attribute that can be matched to other systems. A consolidation mechanism, such as a physical or virtual repository, offers an area where the data attributes can be brought together.
The attributes have been brought together, into a complete view of the master data element. It's exactly what they needed, isn't it? The issue with the varying locations of the attributes has been solved and there is nothing else to consider, right? Probably not. Bringing together attributes from a variety of sources introduces new security, data quality, and governance requirements. Who is responsible for the consolidated data (that can be a tough discussion)? If errors are found, where are changes made? Does a record have to have attributes from every system? Who determines when and how the data can be shared? Some attributes may have more security limitations than others. The governance structure, data security, and confidentiality level of data may change when different sources are brought together. Consider these aspects in requirements and design.
Case 3: Chaos Reigns
Unfortunately, this is one of the most common cases, but is also the case where a successful implementation brings tremendous value. In this case, data governance is limited (or non-existent), multiple sources and processes are used to create the master data element records, and the sources do not even have a common identifier.
Complexity in the processing of the disparate data requires additional capabilities that the previous cases did not need to consider. In addition to solutions mentioned above, this case requires data quality solutions to recognize and reconcile duplicate records and stewards to manage the data.
A new governance organization was established, the legacy source systems have been mapped to a new, common model, and a tool has been implemented to assist with the stewardship process and matching/merging of records. Everything is settled, right? Because of the complexity of this case, there are (unfortunately) a number of factors that need to be considered. Is there support for establishing a "master" data source? Is there a group who clearly has responsibility for this type of data? Are the rules to match records too complex or varied to be automated? In a future installment, I will talk about some templates that can help with the details and considerations of this complex case.
And now for some good news....
MDM projects aren't simple, nor are they free, but they do bring tremendous value to the business. If we examine a variety of potential outcomes (both positive and negative) during the early phases of the project, we can deliver a better solution and avoid some of the common pitfalls.
NOTE: All opinions in this blog are those of the author and not her employer. Any similarities between the cases mentioned above and my (or your) implementations is completely coincidental.