Data Governance is the set of policies and procedures determining how data is created, changed, deleted, secured, hidden, and shared throughout an organization. Reasons you might implement data governance policies include rationalizing sharing of information, regulatory compliance, audit ability, and promoting a corporate culture of shared information and responsibility for data. Whether you know it or not, your organization already has plenty of ongoing data governance activities, usually informal and often detrimental to the organization as a whole.
Let’s say you’ve already made the case for enhanced data governance within your organization… what’s next? I’ve written a bit here about some practical steps you can take to implement a data governance policy in achievable tasks with clear outcomes and deliverables.
Data Governance organizational structures need to be defined such that they meet the needs of your organization, there is no “single-structure-fits-all” approach so don’t just copy your structure straight out a “Beginners Guide to Data Governance”! Some of our clients include the data governance activities in Data Quality or Master Data Management solutions while others will opt for a stand-alone governance program. Some key influencers in making the decision to “tie-in” with another project or not include:
- Size of the organization
- Complexity of data
- Complexity of manual operations and tasks related to data manipulation
- Existing data landscape
- Complexity of functional “silos” within the organization
- Regulatory compliance
The primary tasks of a data governance team are usually to support Business Intelligence initiatives with a secondary goal of supporting privacy/security/compliance goals.
We often propose the creation of “virtual” data governance teams operating at strategic or operational levels, and defined as follows:
Data Governance Council (DGC)
This is a group that makes high-level decisions and includes representatives from business operations, legal and technical areas. This group would typically be responsible for making strategic decisions and providing guidance on matters such as who should have access to what types of data and at what permissions level (Create, Read, Update, Delete), and how joint responsibilities across groups dealing with the same data should be handled (which decisions take priority, etc.).
Data Governance Office (DGO)
This is a team who manages communications between the DGC and data stakeholders. These are often composed of business-unit/regional managers of data stakeholders.
Data Stewards (DS)
These are the resources that carry out the work of data governance. In situations where automated systems are unable to cleanse, merge, or perform other defined operations on data, the matters are raised to the relevant DS as defined by the DGC. The DS will also have responsibilities in the early phases of an MDM project around defining data quality and business rules to repair and enhance existing data.
Data Stakeholders
Not formally part of the data governance team, a data stakeholder is any individual that could affect or be affected by the data under discussion. We usually define this group as anybody who could be impacted by a change in data. It is the responsibility of the DGC and DS teams to ensure that the governance procedures put in place would not negatively impact users or the organization.
Often none of these roles is “full-time,” in fact, it’s usually beneficial for those involved to be deeply immersed in the business, familiar with the corporate culture and the existing methods of data management. After a successful Data Governance project defining the rules, workflows, and to-be processes, the overall workload will be decreased and the utility of the data to the organization improved. It should be kept in mind that there is already some data governance in place, it is often just ill-defined, leading to confusion and wasted time. Our goal is to eliminate this waste as well as vest responsibility for the vital information within the organization rather than nowhere.
One of my typical engagements would last from 20-30 days and look something like this:
- Analyze the “as-is” data governance framework – it is noted that it is not formally defined, but one does exist in the current common practices of the organization. This task would take a look at all existing business applications and determine which business units, key users, customers, or other organizations are able to read, create, change, or delete data in these applications. This exercise will provide great insight into who are best suited to be data owners, stewards, and consumers; the results are often surprising.
- Define a broad Data Governance “to-be” framework that indicates where various data governance responsibilities should be held, and who throughout the organization or outside of it should be able to read, change, and delete data.
- Gap analysis to determine where data is used in unexpected, insecure, incorrect, or improper ways.
- Further gap analysis to determine where users are forced to complete redundant data-related tasks that can be easily automated.
- Broadly define a data lifecycle for various types of data throughout the organization.
- Interview heads of business units, “power users” of business applications, reviews of our suggestions with the consumers and producers of data, and some discussions with IT (limited in scope to the impact of business users actions on actual data) as well as source system data analysis (correlation, duplication, and more…).
- Detail some of the benefits that might arise from the implementation of data governance and how these efforts can be leveraged to increase operating margins, increase customer penetration, and eliminate redundant tasks. This is usually done formally as an ROI analysis, we find the best analysis uses an EVA (Economic Value-Added) approach.