作为咨询公司，是非常不想接“数据治理”项目的，我们公司就拒绝了好几家企业的邀约，因为“只针对业务信息系统采集数据的治理”是没有成效的，也是不对的。如果不从数据全生命周期，以业务应用场景作为起点的项目，几乎是不会成功的，辛辛苦苦做半年，拿不到尾款的数据治理工程项目，太多了。
为什么会如此呢？
因为几乎99%的人对数据治理的理解都是错误的。特别是以那些IT软件公司、技术出身的顾问，还有企业IT主导的数据治理项目，其项目的范围就是业务信息系统，ERP治理财务主数据、CRM治理客户主数据、HRM治理人力主数据、MES治理生产主数据，WMS治理物料主数据。
一方面，这些数据治理的需求是不清晰的，不是对业务信息系统采集记录的原始数据制定标准和规范就完成了数据治理。如果不理解业务是如何使用数据的，中高层管理团队需要什么样的数据统计、报表和业务做哪些分析，你是不清楚数据治理的需求的，标准和规范是没有根的。
我在好几家大型企业集团里面调研，这几家企业的CIO都告诉我，数据治理项目，他们做过好多期了，最终都没有完成落地实施。虽然起到了一定的效果，但是实际的价值并不明显。业务信息系统的运维压力减少了，但是业务还在抱怨数据，管理层还在要求数据准确性和敏捷性。现在，大家给高层提供报表，还是得人工统计汇总，然后各种校验之后给到高层，不能满足高层提出需求，满上给提供报表的要求。
这个问题的根源是什么呢？怎么从根上解决这个问题呢？仔细阅读本文，我结合我们的咨询项目经验，给你答案。
根源一：范围不清晰。
大家对“数据”概念的理解不一致，导致“数据治理”项目范围缺失。
数据治理项目，也是一个项目，我们要用“项目管理”的专业方法来管理我们的项目，从项目目标、项目范围、项目计划到项目任务拆解、项目关系人管理，等等，有十大要素，最为关键的是要目标清晰、范围明确。在很多企业里，数据治理从一开始，范围就没有明确，起源于大家对“数据”这个词的概念定义的不同。不同的人，对数据的理解是不一样的，所以理解的数据治理项目的范围是不同的。
我们从谁看数据的视角来思考一下，老板心里的数据，业务心里的数据，技术心里的数据，基层心中的数据，中层心中的数据，高层心中的数据，是完全不同的，在不同理解上，就有了不同的项目范围。
三种数据表：大家平时工作中用到的数据表，我们分为三大类，分别是原始数据表、决策数据表和管理数据表。
大家在平时工作中，会用到一些数据表来辅助自己做出各种管理决策，比如说负责物流的，有一批货需要发给客户，那么他就需要一个数据表：
1）物流供应商的信息表，选择哪家物流企业来提供服务，是否具备资质和能力；
2）哪家物流企业的运输能力，货运中大中小车的情况；船运能力；航空运输能力；
3）根据交期和运输要求，哪家成本最低，那么就需要供应商的报价单数据表；
4）财务需要账期，那么，每家企业的已经签署的合作协议条款中，哪家企业有财务要求的账期，需要一个合同信息表，而不是去查每一个已经签署的合同。
这些数据表都是辅助这个管物流的管理岗位做出决策的数据，他所需要的这些数据表，我们叫做“决策数据表”。
到了一定的时间，上级经理会需要一种统计汇总表，比如说我们的成本、费用、收入、利润等的统计。然后有各种各样的指标需要呈现在管理层的面前，需要这些管理层能够有整体的判断和认知。比如说我们的收入目标是否达成，我们的费控目标是否达成，我们每一个订单、每一个客户，每一个产品，每一项业务，每一个项目，是否赚钱了？赚了多少钱，有没有达成预期，这个时候，就需要财务参与核算，然后呈报给管理层。这个时候，管理层所看到的报表，我们叫做“管理数据表”，也可以称作“管理报表”，如果是从财务视角出具的，也有一个专有名词“管报（管理报表的简称）”。
所以，我们三类数据表中的管理数据表，有业务提供的业务统计汇总表和财务核算的管理报表。
除了上面提到的两大类数据表之外，就是业务活动发生的时候，我们做的记录，填报，或者采集的数据，这些数据叫做“原始数据表”。是在每次业务活动，每一个记录数据或者采集数据动作，留存在业务信息系统中的数据，通过查询而形成的一种清单，比如说客户信息表、供应商报价单等等。这些就给后面两种数据表提供原始数据，后两种数据表是基于原始数据表所做的统计汇总，满足业务决策和管理层判断所需要的数据需求。
以上三种，都是站在业务视角去看，而IT眼中的数据，则是业务信息系统后台数据库中的表结构和元数据。
有了以上共识，大家在探讨数据治理项目的范围的时候，我们才能够有清晰的范围界定，任何的数据治理，只做IT眼中的底层数据表治理，肯定是不行的，要考业务眼中的三种数据表中的数据。所以，我曾经在公众号文章说过，数据治理需要从业务出发。
根源二：需求不明确
业务参与度不足，业务数据需求没有明确，导致数据治理最终目标无法达成。
在外部顾问承接的项目，或者IT团队推动的数据治理项目，因为业务参与度不足导致数据治理的标准和规范的依据不足，最终的目标无法达成，这是需求的清晰度和需求变更的问题。
一个数据治理项目，就怕需求不清晰，不是表面上看上去清晰，而是真正的细化到每一个节点的数据需求。前面三张业务使用的数据表，每一个表的需求如果没有清晰化，最终的数据治理就无法达成我们业务需要的目标。数据是为业务提供服务的，为管理提供决策依据的，这是最根本的目标。
我们曾经拒绝了一个项目邀约，就是因为他们定义的目标是为公司上SAP而要做数据治理，为了上信息化而治理数据，这个需求看上去是清晰的，但实际上是不清晰的。数据治理的需求端，必须是业务，而不是IT。上SAP，能够有规范和标准的数据给到SAP实施，这个是“伪需求”。
一般，不做数据指标体系梳理，不做明确的业务应用场景，不做流程梳理和规范的数据治理项目，我们是不承接的。因为最终数据治理无法达成业务需求的目标，最终在项目评审的时候，业务部门不签字，我们的项目就无法顺利结项。所以，数据治理项目最好跟应用端的项目结合来启动，是一种比较好的选择，因为应用端的项目能够为数据治理项目提供清晰的要求和目标，比如说要业务看板、要做管理驾驶舱、要管理报表，要做业财融合或业财一体化某种应用等等。
根源三：逻辑不理解
业务管理和业务决策逻辑是数据治理的本质化要求，如果缺少对业务逻辑的梳理和深刻理解，数据治理最终无法形成标准。
数据治理，为业务使用提供的数据，都是统计汇总之后的报表，而报表中的数据，我们叫做“指标”或者“数据指标”。包括过程决策所需要的指标，和管理判断所需要的结果指标，这些指标的计算规则，背后是企业的业务逻辑。
比如说高层要统计收入，我们如何统计这个收入，取数的源头，计算的规则到底是什么？是以订单为准统计，还是以收款为准统计，还是以开具发票作为统计口径，还是以发货作为统计口径，还是以客户确认收货作为收入的统计口径？每一个口径都会带来数据统计的差异。
如果不懂得业务逻辑，那就容易导致数据还是不准，还是各种数据满天飞。如果以发货为准统计，那么退货怎么办？如果以收款统计，那么预收款怎么办？如果以收付实现制、权责发生去统计，没开发票的怎么办？这些要回归到逻辑，大家要统一规则。
本文已经超长了，最后总结一句话吧，数据治理项目必须源自业务需求、满足业务需求，而不是IT技术部门的自嗨，业务需求是起点，更是终点。