数据治理很难但有办法

首先看一个案例，如下是一个离散制造集团产品数据治理工作方案的目录。

从目录看，很多内容并不是数据工作本身的，这种情况非常典型。简单来说，即数据治理绝不单纯是一个技术性的工作，而是一个体系化的若干方面的工作，大量工作在组织、业务、管理、标准、应用系统等方面，并且这些方面往往是决定数据治理效果的基础，或者说，数据治理工作的重点对象常常是这几个方面，而真正在数据仓库（湖）、数据中台等数据系统上的纯数据技术类工作只占一部分。以上图的方案目录为例稍作展开，最初得到的要求（企业高层的指示）和需求（集团和企业的需求不一样）是对产品主数据做集团层面的管理，但产品数据本身的集团管理也基本是空白的，所以需要升级为产品数据管理（主数据是业务实体数据的子集）。同时，产品数据与产品研发管理（产品数据管理PDM、产品生命周期管理PLM）、生产制造管理（ERP等）等直接相关，与物料数据管理是一体化的（物料数据在很大程度上属于治理难度最大的一类数据），所以进一步延伸到集团层面的物料数据管理，与采购管理也有直接的关系（SRM等），且涉及集团统建和企业自建的若干系统，于是包括的数据、系统、组织很多，工作难度非常大。

因为工作很难，就需要有相应的组织和资源才能实质开展工作（必须有人、有钱才能行），对这种难度非常大的集团级项目，首先集团总部要成立高层领导直接管理的、联合多个部门和企业的工作专班，这是工作组织的灵魂，工作思路、目标、责任、考核、制度等等这些关键因素都由专班承载（数据战略、制度等）。虽然实际中决定工作思路的往往是“一把手”或者高层领导，但专班中各部门的负责人需要把真实、准确、正确的信息传递至高层，尽可能支撑高层领导作出正确决策。同时，因为“一把手”或者高层领导因为岗位重要和工作繁忙，且管理是分工和分层的，不能要求高层管理者是覆盖全领域的专家，也不能要求高层管理者有大量时间放在项目上，高层只要把方向选对，知人善用，资源配置好，协调好跨部门的工作就很好了。所以实际中“一把手”基本无法真正全面管理项目，而中层管理者就非常关键了，中层是工作落地时校准方向、筹划组织、真心驱动的关键一层，必须有一些专业的中层管理者和真正的专家支撑好高层领导，落实好工作。其次就是具体承办工作的部门或者企业，第一要有驱动工作的部门，至少要有一个主责部门，如果都是同等分工和责任，项目大概率会在内耗中止步不前。对数据治理而言，常常是数据的Owner作为驱动者较为合适，但实质上是有理有据的责权利清晰是关键（数据认责）。注意此处的要求是驱动，驱动是主动产生动力让整个工作前进的，所以不能仅是组织会议、沟通协调这些工作，让工作有实质进展并最终成功的才能叫驱动。（推荐阅读《多部门能否共同驱动是央企DRP建设的关键挑战之一》）第二个是具体承办的部门或者企业，对集团企业，特别是一级或者二级央企集团，总部的机构编制和人员很有限，而包括数据治理在内的工作都有着大量具体的复杂工作要开展，仅靠总部的少量人员必然不行，所以一般会选择集团内的相关企业投入资源（人员，甚至是资金）承担具体的工作，可以是在对应领域有业务优势的子企业（例如对物料数据治理，可以是集团集采中心或者物资公司承担），也或者直接是集团内的数科公司或者共享服务中心等机构。总的来说，事情都是人干的，要办事就要有人和钱，反之，如果没有准备好人员和资金就希望做一些事是不合逻辑的。关于专家组，对集团级物料类数据治理尤为关键，此处的专家更多是各业务领域的专家，也包括数据治理、信息化等方面的专家。集团级物料数据治理最大的难度之一是覆盖全集团的物料分类体系的设计，各企业为了生产基本都有自己的物料管理体系，所以需要把各企业物料管理专家召集在一起，在专班的组织下结合集团和企业的需要制定集团级的物料分类体系，分类体系需要达到如下一些要求。

因为制定分类体系较为复杂，建设期可能需要组织多次集中工作（甚至是封闭工作），并且因为业务是动态发展的，数据标准应用后一般也要定期或按需组织专家组会议研讨新业务带来的新课题。

这里稍微谈谈物料数据治理常态运行时的专家角色，重点之一是物料数据的审核，通常是需要对应领域的具有一定专业水准的人员审核，才能更有效的判断是否是合理的新增或者变更，结合多方面手段尽量保障“一物一码”。集团企业常常是多业态，不同领域的物料差异很大，导致熟悉A业务的人员无法审核B业务的物料，熟悉B业务的又无法审核A业务的物料，而让一个人同时熟悉A、B、C等多种业务也几乎不可能（专家一定是专长于一部分领域，不会是事事都通），所以在集团层面如果要管理整个集团的物料，那么势必就需要一个专业团队才能够覆盖多个业务领域。至于成立这种有一定规模的专业团队自然是有成本的，此时就要评估集团统管物料在业务和管理上的价值，如果价值较高，那么再高的管理成本也是需要的（既然要管，那必然是要投入资源的），反之或许只能分业务板块加以管理。同时，该团队的专业人员在审核用户提交的物料数据时，不仅是完成了一个业务工作的处理，其实也完成了物料数据治理中关键的一环，所以数据治理往往就是业务的一部分，在数智化中数据治理与业务、管理是一体的。在目录图中有提及分为事务类和分析类功能建设，很多数据治理项目很难取得预期效果的原因正在于此，即大量问题其实是需要通过更好的建设应用系统来解决，毕竟绝大部分数据都是应用系统产生的，很多时候如果不在源端开展工作，寄希望于后来通过数据治理来解决问题常常是无法实现的，此时就类似于“脏水洗手”，一直是高成本和低效的“数据治理”。此时就要分清楚事务类需求和分析类需求（详情可见《关于数据中台的很多误解缘于对事务与分析（OLTP与OLAP）概念的模糊》），一则在应用系统建设和优化时就要考虑数据治理，近些年系统建设常规情况下都会一体化考虑系统集成和数据治理（例如数据标准等），“数据孤岛”等情况往往都是历史遗留问题，对新建系统而言正常情况下“孤岛”问题现在基本不突出；第二是明确需求或者问题的实质，明确是该应用系统解决还是通过数据治理解决，明确该管理解决还是技术解决，数据治理虽然非常重要但不是万能的，特别是要避免数据治理“万能论”，希望仅建设数据中台或者单纯靠技术完成数据治理是不现实的，因为数据与业务、管理是一体的，所以数据治理是复杂的，所以也是体系化的，通常难度都很大。如本文标题，数据治理虽然很难，但是有办法的。领域内经过多年的探索、实践、积累和发展，数据治理的理论体系和技术工具已经较为完备，这是第一个层面的方法，即“通用方法”。而实际中比较困难是怎么在具体的企业中运用数据治理领域通用的理论和技术，现在日常开展工作时，数据管理本身的技术基本问题不大，数据的采集、清洗、建模、分享、……，元数据、数据目录等等工作有专业的数据架构师和工程师团队负责，工作中较为困难的恰恰是上述组织、业务、管理、资源、应用系统等方面的问题，内外部交流时大家沟通探讨的也常常都是这类问题。对于上述问题，解决时基本都是依赖于对业务的熟悉和理解程度、在企业中的位置和角色、对数据治理运用的能力和经验，即实际开展数据治理时的一系列工作内容，也就是数据治理真正落地的方法，这是第二个层面的方法，即“落地方法”，类似于本文第一张图中工作方案目录对应的内容。所以数据治理等工作，虽然很难但总是有办法的（还例如《财务共享咨询是有答案的咨询》等），关键是看企业高层是否真的想干，想干总是可以干成的（当然也是需要一些会干的人），同行们交流至此也常常是有共鸣的。