This article is all about operational data governance. If you haven’t read Bob Seiner’s original article on what it means to govern data, you may want to do so here.
I am the first to agree that documentation is really tedious and I make my livelihood based on helping companies manage the knowledge around governance. But without getting governance consistently documented, you simply never know what you know and what you don’t.
As my then tween-age niece once said – “If you don’t know that you don’t know, then how do you know?” She was talking about eighth grade algebra at the time, but the same applies to data governance.
What do the data documentation corollaries to Bob’s points look like?
Let’s start with his definition and in the context of this article, apply it to your Master Data Standards:
The Definition of “Govern”
[to] gov·ern [data]
gov·erned, gov·ern·ing, gov·erns
- [To] make and administer the public policy and affairs [of data]
- [To] exercise sovereign authority [in data]
- [To] control the speed or magnitude [of data]
- [To] regulate [data]
- [To] control the actions or behavior [of data]
- [To] keep under control [data];to restrain [data]
- [To] exercise a deciding or determining influence [on data]
- [To] exercise political authority [over data]
– FreeDictionary.com [wrapper by Bob Seiner]
In Bob’s article, he does a great job expanding these concepts and applying them to governing data. I’ll now use his format to help operationalize it in the context of standards documentation.
Companies document data standards for three reasons:
- To provide a legacy of knowledge about decisions made regarding data so that when personnel change, the knowledge has a consistent “foundation” that is accessible to all employees from a single source. Relearning past data decisions is much more expensive than managing the knowledge. Forgetting costs money.
- More importantly, the mere act of documenting the knowledge in a complete and organized manner forces the exposure of gaps in knowledge regarding the who, what, when, where, how, and more importantly the “why and because” parts of the data standards.
- Finally, and to Bob’s point, if policy and standards are not documented and agreed to, then they cannot be used as a governance lever. If you cannot define quality data in a standard, then you have no chance for being able to manage the (non-existent) standard. Controls and business rules are derived from standards, not the other way around.
Bob’s definition points are:
For Point 1. To Make and Administer the Public Policy and Affairs of Data
- The Data Standard corollary is: if something is not documented and agreed to then you cannot govern to the policy (or data standard at the more granular level).
For 2. To Exercise Sovereign Authority of Data
- The Data Standard corollary is: it must be clear (and therefore documented in a fully transparent way) who “owns” what in order to be able to rapidly and effectively respond to a “disturbance in the force” (of data). The department or department leader who owns the standard should rarely be involved when there is a data accuracy problem as they are generally not in the data food chain on a daily basis. A good example is the field in SAP that points the value of the inventory correctly to the balance sheet. The standard for Valuation Class is owned by corporate finance as they produce the balance sheet, but they never touch the data in the material master. The value may be entered into SAP by an MRP controller setting up a campaign of new materials, but if there are errors found in subsequent data quality checks, then it is often the cost accounting team (the data accuracy owner) that resolves them before closing. Knowing who does what and getting it documented is the job of the data steward with accountability for the standard. Data stewards cannot know everything about every field, nor can they be accountable for fixing everything versus the standard (in the above example) cost accounting would rarely allow that anyway. The steward must make sure that the ownership IS clear, documented. and agreed-to in order to prevent chaos at one extreme and a totally bogged down, unagile bureaucracy at the other.
For 3. To Control the Speed or Magnitude of Data
- The Data Standard corollary is: there must be documented agreement regarding data share-ability that all can see and be held accountable to regarding data sensitivity and redundancy. The current discussions on GDPR (General Data Protection Regulation) are making it clear that there are fields that are security critical that were never seen that way before. If you don’t tell people in the same way and same place you communicate ownership, field level strategy, maintenance process, et al., then there is little chance they will keep it straight when they are designing new data processes etc. two or three years after they deleted your GDPR e-mail(s).
The next three go together:
For 4. To Regulate Data
For 5. To Control the Actions or Behavior of Data
For 6. To Keep Under Control and to Restrain Data
- The Data Standard corollary #1 is: Both regulatory and business requirements for data must be turned into actionable standards where the “correct data entry” is unambiguous and includes appropriate detail regarding the background so that the standard is more than just “always place “2” into this field”. “Why and because” are important to have a common appreciation.
- The Data Standard corollary #2 is: Documentation of consequences are important for standards. What happens downstream if this data is entered incorrectly? Having a common understanding of key downstream uses of data is important recognize, since ignorance of bad data ramifications is no excuse. Ensure everyone has a reason to care.
- Data Standard corollary #3: If you clearly communicate how to know what the right data looks like, what happens when its wrong and why it is important, people and process development will conspire for higher quality data. Governance starts with everyone agreeing to sing from the same songbook.
For 7. To Exercise a Deciding or Determining Influence of Data
- Data Standard corollary: Not all data is created equal but no one has the breadth of experience or vision to ever know the organizational scope for every field. Documenting in the standard data that has a global strategy or where the standards have local geography, business unit, or subtype variations (finished good vs raw material vs maintenance item) is critical for both operations and process development, as well as for the development for data quality controls.
For 8. To Exercise Political Authority of Data
- Data Standard corollary: Organize your standard so that your data ownership is clear so that the right people are involved in decision making at the right level and at the right time every time. This, most importantly, includes the process for changing the standard itself.
The implications of all the above are:
- If your knowledge of how and why your data is governed (managed, queried, used, and owned…) is not documented where all can see and understand, you are not governing your data.
- Governance is alive and so must be your processes for keeping the communication for changes and enrichments to standards. Indeed, your standards must be more strongly governed than your data itself. Keeping this knowledge as structured as possible and in one place makes keeping up with it far easier both from a maintenance and a user confidence point of view.
So, there you have it, my take on Bob’s expanded definition for governing data re-expanded from a data standards point of view. I would like to invite someone to do the same from a data quality, process, or data architecture or some other point of view as any subtopic of data should also map and expand with the eight definitions / dimensions above.
