Figure 1 – Hitting the Data Quality ‘Bulls Eye’.
[source: Steve Nimmons]
Data is at the core of every business. Data Quality is a consequence of many factors.
Applications act on data, processes act on applications, people interact with applications via processes.
Figure 2 – Factors which impact Data Quality (abridged)
[source: Steve Nimmons]
People have varying abilities, interest levels, workloads, levels of business understanding and experience. Their role in the Information System is critical. In most circumstances they are the source of the data and responsible for its input into (or consumption from) the Information System. Their ability to fulfil this important role is variable and compounded by (not exhaustive):
- Business Process Complexity
- Training Levels
- Availability of exemplars
- Intuitive nature of processes
- Variability of processes
- Constraints within processes (e.g. number of paths, degree of control applied)
- Quality of online help
- Review processes and audits
- Compliance mandates and consequences of non-compliance
- Learning curves relating to processes and use of applications
- Clear definitions of roles and responsibilities
- Churn rates
- Change (e.g. legislation, process changes, application changes)
- Design quality of applications
- An agreed common language
The Data Quality Blame Game
Data Quality is a consequence of interacting variables. When Data Quality drifts:
- Application designers argue from a position of “Garbage in / Garbage out”
- Process and Application designers promote the “stupid or careless users” argument
- Users blame process complexity and lack of intuitive functionality in applications (as well as over-work and lack of training)
- Recipients of reports based on tainted data ‘panic’
- Managers commence a ‘quest for the Golden Hammer’ in an attempt to find a single simple fix (which is forlorn).
The Approach to Take
Tackling Data Quality issues requires an Information Systems focused approach (respecting key variables across People, Processes and Applications). Think about how best to formulate Data Quality countermeasures by focusing iteratively on the weakest links. High-level steps:
- Quantify the actual Data Quality issue (sometimes hearsay is a false amplifier of the real size of the problem)
- Prioritise data items where Data Quality is paramount (those linked to KPI’s, statutory reporting, financial reporting and forecasting for example). Non-business critical data items could be tackled in later phases
- Hypothesise cause of Data Quality drift for prioritised data items
- Substantiate hypotheses – e.g. check against actual circumstances (focus groups, user interviews, remediation programmes in place)
- Check for compound problems – e.g. lack of training and only very occasional use of a specific process will often lead to inconsistent outcomes
- Look for badly designed applications (semantic confusion, no input validation or mandatory fields)
- Check governance and compliance processes. Are there any penalties for non-compliance with that mandated?
- Check for badly integrated applications/processes – e.g. manual re-keying of data or disconnected processes (e.g. system A doesn’t notify system B of an important data change)
Most importantly, do not be drawn towards the simplistic conclusions of the “Data Quality Blame Game.” Information Systems work (much like an orchestra) when all parts are in harmony. The interaction of users with processes and applications is non trivial. Data Quality is a consequence, and hence a symptom of misalignment of variables listed above. Focus on what needs to be tuned, then tune again!
Recent Comments