先交代下基调：不深奥，像是读后感，也是知识总结，仅代表个人见解，话术直白，并未到达领域高度。
全文大约7000+字，阅读时长（能耐着性子看完的话）要看你平时看7000字需要多久了。
真正接触数据咨询的时间并不长，也是从项目开始，学了皮毛并自我感觉良好，但实则浅薄的都有些透亮，期间有过盲目自信。
后来有幸接触了更高阶的咨询内容并能或多或少从小白的角度有了些许认知，经历过自我否定、自我重建，痛苦挣扎，失眠烦躁。
但感谢有机会站在了巨人的肩膀，在不断的认知、总结过程中收货颇丰。
邓宁-克鲁格心里效应，我想我已经逐步接触开悟之道了（又盲目自信）。
先分析“本质”，再逐项拆解。
言归正传。
首先明确什么是数据
数据：“数据是指企业在各项经营管理活动中发生的客观事实经过获取、保存并以一定形式表达的结果”。数据的形式包括但不限于数字、文本、图形、图像、音频和视频等。可以是结构化的，也可以是非结构化的。在企业中也可以一刀切分为业务数据和元数据，相应的管理策略也是不一样的。在后面可能会说明（因为我也不知道我能不能说明白，试试看吧）。
像生物一样，其实数据也是有生命的，同样要经历从无到有，存储使用，再到消亡的过程。也就是数据的生命周期。
再聊聊“管控”和“治理”，我觉得这两个词是有本质区别的，虽然很多时候我们在聊项目的时候，谈“数据管控咨询”、“数据治理咨询”都一笔带过，好像做的事情是一样的，可能不同场景，但在我看来区别不大。
“管控”：拆解开来，有“管理”、“控制”的意思。所以“数据管控”的本质我理解是事前，在企业数据的战略规划阶段就应该明确。
如果从数据的生命周期角度分析，在数据产生之前，就应该明确相应的管控策略。像是建设图书馆大楼的图纸，在整体施工之前。
“治理”：同样拆解开来，有先“治”再“理”的意思。
“治”在百度词条上的解释是
从细小之处进行整治、修理，结合“理”的概念，我理解应该是：“整治、修理之后再进行管理，或者整治、修理的同时伴随着相应的管理策略”。
所以“数据治理”的本质应该是事后。围绕着数据生命周期的角度分析，有在数据产生之后，发现问题制定解决策略的意思。像是修建了图书馆之后，发现地板坏了，需要整修。在修理地板的同时，要管理地板成本、修理位置、时间计划、维护保养策略，人工等等。
所以本质上，前者注重设计、规划的管理，后者注重整治、解决实际问题再回溯整体的管理策略。
方法论支撑上可能区别不大，但是宏观角度和愿景上还是有区别的。
介于实际企业开展这方面工作还是建立在有实际痛点、诉求的角度，要解决实际的问题，所以下文更侧重于“治理”。
好了说了很多，明确了“数据”的概念，“管控”、“治理”的区别，再结合起来看看实际的策略。
业内的方法论体系有很多，其中主流有DAMA (国际数据管理协会) 、ISACA (国际信息系统审计和控制协会)、DGI(国际数据治理研究所)、IBM 数据治理委员会和Gartner 公司等权威机构所代表的。
我所接触最多的或者我所触及的项目应用比较多的还是DAMA的理论基础。
一张熟知的图概述如下：
涉及八大领域，通过一系列保障机制，来规范各领域的内容，通过不同核心领域，来保证规范、制度、流程的贯彻落地。
但是说实话，直观看来感觉这些内容好像大家都知道，但就是不接地气。不知道怎么结合实际解决问题。
时常听到很多声音：“治理谈及的管理办法、制度，很容易写，但都是高屋建瓴的，怎么落地呢？”、“我有痛点、有规划、有愿景，也有政策上的强约束，但怎么能让我看到成效？”
这其实是很多客户、有诉求的参与者共同的问题。
八大领域很清晰，但其实他们之间并不是排他关系，而是互有穿插。
先确定“主线”，来看看怎么把这些内容说清。
既然是“数据”的治理，所以我们就围绕数据的生命周期，看看怎么在数据从无到有，最后消亡的整个过程中结合这几大领域，通过管控制度、流程去约束。
那数据是怎么产生的？
企业信息化建设过程中，为了业务的发展，更好的决策分析、更好的管理监控，应运而生了相应的IT系统，这些系统就带着业务的诉求越建越大，越建越多。业务开展过程中产生了不同业务场景下的各种数据。这部分数据我们可以理解为自有数据。
当我们拿着自有数据进行业务分析的过程中，按照业务场景进行了加工、汇总、转换等等操作，应运而成了加工后的数据。这部分数据我们可以理解为衍生数据。
后来在使用的过程中发现这些数据不能实现我的目的，那怎么办？恰好在企业外部公开市场或者其他渠道有这部分数据，所以就发起了采购，通过合法途径进行获取，拿过来关联我自有数据进行分析决策。这部分数据我们可以理解为外部数据。
从数据来源的角度就把数据分为三类：“内部自有数据”、“衍生数据”、“外部辅助数据”。
这里我们会发现，业务系统中产生的自有数据，和外部采购的数据，在本质上是不同的，内部自有数据为了支撑业务的开展，没了它业务可能做不下去了，而外部数据是为了辅助内部自有数据进行分析决策，没有它，我可以用其他数据替代，我关心的是数据的实际质量，能不能跟内部自有数据进行关联，它的关联性怎么样，同样的外部数据来自不同的厂商，哪一家性价比更高，供应商该怎么管理，数据内容能不能实现辅助分析、辅助应用的目的。
所以针对不同类型的数据有不同作用和定位，相应的管理标准、要求、原则策略也是不一样的。
那在数据产生之前，结合几大领域我们要怎么管控呢？
从宏观角度看，我们要规划好要建设哪些IT系统来支撑业务的开展；这些系统要通过哪些技术实现；要把数据合理、高效的利用起来，我们要怎么规划数据的层级关系。
带着这几部分诉求，我们可以在“数据架构管理”中找到相应内容。
数据架构管理，即：应用架构、技术架构、数据架构等。
在数据产生之前，结合企业现状、战略规划、技术前瞻性、行业发展趋势、政策法规约束等等，通过详细的调研、探讨，深入了解企业现状和战略诉求之后去规划架构体系。
要在各方面因素考虑充分的情况下，不断推演整个架构体系在未来不同时间阶段的合理性、高效性。
相应的在治理角度我们要通过管理制度、办法，去明确在企业中哪些角色要参与架构体系建设中，明确他们分工、工作流程、工作标准等等。
这部分的难点、重点：
先要能够准确摸清企业现有架构体系状况
能够站在行业高度，清晰的认识企业现有架构中可优化、待补充部分，并有清晰的分步实现思路。
能够准确把握或引导客户高级别参与者的战略思路，并与企业实际情况、行业趋势结合。
能够详细规划未来架构体系建设方案，数据架构、技术架构、应用架构。
这个领域属于更高阶的咨询范畴，我也只是粗浅的了解大概，在以后的不断学习过程中在不断总结、补充。
架构规划清楚了，也有制度约束了是不是数据就能产生了呢？
远呢
接下来就要按照相应的架构体系规划的内容分阶段去实现。
直观讲可能涉及要新建或改造IT系统了。
涉及的领域就多了。
首先IT系统建设的主要目的是实现业务诉求。
伴随着业务诉求会有相应的业务流程。
业务功能、业务流程的实现，就涉及数据模型管理了。
在软件工程的角度看，概念模型、逻辑模型、物理模型设计是很重要的阶段，直接影响了IT系统建设的合理性、高效性、准确性。
先从本质上看我们从模型的角度能获得什么？
有哪些实体，直观理解为“表”（Object）
实体间的关系（Relationship）
通过关系能看到数据会从哪些表产生，通过哪些环节流转到哪里去（Behavior）
我们能从系统的模型设计摸清具体的业务流程，反过来也可以从具体的业务流程梳理、数据验证，来重现数据模型体系。
同样需要管理策略、办法，来约束不同的模型的格式要求，相关人员的职责分工，新增、更新、使用等等的流程。
这部分的难点、重点：
模型的易读
模型更新及时、准确，能够与实际的IT系统保持同步。
模型设计的合理、可扩展。
从模型中我们能够很直观的看到：实体、实体间的关系、实体的行为，也就是业务流程。
穿插在模型中的数据都有哪些呢？除了内部、外部、衍生数据这种分类形势，我们还可以把业务数据分为：
主数据
参考数据，一般指标准代码表，多数情况与主数据共同讨论，作为主数据的参考信息。
关系数据
交易数据，这部分数据一旦产生几乎不会改变，有时间戳字段，述清了在什么时间点，做了哪些操作。
通过这些信息中就引入了下一个领域：主数据管理。
主数据是什么数据呢？
字面理解，重点在“主”上，要分清主次。
我们看在实际数据使用过程中，同样的数据分布在不同的系统中，比如“客户家庭地址”，不同系统中不一致，怎么办，用的时候取哪个？
在使用之前是不是需要把不同系统中的“客户家庭地址”都拿出来，分析以哪个为准，这个过程也是在甄别谁是“主”。
引出主数据的定义：可以在系统间共享的数据，与波动较大的交易数据相比，主数据变化缓慢，如：客户数据、产品数据、账户数据等。
交易数据可以通过关键字关联到主数据，形成对交易数据分析的主要维度信息。
主数据必须加以正确维护，才能保证系统的参照完整性。
在主数据使用过程中，不同业务系统，不同需求方对主数据的期望需求是不同，有些系统对数据的及时性要求比较高，有些系统要求并不高，可能一个月需要一个即可。
所以主数据需要满足针对不同服务的标准化要求，主要体现在以下几方面：
及时性
准确性
唯一性
全面性
主数据在直观上解决了在系统间共享的数据，取值不一致的问题。
但是如何保证主数据信息能够提供标准化服务，也是主数据管理的重点。
所以在主数据管理过程中我们要调研清楚：
1.谁是主？
2.谁来用？
3.什么服务？（要做什么？）
4.服务水平要求 （准确性、及时性、准确性、全量）
只有首先明确了这些内容之后，我们才能制定合理的管理策略，从而去分析发现实际问题中的根本原因制定解决方案。
这部分的难点、重点：
共享业务能力现状调研
明确主数据定义上的责任边界，在企业内部明确岗位职责、管理流程，保证核心主数据信息的一致性和共享。
合理的主数据分类
通过主数据的规划、明确主数据信息要提供的服务标准、责任归属以及相应的管理规范。
上文举例的“客户家庭地址”我们该怎么定义呢？相应的对客户信息还有“客户类型”、“客户名称”、“客户号码”等等，怎么约束“客户类型”的取值分为：“个人客户”、“公司客户”，怎么规定“客户号码”的编码规则呢？
就引入了下一个领域：数据标准管理
数据标准定义分为两个方面：基础数据标准和衍生数据标准
我们定义“客户编号”是在企业中客户的唯一标示，与对应的模型主题一致，划分在客户主题，应该是“12”位长的数字构成，每一位数字都有明确的含义， 它在“核心系统”的客户模块产生，在系统中是字符型存储，格式是varchar2(12)，明确这些规则并有维护、更新权利跟义务的部门在银行中是“运营部”。
这段话中我们定义了“客户编号”的业务属性（主题、名称、定义、规则）、技术属性（字段类型、长度）、管理属性（权威系统、权威部门），当然还有更详细的其他定义举例中没有列出，如：“制定依据”等
“客户编号”是业务系统中产生的基础信息项，所以我们在这段话中定义的也就是“基础数据标准”
“衍生数据标准”有些场景也被直接叫做“指标数据标准”在数据使用、加工的过程中，主要解决业务口径、业务规则标准化的问题。比如“资本充足率”的标准定义、计算口径、责任归属等等。同样需要定义清楚业务属性、技术属性、管理属性，并不断维护管理。
通过“基础数据标准”的定义去规范系统中基础信息。
让信息系统的建设实施过程能够通过参考“国家标准”、“监管标准”、“行业标准”结合公司现状更规范。 “基础数据标准”的主题划分与“主数据”的梳理相结合。
那是不是所有系统中的所有信息都需要通过标准的制定去规范呢？
可能涉及几十上百个系统，上万个字段。
纳入标准管辖范围的信息有哪些呢？
主要以下几种场景需要优先考虑通过标准约束：
1. 跨系统共享信息同名不同义；
2. 同义不同名
3. 代码标准化
4. 主数据核心信息项
以上并不是严格的范围约束，而是优先参考。
这几方面在后面数据使用过程中，也是会导致数据质量问题的几个主要原因。
说到这，围绕数据的生命周期，在数据产生之前，通过“主数据管理”、“数据标准管理”去规范、辅助系统信息化建设。
通过“数据模型”管理，辅助梳理主数据信息
通过“基础数据标准”，逐步规范“主数据”信息项的定义
通过“主数据管理”框架进一步明确“基础数据标准”管理框架。
三个领域相辅相成，可以单独管控，也可以一起探讨。
那在数据产生之后，同样需要不断的完善、补充三个领域，规范化系统建设的同时，提升数据质量。
出现了数据质量问题，引出了数据质量管理领域
引用老板对于质量问题的分析归纳，主要分为三类：
1. 水平协同
2. 垂直集成
3. 操作规范性
逐一解释
水平协同：
以银行为例，最开始的“钱庄”账房记账、管家打理，配几个伙计，就能做的风生水起。后来的银行从手工记账逐步建立了核心系统，承接了主要的存款业务，业务扩张核心系统中也要实现信贷业务、理财业务的功能，一个系统应接不暇，后来拆分出了独立的信贷系统、理财系统，但是不同的系统是不同的厂商设计、开发的，同样的信息在不同系统中的名称是不一致的，比如“客户性别”在核心系统中存为：1男2女0未知，但在信贷系统中存为：M男F女N未知，在关联使用或者筛选加工过程中转换不及时，数据就错了。
垂直继承：
还是以银行为例，在统计分析的场景中，分支机构在统计口径与总行不一致，在逐级汇总过程中发现数据存在偏差。归纳为在组织机构中同样的信息比如口径、代码、规则信息，没有达到上下统一，在相同应用场景中产生质量问题。
操作规范性：
这一点认为参与的主观性因素更大，主动或被动的造成了数据准确问题。
一般情况下，在我们遇到质量问题时，多数情况是具体问题具体分析，分析根本原因之后，制定解决方案，然后持续监控管理。
其实发现在解决问题沉淀方法论、工作流程的同时，也沉淀了复现此类问题的规则，质量检查规则不断积累、补充，成为规则库。逐步依赖规则库常态化批量监控数据质量问题。
回过头与数据标准管理结合，将系统信息项设计是否参考标准执行的检查规则补充进规则库，就可以将数据标准的落地检查也可以作为质量管理的一部分。
归纳下，数据质量管理的本质是解决并预防数据质量问题。主要管理内容如下：
1. 明确职责分工，一定要首先说好，发现质量问题谁负责、谁去更新规则库、谁负责日常检查、谁来配合工作。
2. 日常数据使用、批量规则库监控过程中发现数据质量问题。
3. 分析引起数据质量问题的根本原因。
4. 制定解决方案
5. 维护更新质量规则库
这部分的重点、难点
1. 数据质量管理贯穿数据生命周期的始终
2. 分析引起质量问题的根本原因，从根源上制定解决方案
3. 解决方案不断沉淀、积累，回溯系统建设、数据使用的合理性。
4. 解决和预防质量问题相关责任方的界定。
架构、模型清晰、系统建设标准、数据质量不断提升，我们对数据的使用越来越高频、高效，发现数据的价值也越来越大。
从最开始的BI分析，支持决策，逐步接入越来越严格的监管合规要求。不是所有的数据都可以对所有人开放，数据的产生、存储、使用、销毁过程中都要遵照保密要求。
带着直观的诉求进入下一个领域：数据安全管理
这部分我理解，本质上分三块内容：制定安全规则、执行和持续审计
如下图：
这部分的重点、难点：
1. 规则相对好制定，严格执行为重。
2. 贯穿数据整个生命周期的方方面面
3. 一旦出现问题就是大问题
4. 明确分工，精细化岗位、权限控制。
5. 严格审计
文中最开始，提了一句，“数据分为业务数据和元数据” 以上的管控内容基本都是围绕业务数据。
接下来详细探讨“元数据管理”
描述数据的数据，定义都清楚。但说到元数据，大家脑海中的第一印象是什么？
“表结构”、“ETL脚本”
延伸拔高下是“数据模型”、“数据交换”
但元数据的本质是什么？也是数据。
要想把这部分数据管理好，同样需要从生命周期的角度结合“模型”、“标准”、“架构”、“安全”、“质量”、“元数据”去定义管控策略。
等等，为什么还有“元数据”？
套回它的定义：描述数据的数据。
描述“元数据”的数据也是元数据。
这里说的“模型”就是“元模型”
描述元数据的数据对应的模型就是“元元模型”
层次如下图：
例如：
1. M0层是学生记录，即具体的某个学生的姓名和性别；
2. M1层定义“学生记录”内容，它有一个名字和两个字段，每个字段又有一个名字和字段类型；
3. M2层定义“记录”内容，记录是“元类”的一个实例，一个“记录”有两个“元属性”第一个属性定义记录的名字，第二个属性定义记录包含的字段，每个字段有其自己的名字和字段类型；
4. M3层定义M2层描述内容的元素，是包含以下元素：
1) Meta-Class：元类
2) Meta-attribute：元属性
3) Meta-association：元关联
4) 元素之间的关系：Contains（包含）、Generalizes（继承）、Isoftype（类型引用）、DependsOn（依赖）
以此逻辑，理论上可以不断向上层进行抽象，从元—元模型层次开始往上都是自描述性质，因此在应用层面定义一层即可，之所以有M1、M2层是为了能够尽量多的覆盖到不同的模型和元模型。逐层抽象、定义的目的是使下一层的内容可以轻松互通。
这里提及的“MOF”、“UML”还包括这里没有说的“XMI”构成了“CWM”是OMG发布的关于元数据管理的国际标准。
在做元数据管理工具设计、开发的时候需要参考。
这里说到了元数据管理工具，元数据信息的高效管理、使用，对于工具、平台的依赖就非常强的。
通过建立“元数据仓库”来支撑平台和工具的实现。
至于“元数据”架构、“元模型”的设计和层次划分，有本书叫《公共仓库元模型》讲的非常详细，这里就不展开了。
回到开始提及的通过元数据管理的“数据模型”和“数据交换”
对“数据模型”的采集维护、分类，通过“数据资产目录”展示，便于用户知道有什么数据。
“数据交换”的高质量管理，也就是“血缘分析”“影响性分析”的必要条件。
加上对于元数据的“增删改查”构成了这部分管理的基础应用。
随着对数据价值的不断挖掘，场景的不断丰富，基于元数据的应用开发也会越来越完善、越来越多。
这部分的重点、难点：
1. 元数据采集的自动化，保证元数据更新及时。
2. 数据资产目录分类的合理性
3. 基于数据内容的不断新增，对于数据资产目录的更新、继承规则，如何保证资产目录准确、及时、高可用。
4. ETL开发规范严格执行，逐步提升“血缘分析”、“影响性分析”的准确性。
5. 元数据安全的逐步重视。有些场景可以轻易通过元数据信息挖掘隐私信息，造成安全隐患。
以上就是我关于几大领域的浅薄理解。
再回到开头说的问题：“治理谈及的管理办法、制度，很容易写，但都是高屋建瓴的，怎么落地呢？”、“我有痛点、有规划、有愿景，也有政策上的强约束，但怎么能让我看到成效？”
管理办法、制度是什么？
是保障治理工作能够有效执行，有理有据的有力保证。
是企业自上而下的强力共识，通过明确“责、权、利”从框架上保证体系完整。
绝大多数情况制定的标准不能落地、数据质量问题反复未解决、元数据管理可用度低，都是制度约束上没有保证归责到岗的强执行。
所以治理工作从来都不是一蹴而就，也不是一锤子买卖，是要建立在文化共识的基础上，循序渐进逐步开展。
发现数据质量问题，逐步根源分析，寻找解决方案就是一个不错的切入点。
扫描下方二维码
添加好友，备注【交流群】
拉你到学习路线和资源丰富的交流群