谈谈数据治理能力发展曲线【请对号入座】

简介: 理解什么是数据治理,为什么它处于实现价值的关键路径上,以及如何在组织中具体部署它,可能是一条漫长的道路。

一 概述

理解什么是数据治理,为什么它处于实现价值的关键路径上,以及如何在组织中具体部署它,可能是一条漫长的道路。当公司首次推出带有人工智能和数据应用的大型转型项目时,他们很快意识到这些项目需要关键的推动因素,如数据平台、数据湖、数据质量管理和主数据,这些关键因素可以让高质量数据提供到用例中。直到最近,数据治理才出现在众多复杂系统的优先级中。

如今,几乎所有CDO/CTO都明白,数据治理是数字化转型的先决条件。他们熟悉所有基本的组织和操作概念,但让他们传递具体的价值是一项复杂得多的任务。因此,数据治理常常被简化为孤立的文档活动,影响很小。我们看到许多项目正在启动,许多数据治理负责人出现在组织中。起初,他们在说服赞助商和商业伙伴投资这些活动时都遇到了同样的困难。为什么?因为部署数据治理是一个组织必须经历的完整的进化过程,而且过程中的每一步都很重要。

754aad6625e480d9097a33a75ad330f7.jpg

第一阶段——无意识无能力:缺乏数据治理的“症状”是什么?

由于糟糕的数据治理,公司面临着未解决的业务问题;公司被现有的需要成熟数据的计划(战略用例、IT迁移等)被迫管理数据;处理这些症状将有助于认识到数据治理的挑战和关键价值。

第二阶段——有意识无能力:当公司开始数据治理之旅时,会遇到哪些挑战?

证明数据治理的价值:原始数据是未开发的潜力,而精炼数据是黄金;找到启动第一个计划的正确的财务模式:由用例驱动或高层要求驱动;动员人们交付:在数据治理联合团队内部和外部。

第三阶段——有意识有能力:公司在启动数据治理计划时通常遵循哪些步骤?

第一步—规划数据治理:域、操作模型、路线图、工具;第二步——在每个数据域中部署数据治理:数据质量、数据标准和可访问性。通过大型项目在有限的时间内进行彻底的改造;或者把工作分散很长一段时间,从最关键的部分开始,然后逐步地做剩下的部分。

第四阶段——无意识有能力:当数据治理成为新常态时会发生什么?

数据治理不再是一段旅程,而是一项熟练的技能;数据治理是每个人的责任:C级成员、业务所有者、工程主管、领域开发团队、数据专员、用例和特性团队本文的目的是通过了解每个公司不可避免地要经历的数据治理过程,帮助您理解数据治理在实践中是什么。

二 数据治理曲线

阶段1 -无意识无能力:缺乏数据治理的“症状”是什么?是什么触发了它?

甚至在开始之前,第一个挑战就是识别数据治理问题。在这个阶段,该公司还没有意识到其许多业务问题与数据治理活动直接相关。这个过程的第一步是确定哪些根本问题是组织中没有人能够回答的。

1e916ababffe639a02b6322b15478ade.jpg

提出这类问题将数据治理与它可能产生的潜在业务价值直接联系起来,并避免了IT或隐私驱动方法的陷阱,这些方法将数据治理减少为主数据或访问权限管理。

在这一阶段,我们还观察到其他触发数据治理计划启动的典型情况:由于缺乏可访问的数据以及数据所有者和管理人员来定位和理解数据而暂停的情况;

高度隐私风险管理计划,要求数据沿袭或访问权限管理符合规定;

战略性的IT/架构迁移(例如云迁移),需要数据治理来定义访问权限和数据可用性策略;

重大的数字化转型计划,使数据治理成为确保快速交付价值的关键因素;

为了在数据治理的道路上前进,公司需要面对未解决的业务问题,否则就会被迫陷入落后的情况。只有这样,他们才会意识到他们面临的挑战,并理解数据治理的关键价值。

第二阶段-有意识无能力:公司在开始数据治理之旅时会遇到哪些挑战?

一旦公司决定正式开始其数据治理之旅,三大挑战就会出现:(1)证明数据治理是有价值的,(2)找到合适的财务模式来启动第一项计划, (3)动员人们交付。1.证明数据治理的价值:原始数据是未开发的潜力,而精炼数据是黄金

首先的挑战之一是说服董事会。数据治理的提倡者需要找到合适的说辞来证明,有时以牺牲用例为代价,应该对数据治理进行投资,并且应该在数据转换路线图上找到空间。

2. 找到正确的财务模式:由用例驱动或由高层机构驱动

这一领域经常会出现两个问题:启动一个数据治理项目需要多少成本?谁应该为此买单?可以区分出两种模式:

模式1由用例驱动,其中一部分预算专门用于数据治理活动。

模式2由高层机构驱动,该机构拥有支持数据治理主题用例的预算。

当数据治理通过设计嵌入到所有项目中时,模式1是转换后的目标。在转换之前和转换期间,模式2通常适用于建立最佳实践。

3.动员人员交付:在数据治理联合团队内,以及团队之外

围绕数据治理问题调动公司员工是关键的挑战。

在数据治理团队中,成功的关键因素是实现联合交付模型,其中操作是分散的,由每个业务领域团队驱动。一个中心办公室或领导(视规模而定)负责组织方案、实现工具箱、定义标准。它的第一个任务是将公司的数据细分为数据域,并为每个域指定一个所有者,他将负责指定其域中的关键角色(管理员、托管人……)。

除了数据治理团队,中央办公室还必须适应和提高团队的技能,以配合新的、更结构化的数据交互方式。

一旦这些最初的挑战被克服了,组织就可以被认为是有能力和足够成熟的,可以定义最好的方法来开始,并实现第一个有形的结果,而不需要太多的前期投资。

第三阶段-有意识有能力:启动数据治理计划时应遵循哪些步骤?

98c061602e5acaafc1eebc11e45f6947.jpg

1.步骤1——够花数据治理:域、操作模型、路线图、工具

数据治理办公室的第一个关键活动是将数据资产构造为数据域。这项活动使公司能够:

共享数据资产的共同愿景;

确定数据治理路线图的优先级;

分配角色和职责;

结构化数据治理工具。

一旦实践完成了,下一步就是分配所有者(他们将安排活动的优先级并确定目标)和管理人员(他们将在操作上部署质量和文档程序)到每个领域。我们已经观察到,成功的数据治理模式是“联邦”模式,业务活动分散在各个领域,数据治理的负责人在中央数据团队中推动动力、协调活动并赋予专员和所有者权力。

成熟的组织是业务驱动的,并在与数据应用路线图密切相关的情况下构建数据治理路线图。他们将数据域与公司的战略用例进行映射,并对服务于许多用例的域进行优先排序。成功的关键因素是,从小处着手,通过确定两到三个关键领域的所有者和管理人员来避免隧道效应,并在将其部署到其他领域之前对方法进行改进。

工具对于长期维持数据治理很重要,但数据治理首先是一个组织问题。如果组织不相信数据治理的重要性,如果运营模式不到位,这些工具将不会被采用,对公司来说将是一种资源和时间的浪费。

2.步骤2 ——在每个数据域中部署数据治理:数据质量、标准化和可访问性

方法1 -与重大项目在有限时间内完成改造

方法1通常是大公司的首选,这些公司已经启动了重大转型计划,在成功交付数据和人工智能案例方面面临着重要的问题。对于那些正在转向云计算的公司来说,他们的数据资产在新数据平台中的结构也岌岌可危。这种整体或端到端方法旨在通过处理数据治理的四个维度(质量、标准化、可访问性和所有权)来彻底清理数据领域。

这一重大数据转换方案的一个关键方面是协调18个数据领域工作的能力。数据治理办公室在确保数据域之间的一致性和设置总体优先级方面发挥着至关重要的作用。

方法2 -把工作分散在很长一段时间内,从最关键的开始,然后逐步做剩下的第二种方法更适合那些在推出重大项目之前需要证明数据治理价值的公司。首先,这些公司专注于他们想通过数据治理解决的一个特定痛点。有时这些计划甚至没有标记为“数据治理”。

d0799bf825e68ef9317ed43fba8b7a2f.jpg

第四阶段-无意识有能力:当数据治理成为新常态时会发生什么?

在我们开始之前,有必要强调的是,除了纯粹的参与者或围绕数据设计的最新公司之外,相对很少有公司达到了数据治理的最后阶段,即数据治理已成为自动化

1.数据治理不再是一段旅程,而是一项熟练的技能

数据治理不再被视为需要涉众付出巨大努力的耗时转型之旅。现在,这是一项完全嵌入到公司流程中的技能,每个处理数据的人都受到了这一层面的影响。在数据平台中集成数据需要满足特定的标准,如数据文档、数据敏感性识别、数据所有者识别等。

访问数据意味着遵循一个过程,这个过程需要用例管理人员证明他们的数据使用是正确的

只有满足与数据集成相同的标准(文档化、敏感性、所有者、监控等),才能向公司的其他部门提供新的数据集。

2. 数据治理是每个人的责任

C级领导促进了公司内部数据的流通。他们依靠统一的数据视图(单一的真实来源)来做出所有的战略决策和监控公司的表现。企业所有者认识到,数据治理是其业务转型的关键成功因素。每个业务计划都“按设计”包含一个数据治理组件。工程主管是面向领域的数据平台的领导者。他们负责构建平台的通用功能,并制定全球标准以确保各领域之间的互操作性。向用例团队交付高质量数据产品的责任分散在那些最接近数据的领域开发团队中。为了确保数据产品是定性的,领域开发团队依赖于数据管家来保证高水平的数据质量和可用性。数据管理员不是一个角色,它是一份全职工作,位于业务、IT和数据团队之间的中枢位置。他们协调工作,以弥补数据治理债务,并确保新服务“根据设计”进行治理。

使用数据的用例和特性团队被视为具有权利和义务的客户:

消费高质量和值得信赖的数据产品的权利,利用数据市场发现和请求访问数据集。

将数据治理标准应用于他们的用例的责任:产品所有者在代办事项中为数据治理任务留出空间。用例创建的所有数据都有适当的文档记录,在数据管道的每个阶段都开发质量例程。

三 总结

尽管今天的大多数企业仍然徘徊在第二和第三阶段之间,但他们都感到在数据治理过程中前进的业务紧迫性。

有3个主要理由证明这种紧迫性。首先,数字化转型是实现新动能宏伟目标、保持领先地位的关键杠杆,没有数据治理,数字化转型不可持续。其次,我们身处一个快速发展的世界,快速获取数据、快速分析和利用数据对于快速反应至关重要。最后,公司需要吸引越来越愿意接受数据驱动的新人才。

任何公司在开始其数据治理之旅时,首先面临的挑战之一是证明这种紧迫性,并让内部利益相关者相信具体启动数据治理计划的价值。

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
6天前
|
供应链 安全 物联网
未来交织:新兴技术趋势与跨领域应用展望
【4月更文挑战第27天】 随着科技的不断进步,新兴技术如区块链、物联网(IoT)、和虚拟现实(VR)正迅速融入我们的生活和工作中。这些技术不仅各自发展迅猛,而且相互之间的融合预示着一场技术革命的到来。本文将探讨这些技术的发展趋势,分析它们在不同领域的应用前景,并讨论它们如何联合作用,推动社会向智能化、去中心化和沉浸式体验的方向演进。
|
6天前
|
存储 数据采集 分布式计算
大规模数据处理:探究现代技术与商业的无限潜能
大规模数据处理已经成为了当今信息时代中的重要议题,其对现代社会带来的深远影响不可忽视。本文将探究大规模数据处理的意义和应用领域,并详细阐述其中所涉及的挑战和解决方案。
25 1
|
12月前
|
存储 NoSQL BI
【企业架构】描绘未来:使用能力、产品和技术路线图来调整企业和执行战略
【企业架构】描绘未来:使用能力、产品和技术路线图来调整企业和执行战略
|
12月前
|
存储 架构师 BI
【业务架构】业务架构:战略执行之路上缺失的艺术/科学
【业务架构】业务架构:战略执行之路上缺失的艺术/科学
【业务架构】业务架构:战略执行之路上缺失的艺术/科学
|
12月前
|
存储 分布式计算 Kubernetes
带你读《2022年开源大数据热力报告》——热力趋势三:云原生大规模重构开源技术栈
带你读《2022年开源大数据热力报告》——热力趋势三:云原生大规模重构开源技术栈
233 0
|
12月前
|
存储 分布式计算 数据可视化
带你读《2022年开源大数据热力报告》——热力趋势一:用户需求多样化推动技术多元化
带你读《2022年开源大数据热力报告》——热力趋势一:用户需求多样化推动技术多元化
159 0
|
数据采集 存储 监控
数据治理晓说:(三)谈谈“十四五”期间数据治理需要关注的六大趋势
数据治理的概念较早的起源于国外,近些年随着国内信息化的发展,逐步重视数据的共享和应用,随之发现了经常被提及的数据质量问题,从而也逐步开展起了数据治理项目。
数据治理晓说:(三)谈谈“十四五”期间数据治理需要关注的六大趋势
|
存储 数据采集 分布式计算
谈谈数据治理成熟度模型及大数据治理参考架构
数据是企业拥有的最大资产之一,但是数据也越来越难以管理和控制。干净、可信的数据能够为企业提供更好的服务,提高客户忠诚度,提高生产效率,提高决策能力。
谈谈数据治理成熟度模型及大数据治理参考架构
|
关系型数据库 测试技术 领域建模
复杂性应对之道——矩阵思维(多维度思考)
> You should not be a if-else coder, should be a complexity conquer. -Frank # 前言 这篇文章,是对之前我在[《一文教会你如何写复杂业务代码》](https://www.atatech.org/articles/146064)说的“自上而下的结构化分解 + 自下而上的抽象建模”方法论的升级。因为在之前的方法论中,我
5113 2
复杂性应对之道——矩阵思维(多维度思考)
|
Web App开发 监控 大数据
解析业务数据的特征——《企业大数据实践路线》之三
阿里云MVP戚俊带你分析数据类型,进行大数据实战
2433 0