Building a data catalog is not a goal in itself. Before you start, you need to be able to answer a few questions: why build it? How will it support our data strategy and objectives? What benefits will users get? Why this solution rather than another? How will it last?
Building a use case is an essential step of any data mapping approach, yet it is often underestimated.
Data governance deals with abstractions (data as an asset), so, like marketing or finance, its tangible results are hard to see. A chief executive will usually accept the need for marketing or a finance function without a detailed, quantified justification sitting in a file somewhere. Governance rarely gets the same benefit of the doubt, which is why a clear use case matters.
What brings value?
There are broadly two kinds of governance projects:
- Defensive projects: minimize risk, comply with regulations, detect fraud.
- Offensive projects: improve revenue and profitability, support the creation of new services, improve customer knowledge.
Defensive projects are easy to "market": there is a stick (GDPR, for example) and a risk in not complying. Offensive projects, the carrot projects, come less naturally, and you must show how governance is an interesting lever for them.
Indirect gains are easier to argue. For example:
- How do you monetize data whose quality isn't assured?
- How do you improve the efficiency of your teams when much of their time goes to cleaning data? The cost of poor quality is well documented in the consulting literature on data governance.
Direct gains are much harder to demonstrate: how do you prove that good data management practices will improve business drivers?
Two complementary approaches help demonstrate value creation:
- Analyze the organization's strategy and identify the areas where data governance would be most profitable.
- Talk with managers to identify their needs and the limits they run into with data.
How do you match use cases to your maturity?
The second essential element is the maturity of the organization: each maturity level corresponds to different use cases.
Take a simple example, a GDPR compliance approach. The goal is the same: master the personal data your organization handles. But a highly mature organization may already be managing the exchange of sensitive data between systems, while a low-maturity organization is still taking its inventory of personal data.
Not all organizations have the same level of data management maturity, so you need to assess yours. Maturity matrices help you to:
- make your approach factual;
- identify improvement axes more easily;
- compare organizations facing the same needs and constraints.