Julia Bardmesser

As with any measuring activity, the first step is to define the goal of the training. In this case, two potential goals can be: 1. Reduce number of times employees click on a simulated suspicious message 2. Increased accuracy of reported suspicious phishing emails Second step is to define the metrics, and the data needed to calculate them. Third step that is often forgotten is to calculate the baseline before the training occurs. The next steps are the automation of data collection and metric calculation. The last, and very important step is keeping track of the how the metric evolves and whether it still reflects the achievement of the desired goals.

Three out of the four chief characteristics of the data centric organizations, i.e. being able to 1. Find data 2. Know what it means 3. Know its quality 4. Know what it can be used for Rely on metadata and metadata management capability. Data inventory and catalog are the primary tools for managing metadata and thus are fundamental to any company's drive towards data centricity.

In my experience, data quality dimensions, while interesting to the specialists, aren't a useful concept in getting the quality of the actual data better. In fact, more often than not, focusing on DQ dimensions takes the discussion away from the most important question about any DQ issue - what's its impact, how do we measure and communicate it in a way that creates an incentive for a data producer to spend time and money fixing it.

My three rules for DQ scorecards: 1. They must be readable: often data management teams cram too much information in too many colors into one page, making it hard to tell what's really requiring attention 2. They must be relevant: if a low DQ score doesn't have a clear business impact for the user(s) of the scorecard, it shouldn't be on the scorecard. 3. They must be actionable: if a DQ issue can't/won't be fixed for whatever reason, stop wasting time and money in measuring and communicating it, it just becomes a background noise that can drown out the issues that would be fixed if they were noticed.

There are a lot of DQ tools that are available on the market. How do you choose? Here are my top 3 criteria: 1. Ease of use: how easy and intuitive is it for your business user? 2. Ease of integration: how easy is it to integrate into your current tech stack? Is vendor's roadmap inline with your tech roadmap? 3. Ease of development: does it help you find the problem areas that have the most impact on your business? If a tool satisfies these three criteria, then it's a good candidate for an extended POC in your (not vendor) environment, be it cloud or on-prem.

I am going to get controversial here: Data quality dimensions aren't a useful framework for establishing data quality practice in a company. The most important success factor for a data quality program is defining the business impact of a DQ issue in the terms a business person can understand and get behind. DQ dimensions are abstract, non-business specific, and invite long and ivory tower-ish discussions about which rule belongs to which dimension that quickly lose business attention and thus business buy in and thus diminish the chances that these DQ issues would be prioritized for fixing. And isn't improving the data quality - aka fixing the DQ issues - the point of the DQ program?