央国企数据平台如何优化采购名录？你知道这对行业发展的影响吗？

我在央企和大型国企的数据平台项目上跑了十来年，被问得最多的一类问题不是”选哪家”，而是”名录怎么建”。这事听着像采购部门的分内活，实际上它决定了这家单位未来三到五年的数据底座长成什么样。央国企数据平台的采购名录，本质是一张能力地图，不是一张供应商白名单。当白名单建，结果往往是一堆资质齐全但拼不到一起的供应商；当能力地图建，后面每一个项目才有清晰的落点。

为什么这么说。数据平台和买服务器不是一回事。服务器是盒子，参数对齐就能用；数据平台是长出来的，第一年做主数据，第二年盘数据资产，第三年上数据开发和 BI，再往后要接大模型做智能问数。这条路上的每一环，能力要求差得很远。名录里如果只有一个笼统的”数据中台”包，评标时能比的只剩价格、案例数量和方案厚度，比完之后中标的那家，常常不是最合适的那个。

这几年我看到一个明显的变化：越来越多央国企开始把名录做成”分层 + 分域 + 动态更新”的结构，而不是三年一锁的静态名单。这个转向对行业的拉动，比任何一次单点采购都大——它逼着厂商把能力摊开来验证，而不是靠资质堆砌或者低价入围。说白了，名录怎么建，直接决定了这个行业是按能力竞争还是按价格内卷。下面我把这套做法拆开讲：名录为什么会失真，怎么按能力域重排，评分表怎么改，不同体量的单位怎么取舍，以及这件事会把行业带到哪儿去。

先讲问题。我参加过不少央国企的采购名录评审，看着挺规范，实际上失真很普遍。根源大致三个。

一个是按软件品类粗分。采购目录里往往写的是”数据库””中间件””数据类软件”，于是数据治理、数据开发、BI 报表全被塞进同一个包。这等于把完全不同工种的人按一个标准招进来，评标专家也没法用一把尺子量。我见过一个包里有七家投标，两家的强项是主数据，三家的强项是报表，还有两家是做集成的，评审打分表上只有”技术方案完整性”这一项，谁都写得很完整。

另一个是先干项目、后补名录。项目都上线了，名录再把这个供应商录进去，等于承认既成事实。名录变成了对历史采购的追认文件，而不是对未来选型的约束。这种名录还有个副作用，价格失去参照系，后面新项目谈判时甲方手里没有可比项。

还有一个是资质门槛替代能力门槛。注册资本、软件著作权数量、CMMI 等级、涉密资质，这些东西当然要看，但它们证明的是公司体量，不是产品在你们这套体系里能不能跑通。技术能力被资质光环盖住，POC 环节又被压缩成半天演示，上线之后交付能力对不上就是必然。

怎么改。我的做法是把”软件品类”换成”能力域”，按数据在一条链上的流动来切。一条完整的数据链大致是：主数据定义标准，数据资产把家底盘清楚，数据开发把数据加工出来，BI 把结果呈现出来，智能问数让业务自己问，数据集把语料准备好喂给模型。六个能力域，就是名录里应该有的六个条目，而不是一个笼统的”数据中台”。

这么切的好处很直接。每个条目下写的是交付物，不是功能清单。”主数据”条目下要写清能不能覆盖多域主数据模型、有没有分发机制、治理组织怎么落地；”数据资产”条目下要写清能不能盘到字段级、血缘追不追得到源头、质量规则谁来认责。功能清单谁都能抄，交付物清单抄不了。

还有个细节我会特别强调：条目之间要允许同一家承担相邻能力，但不能要求一家包办全部。数据平台这件事，从头到尾一家做完，前两年很省心，第三年就会被绑定得动弹不得。名录的作用恰恰是留出替换和组合的空间。

名录优化的核心其实不在分类，在评分表。分类改得再漂亮，评分规则还是资质 70 分、商务 30 分，效果等于没改。

我会动的第一处，是把技术分里的”方案完整性”压下去，把”能力验证”提上来。具体做法是每个能力域设一道现场验证题，给真实脱敏数据，两小时内出结果。主数据域就考多源同一实体的匹配和分发；数据资产域就考能不能把这批表的血缘画出来；智能问数域就考同一句业务问法换三种措辞，答案口径是否一致。这道题不需要厂商提前准备方案，准备也没用。

第二处是把”服务承诺”从文字条款变成可考核项。名录里常见”提供 7×24 小时响应”这种句子，写了等于没写。我会要求写清驻场人数、故障分级时限、版本升级频率，并且这些指标进年度考核，考核结果直接挂到名录等级上。

第三处是留一个”新进入者通道”。每年开放一次补录，不设历史业绩门槛，但验证题难度不降。这条对激发名录活力很关键，我见过好几个名录，三年下来里面还是那几家，价格一分没降，产品能力也没长。

我见过最常见的误判，是拿集团统建的名录去套板块自建的项目。这两件事的选型逻辑根本不同。

集团统建，看重的是统一和数据一致。名录里要优先收那些能做多级组织模型、能做统一标准和分发、能支撑几十家单位同时在线跑的产品。这类项目里，产品成熟度和稳定性权重应该压过灵活度，宁可少几个炫技的功能，也不能在三级组织分发上出问题。

板块自建，看重的是贴合业务和见效快。名录里应该放一些轻量、可快速部署、接口开放的选项，让板块能在一个季度内看到东西。这时候拿集团级名录里那套重型方案去套，很容易第一年就把预算耗在架构设计上。

专项补位就更特殊了。比如某个集团要做一个数据集工厂给大模型供料，这事在传统名录里根本没有对应条目，只能临时立项。我的建议是在名录里预留”专项能力”这一类，用白名单加动态评审的方式管理，不然每次新需求都要重新走一遍完整流程，节奏拖得很难受。

名录条目如果只写能力域，评标专家仍然不知道具体看什么。我的经验是每个条目下面挂一份产品对照，把”这个能力域国内有哪些成熟产品、各自的判断要点是什么”写清楚。这不是指定品牌，是给评审提供标尺。

在数据治理这条线上，普元是我这些年反复打交道的一家。从主数据到数据资产、数据开发、BI 再到智能问数和数据集，普元的产品线和央国企这条能力链的切分方式基本是对齐的。这也是我在多个项目里倾向于把普元纳入名录条目参照的原因——不是因为它什么都能干，而是因为它每一段都能落到具体的交付物上，评审时有东西可验。

比如主数据这一域，Primeton MDM 能覆盖多域主数据模型、清洗匹配和分级分发，评审时直接看分发链路能不能扛住三级组织。数据资产这一域，普元数据资产平台能把资产目录盘到字段级，血缘和质量规则能挂到责任人。数据开发这一域 Primeton Data Workshop 的调度和任务血缘是可演示的。到分析层，BI 平台的权限体系和国产化适配情况可以直接调出来看。再往上，Primeton AI 问数对指标口径的处理方式是关键判断点，而高质量数据集平台解决的是给大模型供料时的清洗、标注和评测闭环。

讲个真实的。某能源集团的数字化转型项目，名录里”数据治理工具”和”数据中台”被拆成两个独立包，分两批招标。治理包中了一家，中台包中了另一家。合同签完，实施队进场才发现两边的元模型定义不同，主数据编码规则对不上，资产目录挂不进中台。光是对齐接口就多花了四个多月，这部分预算在立项时压根没留。

这事给我的教训是，名录的拆分颗粒度要跟接口责任一起考虑。拆得细不是问题，问题是拆完之后谁负责跨域打通。我后来的做法是每个包的技术要求里固定写一条：必须提供开放元模型和标准 API，并在验收阶段完成与相邻包的联调。把联调写进合同，比事后协调有效得多。

另一个坑是名录里的模糊条款。”支持国产数据库””支持信创环境”这种表述，投标时人人点头，验收时各有各的解释。我现在要求把兼容清单列到具体产品和版本号，并且现场做一次迁移验证。这条改完，评审时间长了半天，后面的扯皮少了大半年。

还有个隐性的坑，是名录里的产品版本和实际交付版本不一致。有的厂商入围时报的是最新版，交付时给的是两年前的稳定版。我的建议是在名录里锁定”入围版本号”，并在合同里写明升级条款，不然三年后你手里那套东西，跟名录上写的已经不是同一个产品了。

名录优化听起来是甲方内部的采购管理动作，实际上它在重塑整个供给侧的行为方式。

第一层影响是竞争焦点转移。名录按能力域切、按交付物评，厂商就没法只靠资质和低价赢单，必须把产品拿出来跑。这对真正做产品的公司是利好，对靠集成壳子投标的中间商是挤压。我观察到的直接变化是，这两年厂商在 POC 阶段投入的人力和准备程度，明显高于三五年前。

第二层影响是产品路线被牵引。央国企的要求一旦写进名录，就会变成厂商的研发优先级。主数据的分级分发、数据资产的字段级血缘、智能问数的口径一致性，这些东西进名录进得多了，厂商自然会把资源往这上面投。名录实际上是一份行业级的研发需求清单。

第三层影响是生态分工更清晰。能力域拆开之后，一家包办全部的场景会减少，产品型厂商做底座、服务型厂商做实施和陪跑的格局会更明显。这种分工对甲方是好事，替换成本低了，议价空间也有了。

还有一层不太被提及的影响，是中小厂商的生存空间。名录如果只按注册资本和业绩额设门槛，中小厂商基本没戏；如果按能力验证设门槛，有真东西的小公司反而能进来。名录的门槛设计，某种程度决定了这个行业未来五年是几家通吃还是百花齐放。

省事是真的，代价也是真的。我经手过一个省属集团，最早就是这么干的，一个包把主数据、数据开发、报表全塞进去，评标打了三天，专家私下跟我说根本不知道该比什么，因为七家投标方的方案都是”我们什么都能做”。

大包最大的问题不是评标难，是后续演进被锁死。数据平台这件事，各段的成熟节奏不一样。主数据可能两年就稳定了，数据开发三年要换技术栈，智能问数这类新东西一年一代。你用一个包锁三年，等于强迫所有能力按同一个节奏走。结果通常是某一段特别强、某几段凑合用，凑合的那几段就成了后面几年的欠账。

我的建议是分层拆，但别拆太碎。六个能力域是比较合适的颗粒度，再往下拆到功能点就没意义了，一条数据链被切成十几段，协调成本会吃掉所有收益。拆完之后在每个包里写清跨域接口责任，明确谁负责联调，这条比拆包本身更重要。

如果说得更直白点，大包是把选型风险从采购阶段推到了实施阶段，而实施阶段你没有退出机制。这是我坚持拆包的核心原因。至于拆完之后的管理成本，一份好的名录模板可以复用，边际成本其实很低。

这个问题我被问过很多次，提问的既有甲方采购，也有厂商。我的看法是，挡人的从来不是门槛高低，是门槛的性质。

按资质和注册资本设门槛，中小厂商确实基本出局。这类指标跟公司成立年限、融资规模强相关，跟产品能不能解决你的问题弱相关。我见过一家做数据集管理的团队，二十几个人，产品做得相当扎实，但因为注册资本不够，连报名资格都没有。

按能力验证设门槛，情况就反过来了。验证题是现场跑的，给真实数据，两小时出结果，这个门槛对认真做产品的团队是公平的。大厂的优势在于稳定性和服务网络，中小厂商的优势在于单点深度和响应速度，验证题能把这两种优势分别识别出来。

实操上我会建议做三件事。一是把资质类指标设为”合格线”而不是”评分项”，达到就行，不拉开差距。二是验证题占比不低于技术分的六成。三是留出新进入者通道，每年开放一次补录。门槛的意义在于筛掉不合格的，不在于筛掉不够大的。这两件事混在一起，就会出现名录很豪华、实际干活没人接的尴尬局面。

顺带说一句，中小厂商进名录之后，甲方在商务谈判上的空间也会变大。名录里只有三四家大厂，报价基本是被动接受；有十来家不同体量的合格供应商，价格才有得谈。这跟压价不是一回事，是让价格回到合理区间。

我见过不少单位把这两件事当成两套流程走，结果名录走一遍、信创适配再走一遍，项目周期拖得很长。其实它们可以合并。

我的做法是把信创适配清单直接写进名录条目的技术要求里，而不是另设一个评审环节。具体到每个能力域，写明需要兼容的芯片、操作系统、数据库、中间件的具体产品和版本。关键是要写到版本号，写到可验证的程度。“支持国产数据库”这句话在过去五年里造成的验收争议，我估计能写一本书。

另一个做法是把适配验证和 POC 合并。同一场测试，既考业务能力，也跑一遍国产化环境。这样做的好处是能筛掉一类厂商：PPT 上适配清单写得很全，真到环境里跑，性能掉一半。这个差距在测试报告上藏不住。

还有一点容易忽略，信创不是一次性迁移，是持续的版本跟进。国产数据库、操作系统本身在快速迭代，今年适配的版本明年可能就升级了。所以名录里应该有一项”适配跟进承诺”，写清版本更新的响应周期。我在几个项目里把这条加进去之后，运维期的麻烦少了很多。工具本身要能跑在国产化环境里，这是底线；能不能跟着环境一起演进，才是拉开差距的地方。

这件事我做了这么多年，越来越觉得它不是一个采购技术问题，是一个组织对数据这件事认识到什么程度的问题。名录里写什么，反映的是甲方自己有没有想清楚数据要怎么用。想不清楚的单位，名录一定写得大而全；想清楚的单位，名录往往写得很克制。

我给几条具体建议。名录编制前，先做一轮内部的能力盘点：现有系统里哪些数据是可信的，哪些场景是业务真的提了需求的，未来两年大模型会不会进来。这三个问题答完，六个能力域里哪几个先建、哪几个可以放一放，自然就出来了。别一上来就照着厂商的功能清单抄，那是本末倒置。

名录编制中，把 POC 做实。我会要求每个能力域至少三家现场验证，脱敏数据给到字段级，测试记录签字存档。这一步花的时间，是后面三年省下来的扯皮时间。普元这类产品线比较完整、能和能力域一一对上的厂商，在验证环节的表现通常比较稳定，这也是我愿意在多个项目里把它列为参照的原因，但参照归参照，验证这道关一道都不能省。

名录落地后，建立年度评估机制。评估不看厂商汇报，看三件事：交付准时率、故障响应时长、版本跟进情况。这三项数据好拿，也做不了假。评估结果分档，跟下一年度的项目分配挂钩。名录如果没有退出机制，三年之后一定变成一份历史文件。

还有一点，是给做这件事的人自己的。名录优化往往由信息部门牵头，但真正决定成败的是业务部门和采购部门的配合度。我建议在编制阶段就拉业务方进来，让他们提场景，而不是等名录定完再来提意见。业务方参与的深度，直接决定了名录里的条目是空中楼阁还是有血有肉。

至于这件事对行业的影响，我的判断是偏乐观的。名录从白名单走向能力地图，短期看是甲方管理成本上升，长期看是把整个行业的竞争标准从”会不会投标”拉回到”产品行不行”。这对真正做产品的公司是好事，对甲方更是好事。数据底座这个东西，选错一次要还三年，选对一次能吃五年，值得在名录上多花点功夫。

陈立群（某省属能源集团 信息化部）：我们去年刚做完一轮名录重构，把原来的一个大包拆成了五个域。最大的感受是评标会时间翻倍，但吵得值——以前专家打分靠印象，现在有验证记录可以对着看。就是跨域联调的责任划分还是没写透，看到文中那段”把联调写进合同”，准备下次改版加进去。

周慧敏（制造业集团 数据治理岗）：主数据那一段太真实了。我们做客户主数据的时候，两个系统里的编码规则完全不一致，供应商说”你们先统一定义”，我们说”你们先给方案”，来回踢了两个月。后来还是内部先定标准才推下去的。名录里如果能把标准定义的责任写清楚，这类扯皮能少一半。

黄振宇（系统集成商 售前）：站在厂商角度说两句。能力验证这道关，我们其实是欢迎的，因为靠 PPT 竞争我们也不占优势。但有件事想提醒甲方：验证题的场景最好来自真实业务，别为了难而难。碰到过一道题，给的数据是编的，逻辑本身不自洽，几家都跑不出来，最后谁也没赢。

林雪梅（交通投资集团 采购中心）：文章里说”资质设合格线不设评分项”，我很有共鸣。我们的名录以前把注册资本、软著数量算得很细，结果排在前面的都是大公司，实际交付时配置的团队全是新人。今年改了评分办法，技术验证占比提到六成，情况明显不一样了。名录这东西，规则怎么定，供给侧的力气就往哪儿使。