数据治理的六大核心准则,终于有人讲明白了

大数据 数据分析
当然不同的企业的情况差距相对较大,数据治理的团队需要具体问题具体分析。在不同的阶段,不同的准则的作用是不一样的,这也需要数据治理团队灵活地掌握。当然基于这些准则并不能保证数据治理一定成功,所以需要科学的数据治理流程或者框架来尽可能提高数据治理的成功。

对于任何从事数据治理的相关人员来说,首先需要明白一个道理,即数据治理在任何企业都是一件非常困难的事情,其往往有着极大的失败的可能。失败的原因往往可能是治理团队给出的建议或者流程对既有的业务产生非常大的影响(业务满意度);数据治理并没有解决当下的数据质量的问题,数据质量问题依旧存在(数据质量问题)问题等;甚至可能是因为公司高层不知道数据治理最终成果,导致数据治理工作被叫停(治理成果不明确)等。

同时数据治理是一项长期的工作,即数据治理团队可能在企业中进行长期的数据治理相关的工作,那么可能由于各种原因导致数据治理团队的工作与业务团队相距甚远,给团队或者外部产生很长时间没有成果的错觉,最后导致数据治理工作的失败。

根据笔者过往项目的经验,在数据治理项目中一定要把握如下6个核心的准则,分别是确定范围、融入团队、由点到面、团结业务、主动沟通、定期汇报成果,它们对数据治理项目的成功提供一定的帮助。这6个核心准则形成如图1所示的数据治理核心准则。

图片图片

图1数据治理核心准则

这6个准则互相依赖,缺一不可,构成数据治理成功的关键。

1.确定范围

确定范围主要是指确定进行数据治理的范围,它包括两个方面的意思。其一是企业中需要进行数据治理的范围,即如果某个企业需要进行数据治理的时候应该依托于企业的业务模式确定需要被治理的范围。举个例子,如果针对跨国企业的供应线进行数据治理,那么可能涉及该企业在全球的任何组织。其二是企业中涉及中被治理数据的范围,即根据业务模式确定组织的治理范围(业务部门或者事业线),然后确认需要被治理的数据范围。

在确定需要被治理的组织以及数据之后,需要明确具体特定组织的不同数据所被要求的严苛程度并不是一致的。因为在企业相同的业务场景下中往往存在不同类型的数据,例如某些数据是全球的、国家层面的或者本地的。所以不同级别的组织架构的数据重要程度往往也是不一样的。如果要求所有的数据都按照一种标准进行要求,无论是对于数据治理的团队还是对于企业来说都是不太现实的,所以在确定具体的范围之后一定要分清所需要进行数据治理的数据重要程度。

2.融入团队

按照笔者过往的经验,往往企业80%的业务可能主要集中在企业数据的50%甚至更少的数据中(这些数据往往跟主数据息息相关),并且90%的问题可能都是因为这50%的数据带来的。如果从数据治理的成果来看,需要集中资源去解决产生绝大多数问题的关键数据。那么就需要数据治理的团队去深入到一线中,去了解产生以及使用这些数据的技术人员或者业务人员所遇到的痛点,并从组织、数据标准或者流程等层面去解决类似的问题。

融入团队可能是数据治理核心准则之一。因为一个企业或者部门需要进行数据治理的原因往往是该企业或者部门中存在产生数据问题的因素。这些因素可能是因为技术原因导致上游下发数据不及时或者不准确,或者是因为进行数据录入过程中没有按照制定的流程或者规范进行。这些问题往往并不是一个简单的流程规范就可以解决的,为此需要切实地观察技术团队以及业务团队日常运行的工作,发现其中关键的因素并加以解决。很多时候,问题并不是因为技术导致的。

笔者曾遇到某位业务人员抱怨某个系统数据初始化无法在早上6点左右完成,因为数据不全导致其无法在6点进行系统操作(其他业务人员往往都是在工作时间的时候进行操作),技术团队进行数据优化依然无法满足该要求。数据治理团队融入团队与其沟通之后才了解到,其一般7:30左右要送其孩子上学,往往到公司都会晚到,所以需要早起进行系统操作。之后系统中开发一个定时执行某些预设操作的功能之后,该问题得以解决。

很多时候一个看似合理的业务需求,背后往往可能是一个需要我们去探究的原因。如果单纯地按照业务用户的要求进行数据跑批优化的话,那么往往依旧无法满足业务的需求,为此需要探究该用户真正的需求,这也是融入团队的核心。

3.由点到面

很多团队在开展数据治理项目的时候,往往都是全面铺开,将数据治理的团队的成员融入到各个团队中拟进行相应的治理工作。但是这样做往往面临着各种各样的阻力,例如数据治理团队似乎干扰正常的业务流程、团队成员似乎并没有提供有效的帮助等。这些声音一方面会打击数据治理团队内部的信心,一方面会提高数据治理团队推进相关政策的阻力。

为此在融入团队收集业务背后真实诉求或者原因之后,数据治理团队应该收集整理这些信息,结合数据治理的范围统筹分析,找准一个关键的业务痛点进行治理。这个痛点可能是企业内部收到外部监管的部分或者核心的业务流程中的某个环节等。

依托这个痛点之后进行治理之后,然后重新分析当前企业内部不同的关键信息之后,再次治理,在运动中完成数据治理的工作。当然很多时候这个过程目标可能会发生变化或者调整,这些都是非常正常的事情。但是无论怎么看数据治理都应该以一个核心痛点作为一个起点,然后逐步扩大被治理的范围。

4.团结业务

数据治理并不是一个技术驱动型的工作,其更多往往需要得到企业内部的业务人员的认可,即它能否切实地提高企业业务的运行效率,减少企业运行中的风险等。所以这个时候需要相应的业务人员进行背书,来肯定数据治理团队的成果。

为此当数据治理团队在某个特定的领域获得阶段性的成果的过程中,需要团结该领域所在的业务人员去针对该成果进行定性,即肯定数据治理团队的工作成果。

这个过程有两方面直接的益处,一方面可以证明数据治理团队工作的价值,鼓舞数据治理团队的士气(因为数据治理团队往往收到的质疑大于收到的肯定);另一方面可以通过这个机会增进与业务方的关系,增强数据治理团队的非职权影响力,方便后续的数据治理团队经验在不同团队的推广。

5.主动沟通

数据治理团队将在某个部门或者具体项目上的经验总结形成具体的规范或者标准之后,必然面临将该规范或者标准推广到其他部门或者团队的过程。这个过程往往是数据治理过程中相对最漫长、最耗费心神以及可能与其他部门冲突最激烈的过程。

为此数据治理团队依然需要融入被推广的部门或者组织中,去发现该组织与其他部门之间的共性与个性,找出该部门中的核心人物,这个核心人物往往是团队中最具有影响力的人,这个人比较了解团队实际情况,但其可能不会最直接的领导(往往也是如此)。数据治理团队可以与其主动沟通,充分汲取他(她)的意见之后,并更新迭代相关标准或者规范,然后逐步推广落地。

企业中往往有新成立的部门或者存在很久的业务部门,针对同一规范部门的反映可能是不一样的。如果规范的内容是从旧部门中产出的,那么相应的这个规范就可能更容易推广,反之可能就不一样。当然如果是新成立的部门收到更高层的直接领导或者支持,那么情况也可能发生改变,为此数据治理团队一定要因地制宜地找出关键人物,然后与他沟通推广数据治理的成果。

6.定期汇报成果

数据治理团队的成功往往依赖于团队成员的非职权影响力,为此需要通过成果去提高自身的影响力,进而保证数据治理的成功。那么很明显在团结业务以及主动沟通之后,在组织层面向高层数据治理团队的成果,用来提高高层对于数据治理的信心,进而提高其的支持力度是数据治理可以顺利进行的关键之一。

但是需要注意的是,定期汇报成果的材料以及与会人员必然是需要进行准备以及思考的。因为既然数据治理团队需要提高高层的信心,那么汇报内容就必须与高层关心的方向相匹配,并在汇报的过程中反复强调。此外需要进行数据治理的企业往往是具有一定规模的,那么其内部不同的业务部门之间相互往来程度也不完全一样,汇报的相关方需要与下个阶段数据治理的工作相关联,例如在汇报成果的会议上描绘一个与下一个治理部门相关数据应用场景,用来动员相应的业务部门,这无疑也会提升数据治理团队工作的顺利程度。

当然不同的企业的情况差距相对较大,数据治理的团队需要具体问题具体分析。在不同的阶段,不同的准则的作用是不一样的,这也需要数据治理团队灵活地掌握。当然基于这些准则并不能保证数据治理一定成功,所以需要科学的数据治理流程或者框架来尽可能提高数据治理的成功。

这些具体的流程在《企业级数据架构》一书都有这更加详细的介绍。

关于作者:

李杨,资深数据架构师,在数据相关领域有10年以上工作经验。头部保险资管公司科技平台交易系统团队开发组负责人,负责多个应用以及数据平台的建设、优化以及迁移工作。曾担任某数据公司技术合伙人,负责多个金融机构的数据仓库或数据平台相关的工作。《企业级数据架构:核心要素、架构模型、数据管理与平台搭建》作者。

责任编辑:武晓燕 来源: 数仓宝贝库
相关推荐

2021-12-07 18:24:26

数据安全

2021-09-10 18:23:14

Hadoop

2021-12-03 18:25:56

数据指标本质

2022-04-27 18:25:02

数据采集维度

2021-09-03 18:38:13

数据湖数据仓库

2022-05-01 22:09:27

数据模型大数据

2021-06-29 11:21:41

数据安全网络安全黑客

2020-11-30 08:34:44

大数据数据分析技术

2022-04-22 11:26:55

数据管理架构

2022-04-12 18:29:41

元数据系统架构

2022-01-05 18:27:44

数据挖掘工具

2022-11-01 18:21:14

数据埋点SDK

2021-06-13 12:03:46

SaaS软件即服务

2021-10-09 00:02:04

DevOps敏捷开发

2022-03-27 20:32:28

Knative容器事件模型

2021-10-17 20:38:30

微服务内存组件

2021-03-25 11:24:25

爬虫技术开发

2020-11-03 07:04:39

云计算公有云私有云

2021-08-31 19:14:38

技术埋点运营

2021-10-12 18:31:40

流量运营前端
点赞
收藏

51CTO技术栈公众号