在企业数字化转型的进程中，数据治理是提升数据质量和价值的关键环节。然而，数据治理的启动并非易事，需要明确的契机、相关方的支持以及合适的时机。本文从数据治理的启动契机入手，探讨了如何找到合适的业务场景、明确相关方以及把握启动时机。
在开始讲启动契机之前，先问自己一个问题：假如数据都清洗干净了、所有数据都拉通了、数据质量提升了，然后那，然后在这个数据的基础上你想做什么?
我理解这个一切都准备好了之后的那个“然后那”的答案，就是一个数据治理启动的契机一部分。如果，面对这个“然后那”，并没有一个强有力的答案，那么个人认为就还没有找到这个启动的契机。
缺少这个契机，主要是缺少了一个业务场景，或者说业务目标，没有业务场景、目标的数据治理，那就是纯为了治理而治理。为了治理而治理是一定不会成功的，因为都没有一个实际的业务来校验、反馈是否真的成功。自说自话的结果，没什么意义。
单独说一句，提升安全合规性也是一个业务目标，甚至可以说是一个事关生死的业务目标。
这个契机不仅仅是一个场景，还要包含这个场景的相关方，这个场景适合的时间。
按照讲故事的逻辑，就是需要明确一下什么时间，什么人，做了什么事情。这三点都明确了，且觉得合适，那么就是数据治理启动的一个契机了。
做了什么事情，就是一个场景。也就是具体做的一件事情。
什么人，也就是找到数据治理的相关方。
什么时间，也就是启动数据治理的时机，什么时候合适。
这个启动的契机，需要协调各个利益方，只有找到利益方了，满足各方的意见才能做到很好的落地。
下面我们从这三个要素角度，试着看看都分别有什么。
场景主要是要找到要干什么事情。也是开篇提到的那个问题的答案。然后那？数据都清洗、拉通、质量提升之后，然后想干什么。
在DGI数据治理框架中说，企业生存的三个主要驱动力包括：
而这个数据治理的场景，也逃脱不了这三类驱动力。可以从这三类驱动力中找到想干什么。并且，这件想干什么的事情，最好一句话就能够说清楚的。
为什么强调一句话，个人之前看到过一个说法：凡是一句话说不清楚的需求，都是伪需求。这句话可能有点过于绝对了。但是传达的道理还是挺明确的，即必须有一个能够简短表达的需求。
这个确定场景的过程也绝不是闭门造车的过程，是需要深入到业务中去，真实的了解痛点在哪里。
这个过程中如何和业务沟通配合，就是“人和”的部分了，在整个数据治理过程中充满了这种人与人之间的沟通交流，是否能够达成配合顺利，达到“人和”的程度，也是成败的关键。
（后续，会单独说下个人认为数据治理过程中的“天时、地利、人和”以及“利其器”的内容）。
在沟通过程中也会有一些沟通模板。有一个固定的模版，能够更好的进行推广，升级沟通形式。
并且这个场景，最好是能够获取高层认可的，或者直接就是高层想做的。这样推进的时候会阻力更小。
在找到了具体场景的同时，需要明确这个场景在实际落地的时候的相关方。
个人理解这个相关方包括两类：直接相关方和间接相关方。
直接相关方就是治理这个动作直接作用的双方。类似于力作用的时候的施力一方，和受力一方。这里面就是发出治理需求的一方，一个就是被治理影响的一方。
直接相关方的施力一方：就是发出治理规范要求的一方，可能是专门的数据管理部门，也可能就是数据中台部门。后续，我们假设这个部门就是数据中台部门。
但一定不能业务部门或者IT部门来做。因为受力一方就是业务部门和IT部门，不能即做选手，又做裁判。
直接相关方的受力一方：就是IT部门和业务部门。IT部门就是系统建设的部门。业务部门就是系统使用的部门。在数据治理过程中都会对这两个部门提出相应的一些要求。后续我们也统称为业务部门。
间接相关方：就是能够让治理顺利施行的一方。这个方面个人认为是治理工具提供方。
个人总感觉数据治理过程中的工具提供方一直是没有被充分重视的一个环节。各种数据治理政策的落地，各种目录的梳理其实都需要工具辅助支撑，才能很好的落地的。
这个工具，通过采购可能并不一定完全满足需求。如果通过自研，那么工具的整个研发周期又会很长，是否将工具研发周期也包在数据治理的周期内？如果提前准备工具，又需要和实际治理过程中需求相匹配，但是还没有启动数据治理，具体需求还不能确定，怎么让提前准备的工具完全匹配？
而且工具提供方其实最终产物是一个平台工具，并不实际的产生业务价值。
这些都是这个工具提供方，这个间接相关方的难点。即需要工具，又不想让工具的准备占据过多精力。
间接相关方可能还会涉及到安全部门。一般公司会有独立的安全部门来负责安全。或者法务部门，现在数据安全法，个人隐私保护法也都比较多，由法务部门提供些意见支持还是有必要的。
确定好了直接相关方和间接相关方。明确了要做的场景中，这些人都处在什么位置，都需要干什么。是确定契机的第二点，明确什么人。
人力即权力。或者说人事即权力。这种人事安排，组织安排是否合适，是否和你要做的事情相匹配，即意味着这件事情能不能做的下去。权力能不能发挥出来。
确定了什么事情：找到了场景。明确了什么人：明确相关方。第三个就是确定时间了。
也就满足最开始提到契机里面包含的：什么时间，什么人，做了什么事情中的第三个要素了。
这个时间包括宏观上的时间，也包括微观上的时间。
宏观上的时间比较重要的一点就是：系统不再频繁做大的功能变更了。如果业务还处在高速发展期，业务流程，数据流向会进行大的彻底的变更。那么这种时候，时间上就不是合适的时间点。
另外几个是，组织要足够大，系统要相对复杂。如果组织本来就比较小，或者系统很少，关系比较简单，那也没有必要进行独立的数据治理。
在时机上有跨职能项目合作。或者是整体合规要求，这种被动的时机，也是启动的不错的时间点。
微观上的时间是场景的业务方准备好了。如果业务方现在有其他的更重要的事项需要研发，你这时候去让业务配合，即使说通了，但是也不是人家第一优先级。怎么可能好好配合进行数据治理。
而且好多时候，这种业务方没有准备好，还不能明说。要看看他们的当前目标是什么，多私下沟通交流，感觉还是挺微妙的。
如果没有筹齐这三个要素，说明做这件事情的契机还不成熟，还需要再等等、再找找，启动全局的数据治理，还是需要三思下。或者采用更聚焦、更局部的方式来启动。
如果已经集齐了这三要素，那么下一步我们看看数据治理过程中直接相关的两方，也就是数据中台和业务部门的几种合作的模式。通过哪种合作形式能够更好的进行数据治理的推进。
本文由人人都是产品经理作者【数据小吏】，微信公众号：【数据小吏】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。