数据治理的 “独孤九剑”（下）

数据治理需要提出具体的业务目标，要能解决具体的业务问题，这个痛点不应该是IT部门的，也不是某个业务部门的，而应是全公司的，即带有跨领域跨部门的特点，只有管理层感到痛的业务问题才值得去做。

4、对齐业务，解决核心业务问题

数据治理需要提出具体的业务目标，要能解决具体的业务问题，这个痛点不应该是IT部门的，也不是某个业务部门的，而应是全公司的，即带有跨领域跨部门的特点，只有管理层感到痛的业务问题才值得去做。

比如华为公司为了解决财务风险问题启动了数据治理项目，决定了这个数据治理项目能带来明确的财务收益。

我们的数据治理目标大多来自于公司管理层的要求，初期设置的业务目标大概有10多项，以下是举例：

推动A数据在网络和市场的定义一致性，使得前端市场的需求能够有效传递到后端网络，提升投资规划决策的科学性；

推动B领域数据采集的统一归口管理，提升B领域数据采集的时效性，助力B领域各类业务数据的高效分析；

打破C领域数据对各部门开放的壁垒，降低汇聚周期，进一步提升各部门跨域融合数据的分析能力；

汇聚D业务涉及的核心线下商业数据，助力D业务的精确营销；

构建完整的企业数据字典，嵌入到生产流程，助力自助生态能力的提升；

数据治理很容易做成“打造一个所谓的数据治理体系框架，建立了一堆组织，下发了一堆的规范标准.......”   以下这些都不是数据治理的目标：

成立企业数据治理委员会，下设数据治理办公室，明确各部门数据责任人.....；

发布元数据管理办法、数据质量管理办法，数据共享管理办法......;

打造企业数据目录，构建数据开发平台......;

重构数据开放流程，优化数据汇聚流程......;

如果公司提不出明确的业务目标，热衷于去建立一个数据治理体系框架，就有点舍本逐末，所以产生这种问题，一般有三个原因：

（1）公司对数据要素的高效配置能力理解不够深

（2）公司对数据驱动业务的现状和问题理解不够透

（3）狭隘的部门视角或者站位太低

数据治理是一把手工程，对老板是一种挑战，《华为数据之道》现在很多老板在看，这是有必要的。

5、推动项目，确保数据变革成功

数据团队每年会有不少数据项目，比如元数据、数据平台、数据采集、数据开放、主数据等等，其中一些跨领域的特性很突出，只有依托企业数据治理组织的统筹推进才能解决协同的问题，包括管理层的汇报、利益方的支持、项目的培训及常态化的沟通。

我这里给出两个跨领域项目的对比，高下立见：

“我们8年前建设大数据平台，项目做这做着就变成了纯粹的换计算和存储引擎，至于如何更好的归集各部门的数据无人关注，因为协调不动其他部门的更多配合，项目建设后数据资产没有得到明显增加，业务的获得感很弱，大数据是大忽悠不是空穴来风”

“今年我们启动了地址主数据项目的建设，需要对市场、政企、网络、规划和工程等五个部门的13个业务流程进行调整，涉及CRM、资管、精销平台、大数据平台等10个系统的改造，横款了BOM三域，难度远超8年前的大数据平台，但依托于企业数据治理组织的统筹推进，大家还是愿意配合去完成大量改造，这在2年前是不可想象的，当然其中的争论很多，讨论不下百次，但目标始终不变“

6、制定标准，规范数据管理行为

在跨部门项目的推进过程中，在上下游流程和系统的对接中，必然会涉及到语义和数据一致性的问题，如果统一了标准，不仅可以简化流程，还可以降低协作的沟通成本。数据治理组织需要代表公司牵头立法，包括组织标准编写、评审及提交数据治理委员会批准。

数据标准渗透在每一类数据管理活动中，无论是数据架构，数据建模、数据存储和操作、数据安全、主数据和参考数据、元数据、数据质量等等，但我们没必要为每一类活动都去制定标准，这个取决于业务需要和管理成本的大小，因为制定和执行标准是有代价的。

比如领域一定要建立数据字典标准吗？不一定，领域内部能沟通清楚的就没必要建，但如果要面向企业打造一本数据字典，那么标准就有必要建立，否则其他领域看不懂。现在数据标准工作得到越来越多的重视，那是因为数字化时代数据要素共享和开放成为了趋势，数据仓库那个时代，少有人提标准这个事情。

我们在建设地址主数据项目中，定义了地址数据的“13+N”的标准，如下所示，这是跨领域协同必需的：

““13”指的是从省、市到户号共13个层级；“N”指的是地址类型、标志物别名、经纬度、兴趣点名称、兴趣点行业类型、描述信息6个附加信息。”

7、问题管理，推进跨域问题解决

数据治理组织既然可以建立标准，即拥有数据领域的立法权利，相应的也需要有司法的权利，即进行问题管理，问题管理包括且不限于授权、合规性、标准冲突、一致性、数据安全、数据质量等等。

虽然大多问题在数据管理团队内部就能解决，但公司有10-20%的跨领域数据问题是无法自行解决的，但又是极其重要的，这些无法解决的问题容易被隐瞒，被忽视，深埋于地下，比如供应链的物资编码问题、统计报表的口径问题、严重的数据质量问题、数据快捷开放问题等等。

数据治理需要建立问题升级机制和流程，能将问题升级到更高的管理机构，比如数据治理委员会，数据治理团队通过问题识别和记录、组织讨论、确认方案及向上升级，促进问题闭环的形成。

我们通过建立跨部门联席会议和常态化沟通协作两大机制来推进问题解决，数据问题能被放到一张圆桌上进行讨论，这其实就是巨大的成功：

“一是依托数据治理办公室，建立了定期的跨部门联席会议制度来识别和收集问题：一种是管理层提出问题，要求我们协同各部门数据责任人推进解决，这种问题往往是需要跨部门联动的，比如企业级数据目录的构建、主数据的建设、数据开放管理办法的制定、平台工具的集约化建设等等。另一种是业务部门的数据责任人提出的需要数据治理办公室协调解决的问题，比如宽带长流程问题的解决，外部业务数据的归口采集，全流程效能分分析支持等等。”

“二是建立常态化沟通协作机制，高质量落实联席会议工作要求，包括培训辅导、沟通协调、跟踪通报等手段来推进问题闭环管理。”

8、监督控制，保证持续执行到位

数据管理的制度、规范和标准是纸面上的，往往是篇章式、片段的、模糊的，必需将其嵌入到数据管理相关生产流程中才能有效发挥作用。

当然数据治理不要去额外新增管理流程，而是要把要求叠加在原有业务流程之上，这会对业务带来影响，业务部门只有接受数据治理的监管才能确保执行到位。

比如地址主数据有“13+N”的数据录入标准，前端人员需要按照结构化的要求去录入数据，这改变了前端业务人员的操作习惯。

数据治理在带来全局收益的时候，可能会让局部业务领域付出代价，因此，数据治理组织在制定规范标准的时候，一方面要协同相关业务部门充分权衡利弊，另一方面，也需要善于利用技术手段去破解规范性和灵活性的结构性矛盾。

比如地址主数据有13+N”的录入标准碰到了业务方的强烈反对，因为影响业务受理效率，我们后来采取了分角色的管理策略，针对后端业务流程的录入，严格按照规范标准录入，对于前端业务流程的录入，仍然沿用旧的方式，但会给出一个AI的算法做初步的格式化，再结合人工纠正的方式来解决。

相对于以前数据团队做数据治理只是局限在数据仓库领域，并且采取事后监督的方式去做管控，现在我们的数据治理终于能直接介入业务系统，从源端解决问题，同时采取事前事中的方式进行实时控制，并且能基于业务流程数据进行分析评估，这是跨越式的进步。

9、评估合规，确保法规合理执行

数据治理要求以业务为导向，这个业务不能简单的理解成创造收入的业务，降低成本的业务，还应包括合规性的业务、满意度的业务等等，比如一旦不合规，短期就可能给公司带来收入影响。

数据治理组织一方面要去深刻的理解各类数据法规，配合公司法律、安全部门对涉及数据监管要求或审计承诺的作出响应，比如证明数据质量合格，另一方面，也要去破除那种阻碍业务正常开展的、过时的、不合理的、但又既成事实的规定。

公司涉及数据的业务流程还存在着大量的冗余的，不合理的环节和规则，但大家已经习以为常，数据治理组织需要去分析流程的堵点和卡点，推进流程的优化，从这个角度看，数据治理干的已经是数字化转型的工作了。

比如我们在分析数据汇聚流程中发现，A部门基于条线需要设置了一些规定，导致审批环节超过11个，但这种部门流程已经不适合企业级数据的汇聚要求，因此将其精简到了4个。

又比如在数据对内开放流程中，以前各类数据的审批都遵循同样的流程，导致数据开放时间很长，后来通过对数据进行敏感分级并制定不同的开放策略，实现了90%以上的数据在一小时就可以开放，如下图所示：

近几年国家一方面下发了“三法一条例”来规范数据的使用，另一方面也在推动数据要素流动数据基础制度的建立，公司数据治理组织也要与时俱进。

独孤九剑，基本上涵盖了DAMA数据治理活动的大部，其实数据治理重在“治理”两字，要求跳出“数据”找出路，自己以前搞错了重点，陷在“数据”里不可自拔。

免责声明：

本文转载自【大鱼的数字人生】，版权归原作者所有，如若侵权请联系我们进行删除！

易知微以自主研发的EasyV数字孪生可视化搭建平台为核心，结合WebGL、3D游戏引擎、GIS、BIM、CIM等技术，协同各个行业的生态伙伴，围绕着数字孪生技术、数字驾驶舱和行业应用，共同建设数字增强世界，帮助客户实现数字化管理，加速数字化转型。

易知微已经为3000+ 客户提供数字孪生可视化平台和应用，覆盖智慧楼宇、智慧园区、智慧城市、数字政府、数字乡村、智慧文旅、工业互联网等众多行业领域，包括国家电网、移动云、中交建、中铁建、融创、云上贵州、厦门象屿、天津火箭、上海电视台、金华防汛大脑、良渚古城遗址公园、李宁、浙江大学等典型案例！