第二十七章：数据治理的可行性自我评估-CSDN博客

本文链接：https://blog.csdn.net/zlei1990/article/details/149336824

随着【主数据】【数据生命周期】【数据标签】三个模块的结束，本章正式进入【总】的阶段。下面，直接开始第一章的总结：数据治理的可行性自我评估。

数据治理，并非所有的企业都适合启动的。什么样的企业暂时不适合启动数据治理？这一章总结一些特征，可以进行一些参考。

不适合启动数据治理的企业有哪些特征。

1、第一个特征：业务目标不明确的企业

个人有一个观点，凡是说影响数字化转型是因为数据治理没有做好的企业，都做不好数据治理。

因为，没有想清楚数据治理的业务目标到底是什么。数字化转型本身是一个特别大的词，不可能用这个大词来代替业务目标。

需要一个明确的业务目标，是假如所有的数据问题都解决了，数据孤岛已经被拉通，数据质量已经提升。那么，基于这个治理好的数据，是想做什么，达成什么业务目标？

如果这个业务目标没有想清楚，就会是为了治理而治理。可能还不适合启动数据治理这件事情。

就拿传说中数字化转型做的成功的华为来说，也是基于打通国内外的订单合同、财务数据，这个具体的业务目标而做的数据治理。

所以，第一点，业务目标不明确的企业还不适合做数据治理。

当然，找到业务目标这件事情本身就是比较困难的，而且大概率找外部的支持是没有办法解决这个问题，仅仅能够起到辅助的作用。

想要在业务中发现问题，找到业务目标，只有内部人员深入业务，自己去发现业务的需求点。

所以，不妨从一个小的业务问题开始，明确业务的具体目标。只有在具体业务问题里面，数据治理才能够发挥出来真正的价值。

2、第二个特征：业务流程不稳定，或业务流程过于简单

数据治理，需要先有数据才能够去治理。

当业务流程不稳定的时候，业务本身还处在高速发展阶段，业务流程经常会变更。

数据由业务产生，业务的变化势必会引起数据的变化，在变化的数据上做治理，是不可能的事情。

当然，这个稳定是一个相对的稳定，绝对不是说业务不发展了。至于这个相对值如何把握，其实没有一个明确的度，具体情况具体分析了，或者当领导觉得这个度到了的时候，就是可以的了。

除了业务流程相对稳定外，业务流程也不能过于简单。

数据的价值只有在跨系统，跨组织复用的时候，才能发挥出来价值。

组织足够庞大，系统足够复杂，才适合进行数据治理，更大的发挥出数据的价值。

而如果业务流程本身过于简单，数据过于简单，可能也不适合做数据治理。

3、第三个特征：短期压力过大，缺乏领导支持

个人一直觉得，数据治理的过程是一个信任的过程。

因为会花费大量的时间做水面之下的工作，这种水面之下的工作是不会马上有业务产出的，如果本身短期压力过大，对于业务产出有要求的话，可能也不适合马上启动数据治理。

当然，没有业务产出并不代表没有目标产出。需要有阶段性的目标产出，只不过这个阶段性的目标产出并不会那么具有业务价值。

就像第一点提到的，在具体业务问题中进行的数据治理。那么，完成这个基于业务问题的数据治理可能会涉及到方方面面，一个领域的数据治理可能会耗时一两年，有多少公司能够等待这么久，又有多少领导能够容忍这么久。又有多少人能够知道两年后的能产生的价值而一直投入。

所以领导的支持显得尤为重要。是真的支持还是口头支持，是上心的支持还是放任自流的支持，又是另一个话题了。

之前看过一篇数据治理成功的文章，开始觉得做数据治理的人是幸运，能够得到真正的支持。但是转念一想，这份幸运也是长时间的信任、成果累计起来的。就更多的变成了佩服了，佩服做决定的人，佩服执行决定的人。

4、第四个特征：基础设施薄弱

这里的基础设施，主要是针对数据治理的工具。工具的支撑是数据治理的重要基础。

工具基础薄弱，没有各个模块所需要的一些工具能力，是没有办法进行数据治理的。所以，基础设施也是能够启动数据治理的一个关键条件。

这里也不能因为基础设施的薄弱，而过分的对工具追求。工具本身不是目的，而是手段，不能本末倒置，陷入对于“工具崇拜”的误区中，把买了工具作为数据治理这件事情的目标本身，花费很多购买了工具，却没有相应的流程和人员来有效的利用这些工具。

说到买工具，这里也提一下自研和买工具的个人感受。如果自研的话，好处当然是能够更好的满足自己的需求了，坏处就是前期投入成本高，周期长，后期也需要维护人力。如果自研的话，就是正好反过来了，前期不需要过长的周期，快速的拥有一个工具，坏处的话就是不一定能够满足不同的个性化需求，至于后期的维护成本，有维保的费用可能不见得低多少。

个人是数据平台产品经理，发现不同的公司都是不同的，都会有自己的特殊需求，所以，我倾向于自研工具多一些。但是，目前的大环境似乎却是反过来的，除了体量特别大的公司，大量公司不再维护数据平台工具，也就不需要数据产品经理了。

更加倾向于使用云厂商工具，一方面是大环境上使得降本成为一个风气，另一方面自研工具的投入大，产出不可量化也是一个问题。

5、第五个特征：缺乏专门的人才

事在人为。

企业内缺乏专门的人才，也不适合启动数据治理。

但是什么样的人算是专门的人才那？

这件事情就又涉及到一个问题数据治理是适合偏技术的人、偏产品的人、还是偏业务的人来实施。

说实话，个人没有明确的答案。

我个人是有技术和产品经验的，所以在写数据治理文章也好，做数据治理方案也好，都会从技术实现，产品方案上考虑。优势就是落地性强，劣势就是可能业务性少一点，而且也容易让自身的局限性所限制。

因为，没有特别强的业务视角，也自然不能体会完全业务的视角来看数据治理是什么体验。

如果业务出身的话，因为有了较强的业务基础，这是一个优势，但是技术和产品知识的补齐还是有必要的。

是偏技术、产品，还是偏业务的，都有需要补齐的课程。也许不断前进的人，才是适合数据治理的人。

但是，不管哪类人，都需要有一套完整的自洽的理论框架，是否有这种人来做统一指导很是关键。这种人往往也是关键岗位，也看到过很多，关键岗位但是不合适的人，影响的不仅仅是一个岗位的问题，而是整个团队都不能发挥出能力。这个还是很吓人的，这个也让我对数据治理能否成功，带有一点点宿命论的感觉。有时候，错了，就是错了，就不会再成功。就需要花很长的时间去等待大的变动，新的调整和机会。

6、第六个特征：组织结构不合理

组织结构决定产品结构，组织结构决定技术结构。同样，组织结构也觉得数据治理的发挥。

一件事情能不能顺利的推进，人是关键，而能否发挥出人的潜力，就是组织结构的事情了。

之前，在【数据技术无第二，数据治理无第一】中也提到过，数据治理的理论、方法有很多，每个人都会有一套自己的理论，实践。

如果，没有一个合适的组织来进行协调不同的人，那么不同的小组向不同的方向发力，势必会出现相互掣肘，甚至反方向的力。

万事万物都有一个窗口期。一旦反方向的力形成，除非翻天覆地的大变化，否则很难扭转形式。而做数据治理这件事情的窗口，可能也就过去了，下次窗口不知道什么时候再来了。

个人一直觉得，数据治理这件事情，或者说公司内部想做一件事情，一定程度上是需要“独裁”的。需要一个唯一的大脑指明方向的，在这个唯一大脑的指挥下，手、脚、耳、口、鼻，形成一个统一的整体。而组织需要做的事情就是，明确这样的机制，谁做大脑，谁做四肢。可以提意见，但是最终只能有一个统一决策。好的组织就是确保这件事情的，形成一个有机的整体，将事情干成。

这里的大脑，倒非一定是组织内最大的领导。这个又涉及到决策形式是从上到下的决策形式，来时从下到上的决策形式了。不展开说了，但是这个大脑需要团队信服，配合。这都是需要通过合理的组织来完成的。

这里的组织结构更多的是指实际的组织，而并非虚拟的组织。公司内虚拟的组织双线汇报，评估考核，甚至日常办公是不是做在一起，都让虚拟组织效果并不怎么明显。

说完了暂时不适合启动数据治理的企业特则，那么条件反转一下，是不是就是适合启动数据治理的特征的企业了。

反转后适合做企业治理的五个条件，就像搭建一个小房子：业务目标明确是屋顶，业务流程稳定、短期业绩压力不大且领导支持，是两个支柱，基础设施完备、具备专业人才、组织结构合理是三个地基。

只有这样，才能把数据治理这个房子盖起来。