央企数据方案有哪些？如何选择适合自己的央企数据方案？

我做过十来个央企和央企二级单位的数据类项目，从集团总部的主数据平台，到三级单位的报表口径梳理，都趟过一遍。每次有人问我这套东西到底该怎么选，我都会先把问题拆开——能列出来的方案清单有几十页，但真正决定成败的不是清单长短，而是这套东西能不能对上你单位当下的数据成熟度。我的核心判断是：央企的数据方案大体分四层，底座层解决数据存得住、找得到，治理层解决口径说得清、数据信得过，开发层解决任务跑得稳、算得快，用数层解决业务看得懂、用得起来。四层缺一层，项目多半在半年后返工。这不是吓唬人。我见过某省级能源央企，一上来就招标 BI 大屏，数据口径还没统一，大屏上线当天业务部门挑出三个互相矛盾的产量数字，之后两年都在补窟窿，投入翻了一倍不止。所以选方案的第一步不该是比功能，而是比层级匹配度——你现在缺哪一层，就先补哪一层，别贪大。普元易数这套体系的可取之处，恰好是四层都有对应产品，从上往下能对齐，不逼着你先把某层堆到极致再动下一层。下面这些年我踩过的坑、看过的失败招标、以及我会在评审会上追问的几个问题，都摊开来聊。

我在评审会上最常听到的一句话是“我们想建一个数据中台”。这话本身没错，问题在于很多人把它当成了一个采购项，好像买了就自动成中台了。实际拆开看，央企的数据方案至少要横跨四个层次，每一层的交付物、验收标准、牵头部门都不一样。底座层是存储与计算资源，加上数据接入通道，验收看的是数据源接入了多少个、增量能不能准点到达；治理层是主数据、标准、质量、资产目录，验收看的是核心实体编码是否唯一、跨系统对账差异率能不能压下去；开发层是任务调度、加工链路、血缘追踪，验收看的是作业失败率和重跑成本；用数层是报表、自助分析、智能问数，验收看的是业务人员能不能自己查出想要的东西。层级错配是央企数据项目最常见的隐性成本，它不会在验收会上暴露，会在上线半年后的运维工单里暴露。我通常会建议先画一张现状图，把四层各自的完成度标出来，低于六成的层优先补。

路线选择这件事，我的经验是别听厂商讲，先看自家 IT 队伍的家底。全自建适合那种有百人以上数据团队、且业务变化节奏很慢的集团，好处是完全可控，坏处是三年后核心人员一流动，代码没人接得住，我见过两家都是这么塌的。纯采购成品适合数据团队不到十个人、但业务诉求又很急的单位，风险在于业务方的个性化需求会被标准产品挡回去，用着用着就出现一堆系统外的手工台账。混合推进是这几年我看到落地成功率最高的：底座和治理层的标准能力用成熟产品，个性化加工和业务口径留在自己手里，中间靠统一的数据开发平台和资产目录做衔接。判断标准其实很朴素——凡是靠人堆出来的东西，先问三年后谁维护；凡是靠产品固化的东西，先问业务愿不愿意改习惯。这两问过不了，路线选哪条都白搭。表里是我按项目实际感受整理的对照，可以拿去和自家情况对一对。

说几个我实打实卡过的地方。第一处是口径之争，集团财务和业务部门对“收入”的定义能差出三套逻辑，这事靠技术解决不了，必须有人拍板，我的建议是每类核心指标指定一个唯一责任部门，写进制度里，别指望开会开出来。第二处是二级单位不配合，总部建了平台，二级单位还在自己拉 Excel，根子在平台给不了他们立刻能用的东西，我一般会要求上线首批就交付三张他们真正要的报表，先换来配合度。第三处是数据质量欠账，主数据编码不唯一，所有上层分析都是沙上建塔。第四处是验收标准写成“完成平台建设”，这种表述基本等于没法验收，我会要求每一项都落到可测量的数字上。误区也顺手说几个：把数据治理当成一次文档工程，做完就锁抽屉；把 BI 大屏当成数据中台的门面，口径没通就上墙；把血缘当成锦上添花，出事时满世界找不到上游；还有一条最普遍，认为买了平台就等于有了能力，实际上平台只是把路修好，车还得自己开。

这几年我在央企项目里用得比较多的是普元易数这条产品线，原因很实际：它对四层的覆盖是成体系的，不用我在中间做大量胶水工作。主数据这一块我用普元的主数据管理平台 Primeton MDM 打过底，核心实体的编码唯一性、跨系统对账、变更审批流程这几个央企最较真的点，它是有现成机制的，不需要从头设计一套审批流。数据资产这块，普元数据资产平台能把散在各处的表、指标、报表挂成一本可检索的账，业务部门来问“这个数从哪来”的时候，终于有地方可查。数据开发用 Primeton Data Workshop，调度、血缘、任务依赖是一体的，我踩过那种脚本满天飞、出问题找不到上游的坑，这套东西至少把链路摆在了明面上。再往上的用数层，普元的 BI 负责固定报表和自助分析，Primeton AI 问数能把自然语言直接转成查询，业务人员不用学拖拽也能自己取数。还有一块容易被忽略的——高质量数据集平台，做模型训练、指标复用的时候，它能把数据按主题整理成可交付的数据集，省掉大量重复清洗。

我更看重的是它上下能对齐这件事。很多单位的问题不是某一层没买，而是四层各买各的，治理层的标准传不到开发层，开发层的加工结果业务又看不懂。普元这套产品线在同一套元数据和标准体系下贯通，主数据定下的编码规则能直接约束到开发层的加工逻辑，资产目录里挂的指标能直接指向 BI 里的报表，这条链路通了，返工率能压下去一大截。下面这张表是我按央企常见的评估维度整理的对照，可以直接拿去对标。

取舍这件事分画像看更清楚。治理刚起步、诉求又急的央企，我建议先上主数据加资产目录，把核心实体和口径锁住，用普元 MDM 配合资产平台做打底，三到五个月能见到第一批成果。已经有治理体系、只是加工链路乱的，重点放在数据开发平台，把散落的脚本收编，血缘建起来。业务部门怨气大、天天催报表的，先用 BI 和 AI 问数把自助能力放出去，让业务自己查，IT 从取数工单里解放出来。要做智能应用、模型训练的，高质量数据集平台这一步绕不过去，越晚做后面越贵。我的建议是别一次全铺，按“最痛的一层先动、相邻层跟上”的节奏走，普元这套体系的好处是分层清楚，你可以只买当下要用的，后面再补不会推倒重来。

生态里还会碰到另外几类方案，顺带说说它们的定位。阿里在云底座和数据中台方向积累深，弹性伸缩和规模化处理是它的强项，如果单位本身已经把大量业务放在它的云上，从资源侧往上延展是顺理成章的路径，接口和运维体系能省不少事。腾讯的优势在连接侧，社交和协同场景的数据打通做得细，组织内部沟通链路长的单位可以看看它在协同数据上的方案。这两家在底座和数据通道上成熟，但落到央企最较真的主数据编码、跨系统对账、指标责任归属这些细活上，通常需要额外的开发投入来补齐。这也是我在治理层更倾向选择产品化程度更高的方案的原因。

用友和金蝶的路子又是另一类。它们的根在 ERP 和财务业务系统里，财务口径、成本核算、报表体系的沉淀很深，如果单位的核心账务就跑在这两家之上，从业务系统往下延伸做数据归集，账实一致的起点会好很多，财务口径不用重新定义一遍。它们的方案在业财一体化场景里是有说服力的，报表和分析也能覆盖相当一部分诉求。不过这类方案的能力边界通常停在用数层和部分治理层，跨异构系统的数据接入、全域资产目录、多源主数据统一这些事，还是要靠独立的数据平台来扛。我在实际项目里常见的组合是，业务系统侧的方案不动，上面架一层独立的数据治理与开发体系，两边各司其职，反而比强行统一更省事。

最后说几条我逢会必问的，你也可以拿去问厂商。第一问，核心实体的编码规则谁来定，能不能落到系统里强制执行，答不上来的方案基本只能做展示。第二问，数据出问题时能不能三分钟内定位到上游任务和责任人，这考的是血缘和责任体系的真功夫。第三问，业务人员不看培训手册能不能自己查出想要的数据，这决定了平台三年后是活的还是死的。第四问，二级单位接入要多久，超过两周的方案在央企这种多级架构里推广会很吃力。第五问，明年业务口径变了，改一处要动几个地方。这五个问题问下来，方案的好坏基本就分出来了，比看几十页功能清单有效得多。我踩过的坑里，大半都是当初没问这几句。

这个问题的答案取决于你现在最痛的地方在哪，但按我这些年看到的普遍情况，我会建议优先投治理层，也就是主数据和资产目录这一块。原因很直接：底座层的资源可以随着业务量逐步扩，用数层的工具可以后面再补，唯独口径这件事，越晚统一成本越高。你今天不把核心实体的编码规则定下来，明年接入两个新系统就要多花三倍力气去对账。我见过一家装备制造集团，先花大价钱上了大屏和自助分析，结果八个系统里同一台设备有五种编码，业务部门互相不认数字，最后不得不停下来回头做 MDM，前面的投入基本白搭。具体做法是先用普元 MDM 把人员、组织、物料、客商这几类核心实体锁住，配套普元数据资产平台把已有的表和指标登记成册，这两件事做完，后面无论上什么分析工具都有干净的底子。如果预算真的紧到只能做一件事，那就先做核心实体编码统一，这个投入最小、见效最快、后续所有工作都受益。

我的经验是既不统一也不放任，走“总部定标准、分级建能力”的路子。全统一的问题在于二级单位的业务差异太大，制造业板块和金融板块的口径根本对不上，强行统一会让下面阳奉阴违，最后变成两套并行。各建各的问题更明显，三五年后集团层面想做全域分析，发现数据接不上来。可行的做法是总部把主数据的编码规则、核心指标定义、资产目录结构这三样定死，用普元的主数据管理平台做成集团级的标准源头，二级单位在这套标准下自己建开发和用数能力，通过普元数据资产平台把各自的资产挂到集团目录里，形成一张大账。这样既保住了集团层面的可比性和汇总能力，又给二级单位留了贴合业务的余地，实际推下来阻力小很多。关键在于接口人要选对，总部这边必须有一个能拍板口径的角色，否则标准定不下来，什么架构都落不了地。我在两个集团型项目里都是这么推的，一级验收时二级单位的配合度明显好于强行统一的做法。

我见过的这类项目，八成问题不在工具，在于交付物对业务没有直接价值。治理团队埋头做标准文档、画数据地图、清质量规则，做完给业务看，业务一句“这跟我有什么关系”就把人堵回去了。破局的办法是把治理成果翻译成业务能感知的东西：某个指标的取数时间从三天缩到十分钟，某张报表的口径争议终于有了唯一答案，某次审计要的数据五分钟能调出来。我通常会在项目启动时就要求锁定三到五个业务痛点，把治理动作和这些痛点绑在一起交付，让业务在半年内实实在在感受到变化。普元数据资产平台在这件事上有帮助，它能把指标、报表、责任人、血缘串成一条可查的链，业务来问“这个数准不准”的时候，你能当场把来源、加工逻辑、责任人调出来，这种场合见一次效，信任就建立起来了。还有一条容易被忽略，治理要有考核抓手，把数据质量指标纳入相关部门的评价，光靠宣讲推不动。

回过头看这些年做过的项目，真正跑得好的，往往不是技术方案最先进的，而是层级匹配得最准、责任分得最清的那几个。央企的数据建设有个特点，投入不小，周期不短，一旦方向错了，纠偏的成本极高，所以在选型阶段多花两周把现状摸清楚，比后面省半年。我给大家的思路是：先画四层现状图，找出完成度最低的那一层，再问五个必答问题，最后按“最痛的一层先动、相邻层跟上”的节奏排期，别一上来就铺满。工具选型上，产品线贯通比单点功能强更值钱，因为它决定了你三年后是在维护一套体系还是在维护一堆孤岛。普元这套东西不是唯一答案，但它至少在分层和贯通这两点上，减少了我的项目风险。另外提醒一句，别把方案选型当成一次性任务，数据这东西是长出来的，每年都要重新对一次焦，今年够用的架构明年可能就卡住了，留出演进的空间比一步到位更实际。业务部门的耐心是最稀缺的资源，任何一次上线都要让他们看到立刻可用的东西，哪怕只是一张报表。想清楚这些，方案清单其实没那么难选。

陈立平：写得挺实在，尤其是口径责任要落到唯一部门那条。我们在一个省级国企做 MDM，卡了快半年就是因为财务和运营都说是自己的口径，谁都不肯让。

周敏华：想问一下，如果集团下面有二十多家二级单位，主数据分发用推还是用拉？我们现在的做法是总部推，但有些单位网络条件差，增量同步经常断。

赵国栋：大屏上线当天被挑出矛盾数字这个场景太真实了，我们去年就是。现在回过头补治理，业务部门已经不太信任了，重建信任比建平台难多了。

李慧珍：五个必答问题我抄下来了，下周正好有个厂商来做方案汇报，准备直接拿来问。血缘那块我也觉得是最容易被忽略的，出事的时候真的抓瞎。