Defining Data Governance Dashboards
In reflecting on my recent data governance dashboards webinar, we need to keep a few things in mind to help put our dashboards approach into context. If we truly understand why we are creating a data governance dashboard and the importance of the dashboards to our organization, then we can better prepare ourselves for all the necessary tasks. We need to have solid answers to the “why” question before embarking on this initiative.
Overall, the dashboard creates awareness and transparency of the data and any governance issues.
This transparency leads certain stakeholders to actually assume accountability for the data issues and not pass the buck. Additionally, the dashboard may help eliminate some of the fire fighting emergencies that often occur when a data issue becomes catastrophic. Lastly, the dashboard creates confidence in the data. When the business owners and executives are confident that the data is within accepted tolerances of critical business rules, they can make the best decisions about their business.
There are a number of attributes that must be present in order for the dashboard to be effective. The dashboard must be actionable – the purpose of the dashboard is to create activity around improving data quality. In order to make decisions on what kind of action should be taken, there needs to be enough detail to fix the issues.
Additionally, the dashboard should have a flexible architecture so it can adapt to changing business requirements. It should also contain technical metadata highlighting statistics about the issues as well as business metadata about the business rules, definitions, data stewards, etc. Other necessary metadata should be included by way of historical trending. This way, you can show improvements over time.
Lastly, visual indicators provide a quick way to summarize the health or quality of the data, but a data steward should provide analysis and comments about what the trends really mean.
By building your dashboard around these attributes, you have therefore made it relevant to the business. The business will also want the actual data to be relevant too. Help them understand how data governance can improve inefficiencies in their processes, and how data is tied to their KPIs, initiatives, goals, and objectives. You will also want to use the same data they are using. Figure out where their reports are housed and where they source the data.
These activities are already built into our Trillium Data Governance Life Cycle, because the dashboard is a necessary deliverable of the program.
During the initiation phase, we identify reporting as part of our data governance strategy and include policies related to reporting and dashboards. Additionally, we complete a data profiling policy (and subsequent profiling activities), and define data stewards and maintenance owners.
Moving on to the Analysis phase, we identify the key data attributes and business rules to be monitored. We also identify owners and ensure alignment to the business’ KPI, goals, and objectives. We then create documentation for the thresholds and business rules as part of the data quality service level agreement. Lastly, we will create processes for the corrective actions and escalation processes.
During the last phase of the Data Governance Life Cycle, we complete the final steps to bring the dashboard vision to reality. This includes creating templates, updating processes, monitoring the data, and adding other controls around our processes.
For the presentation layer, we need to adopt one or more reporting frameworks. There are a number you can choose from and you may need more than one to meet your business requirements. All of our frameworks share a common theme for different levels of summaries -- Executive, for the highest level of summarization; Operational, containing high level monitoring within key policy areas; and Tactical, which contains the lowest level of detail.
You may have the most success with a framework that monitors data quality aligned to specific business KPIs, goals, and objectives. And you may need to go through a number of iterations in order to fully capture the changing requirements of the business. It all depends on your unique implementation.