This is the second posting in a series on data management. In the first post, I discussed Why data management is easier than it seems. Three main reasons are: (1) you probably have several components in place already, (2) you can start small and keep improving continuously, and (3) there are many good practices available, for example in the DMBOK or in my book Data management: a gentle introduction.
When looking at the essence of what an organization does, and how it functions, the mantra is: people handle data that lives in systems when executing their processes and create value for the organization. Take one component out, and the whole thing falls apart. No one in the organization will question the usefulness of people management, systems management, or process management. Then why is data management such a hard sell?
In this post, I will consider why data management is harder than it seems. I will admit that I think this is a really hard question for the simple reason that it seems so obvious that we should ‘manage our data as an asset’.
Based on the research that I have done for my book, I have come up with several answers to this question. The ‘evidence’ for these answers lies in the literature that I have studied, combined with the conversations that I have had with professionals over the years, and my experience in the field. I will try to keep these answers short and to the point – and welcome further debate about them. Drop me a note if you want to share your perspective.
The ‘data = IT’ myth
It seems that many people think that data is an ‘IT thing’. After all, data lives in our systems and we certainly pay our IT staff enough, so how hard can it be to manage data as an asset? This mindset is wrong. First, not all data is digital/ in our systems. Second, data drives/ is strongly linked to our processes/ is so crucial for value creation that handling data must be a business responsibility. The effect of this line of thinking – if not managed well – is a continuous battle between business and IT professionals playing a ‘blame game’ for poor data. This is the opposite of a productive discussion about how to leverage our data.
The ‘we have systems for that’ myth
Another argument that I often hear goes like this: we have invested a ton of money in data quality tooling, data integration tooling, self-service business intelligence tooling – so data must be managed well, right? That’s what these systems do, right? Wrong! It’s all about the people. Everyone in the organization handles data. Not training them to do this well (and manage the data effectively) and relying solely on fancy systems to do the work is not a sustainable strategy. Systems help, but ultimately it is about the people in your organization.
The silo culture (or: it the ‘is not my responsibility’ myth)
This may be the biggest issue that I have encountered in my consultancy assignments. In many cases, we see a culture where everyone works (hard) to manage things well within their own silo. My process, my systems, my data. This does not account for the fact that data does not stay within a single silo. Data about our customers, products, services, suppliers, financials etc. are used across the organization. This implies “horizontal thinking”: we should not only consider our own needs, but also talk with other stakeholders in the data value chain. The effect of this myth is that data value chains are often too complex, with too much manual interventions, and with checks and balances that are often duplicated.
Data touches everything (or: the ‘it is only a minor/ local problem’ myth)
When you start working on improving data quality (fit for purpose, available at the right moment with the right quality), the variables to manage is staggering. Take, for example, customer data. You will run into questions such as: does everyone have the same definition of customer, and if not – is there a good reason for deviations? Do we all need the same attributes about customers, and with the same quality (accuracy, frequency, etc.)? Which systems do we find this data in? And in which processes depend on this data? Can we find owners/responsible parties for the data, processes, and systems? Is there perhaps an architect who knows how the pieces of the puzzle fit together? The number of variables can be so big that it is hard to get a clear picture of the domain. In other words, it may be perceived as a wicked problem. The effect of this point is that professionals only try to solve the local problem (leading to the silo culture), or abandon the improvement initiative altogether.
These are my top four reasons why data management is so hard. There are probably more reasons. To tackle these challenges, I recommend the following:
- Understand that data management is a people thing. Motivate your team to think ‘horizontally’ and involve them in improvement initiatives.
- Combine top-down planning (develop a vision of what you want to achieve) with bottom-up experiments (try things out locally and scale them up if they prove successful).
- Make this a shared business and IT responsibility: involve professionals from both sides of the house.
- Try to get an understanding of the essential/ fundamental aspects of your organization. Work with your architecture team. Use the tools that are available (e.g. ArchiMate, DEMO).
- Use good practices and open standards such as DAMA’s DMBOK or from my book Data management: a gentle introduction.
- Don’t be impatient: these things take time
This article is part of a series. So far, I have discussed Why data management is easier than it seems (first post) and (in this post) Why data management is harder than it seems. In the last post, I will offer Tips to make a good start with data management in your organization. For questions and suggestions, please drop me a note.