As a parent of two toddlers I have been reminded that there is no rule without an exception. Those who have gone live with a MDM project are also reminded of the same. No matter how much time is spent on creating the rules, there will always be exceptions.
One thing that separates those who manage to create true long term data governance from those who only succeeds with a foundation that diminishes with time is how exceptions are looked upon and treated.
Exceptions are either treated as something that should not occur or as possibilities to evolve and refine the rules and processes. By exploiting the exceptions and actively deal with them it is also possible to get a better general understanding of why, for example a data governance board is needed.
Exceptions turn either into monsters or are ignored. The monster grows as the email chain gets larger moving upwards and outwards in the corporate organization. The alternative is that it is ignored and left unattended at someone’s desk until it has turned into a real fire and all of a sudden needs urgent attention.
That is why it is so important to capture the exceptions as early as possible so as not to use any resources in vain or to ignore exceptions that need attention.
Once the exception has been captured it is time to deal with it in a structured way, i.e. a process. You can either have a dedicated exception process or perhaps it is possible to send it into your data governance process where you handle for example, structural changes to you data model.
Whatever the approach the process needs to be effective (as always). For example, the right person doing the right things at the right time. An exception can be small or big. A small exception only affects a small subset of the data, few business units, few processes and few IT applications. A big exception has impact on a big subset of the data, several business units, several IT applications, and/or several processes or cross functional processes.
Prioritization and classification should be done early in the process. The classification should determine the correct decision group and assignment of the correct resources. It is of course much easier to get the right attention from the decision makers if the decisions are on their level and affects their business units.
Once you have dealt with the exception you have a golden opportunity to create and maintain a knowledge base of how the master data is used and how to handle specific exceptions. If maintained you will get a natural main source of information where everyone can find information about the master data.
If you are in the beginning of, or have not yet start your Data governance journey you have not only the possibility to cover exception handling from the start but also to use it as a starting point.
Use your current exceptions when you are building your business case. Use an imaginary exception handling process to identify the members of the data governance board. Use minimal resources when you are creating your rules. Focus instead of creating processes that supports evolution of the rules and thus building a solid foundation for long term data governance.