The world of IT service management (ITSM) is often good at identifying, and dealing with, things that require improvement – there is, after all, the ITIL continual service improvement (CSI) (now known as simply Continual Improvement in ITIL 4) concept to lean on. However, a not-insignificant ITSM issue that’s commonly overlooked and perhaps not even seen – is that of poor data quality. And what results from this bad ITSM data.
This article digs into the problem of bad ITSM data, describing the seven most-common data-quality management issues we see when offering our data-quality-improving capabilities to our customers.
1. Not Knowing There Are ITSM Data Quality Issues
This should require little explanation. For whatever reason, organizations have never challenged the quality of their ITSM data (or have deliberately chosen to ignore any potential issues). Consequently, ITSM data is assumed to be accurate, as are the decisions and actions that leverage it. Alternatively, decision makers ignore the untrusted data and make decision based on their own assumptions of how things are.
2. Excuses Are Used to Prevent a Start Being Made
We all do this at some point – a task seems too difficult to start, so we put it off. Perhaps hoping that it will eventually go away if ignored. Unfortunately, data quality issues will never simply go away or miraculously correct themselves.
A common excuse with ITSM data issues is not knowing where to start – especially when overwhelmed by a number of issues that need to be addressed. Another is the “We need to sort out a different issue before we can address our data-quality issues” excuse. For instance, a process/service/configuration management database (CMDB)/etc. isn’t quite finished and, as such, any data-quality-improvement initiatives can’t be started.
3. It’s Seen as Too Difficult
It’s an extension of issue #2 – people expect addressing ITSM data issues to be “too tough a nut to crack” (but they do know there’s a need to improve). There might be the belief that it’s one of those “too hard to tackle” issues, and thus nothing gets done. Or there could be a lack of knowledge related to available solutions. Or competing demands for improvement resources (it’s not uncommon for the focus on system development and new features to be deemed more important than data quality).
4. Insufficient Investment of Resources
As with issue #3, there might be more focus on system development, and new features, than on ensuring the ITSM data status quo is fit-for-purpose (in terms of data quality). Or data-quality management plans are created but then not followed. Or there’s insufficient investment in data maintenance.
5. No Data Ownership and/or Usage Clarity
Who owns which data?
When we’re helping our customers, we see a lot of ITSM data without ownership or without a proper definition on how and where it should be used, and by whom. This only adds to data-quality issues and the adverse outcomes.
6. A Lack of Insight
This is when organizations know, or have a gut feel, that things aren’t right with their ITSM data. But they don’t know what needs to be fixed because they can’t easily point to where the main issues are. For example, it’s hard to report “what’s missing.”
7. Missing Skills, Tools, and Techniques
This might be a lack of data-modelling capabilities. Or not understanding the information architecture. It can be caused by a number of things – for example, not having funding for – or access to – suitably skilled people, or not having access to a fit-for-purpose ITSM data-quality management tool.
These are the seven most common ITSM data-quality management issues we see with our customers. There are of course more, plus there are available solutions to the challenges created by these issues. Please contact me if you would like to know more about our customers’ steps to improve and maintain their ITSM data quality.
Mikko is the Product Manager at JustinLabs for Data Content Manager, a NowCertified ServiceNow application for modeling, managing and auditing data; and has been working as a solution consultant and architect since 1999 prior to working as product manager. Most experienced in IT service management, ITIL, and IT4IT, together with multiple tool and best practice certifications.