The Road to Data Maturity – Many data leaders know that the utopia of having all their data perfect and ready to use is frequently like the next high peak on a never-ending hike, always just that little bit out of reach.
Luca Rovesti, Head of Client Services for Datactics, hears this all the time on calls and at data management events, and has taken some time to tie a few common threads together that might just make that hike more bearable, and the peak a little closer, from the work of data stewards to key software features.
Without further ado: Luca Rovesti’s Healthy Data Management series, episode 1:
Lots of the people we’re speaking with have spent the last eighteen months working out how to reliably measure their business data, usually against a backdrop of one or more pressures coming from compliance, risk, analytics teams or board-level disquiet about the general state of their data. All of this can impact the way business decisions are made, so it’s critical that data is looked after properly.
For those who have been progressing well with their ambition to build a data driven culture, they’re usually people with a plan and the high level buy-in to get it done, with a good level of data stewardship already existing in the organisation. They’ve now moved their data maturity further into the light and can see what’s right and what’s wrong when they analyze their data. In order to build a data culture, they’ve managed to get people with access to data to stand up and be counted as data owners or chief data officers. This enables business teams to take ownership of large amounts of data and encourage data driven decision making. Now, they are looking at how they can push the broken data back to be fixed by data analysts and data scientists in a fully traceable, auditable way, in order to improve the quality of the data. The role of a data scientist is paramount here, as they have the power to own and improve the organisations critical data sets.
The big push we’re getting from our clients is to help them federate the effort to resolve exceptions. Lots of big data quality improvement programmes, whether undertaken on their own or as part of a broader data governance plan, are throwing up a high number of data errors. The best way to make the exercise worthwhile is to create an environment where end-users can solve problems around broken data – those who possess strong data literacy skills and know what good looks like.
The best way to make the exercise worthwhile is to create an environment where end users can solve problems around broken data – those who possess strong data literacy skills and know what good looks like.
As a result, we’ve been able to accelerate the development of features for our clients around federated exceptions management through integrating our Data Quality Clinic with dashboarding layers for data visuals, for example, PowerBI, Qlik, Tableau etc. We’re starting to show how firms can use the decisions being made on data remediation as a vast set of training data for machine learning models, which can power predictions on how to fix data and cut the amount of decision-making time manual reviews need to take.
It’s a million light-years away from compiling lists of data breaks into Excel files and emailing them around department heads, and it’s understandably in high demand. That said, a small number of firms we speak to are still coming to us because the demand is to do data analytics and make their data work for their money. However, they simply can’t get senior buy-in for programmes to improve the data quality. I feel for them because a firm that can’t build a business case for data quality improvement is losing the opportunity to make optimal use of its data assets and is adopting an approach prone to inefficiency and non-compliance risk.
…a firm that can’t build a business case for data quality improvement is losing the opportunity to make optimal use of its data assets and is adopting an approach prone to inefficiency and non-compliance risk.
Alongside these requests are enquiries about how data teams can get from their current position – where they can’t access or use programming language-focused tools in IT and so have built rules themselves in SQL (relying on those with computer science expertise) – to the place where they have a framework for data quality improvement and an automated process to implement it. I’ll go into that in more detail in the next blog.