There is a potential enormous impact when a reference data list or valid value list is changed. Some changes more than others. And you need to be prepared. But, as a rule, lots of things happen if you change reference data. I have added a code, or I removed the code, or I changed the code. I did not tell anyone, and suddenly, the system application is not working anymore. And, a bunch of reports are not working. My analytics are off, or the data integrations are erroring out. You need to understand your reference data and document it and have approaches when reference data is changed. This blog post will discuss the different approaches when reference data changes. If you need some additional information on what is reference data then feel free to check out our video or blog post on the subject.
There are three approaches to managing reference data:
Most common approach, which does not have any governance structure at all, is what we call the surprise attack or the fire drill. Someone has anecdotally reported an issue only after a change has been made. Someone notifies that the reports are broken or that things seem wrong. You realize that a code has been changed. That is better than the alternative, which is that you never notice. Your numbers are just wrong forever. You want to avoid this fire drill, as everything stops until this is fixed, and much time is spent.
Ideal approach is to have a very proactive approach where no one would go adding a new code or changing a code if it is considered important, without first, requesting the change. Then getting approved by data stewards, who analyze the change for impact. This is your ideal approach. Data governance (data intelligence) and the Data Cookbook will assist with this. You need to have your reference data documented so impacts can be found easily.
The reality is that the ideal approach will not always happen as it is a very mature level of data governance. The reality is that someone just goes and makes the change. You do not want to end up with the surprise attack or fire drill. You want some sort of reactive change management structure to fall back on when there is not an ideal approach being done. That means that you are being informed as soon as the changes are made. And then immediately send that change for review. The data stewards can look at it and make decisions. Maybe even rolling back the reference data change. You want to mitigate the impact. Again, you need to have your reference data documented so impacts can be found easily.
You want to be able to do the ideal method and handle the reality as both will occur. Both are a part of data governance, and from a pragmatic approach, it is important to implement both in your organization. If you rely only on the ideal approach, then you will likely fail because that involves a person making sure to take proactive measures and submit the request. But, if you have a way to monitor your reference data for changes, such as having a tool like the Data Cookbook, then you can govern it so impacts are minimal. Additional reference data specific resources (blog posts, videos, recorded webinars, etc.) can be found in this blog post. Additional data governance and data intelligence resources can be found here.
IData has a solution, the Data Cookbook, that can aid the employees and the organization in its data governance, data intelligence, data stewardship, and data quality initiatives. IData also has experts that can assist with data governance, reporting, integration and other technology services on an as needed basis. Feel free to contact us and let us know how we can assist.
Photo CreditStockSnap_U2VSC4E3VS_emergency_referencedatamethods_BP #B1125
