Master Data Management Tips: Changing a Match Rule

When we are talking to companies about our MDM platform we cover a broad range of topics, from measuring ROI, to more technical questions about the way the software operates. A common technical question is “How do we change a match rule?” Our answer – “With a great deal of care and planning!”

In this article, we will talk about why the data governance considerations relating to the changing of a match rule (or any MDM rule) are far more important than the mechanics of implementing the change.

The planning for a master data management project must cover a lot of ground: people, process and technology. A common technical question is “How do we change a match rule?” Our answer – “With a great deal of care and planning!”

When you hear questions about defining or changing master data processing rules, we encourage you to dig a little deeper and make sure the System Development Lifecycle (SDLC) of master data management is not being overlooked. Changing rules in the master data process is akin to changing code in a production application. The planning, testing and downstream impacts of the change may dwarf the effort required to make the change. Changing the rules for matching are the question we hear most often, and we never miss the opportunity to test the client’s appreciation for master data SDLC. 

Changes to master data rules should be made in a development environment where they can be evaluated for accuracy and volume. If you are adding a new rule to catch duplicates that have otherwise been missed, then you will create a spike in the number of matches that will be distributed to connected applications or data stewards. Application owners of connected systems should be consulted on the potential impact of new duplicates and changes to their data arising from merging records and surviving new values to the master record.

The worst-case scenario occurs you find a match rule in a production environment that is over-matching to create false-positives. When this happens, your first priority should be to triaging any damage caused by these false positives in downstream systems and processes. Start by shutting off the rogue rule, then identify what master records have been impacted by this bad rule, and finally inform the system owners of connected systems about the records impacted.

Summary

When planning a project, look out for stakeholders that over-simplify their assessment of a master data program based on the elegance of the user experience (UX) when changing rules. Making a rule change is only a small part of the required SDLC process.