Are your "critical data elements" really critical?
Defining critical data elements can be tough. And it can lead to a fairly pointless listing of almost all data elements in a given warehouse as critical. While frustrating, this outcome is understandable. The data elements wouldn’t be in there if they weren’t contributing to something operational, financial or regulatory.
How can we make this process easier and more effective in defining what’s truly critical?
Our approach is to start by defining key business terms.
Writing definitions of terms that constitute metrics highlights the data elements used to calculate them. The definition of business critical activities and metrics will naturally highlight critical data elements.
But we’re still left with the problem of determining which business terms we should define. A brainstormed list of potential terms can be just as long and unhelpful as a list of potentially critical data elements!
While ultimately we see value in defining a very comprehensive list of business terms, if a list of critical data elements is the goal, terms to be defined need to be limited to focus on achieving that goal. So where do we start?
Start where you’ve got the biggest or most pressing reporting or operational problems. These involve the data elements that are causing the most critical problems right now.
Here’s the process we follow:
1. List and prioritise critical reporting or operational issues currently experienced.
2. Start with the highest priority issue and list business terms associated with it.
3. Define those business terms. Where terms are metrics, your definitions should include calculations. This will make the data elements associated with this issue clear. You’ll often find this also makes the cause of the issue clear, which is an added value to this exercise.
4. These data elements can be considered critical, as the reporting/operational issue involving these data elements was considered the highest priority. Critical problem = critical data elements.
5. Repeat this process, working through all reporting/operational issues.
6. Continue the journey of language management by maintaining the currency and applicability of definitions as the business changes. Applying a life-cycle management process to terms, as well as governance & accountability.
It’s important to remember that if you have a term that’s needed for operational, regulatory or financial reporting, or would potentially include personal or sensitive information, then the underlying data will most likely be critical. This rule of thumb can be applied after you’ve moved through the steps above to ensure nothing has been missed or overlooked.
The Added Bonus…
When you approach your critical data element collection like this, you’ll not only have done so in a way that targets any critical issues, assisting them to be resolved, but you’ll also have a glossary that is an active and usable resource for IT projects, cross-functional area communication and general business activities.
How are you determining critical data elements?Have you found it overwhelming or ineffectual to simply “decide” which data elements are critical?Could you use an approach like this to turn data governance into a manageable task with a clear path forward?
