9 Signs Your DQ Programme Is Off-Track & 4 Clues To Making It Work

Managing a Data Quality (DQ) programme requires a multi-faceted approach to data.

0
985
Data quality has never been a challenge to organisations as it is now.

As we watch the business landscape rapidly evolving – with the emergence of new business innovations and new forms of competition, catalysed by advances in digitisation, analytics, Artificial Intelligence (AI), Machine Learning (ML), Internet of Things (IoT) or robotics – the availability of quality data is more than ever a critical requirement. Now allowing us to yield the full potential of these new technologies to build a competitive edge, that makes all the difference in an increasingly competitive business environment.

Data quality has always been a challenge to all organisations. But it has never been so challenging as it is now: with increasing data needs and more complex business requirements, not to mention larger volumes of data available from the most diverse of sources.

Starting and successfully managing a Data Quality (DQ) programme with a focus on leveraging the business strategy, is an ambitious goal. And often, the results are far from the expected at multiple levels. These also tend to be expensive initiatives that are time and resource consuming. They are often intrusive and disruptive, creating a natural resistance to change within the organisation.

So, what is wrong?

For those involved in starting or running a comprehensive DQ programme, there are signs revealing that changes need to be made to get your programme back on track.

1. Your organisation’s data is clean and accurate

One of the most current definitions of quality data defines it as “data that is fit for purpose.” However, there is never a single purpose for a single data element, and data can simultaneously have different levels of quality. DQ metrics are frequently very tightly connected to IT and to the systems that produce and manage that data. Those are usually compliant with the requirements, so by definition, the data they hold has the necessary quality.

Except that a technical requirement is not a business requirement and data must be considered from a business perspective, under business requirements and needs. When looking at it from this perspective, the perception of DQ can dramatically change.

2. Your organisation’s data has a single business definition

A customer is a customer.

Except when it is not. Each area within the organisation defines a customer in its own way, each system holding customer data also handles this data with different rules and purposes.

This highlights the importance of the existence of a data catalogue and business glossary, enabling consistency in data usage across the organisation and providing context to key stakeholders to find and understand data.

3. Skipping the assessment phase

It is critical to have a comprehensive view of the organisation, a clear understanding of the data environment. Addressing data quality cannot be reduced to handling a data set in a given database.

Addressing data quality means to address the three dimensions that directly affect data: people, processes and technology. The starting point to an effective DQ initiative is that data is assessed in this broader perspective.

4. Not profiling and interrogating data values

Applying a solution without the full understanding of the problem does not lead to success. It is essential to understand the data and its impacting factors.

A detailed profiling of the data and subsequent analysis of the results – identifying the root causes and possible remediation actions – is essential to avoid the recurrence of the issues and the allocation of time and resources in initiatives that will hardly bring the expected outcomes.

5. Not creating and using DQ standards

A data standard is nothing more than formalising representation, format, and definition for data elements, ensuring homogeneous routines for data entry, that all directly lead to higher levels of quality throughout the data life cycle.

6. Not following the DQ roadmap

DQ is a means to an end, not an end in itself.

It is important to define clear objectives, aligned with business objectives, strongly supported in business cases, and plan accordingly. The roadmap can and should be revisited and adapted to changing circumstances, but what should be avoided at all cost is to fall in a cycle of detached initiatives that contribute very little to the organization’s objectives.

7. Building the DQ programme as one large project

Addressing a DQ programme as one or more large projects impairs the capability to deliver effective results in reasonable time frames. This makes it hard, even with strong sponsorship, to keep the necessary traction to complete all the necessary changes.

Starting with smaller projects – ones that combine a reasonable funding model, with short time frames, targeted and with the necessary internal engagement – will allow targeted delivery returns in a short time frame. You will also be able to leverage subsequent initiatives.

8. Viewing technology as the entire solution

Exclusive focus on a technological approach will only address part of the problem.

DQ must be approached from a holistic perspective. Simultaneously handling people, processes and technology as a whole, all the while creating solutions that involve these three dimensions.

9. Not continually monitoring and evaluating data

DQ is a continuous cycle of assessment and remediation.

Continuous monitoring will improve and sustain the quality of critical data. That will simultaneously emphasise the importance of data leading to better data quality.

What to do about it?

A successful DQ program may be a daunting task, although not impossible depending on the approach.

1. Start with business areas that can clearly identify and measure the business impact of bad data on their processes

In every organisation, the opportunities to identify these cases are abundant.

There are pain points across all the business areas related to the quality of data and identifying them is not a challenge.

2. Build your business case with those willing to defend it

Once you have identified a critical pain point, you will have the business stakeholder that can passionately and effectively articulate the impact of poor data quality in their processes and that will be eager to defend the project.

3. Focus on turning insights into action

Having the business stakeholder working by your side will accelerate the process of quickly moving from findings to specific actions.

4. Establish data quality targets based on critical data for business

A deep understanding of the impact of bad quality data on the business processes enables a more accurate prioritisation of the critical data, hence making it easier to identify clear targets at an early stage.

 

Do you have a story that you think would interest our readers?
Write to us editorial@cio.co.ke

LEAVE A REPLY

Please enter your comment!
Please enter your name here
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.