第七章:数据治理中的“天时、地利、人和”以及“利其器”

【第七章:数据治理中的“天时、地利、人和”以及“利其器”】第七章:数据治理中的“天时、地利、人和”以及“利其器”

数据治理的成功 , 离不开 “天时、地利、人和” 的相互促成 , 再加上 “利其器” 的辅助 。 本文将这一传统智慧应用于数据治理场景 , 供大家参考 。
本来计划是将这一章放在最后 , 进行总结介绍的 , 不过写的过程中发现 , 各个章节多多少少都已经涉及到一些内容 。 而且在前面提出来 , 也是一个提前总结 。
任何一件事情能够做成 , 真的是“天时、地利、人和”相互促成的结果 。 缺少哪一点都可能会出现意外 。 在数据治理的过程中也是同样的道理 , 那么什么是数据治理过程中的“天时、地利、人和” 。 以及具备了这些就一定能够达成目标吗?
老话说“工欲善其事 , 必先利其器” 。 数据治理中的“利其器”又是指的什么 。 这里就说说个人的一些理解 。

一、“天时、地利、人和”的解释特意搜了一下这个词的出处 。
出自《孟子.公孙丑下》 , 原文为 “孟子曰:‘天时不如地利 , 地利不如人和 。 三里之城 , 七里之郭 , 环而攻之而不胜 。 夫环而攻之 , 必有得天时者矣;然而不胜者 , 是天时不如地利也 。 城非不高也 , 池非不深也 , 兵革非不坚利也 , 米粟非不多也;委而去之 , 是地利不如人和也 。 ’” 。
解释 天时: 通常指有利于作战的时令、气候等自然条件 , 也可引申为时代背景、机遇等外部环境方面的有利因素 。 比如古代战争中 , 选择在合适的季节出兵 , 像冬天河水结冰利于行军渡河 , 或者刮起对己方有利的风向等情况 , 就可以说是占据了 “天时” 。 在更宽泛的现代语境下 , 一个人创业正好赶上行业蓬勃发展的阶段 , 市场需求旺盛 , 这也可看作是遇到了好的 “天时” 。
地利: 主要是指有利于作战的地理形势 , 像占据险要地势、易守难攻的关隘 , 或者有丰富物产的地区等 , 都属于地利因素 。 例如三国时期 , 蜀汉占据益州等地 , 凭借山川险阻等地理优势进行防御 。 从广义来讲 , 经商时选择一个地理位置优越、交通便利、人流量大的店铺地址 , 就是获得了 “地利” 条件 。
人和: 强调的是人心所向、内部团结等人文方面的有利因素 。 在军事上体现为军队内部上下一心、众志成城 , 百姓也拥护支持;在日常工作、生活等场景中 , 一个团队成员之间彼此协作、配合默契 , 人际关系和谐融洽 , 大家为了共同目标齐心努力 , 这就是具备了 “人和” 的良好状态 。
总体而言 , 这句话强调了在诸多因素中 , “人和” 相较于 “天时”“地利” 更为重要 , 突出了人的主观能动性以及内部团结协作所产生的强大力量在事情发展中的关键作用 , 后来也被广泛应用到军事、政治、商业、社会生活等诸多领域 , 用来分析成功所需要具备的条件 。
上面是从网上搜索到的 。 个人倒没有想说谁比谁重要的意思 , 只是想表达事情想做成 , 需要具备一些条件 。 这些条件能够和“天时、地利、人和”很好的类比 , 是各方条件相互促进 , 才能将事情办成 , 这样一种感觉 , 所以使用了这三个词 。
下面说说我对这几个词的理解 。

二、天时:大的政策趋势导向一说到数据治理 , 经常会听到的一种说法是“数据治理是一把手工程” 。 个人只同意这句话一半 , 数据治理确实是一把手工程 , 但也并不是一把手支持了就一定就能够成功的 。
就像这篇文章提到的 , 是需要天时、地利、人和 , 相互配合才有可能成功的 。
一把手的支持 , 仅仅能够提供一个公司内大的政策趋势导向 。 有了一把手的支持 , 能够明确的让领导给人 , 给钱 , 给时间 。 提供这样一个政策趋势的大环境 , 从而让数据治理在这个大环境下 , 在这个天时下进行稳步推进 , 而不至于急功近利、揠苗助长 。
同时 , 这个支持还需要能够明确可达成的范围是什么 , 不能在支持过程中既要、又要、还要 。
之前章节中提到的数据治理的边界在哪里、数据治理的目标、数据治理作用的数据分类是什么 , 都是想在启动数据治理之前能够明确下 , 哪些是数据治理能做的 , 哪些是数据治理不能做的 。

三、地利:适合的场景开展业务如果天时是一个大的政策趋势导向 。 那么地利就是一个适合的业务场景了 。
数据治理不能为了数据治理而治理 。 需要有一个明确的、一句话能够说清楚的业务场景 。
有了业务场景 , 才能有对应的业务方 , 在推进数据治理的过程中 , 才能不飘在空中 。 如果缺少了这个真实的业务场景 , 那么数据治理就总是感觉轻飘飘的 , 不落地 , 不扎实的感觉 。
这个场景需要多和业务进行沟通 , 真正从业务中来 。 并且这个业务场景 , 最好是领导层认可的 , 那么这个地利和天时也算部分结合了 。
这个地利在数据治理启动的契机中 , 寻找场景部分介绍的就是这个“地利” 。

四、人和:良好的业务关系 , 和谐的团队氛围人和的过程 , 是让公司内部有这个意识 , 各个组织之间相互配合不内耗 。
首先 , 是和业务部门有良好的关系 , 这样的进行“地利”沟通的时候 , 能够更加顺畅的进行调研 。 在梳理业务流程的时候 , 理清数据流向的过程中 , 都需要和业务进行深入沟通 。 在进行治理过程中 , 业务部门能够接受治理的一些规则、要求等 , 也都需要业务能够配合 。
另一方面的“人和”是 , 数据中台(假设数据中台部门是数据治理发起部门)内部能够有和谐的团队氛围 , 知道不同小组的定位 , 不同小组之间既有特定的负责范围 , 又能相互间配合 。 知道共同的目标 , 如何合力达成目标 。
毕竟 , 如果数据治理的发起团队先内部各个小组之间都不和谐 , 那么治理的政策基本上是贯彻不下去的 。
这些“人和”的关键可能还和组织架构有关 。 组织即权力 。 怎样的组织架构能够更加顺畅的让团队内部和谐沟通 , 怎么的组织架构能够和业务进行良好的交流 。 这些也都是具体不同的公司 , 具体分析了 , 没有一个放之四海皆准的形式 , 都是很微妙的设置 。
正是这些微妙的点 , 让数据治理并不是那么容易 , 也是这些微妙的点 , 让数据治理变得有意思 。

五、利其器:工具的辅助落地能力最后加一个条件 , 就是“工欲善其事 , 必先利其器” , 需要工具进行辅助来完成这件事 。
整个过程中工具的准备也是必不可少的 。 没有相应的工具进行配套的规范落地 , 让具体的人能够方便的进行操作 , 那么要想做成也是很困难的 。
个人认为工具在数据治理的过程中处在一个比较尴尬的位置 。
一方面容易走向两个极端 , 一个极端就是认为上了一套工具了 , 就能够包治百病 , 所有数据问题似乎都能够解决了 。 另一个极端就是忽视工具的需求 , 似乎只要有了组织、有了规范 , 数据治理就能够顺利的落地了 , 整个过程中都不提工具的作用 。
不管是哪种情况 , 工具有一个问题点就是:他需要一个单独的周期来准备 。 如果是采购的工具需要进行个性化改造 , 需要进行学习适应 , 如果是自研的工具 , 需要一个较长的研发周期来进行研发、测试 , 让工具变得稳定 。
这些都需要时间 。 而这个工具准备的时间从哪里出?是否将工具准备的周期也包在数据治理的周期内?如果提前准备工具 , 又需要和实际治理过程中需求相匹配 , 但是还没有启动数据治理 , 具体需求还不能确定 , 怎么让提前准备的工具完全匹配?如果不提前准备工具 , 随着组织调整 , 政策发布 , 一起来准备工具 , 那么节奏上一定会被准备工具所延后 , 组织调整和政策发布很快 , 但是工具准备确很慢 。
如何解决这个问题 , 需要具体场景具体分析了 。
而且还需要考虑一个点 , 工具提供方其实最终产物是一个平台工具 , 并不实际的产生业务价值 , 这也会在研发过程中遭遇比较大的压力 。
这些都是这个工具提供方 , 这个间接相关方的难点 。 即需要工具 , 又不想让工具的准备占据过多精力 。
但是不管哪种情况 , 需要手工编写程序收集的元数据 , 工具帮你自动获?。 恍枰斯な侗鸹虮嘈创胧迪值氖葜柿考觳?, 工具帮你自动识别问题;用文档管理的数据字典 , 工具帮你在线管理 。 所以 , 不能否认工具就是“善”数据治理这件事情的一个“利器” 。 至于 , 到底怎么准备这件利器 , 需要结合各自不同情况进行分析了 。
另外 , 当数据治理部门内部进行工具使用 , 工具推进的过程 , 也是“人和”的部分了 。

六、总结有了“天时、地利、人和” , 以及”利其器”就一定能够成功吗?答案恐怕也不是绝对的 。
对于成功的定义权在谁手里?怎么算是成功那?这是一方面 。 组织架构是否能够将这些能力顺利的发挥出来 , 也是各家各部相同的 。
另一方面是 , 你不可能拿着一个地图 , 在所有环境下去找路 。 现实环境千差万别 , 既要有固定的思路 , 又能够根据不同环境进行适时地变化 , 其中的感觉还是很微妙的 。
根据Gartner统计 , 数据治理项目大概有90%是失败的(并没有确切的找到数据出处 。 怎样的统计范围 , 如何定义失败等等 。 暂时持保留意见) 。 不过也不用过于悲观 。 在整个数据治理的过程中 , 谨慎乐观 , 一步一个脚印 。 能够明确知道自己正在做什么 , 目的是什么 , 就是一种成功了 。
写到这里 , 感觉越来越多的情况是没有一个定论的 。 都需要按照各自的场景进行个性化调整 。 这个是数据治理不稳定的地方 , 也是数据治理有趣迷人的地方 。

七、开启下个阶段整个数据治理实践之路 , 是按照“总-分-总”的形式来规划的 , 介绍完这一章 , 数据治理第一阶段“总”的部分就算告一段落了 。 “总”的部分一共7个章节 。 第一章算是开篇内容 。 之后的数据治理的边界在哪里、数据治理和数据管理怎么区分、数据治理的目标、数据治理启动的契机、数据治理作用的数据分类是什么、以及本章的 数据治理的“天时、地利、人力”及“利其器” , 都是想在治理之前明确下一些前提条件 , 划定下范围 。 是为了更好的开启下个阶段 。
下一章开始 , 将进入“分”的阶段 。 分的阶段会按照数据治理的目标中提到的5个维度 , 9个模块进行逐个介绍 , 下个阶段需要整体规划一下 , 敬请期待 。
还是像一直表达的 , 这些内容仅仅提供一个参考视角 。 而且 , 数据领域是一个实践的学科 , 可能本身解决方案就是千差万别的 。 希望大家在实践过程中 , 都能找到适合自己的那一条路 , 最终到达山顶 。
如果你觉得 , 我的总结对你有一定的启发 , 帮忙点赞、转发、关注一下 , 这对我很重要 。
本文由人人都是产品经理作者【数据小吏】 , 微信公众号:【数据小吏】 , 原创/授权 发布于人人都是产品经理 , 未经许可 , 禁止转载 。
题图来自Unsplash , 基于 CC0 协议 。

    推荐阅读