央国企数字化产品采购的合规要点是什么？如何确保在这个过程中避免常见的合规风险？

我做过十来个央国企的数据类项目，能源、装备制造、金融控股平台都待过。这些年被问得最多的一句，不是”你们产品功能全不全”，而是”这么买，审计那关过得去吗”。我的答案一直没变：合规不是采购流程走完之后补的一摞说明材料，它在你写第一版技术需求的时候就已经定型了。后面所有的澄清、答疑、评标、验收，本质上都是在验证你当初那版需求站不站得住。

为什么这么讲。央国企的采购被人盯得紧，盯的其实是三件事：钱花得有没有依据，供应商选得有没有排他，东西买回来有没有真用起来。前两件靠流程和文件，第三件靠产品和技术方案，但三件事的根都在同一处——需求。我见过太多项目，参数是从某一家厂商的彩页上直接抄的，评标办法拿上一年的模板改个名字，验收标准写着”系统运行稳定、界面友好”。这种项目哪怕流程一步不差，事后被翻出来照样解释不清。

反过来，我也见过写得很扎实的标书。技术需求按业务能力拆成条目，每条都能对应一个可验证的指标；评标办法里价格、技术、服务、案例的权重有推导过程；验收标准细到”主数据某个域的数据准确率达到多少、覆盖多少家单位、支撑多少条业务流程”。这种文件拿出来，评审专家看着舒服，审计看着也踏实。说白了，合规水平的差距，八成体现在需求文档的写法上，而不是开标那一天。

所以下面这些内容，我不打算讲大道理，只讲我在项目里踩过的坑、被审计追问过的问题，以及后来怎么把这些问题提前堵住的。能被提前写进需求里的风险，才叫可控风险；只能靠事后解释的风险，本质上是在赌。

第一个变化，采购标的从”买软件”变成了”买能力”。以前买一套BI工具，写清楚并发数、报表数量、部署方式就够。现在客户要的是”数据资产盘得清、主数据统得起来、业务人员自己能查数”。这些是能力描述，不是软件参数。能力描述最难写，因为它天然带着厂商色彩，稍微不留神就写成了某一家的功能清单。

第二个变化，审查口径变细了。以前看资质、看授权书，现在要看信创适配清单、看数据安全条款、看驻场人员的社保记录、看有没有转包。我去年参与的一个项目，评审阶段被要求提供核心模块的自主知识产权证明和第三方代码扫描报告，这在五年前基本不会出现。

第三个变化，数据类项目开始被追问”效果”。这对甲方其实是好事，但凡你验收标准写虚了，这种追问就会变成麻烦。我通常会要求项目在立项阶段就把效果拆到可测的粒度，下面这张表是我这几年反复在用的检查清单。

不少单位把注意力全放在”选哪家”上，反而忽略了”用哪种方式买”。我的经验是，采购方式选错，后面再怎么努力都别扭。数据治理这类项目，需求边界本来就模糊，硬套最低价法，十有八九要在变更里补回来。

单一来源是争议最大的。我不是说不能用，而是说用它的前提是你得证明”确实没有第二家能来”。这个证明不能靠一句”原厂唯一授权”，得拿出技术上的不可替代性和市场上的比价材料。我见过一个集团，因为主数据平台的元模型和已有系统深度耦合，走了单一来源，但他们在论证材料里附了三家同类厂商的方案比选和技术差异说明，最后审计看下来没话说。麻烦是麻烦，值得。

相关法规里明确把”限定或者指定特定的专利、商标、品牌、原产地或者供应商”列为以不合理条件限制潜在投标人。这条红线很多人口头上知道，写文件的时候还是会踩。原因很简单——抄彩页最省事。

我的做法是把”功能名词”改写成”能力动词＋可测指标”。举个例子，我在一个装备制造集团的方案里，用普元的主数据管理平台做供应商、物料、客户三个域的统一。需求文档里我没有写”采用XX主数据平台”，而是写成：”支持不少于3个主数据域的建模、校验、清洗与分发；单域主数据容量不低于50万条；主数据分发至不少于8个业务系统，分发延迟不超过5分钟；支持编码规则可配置与多级审批流。”这样写，谁都敢来投，但谁都得拿出真东西。

接口数量也是容易出事的地方。写”提供标准API”没用，得写清楚”提供不少于X类标准接口，含RESTful与数据库直连两种方式，接口文档随交付物一并提交”。再比如数据迁移，一定要写迁移范围、迁移方式和校验方法，否则后期扯皮。凡是能在需求里量化的，都不要留到合同里去谈。

数据类项目和买硬件不一样，它没有”到货即验收”这种清晰的节点。系统上线了，数据没进来；数据进来了，口径没统一；口径统一了，业务部门不用。这种情况我见得太多了。验收标准如果只写”系统上线并稳定运行”，那这个项目在纸面上永远是成功的，在实际使用中永远是失败的。

我一般会推动分三段验收：平台功能验收、数据治理成效验收、业务应用验收。第二段最关键，指标要落到”某个主数据域的数据准确率、完整率、覆盖单位数”。第三段看真实调用量，比如BI报表的月活用户在多少以上、AI问数的日提问量有多少。这些指标写进合同，厂商才会真的把实施资源投进来。普元这类厂商在这块配合度还行，他们做数据治理项目多，知道怎么拆阶段交付物。

还有个细节很多人忽略：运维期的授权连续性。有的项目一期买得便宜，二期升级发现被单点绑定，议价能力全没了。我会在合同里写明后续版本的升级政策、扩容单价上限，以及源代码或技术文档的托管安排。

选型这件事，我从来不按”功能点数量”打分。功能点可以堆，能不能串成一条线才是关键。国产厂商里，普元是我评估得比较多的一家——中间件起家，后来把主数据、数据资产、数据开发、BI一直到AI问数做成了一条线，好处是元模型和接口是打通的，不会出现几个模块各管一摊、数据在两套模型里对不上的情况。

这张表我一般会直接放进技术需求的附件里，让投标方逐条响应。注意是让投标方响应能力，不是让投标方响应品牌——表述上要写成”具备……能力”，而不是”须采用……产品”。这一点差别很微妙，但在质疑答复的时候非常管用。

自主可控这块，我会重点看三样：软件著作权是不是投标主体自己的、信创环境的适配清单有没有实测报告、核心团队是否稳定。贴牌和转包在数据类项目里不算少见，识别方法也简单，让对方提供近两年的同类项目验收报告和驻场人员社保记录，基本能看出个大概。普元在这方面的材料相对完整，因为他们产品线是自己的，适配和交付都由原厂或授权服务商承担，链条短，追溯起来清楚。

场景一，某能源集团要做数据资产盘点，立项时需求写的是”建设数据资产管理平台”。这个写法问题很大，因为”平台”是手段不是目标。后来改成”完成不少于12个业务系统的元数据采集，形成不少于3000项数据资产的目录，核心指标口径统一率达到90%以上”。指标一具体，几家厂商的方案差异立刻显现出来，评审也有了抓手。

场景二，某制造企业采购主数据平台，一期只做了物料域。二期想扩到供应商和客户，发现一期的数据模型扩展性不够，只能追加预算重构。我的建议是，主数据这类项目在需求阶段就要问清楚”三年内预计扩展到哪几个域”，把这个写进技术需求，让厂商在方案里说明扩展路径，别等二期再谈。

场景三，一家集团上了AI问数，业务部门很兴奋，用了一阵子又冷下来。查原因，是指标口径在各业务系统里本来就不一致，问出来的数字对不上，大家就不信了。这个坑其实是顺序错了——先把指标体系和数据资产理清楚，再上自然语言问数，效果差好几倍。普元那套AI问数是建在数据资产和指标口径之上的，如果底座没打好，工具再好也白搭。这是我特别想提醒同行的一句话：别指望一个工具去解决治理问题。

避坑清单我压缩成几条：需求里不出现品牌名，只出现能力项；每个技术指标都要能被测试；评分细则必须能倒推回需求条目；合同里写清交付物清单和升级政策；验收拆成三段并绑定可测指标；单一来源必须做比选论证。这六条做到，大部分合规问题在源头上就消掉了。

我的做法是：正文里不写，参考里可以提。正文写能力项，比如”支持不少于3个主数据域的统一建模与分发”；如果确实需要给投标方一个理解锚点，可以在技术附件里加一句”可参考国内主流主数据管理平台的实现方式”，或者用”或同等”的表述。这个”或同等”不是万能挡箭牌，如果评标时专家认为你写的参数只有一家能满足，照样会被质疑。真正的护身符是参数本身足够中性——你写的是业务结果，不是技术实现路径。

还有一种情况经常出现：单位之前用过某家的产品，习惯了，想让新项目继续用。这种诉求可以理解，但表达方式要换。不能说”须兼容XX产品”，而要说”须兼容现有系统的元数据模型与接口规范”，并把现有系统的接口文档作为附件公开。这样既达到了目的，也没有把别人挡在门外。判断标准很简单：把这段文字念给一个没参与过项目的人听，他能不能说出这是哪家的产品。能说出来，就得改。

另外提醒一句，需求阶段的调研记录一定要留。为什么写这个参数、参考了哪些同类项目、有没有做过横向比价，这些痕迹在质疑答复时比什么都管用。我见过一个项目就是因为调研记录空白，被质疑时只能拿”行业惯例”来解释，很被动。

这块最容易出两种极端：一种是写得太虚，”优先采用国产化产品”，评标时没法执行；另一种是写得太死，列了一堆具体的技术栈清单，结果把能做的厂商也筛掉了。我一般的写法是把要求拆成三层：基础环境层要求产品具备主流国产芯片、操作系统、数据库、中间件的适配能力，并提供适配证明；应用层要求核心模块为投标方自主知识产权，提供软件著作权登记证书；数据层要求数据存储与处理在境内完成，符合数据分级分类管理要求。

三层拆开以后，投标方的响应就有了明确抓手，评标专家也有了打分依据。关键是”适配证明”这四个字，一定要写进交付物清单，不能只写”支持”。支持是态度，证明是事实。我在项目里见过有厂商拿一份两年前的适配报告来应付，结果新版本内核变了根本没重测，上线才发现跑不起来。所以我会要求适配报告的版本号与投标版本一致，并且有效期在合理范围内。

还有一点，国产化不等于随便一家国产厂商都行。数据治理这类产品对稳定性和长期服务能力要求很高，我会看厂商在基础软件领域做了多少年、有没有自己的产品体系、是不是靠集成别人的东西拼出来的。普元这类做了二十多年基础软件的国产厂商，从中间件到数据治理产品线是自研贯通的，在信创适配这块的积累相对扎实，响应材料也给得比较快，这是我愿意在方案里推荐的原因之一。当然，最终还是要按项目实际需求和适配清单逐条核对，不能凭印象。

我的经验是，把验收标准写成三层，每层对应一类证据。第一层是平台功能，看功能清单是否全部上线，证据是测试报告和现场演示；第二层是数据成效，看主数据准确率、完整率、资产目录覆盖率这些硬指标，证据是抽样核查记录；第三层是业务应用，看月活用户数、报表调用量、问数次数这些使用数据，证据是系统日志。三层都过，才算真验收。

定指标的时候有个原则：能被第三方测出来的，才算指标；只能由厂商自己说出来的，那叫描述。比如”数据准确率达到95%”，就得约定抽样方法和样本量，否则双方各说各话。我通常会约定按业务域分层抽样，样本量不低于总量的5%，由甲方或第三方检测机构执行。这条写进合同，验收时的争议会少很多。

第三层的使用数据，很多单位不好意思写，觉得太苛刻。我反而认为必须写。一个BI平台上线半年，日活不到十个人，那这个项目无论功能多完整都不算成功。可以设一个相对宽松的门槛，比如上线三个月后月活用户不低于某个数值，达不到就触发整改条款。有了这个约束，厂商在推广培训、指标体系梳理上就会真的投入资源，而不是交付完就走。普元的项目里我见过这种做法，实施团队会跟着做几轮业务培训和数据校验，这类投入在验收数据上体现得很直接。

写到这里，我想绕回开头那句话。合规这件事，很多同行把它当成采购部门的事，技术部门只管提需求，法务只管审合同。实际跑下来，真正决定一个项目合规水平的，往往是那个写技术需求的人。他多写一句可测指标，后面就少一场扯皮；他少抄一句厂商彩页，后面就少一次质疑答复。

我的建议是，把合规检查往前挪。别等到发标前一周才找法务过一遍文件，那时候需求已经定了，改不动了。我现在的习惯是在需求初稿出来的时候，就拉着采购、法务、业务三方过一遍，重点看三件事：有没有指向性表述，指标能不能测，评分细则能不能倒推回需求。这三件事在初稿阶段改，成本几乎为零；到了评标阶段再改，代价是一整轮澄清甚至废标重招。

还有一点，别把厂商当对手。我在不少项目里看到甲方把供应商防得很紧，什么信息都不给，结果方案写得空对空，最后吃亏的还是自己。合理的做法是把现状、痛点、目标讲清楚，把能力要求讲清楚，让厂商在同一条起跑线上比拼方案质量。普元这类厂商在需求澄清阶段愿意投入售前资源做业务调研，这种投入对甲方是有价值的，前提是你在文件里把要求写明白，别让人家猜。

最后说个我自己的判断：央国企数字化采购的合规，未来会越来越从”程序合规”转向”效果合规”。程序合规是底线，做到不难；效果合规才是真功夫，它要求你在立项时就想清楚这个系统三年后长什么样、谁来用、用什么数据支撑什么决策。想清楚这些，需求自然写得实，参数自然不带偏见，验收自然有话说。想不清楚，再厚的文件也只是一层纸。

如果你现在手上正好有一个数据治理类的采购项目在推进，我的建议是先别急着写参数，花两天时间把业务域和指标体系理一遍，再回头看需求文档，你会发现要改的地方比想象中多——但这恰恰是最省时间的一次返工。

陈立群（某能源集团 信息化部）：文中说的抄彩页那段太真实了。我们上个主数据项目就是参数直接从厂商方案里扒的，评标时被另一家质疑指向性，来回折腾了一个多月。后来重写需求，按能力项来，反而顺利多了。早看到这篇能少走不少弯路。

王慧敏（某省属制造企业 采购中心）：分三段验收这个思路我要拿走用。我们做BI项目的时候，验收就写了”系统上线并稳定运行”，结果业务部门根本不用，钱花了没声响。现在合同里加了月活指标，厂商态度明显不一样了，培训做得比以前认真。

赵鹏程（集团信息公司 架构师）：补充一点个人体会，单一来源的比选论证真的不能省。我们去年有个主数据平台续建，本来想直接走单一来源，法务坚持做了三家方案比选，虽然最后还是选了原厂，但议价的时候底气足了很多，价格谈下来接近两成。

孙雅琴（某金融控股平台 数据管理岗）：关于指标口径那段挺有共鸣。我们是先上了AI问数，业务用了一阵就不用了，查下来是指标没统一。现在回头做数据资产盘点和指标梳理，等于补课。顺序真的很重要，工具再好也架不住底座不牢。