Although an enterprise data governance office and organisation is desired, this may not be practical during the early stages of implementing the capability,
Early efforts may be driven from a project perspective (e.g. BCBS 239 or Customer Experience) or may be driven by one business area that sees value in the absence of broader, enterprise buy in.
In the longer term, these initial areas may form the core of the enterprise data governance structure.,or may form sub-committees or working groups inside the enterprise structure.
In my experience, there are three commonly overlooked areas or communities that may have substantial value to contribute to the enterprise program.
1 Human Resources governance community
HR data (simplistically employee and payroll) is a good candidate for governance
HR data is sensitive (personal identifiers and salary information is typically not shared), must be in compliance with privacy, tax and employment regulations (as a minimum), and errors result in incorrect payroll payments – which may lead in turn to unhappy staff, legal or union issues, and the financial impact of dealing with incorrect payments.
Yet, as HR is typically seen as a supporting function HR data governance may be overlooked. Have you considered your HR team as a community in your data governance structure
2 Information technology governance community
Whether one believes that IT should lead data governance initiatives or not, IT is a data governance community in its own right.
IT is typically responsible for the physical delivery of most data management implementations and must maintain and govern technical data assets such as systems, data dictionaries and data models.
IT also have their own business terms, policies and standards that they must govern, independent of the lines of business.
How are you accommodating IT in your data governance structures?
3. Reference data governance Community
Last, but definitely not least, the reference data community must be considered
In too many organisations, reference data is maintained by (junior) IT staff, who take responsibility for adding codes to reference data tables largely without business input or sign off.
Of course, some level of reference data governance can be delegated to lines of business. For example, if the Accounts team need to add new gGeneral Ledger (GL) codes to accommodate a new class of payment, then this can be governed by the Finance community
Most reference data, however, has a shared impact.
New country codes, or mapping and aggregation of country codes across systems, for example, needs input from stakeholders accross various lines of business and projects. There is a case to be made to hose reference data governance in its own community or special interest group.
What other communities are frequently over looked by the data governance organisation?