【译文】数据管理和数据治理104：数据治理中的“阴”力
在我们关于数据管理和数据治理的故事中，我们继续讨论数据治理概念。数据治理通过遵循数据管理的原则来发挥其“阴”力作用。以下两个陈述表达了数据管理和数据治理之间的阴阳二元性的观点：
1. 首先，要继续执行数据管理/数据治理计划，每个公司必须明确数据管理的定义、范围和组成部分（如本系列第一篇文章中所述）。
2. 数据治理框架必须符合数据管理规范（如本系列第二篇文章中所述）
本文基于第二点继续阐述。
在详细阐述之前，我想再次声明一下我在本系列第三篇文章中讨论的数据管理规范：
数据管理是一种业务能力。
它的主要目标之一是控制数据和信息资源。
数据管理可以从狭义或广义的角度来看待，这取决于它与IT功能的关系。
“狭义”是指从数据管理专业人员要完成的任务的角度来看待数据管理的视角。“广义”是从企业的角度来看待数据管理，即数据和信息资产的生命周期。
数据管理能力的关键组成部分取决于选择的视角。
“狭义”视角将数据管理框架（数据治理）、数据质量、数据建模和体系结构以及部分应用程序体系结构视为数据管理子功能。从“广义”的角度来看，添加了业务、应用程序、技术体系结构、信息技术和安全性等子功能。
数据管理为不同的利益相关者群体提供价值主张。
数据和信息价值链提供了价值。为了做到这一点，应有支持数据和信息价值链的一组数据管理子功能。
数据管理的功能提供数据管理能力。
本文为正在启动数据治理倡议或计划来（重新）评估当前状态的公司提供了实用建议。它展示了关于数据治理公司应该做出的决策。决策的编号代表决策的顺序。
决策1. 数据治理是数据管理的一个子功能。
首先，让我们具体说明什么是业务能力。根据开放组织的说法：“业务能力是指企业为实现特定目的或结果而拥有或交换的一种特殊能力”。在这方面，数据治理也是一种业务能力。数据治理是数据管理的组成部分或子功能之一。数据治理的目的是：
1.建立数据管理框架。
2.协调运作和有效的数据管理。
决策2.数据管理框架包含两个关键组件：规则和角色。
在我的理解中，框架是数据管理操作的一种有机结构。为了正常运作，这个结构需要两个关键组成部分：规则和角色。规则和角色集应与上述数据管理功能的规范相匹配。
决策3.数据管理规则集取决于业务级别
则规规定了做事的方式。有多种类型的规则适用于数据管理操作。这取决于企业的组织级别：战略、战术、操作。规则的示例如图1所示。
图1. 不同业务级别的规则示例
战略层面 STRATEGIC LEVEL
在战略层面上有三个数据管理规则。
数据（管理）原则是构建数据（管理）能力的关键基础。原则规定：
· 公司为什么需要数据（管理）
· 公司将获得什么利益
· 公司将如何获得这些利益。
数据（管理）战略应：
· 开发数据管理能力的中长期业务驱动因素
· 定义范围和数据管理子功能
· 与业务目标保持一致
· 概述每个数据管理子能力的结构以及协调其活动的机制
· 衡量成熟度的方法。
数据管理路线图应详细说明实施数据（管理）战略的中长期计划和可交付成果。路线图应该专注于达到期望的成熟度水平。
数据（管理）战略的范围包括总体数据管理能力及其子能力。
数据治理应协调将每个子能力的战略计划集成到总体数据管理战略中。
战术层面 TACTICAL LEVEL
在战术层面上，每个数据管理子能力都应该以制度和标准的形式制定自己的规则。
例如，对于数据质量、企业体系结构和安全性，公司将有单独的制度、标准和流程。
根据Businessdictionary.com定义，制度是由组织的管理机构制定和实施的一套基本原则和相关指导方针，用于指导和约束组织为实现长期目标而采取的行动。制度通常定义特定数据管理子功能的操作规则。
标准（standard ）规定了质量水平或规范。例如数据标准，它规定了描述数据的规则。
流程（process ）记录了为实现结果而采取的一系列行动。
路线图应转化为一份中期计划，如年度计划。
应规定与数据管理相关的角色、职责和任务。
战术层面的数据治理应侧重于：
1. 一套标准的文件编制方法。
例如，您应该期望策略和流程以相同或类似的格式编写。
2. 协调不同子能力的活动。
通常，一个子能力的活动和可交付成果与另一个子能力具有相互依赖性。数据治理应该有助于正式的协调。例如，执行数据质量任务需要数据架构师的可交付成果。
3. 调整不同数据管理子功能提供的文档。
每个数据管理子功能都将开发其管理流程。数据治理应该负责检查这些流程的一致性。
操作层面 OPERATIONAL LEVEL
在操作层面上，流程被细化为操作步骤。数据管理角色要求应以职能岗位描述的形式明确。
数据治理应侧重于审核和控制制度、标准和流程的实施结果。
我想强调的是，每家公司都应该制定实施和执行可行的规则。它们应该与公司规模、需求、资源和数据管理的范围相匹配。
讨论了规则之后，我们继续讨论如何开发一组可行且易于实现的数据管理/治理角色。每次我读到一些关于数据管理/治理角色和机构的文章时，我都会有一种复杂的情绪：困惑、诧异、好奇……我已经找到出产生这些情绪的三个关键原因：
1. 角色数量
曾经，我统计了DAMA-DMBOK版本中提到的数据管理功能、角色和主体。你能猜出有多少吗？120!!!!
2. 角色一词被同时用在多个语境中
为了证明我的观点，让我们考虑一下DAMA-DMBOK第一版、第二版和DAMA字典中列出的管理专员（stewards）或类似角色：
· 数据管理专员
· 数据管理专员（data custodian）
· 首席数据管理员
· 业务数据管理专员
· 协调数据管理专员
· 执行数据管理专员
· 数据管理职责协调员（data stewardship facilitator）
· 技术数据管理专员
· 领域专家
正如你所看到的，一个“管理专员”的角色同时出现在不同的语境中，混淆在一起。这些语境包括：
· 组织层级的不同层次
· 专业领域
· 要执行的任务。
这种复杂的表达产生了一些难以察觉的角色。此外，很难明确各个角色职责、角色区分，并将其付诸实施，在工作人员中提高认识。
3. 忽略了数据和信息价值链的动态特性
数据从其来源流向其目的地。有几个类似的概念描述这一运动过程：“数据生命周期”、“数据血缘”、“数据流”、“数据和信息价值链”。
让我们回到“数据管理专员”角色的例子。数据管理专员有不同的任务，这取决于他们在这个链中的位置。但这是你很难在角色列表中看到的。
DAMA-DMBOK发明了一种解决方案，通过创建额外的角色来解决这个问题：“数据创建者”、“数据生产者”、“数据所有者”、“数据消费者”、“数据用户”。
我通过引用定义链来说明下DAMA-DMBOK解决方案：
领域专家是“对某一特定功能主题具有丰富经验和知识的人”。
数据管理专员是“负责与数据管理相关的任务的业务主管和/或主题专家”。该角色的任务列表太长，无法完整引用。不幸的是新的第二版DAMA-DMBOK甚至没有一个“数据管理专员”岗位的明确定义，只有“管理职责（stewardship）”。
数据所有者是“业务数据管理员，对其域内的数据决策具有批准权限的人”。
因此，数据所有者是数据管理专员，同时也是主题专家。所有这些角色都被DAMA-DMBOK视为独立的角色。这意味着这三个角色可以同时分配给一个员工。
我是一个数据管理领域工作了10年的从业人员。我每天都和很多业务人员交流。假设，明天，我会接近我的一个同事说：“嗨，约翰，恭喜你！在我们新的数据治理结构中，您将得到几个角色。您是领域专家、业务执行数据管理专员、一个数据链中的数据所有者和另一个数据链中的数据用户。你现在有很多额外的责任和任务。请阅读几个描述这些角色的岗位说明，“我要继续吗，或者你自己能猜到约翰的反应吗？
对我来说，角色有两个简单的要求：
清晰：每个角色的责任可以用几行文字清晰说明
明确：每个角色需要有一个明确独特的责任清单。
那么如何才能做到这一点呢？
决策1.角色应对应于业务能力维度
让我们回到业务能力的概念上来。“业务能力是企业为实现特定目的或结果而拥有或交换的一种特殊能力。”业务能力由几个维度组成。Open Group将这些维度定义为：“角色、流程、信息和工具的组合实现了业务能力”。在图1中，您可以看到业务能力维度图。
图1 数据管理能力结构
角色描述了在商业运作中的参与人员。角色以业务单元、职能工作等形式描述。
流程是指不同抽象层次上的业务流程。
数据“表示业务能力所需或消耗的业务信息和知识”。
工具“包括信息技术系统和应用程序；物理或有形资产[……]、无形资产”。
这样的数据管理能力模型对于实现数据管理能力是一个很好的工具。因为它允许沿每个维度指定功能的不同组件，并从不同维度链接到角色。
让我们分两步将该模型应用于管理/治理角色。
1. 指定每个维度的角色
图2：具有相应角色的数据管理能力模型
让我们看看每种能力的维度和相应的角色
“流程”维度：业务流程所有者的角色与此维度完全匹配。角色的核心责任是管理过程绩效。
“系统”维度：系统或应用程序所有者的角色立即浮现在脑海中。关键责任集中在维护和管理任何信息系统的生命周期上。
“角色”维度：组织结构就是这个维度最好的例子。然后可以贴上“首席”、“执行”、“协调”等标签。
“数据”维度：这个维度可以包括两组角色。第一组由任务类型定义：“领域专家（SME）与数据管理专业人员”。领域专家是专业人士，他们是各自领域的专家，与核心专业任务一起执行数据管理任务。例如，财务总监是财务数据定义方面的专家。他们将参与数据管理活动，与数据建模师（数据管理专业人员）分享他们的专家知识。第二组“数据所有者vs数据用户”展示了数据和信息价值链对角色结构的影响。
在深入研究数据和信息价值链这一复杂主题之前，让我们先将属于不同维度的角色联系起来。
2. 从不同维度链接角色
再次说明下，我将用这个例子列出管理专员的不同角色。结果如图3所示。
一旦指定了数据管理专员的角色，就可以将其链接到组织层次结构中的不同角色。
层次结构中的这些角色也可以链接到其他维度。例如，对于“系统所有者”角色，可以添加标签，如“主管”、“执行官”等。。
用这种方法的使用可以简化地创建一组清晰明确角色的。
图3.从不同维度链接角色的例子
现在让我们看看数据和信息价值链对角色设计的影响。
决策2. 遵循数据和信息价值链的设计角色
“数据和信息价值链是由数据管理能力合力支持的一系列行动，这些能力能够将原始数据转化为有意义的信息，从而向利益相关者群体提供相应的价值主张”。“数据所有者”和“数据用户”的角色表明了不同观点的利益相关者（SME）在数据转换过程中对数据的关注和行动。这些角色的定义有一个很大的挑战。让我们看看图4。数据在一组应用程序中流动，并在途中发生变化。不同的操作（如计算、聚合、重新格式化、筛选）会创建新的数据和信息。我想到几个问题：
· 有此转换路径上谁拥有哪些数据？
· 如果数据用户使用数据进行进一步的计算，他们是否成为新数据所有者？
· ......
图4. 数据所有者和数据用户在数据转换路径上的角色
答案不是很直截了当。“数据所有者”的定义还没有给出答案。
在DAMA数据字典中，数据所有者被定义为“在其职责范围内负责数据定义、制度和实践决策的个人”。
在DAMA-DMBOK的第二版中，数据所有者是“业务数据管理专员，对其领域内的数据决策具有批准权限”。
不幸的是，没有人解释“责任范围”或“领域”的含义。我在罗伯特塞纳的一篇文章中看到了一些关于领域的解释。据他说，定义领域有三种选择：按主题领域、一级和二级数据资源以及按组织单位。然而，这两种选择都没有解决这个难题。
让我们举两个不同的数据实体示例：国家代码和特定客户的收入。两个数据实体都属于“客户”主题域。一个国家代码实体在数据转换过程中几乎不会发生变化。因此，可以立即为帐户管理功能分配“数据所有者”。收入（revenue）较为复杂，收入是根据发票上的信息计算出来的。后来，收入确认和汇率的会计原则在数据转换过程中得到了应用。这个新创建的数据的所有者是谁：仍然是帐户管理的数据所有者，还是数据有了新的所有者-财务部门？
在实践中，我看到了两种不同的解决方案。
解决方案1 此解决方案基于数据建模实践。在我们的收入例子中，收入是属于“客户”主题域的数据实体，这意味着账户管理的数据所有者被指定为客户收入数字的数据所有者。显然，有关财务部门作为转型规则“所有者”角色的问题随后出现了。此解决方案更适用于应用程序或数据转换点的数量达到几十个或几百个的大型组织。
解决方案2 第二种解决方案基于新数据创建原则。这意味着在创建新数据时，会分配一个新的数据所有者。在我们的案例中，财务部门将成为新的数据所有者。这种解决方案对在数据和信息价值链上只有几个数据转换点的中小型公司更为可行。
您可能已经注意到，在本次讨论中，我没有考虑数据管理专员的角色。在实践中，我尽量避免使用管理专员的角色。在我看来，领域专家与“数据所有者”和“数据用户”角色以及来自组织层级的角色相结合，足以分配职责。那些仍然对数据管理专员角色感兴趣的人，请注意，他们必须是数据所有者和数据用户之一。
在设计一组角色时，您所能做的最好的工作就是使其尽可能简单，以确保其在实现中的清晰性和可行性。
对于那些有兴趣“做好准备”建立角色集的中型公司，请参阅我的《数据管理工具kit》一书。
在本系列的第五篇也是最后一篇文章中，我们将概述逐步实现统一数据管理/数据治理能力体系的方法。