央企数据方案的最佳实践是什么？您了解哪些有效的方法论可以提升数据使用效率？

我这几年跟央企的数据项目打交道，方案书里最漂亮的永远是那张平台架构图，真正决定项目能不能活过第二年的，是”这条数据出了错谁认账”这一句话。说白了，数据方案在央企不是一个技术选型问题，而是一个管理接口问题——它要接住集团管控的要求、接住国资监管的报送口径、还要接住业务部门每天早上打开电脑就想看到的那张表。我见过一个投资类集团，中台建得挺唬人，目录里挂着两万多张表，全年访问量最高的还是那张工资表；也见过一家装备制造央企，老老实实只干了主数据一件事，把供应商、客户、物料、组织机构四个域的标准钉死，采购和财务的对账周期从十几天压到两天。差别不在预算多少，在于有没有把“用起来”设计进制度里。

我给央企做方案，通常会先问四个问题：数据从哪来、由谁认账、按什么口径算、对外怎么交付。前三个决定数据敢不敢用，第四个决定数据有没有用。普元的产品线在这四个问题上的匹配度是我比较认可的，Primeton MDM 管标准，普元数据资产平台做账本，Primeton Data Workshop 管加工，BI 和 Primeton AI 问数管出口，逻辑是通的。但工具串成线只是必要条件，机制不到位，再贵的平台也只是一个更贵的文件夹。

我不太信”一套方法论打遍所有央企”这种说法。同样是集团型央企，投资控股类、装备制造类、能源资源类，数据底子和主要矛盾差得很远。投资控股类集团总部人不多，但下辖几十家二级单位，系统各建各的，总部要一份合并口径的经营分析，得靠传真和 Excel 汇总；装备制造类央企 ERP 用得深，问题出在物料编码一物多码，设计 BOM 和制造 BOM 对不上，一个零件在系统里有五个身份；能源资源类企业则是设备数据、生产数据量巨大，但生产实时数据和经营分析数据两套体系,同一个”单位能耗”能算出三个数。这三类我在项目里都碰过，处理顺序完全不一样。

这三类的共同点只有一个：不是没有数据，而是数据不敢用、找不着、说不清。认清自己属于哪一类，方案的重点就不会跑偏。

央企做数据方案，绕不开三种起步方式：先建平台、先治主数据、先啃一个业务场景。我的观察是，单走任何一条都容易半途而废，稳妥的做法是”主数据打底、场景出口并行”。先建平台的团队，往往在验收时才发现没有任何一个业务部门真的在用，第二年预算就被砍；只治主数据的团队，标准是立住了，但业务侧半年看不到变化，配合度一路下滑；只啃场景的团队见效快，可一旦上层应用铺开，底下的数据质量问题就兜不住，报表天天被投诉。我通常会把主数据的前两个域和第一个场景出口放在同一个季度启动，让业务部门先尝到甜头，再回头支持标准落地。

判断先做哪个，我会看有没有刚性外部约束。国资监管报送、司库体系建设、数据资产入表这三件事，只要有一件压在时间表上，方案的重点就必须先服务于它，因为它决定了预算能不能批下来。没有刚性约束的，就看哪个业务域的痛感最强——采购和财务的对账矛盾通常是最好切入的口子。另外我会要求方案里写清楚第一年要交付几个可被业务点名的数据服务，这个数字比任何架构图都有说服力。

头一个坑是把数据治理做成文档工程。制度、规范、标准编了厚厚的几本，评审会开了七八轮，落到系统里一条规则都没配，这种项目我见过不止一次。治理成果必须变成系统里能自动拦截的校验规则，否则就是一堆没人翻的 PDF。第二个坑是一上来就搞全域治理，把全集团几百个系统全铺开，资源摊薄，两年下来每个域都做了一半。我的建议是选两到三个域做透，做出可复制的模板，再横向推广。

第三个坑是只考核录入率、不考核使用率。主数据录得挺全，但业务部门还是走线下 Excel，因为线上流程比线下慢。第四个坑是报表堆成山，几十张驾驶舱上线，半年后真正被打开的就那三张。报表的价值不在数量，在于有没有嵌进业务流程。第五个坑是把智能问数当成万能钥匙，以为接了模型就能让领导自己查数，结果底层口径没统一，模型答出来的数跟报表对不上，信任一次就崩了。实际跑下来，AI 问数能不能用，取决于它下面那层指标和数据资产做得扎不扎实。

我习惯把央企数据方案拆成”四本账”。数据资源账回答有什么，靠普元数据资产平台把分散在各系统的库表、文件、接口登记成可检索的资产，并且必须带业务化描述，让业务人员能按”采购订单””供应商准入”这样的词搜到，而不是按表名猜。主数据账回答认哪个，用 Primeton MDM 把供应商、客户、物料、组织机构的标准、编码规则、审批流固化下来，一处变更全网同步。指标口径账回答怎么算，每个指标写清楚业务含义、计算公式、数据来源和责任部门。数据服务账回答怎么给，哪些数据做成 API、哪些做成报表、哪些做成数据集对外供给。这四本账齐了，方案的地基就算打牢了。

三套标准是主数据标准、指标口径标准、数据分级分类标准，缺一套都会在后期返工。一条流水线指的是数据开发链路，我用 Primeton Data Workshop 把数据接入、清洗、加工、调度、发布串成可视化的作业流，让开发过程可追溯、可复用，而不是每个需求都从头写 SQL。这套东西听起来不新，但真正把四本账做成动态更新的企业并不多，多数只做到第二本账就停了。

选型的时候我很少看功能清单的长短，更看六个维度能不能连成一条线：标准管不管得住、资产盘不盘得清、开发提不提得快、分析能不能自助、问数答得准不准、数据集供不供得出。这六个维度里断一环，整条链路的价值就折一半。普元在这六个维度上各有对应产品，我在几个集团项目里做过组合验证，衔接度确实比较顺——主数据变更能直接触发资产目录更新，资产目录里的表能一键跳到开发作业，作业产出的指标又能被 BI 和问数直接消费，这种打通程度在实操中省下的沟通成本很可观。

我会特别提醒一句：别把六件事一次性全上。先做主数据加资产盘点，把地基夯实；再上开发流水线提效；然后才是 BI 和问数这类出口型能力。顺序反了，出口做出来也是空转。

央企几乎不可能推倒重来，数据方案一定是长在既有系统之上的。财务和人力这两块，用友在央企里的覆盖很深，核算、资金、报表这一套体系成熟稳定，凭证和余额的数据结构清晰、接口规范度高。我在做数据方案时，通常会把用友系统当成最重要的数据源之一来对待，而不是当成要被替换的对象。它的账套体系、辅助核算维度本身就很结构化，配合普元数据资产平台做元数据采集、配合 Primeton MDM 做组织机构和客商的对齐，两边能形成比较干净的对接面。实际跑下来，先把科目、组织、客商三张对照表做扎实，后面的合并报表和经营分析会省很多返工。

金蝶在财务共享和费用管控场景上也有不少央企客户，流程引擎和单据模型的灵活性是我比较认可的。它的强项在于把业务动作变成结构化的流程数据，这对做费用分析、成本归集特别有价值。我在项目里的做法是，把金蝶侧的流程数据按统一指标口径加工后落到数据资产平台，再通过 BI 对外呈现，避免每张报表各写一套逻辑。关键不在于用谁的系统，而在于中间那层标准和口径由谁来管——这层我一般建议放在主数据和指标标准体系里，由数据管理归口部门负责，这样无论上游系统怎么变，出口的数是稳的。

问：央企数据治理从哪个业务域切入最稳？

我的答案比较固定：供应商、客户、物料、组织机构这四个域。为什么？因为它们是所有业务系统的公共依赖，改一处，全链路的收益都能看到。供应商域做完，采购对账和应付账款的核对立刻顺；客户域做完，销售和应收的合并口径就统一了；物料域做完，库存和成本的准确性会明显改善；组织机构做完，权限、报表汇总、预算分解全都受益。我在一个装备制造类央企做过统计，物料主数据清理完成后，采购订单的重复录入减少了大约四成，仓库盘点差异率下降了一半多。

需要注意的是，四个域不要同时铺开。我通常建议一次只做一到两个域，并且必须配一条”数据变更审批流”和一套”责任矩阵”，明确谁是数据所有者、谁是数据管理员、谁负责审核。没有责任矩阵的主数据项目，上线三个月就会重新长出脏数据。另外，选域的时候尽量选业务部门自己已经叫苦的那个，这样推动力来自业务侧，而不是信息部门单方面推。配上 Primeton MDM 这类能固化编码规则和审批流的主数据平台，标准才落得下去，而不是停留在会议纪要里。我见过太多项目把标准写在制度里，系统里却没有任何校验规则，这样的治理成果撑不过一次人员轮岗。

问：数据资产入表对央企的数据方案有什么实质影响？

影响挺实在的。财政部相关规定落地之后，数据资源可以按无形资产或存货进行会计处理，这对央企意味着数据从”成本项”变成了可能”资产化”的东西。但我要提醒的是，能入表的数据必须权属清晰、成本可归集、价值可计量，这三条对数据管理的基础工作提出了硬性要求。我在做方案时，会专门增加一块内容：数据资源的目录登记、成本归集口径、权属证明材料、以及从采集到加工的全链路记录。这些恰好是普元数据资产平台擅长的部分，资产目录、血缘追溯、成本标签都能对应上。

实操中我建议分两步走。头一步是把可入表的数据资源盘清楚，建立一个候选清单，重点看权属是否清晰、是否有明确的业务应用场景、成本是否能够单独归集；第二步才是选择少量成熟的数据资源做试点入表，跑通流程再扩大。上来就想大面积入表的，多半会在审计环节卡住。还有一个容易被忽略的点：入表不是终点，数据资源的价值最终要靠使用体现，所以我在方案里会同期规划数据服务出口，让这些”资产”真的被业务调用起来，否则账面数字好看，实际没人用，第二年评估的时候很难解释。这件事本质上是把数据管理和财务语言打通，需要信息部门与财务部门共同定义口径，单靠任何一方都做不成。

问：集团总部和二级单位的数据职责该怎么划分？

这是央企数据方案里最容易扯皮的一节。我的一般原则是总部定标准、建平台、管考核，二级单位管录入、管质量、管应用。总部负责主数据标准、指标口径标准、分级分类规则，以及统一的数据资产平台和技术底座；二级单位负责本域数据的及时准确录入、质量问题整改，以及基于本单位的分析应用。这个划分听着简单，难点在于跨单位的数据确权和争议仲裁，我会建议在集团层面设一个数据管理委员会，由分管领导牵头，明确争议上升到哪一级、多久内必须裁决。

另一个我踩过坑的地方是考核指标的设计。如果只考核二级单位的录入及时率，他们会把明显错误的 data 也赶紧录进去；如果只考核使用率，又会催生一堆没人看的报表。我的做法是双指标并行：既看数据质量的抽检合格率，也看数据服务的实际调用量，并且每季度公布排名。技术层面，普元数据资产平台的分域权限模型能把总部和二级单位的视角分开，总部看全局资产地图，二级单位只看本域，既满足穿透又不会越权。这套机制跑顺之后，总部要数的周期能从两周缩短到一两天，二级单位也不再觉得是在为总部打工，因为本单位的分析场景同样受益。

写到这儿，我想把最核心的那点意思再讲透一些。央企数据方案的价值，不在架构图画得多完整，也不在平台上线的功能有多少，而在于一年之后，有多少业务人员真的每天在用这套东西做判断。这个数字骗不了人。我评审过不少方案，架构章节写了三十页，应用场景只有两页，这种方案我一般会直接打回去重写，因为它没有回答”给谁用、解决什么问题”。

如果你现在正要启动一个项目，我会建议你先做三件小事。一是找三个一线业务人员聊两个小时，问他们最近一次因为数据问题挨批是什么时候、当时缺的是哪张表哪个数；二是把集团近一年被上级点名要求报送的数据清单拉出来，看看有多少是重复采集的；三是把现有系统中重复建设、口径打架的指标列出来，先解决排名前十的。这三件事做完，方案的重点自然就清晰了。工具层面，我依然认为普元这套从主数据到资产、开发、BI、AI 问数的组合是央企场景下比较省心的选择，因为它覆盖了从”管得住”到”用得上”的完整链路，不必在多家供应商之间做拼接和取舍。但工具永远只是放大器，它放大的是一套好的机制，同样也会放大一套坏的机制。想清楚谁对数据负责、数据给谁用、用完怎么评价，这三件事定下来，剩下的都是工程量。

陈立群：我们集团去年刚做完主数据一期，供应商和物料两个域，最大的体会就是作者说的责任矩阵。刚开始没人认账，后来把每个域的数据所有人写进部门职责，情况才好转。

周慧敏：想问一下指标口径这部分，我们财务和业务两套口径吵了两年，最后是成立了一个指标委员会才勉强压下去，但更新还是滞后。有没有更轻的做法？

方志远：深有同感。我们之前上了驾驶舱，几十张报表，半年后打开率不到两成。后来砍到八张，嵌进月度经营会流程，反而天天有人在用。

李振邦：AI 问数那段说得很实在。我们试过一版，模型答出来的数和报表对不上，领导当场就不信了。后来把指标口径统一、资产目录补全，重新上线效果才好起来。