Rigorous design of data governance sounds like it could be pretty time consuming for some people. So in order to get funding or just the authorization to spend the time on this, should people head straight for the top and convince executives to give them a blank check and a big stick to solve the problem or? It goes back to the fact that for date governance, there really aren’t standard best practices. The answer really does depend on how the company’s decision making processes look.
For instance, we’re working right now with a large financial services firm, and the C level executives there have a lot of control, and the company can turn on a dime based on executive edict. So the CEO says, you know what, we’re going to become more customer focused, and everybody changes the way they do things. A company like that would probably be better at adopting a top down approach to data governance. That starts with a small steering committee that has enough authority to make things happen.
And I compare that with a high tech company that we’re working with, that almost practices anarchy when it comes to decision making. Whenever there’s a problem, somebody just fixes it themselves. So there a grass roots effort might make more sense than imposing executive edicts around governance.
So to answer the question about best practices for data governance, it really all does come back to what current decision making practices look like and how the company’s culture supports them.
|#1 Ranking: Read how InetSoft was rated #1 for user adoption in G2's user survey-based index
How to proceed with the data governance project? Start with the need, pain or problem that needs solving. And we’re working with a mortgage lender right now who just can’t see the different relationships it has with the same individual. And that’s a huge issue, not only for customer data integration but for data governance. The business impact is huge. This inability to actually recognize an individual customer results in things like duplicate mailings, redundant conversations and frankly, using silly sales pitches that have really embarrassed the company.
You start doing data governance by defining the elements that need to be in the customer’s master record. These need to be shared across systems. What does that looks like? Make sure that the definitions are clear. What constitutes customer value? What are the components of that? Is profitability a component of that? Is revenue a component of that? Is return on marketing investment a component of that?
You can see the policy making and decision rights entrenched in these issues. Does the term revenue mean booked revenue or billed revenue? Just as important, make sure that those policies are realized in the new systems and processes that are being deployed. So where somebody starts depends on a real business need, not the convening a committee for what really results in an intellectual exercise around the importance of data.
Practically speaking, who is doing all this? How are successful data governance programs are structured? Who is on the team? What kind of skill sets? Can data governance be a part time job?
We’re seeing the evolution of the structure of data governance. And so, so we’re seeing a formal committee initially created. Once data governance has been designed, and the barriers have been taken away, that committee is the general committee that begins data governance and begins the policy making. Clearly that committee is comprised of IT and business people who are working together to come up with those policies and more importantly, to determine who has the authority to make those policies. And deciding who has the authority to execute those policies.
But over time what we’re finding is as that process, that decision right process matures, that the emergence of what we call date governance regimes takes hold, because at the end of the day, a human resources person doesn’t necessarily need to be involved in a governance meeting around customer profitability policies, or privacy policies. And so what we’re finding is that over time as governance matures and the vocabulary of governance pervades the organization, the concept of these regimes, which are smaller units of decision making authority for specific data subject areas, or for specific business processes, there is sort of a, a deconstruction of this high level team into smaller faster decision making regimes.
That has worked very well because it allows people to control what is controllable and what they’ve got domain over while informing other people about those policies and decision as they move forward. So it actually works very well. We don’t recommend starting there, but as governance matures, this model of regimes work very well.
What are the deliverables or the resources that a data governance team might actually develop and maintain? What do they actually produce?
It’s interesting because when we go out to clients who are interested in starting data governance, one of the first questions we ask them is, let’s paint the scenario of a working data governance framework umm, and then ask what’s your ability to execute on that? And that’s the million dollar question, because what we find is there should be a closed loop and not a lot of people understand this. There needs to be a closed loop between data governance, which is again, the policy making and decision rights around corporate data and date management, which is the execution of those policies.