来源：风姑娘的数字视角

关于数据治理，在当前企业中，无论是在金融、零售、保险、互联网等各行各业的重要性已有各种铺天盖地的文章，这里就不赘述，我之前也写过好几篇关于数据治理的文章，有兴趣的可以翻下历史文章，比如数据治理10大坑。

数据治理很重要，但是要做好却非常非常艰难，这比上一套BI 系统难多了，可以算是一场攻坚战，我觉得要打好数据治理的攻坚战，首先是在认知上要有正确的意识，意识决定行动，这样才有可能有胜算。

数据治理归属IT类项目

关于项目归属的问题，正常的反馈肯定是IT类，因为数据治理说白了就是治和理，不管治和理都要用到各种各样的系统，各式各样的数据，以及各类方法工具。

我对于这种项目的概念是分战略层和战术层以及执行层。治在理之前，怎么治是关键，理更偏向于具体的整理、处理即行动。

所以怎么治？是IT说了算么？

如果我们将数据拆分为主数据、业务数据、参考数据、元数据。假设就分为这四种，这里面和IT最有可能密切相关的是元数据，元数据里还可以进行再细分到底是与谁关联性最强。

主数据、业务数据严格来说都要为业务服务的，但IT人员并不懂这些数据是如何和业务挂钩的，或者更严苛来说需要懂数据又懂数据应用的人来主导更好，因为不是所有的业务目标技术手段都能实现，也不是所有的技术业务人员都能听得懂，但是这块数据治理往往都是IT 人员主导，最后就干成了技术项目，与业务几乎没什么关系。

还有一类是参考数据，比如我们常见的货币、行政区域这种固定而几乎不会发生变化的参考数据，在所有的参考数据种，哪些是业务关心的，比如有没有出口业务，比如业务全国铺向了哪些区域，这都决定了企业会使用到哪些参考数据，这些IT人员可以做决定吗？

所以数据治理在战略层应该属于业务类项目，在战术层是业务与IT 相结合的项目，在执行层是IT 人员主导的过程。

数据治理从头到尾都是IT 人员的事

很多公司这种项目立项在技术部门，然后找到相应的供应商来支持。结果你会发现整个项目都是搞技术的，信息部的人只懂技术或者只关心技术，一般懂数据应用的人都是非常稀少的，所以更多进入到数据治理项目的是做系统做ETL开发出身的工程师，而项目供应商的团队你也会发现都是搞技术，写代码的，然后这拨人顾自在那做，很快就交付了，或者一拖拖个一年半载都做不完，或者做完了项目价值无法体现。

在第一个认知里，如果你看懂了，你就会发现这个思维认知也是存在问题的，技术人员拥有的是技术思维，产品思维，系统思维，但是并没有数据应用思维，也不懂业务，所以业务部门全员脱离，最终项目价值和业务无法沾上边，这个项目就坐实了属于成本类项目。

数据治理不应是少数人或者技术人员的战斗，应该是全业务参与。

数据治理和BI项目一起做就可以了

数据治理项目单独做确实比较痛苦，所以很多人都不会单独起一个数据治理项目，很多会在上报表系统的时候把前面的数据整理归为数据治理，这个也是存在一定误区的。

如果按我们前面的分法，数据分为主数据、业务数据、参考数据、元数据，其中主数据与各业务系统运行息息相关，很多系统都不可缺少主数据，所以主数据在系统更换或者升级的时候做最好。

业务数据即各种指标加工、计算逻辑制定，这个可以在BI 系统建设之前或者一起做问题不是很大，但是正常BI项目的指标梳理都是不太完整的，或者又会做成一个技术项目，这个是非常需要注意的。

然后参考数据，这个可以按需，问题不是很大。

元数据要分很多，比如指向业务类的，要结合实际情况是什么时候开始，一些是指向底层中台的就和业务指向的内容操作不一样，具体要结合公司情况到底要管哪些数据，要管到多深、多广。

要注意的是这里提供的是比较简易、比较通用的判断思路，但是思路是死的，并不适用于所有的企业以及所有的企业发展阶段，以及所有的管理要求，所以仅代表一些观点，它是灵活转变的，大家仍然要结合企业的现状进行判断。

总体来说，数据治理非常非常重要，但是非常非常难，难在战略规划、难在执行、难在后续一如既往贯彻，但是如果首要认知上拥有了正确的认识，那么数据治理你就迈向了一条正确的道路，剩下的就是找到懂数据应用的人一起迎难而上。