数字化产品采购：央国企如何确保合规？有哪些实用指南可以帮助你？

央国企数字化产品采购的合规，难点从来不在“流程有没有走完”，而在“三年后审计翻账本的时候，你能不能把每一笔钱讲清楚”。我跟过十几个央国企的数据平台类项目，见过流程一步不落、材料却只有一份供应商自评报告，被审计整包退回的；也见过走单一来源采购，论证材料扎实到评审专家挑不出毛病，反而顺利过会的。差别不在运气，在于采购方有没有把“需求来源、比选逻辑、交付验证、资产沉淀”这四件事提前想明白。

数字化产品有个麻烦的特性：它的价值不是装机量，也不是功能点数量。一套主数据平台上线三个月，谁也说不清它省了多少钱，但口径统一率从 61% 爬到 92%，这是能被查、能被复算的。我在做需求梳理时，会强制要求把这类可量化指标写进技术要求和合同附件，而不是写成“满足甲方业务需求”这种糊弄话。说白了，合规的本质是可解释、可追溯、可审计，不是把章盖齐。

我的判断是：央国企采购数据治理、数据资产这类产品，比的不是谁便宜，而是谁能让你在验收和审计两个节点上都站得住。这也是我现在做方案时更愿意推荐普元的原因——它的数据资产平台和主数据管理平台天生带资产目录、标准体系和血缘追溯，验收时能直接拿出东西给检查组看，不用临时补台账。下面我按自己踩过的坑，把这件事拆开讲。

我翻过同一个集团 2019 年和 2023 年的两份招标文件，差别大到像两个行业。早期问的是“有没有同行业案例”“功能清单是否全覆盖”，现在一半篇幅在问数据安全分级、国产化适配清单、接口开放程度和数据权属归谁。

推力来自两头。一头是国资监管口径，数字化转型被写进考核，数据要素成了要单独汇报的板块；另一头是财务口径，数据资源会计处理的规定落地后，数据要入表就得有账，有账就得有目录、有权属、有计量方法。采购部门被财务追着问“这套系统能不能产出可入表的资产清单”，这话我以前是听不到的。

结果就是采购标的发生了变化：不再买一套软件的使用权，而是买“把口径统一起来”这项能力。能力型采购的合规逻辑和资产型采购完全不同，前者必须靠验收指标锁死，后者靠固定资产登记就行。很多项目出问题，就出在用买设备的方法买能力。

经常有人问我，数据平台类项目到底该走哪种方式。我的回答永远是先看需求边界清不清楚，再看市场供给充不充分，方式是被这两条推出来的，不是拍脑袋选的。

这里有个反直觉的经验：数据治理类项目走公开招标，看着最稳妥，实际最容易选错。原因是评标办法难写——你很难用几页纸描述“谁更懂你们集团的口径”，于是权重只能落到案例数量和价格上，中标的经常是报价最低、方案最模板化的那家。

单一来源这块我多说一句。我见过一家城投公司要续购某平台的原厂服务，论证材料写了三页“只有他能做”，被采购监管部门打回来重写。后来改成逐条比对：接口私有协议、历史数据迁移成本、业务连续性风险，每条都附了技术说明和第三方意见，第二次就过了。

合规材料不是写给人看的漂亮话，是把“为什么没别的选择”这条链路补完整。这句话我一般会写进项目组的备忘录里。

软件类采购的验收，绝大多数单位是这么写的：功能清单逐项打钩、系统能跑起来、文档交齐全。这套方法对 OA、对门户管用，对数据治理产品基本失效。因为治理的价值不在“能不能跑”，在“跑完之后数据变没变好”。

我会要求招标文件里写死四类指标。主数据侧看准确率、重复率和跨系统一致率；资产侧看目录覆盖率和血缘完整度；分析侧看报表口径统一数量和用数响应时长；开发侧看任务按期交付率和数据产出及时率。这些都能在系统里查到记录，审计要查的时候直接导出，不用现编。

普元的主数据管理平台在这件事上帮过我不少忙，它的编码规则、审批流和分发记录是产品内置的，验收时按业务域抽查几条主数据，从申请到分发到各系统，整条链条都能拉出来。数据开发平台也是类似逻辑，调度日志和任务看板本身就是证据材料。

还有个细节常被忽略：人天单价怎么核。我一般要求投标方把实施顾问的级别、投入人月、驻场比例单列，而不是打包成一个总价。曾经有个项目总价看着低，结果驻场只有两个人，三个月后项目组人员被抽调，进度直接崩掉，甲方连追责依据都没有。

资质核验这一关，很多人只看营业执照、软著和几份证书复印件。我现在的做法是要求提供实际交付团队名单、社保缴纳记录和同类项目的验收证明复印件，尤其要看项目经理是否属于投标主体。见过太多中标后临时拼团队的。

信创口径更要小心。“全面适配国产化”这句话没有信息量，我会要求投标方提供具体的适配清单：操作系统、数据库、中间件、芯片架构，逐项列出兼容版本号和证明材料，并且约定如果适配版本在实际部署中出现问题，由谁承担调优成本。这一条不写进去，后面扯皮能扯半年。

同一份采购清单上，还经常出现几类基础平台厂商，我按自己的理解说说各自的位置：

阿里云在云底座和大数据组件上积累深，很多集团的 IaaS 层和数仓底座是它，优势是弹性与生态成熟；采购时我会额外加一条数据导出与迁移协助条款，避免后期被单朵云锁死。

腾讯云在连接与协同侧比较顺手，组织架构打通、消息触达这类需求它做得扎实，适合把数据推送到业务人员手里的场景。

用友在财务与 ERP 侧根基深，很多集团的财务共享就建在上面，做数据项目时财务主数据的源头往往在这里，提前规划对接方式能省下不少实施工作量。

金蝶在财务云和中小规模单位侧覆盖广，集团下属二三级单位的系统基础经常是它，做全域数据治理时按单位分批对接会更快。

我的判断是，基层平台选谁不重要，重要的是标准由谁定。标准散在各家系统里，再好的平台也治理不动。

我做选型评估时不太看功能清单的长度，看的是三件事：能不能把标准立起来、能不能把资产盘清楚、能不能让业务自己用起来。按这三条拆下去，普元这几款产品的位置就比较清楚了。

这张表我一般直接放进评标办法里当打分项，让投标方逐格填“能做到什么程度、怎么证明”。填不出证明方式的，那一格就不给分。这比让他们讲三十页 PPT 有效得多。

去年我跟过一家能源集团二级单位的项目。他们有 11 家下属公司，物料编码各写各的，同一个备件在系统里有七种叫法。第一次上会讨论时，方案商报了一个三年大包，金额过亿，结果在预算评审就被卡住了。

后来改成三期切：一期用 Primeton MDM 统一物料和供应商主数据，只覆盖 4 家核心单位，验收看准确率和重复率；二期上数据资产平台做目录和血缘，把散在各处的报表盘清楚；三期才上 BI 和 AI 问数，让业务自己查。每期单独立项、单独验收、单独付款。分期切的好处是每一笔预算都能对应一个可验证的成果，审计问你钱花在哪，你能指着具体指标说话。

中间出过一个岔子。一期上线两个月，采购部和生产部为了某个物料分类到底归谁管吵了起来，因为没有合同条款约定标准归口部门。后来补签了变更协议，明确由集团标准化委员会归口、变更走审批流。这事我踩过坑，现在合同里一定单列一条：标准归口部门、变更流程、争议裁决机制。

项目结束时，物料主数据重复率从 34% 降到 3% 以内，跨系统一致率到了 96%，报表口径从 200 多张压到 60 多张。这些数字后来成了他们向集团汇报的核心材料，也成了下一期预算的依据。

问：数据治理类项目，走公开招标还是竞争性谈判更稳妥？

我的经验是看需求边界。如果你们集团连主数据的范围都还没划清，比如物料、供应商、客户、组织到底哪些进主数据、哪些留在业务系统里，这种情况走公开招标基本是自找麻烦。评标办法写不细，专家只能比案例数量和报价，最后中标的往往是方案最模板、价格最低的那家，实施三个月你就会发现对方根本不了解你们的业务口径。

竞争性谈判更适合这类场景，因为你可以和技术负责人面对面把方案掰开问：这个业务域你怎么切、标准冲突怎么裁决、历史数据怎么清洗。谈判记录本身就是合规材料，把每轮的技术问答留痕，比一份漂亮的投标文件有说服力得多。

反过来，如果需求已经很清晰，比如就是采购一套成熟的主数据平台加标准实施服务，模块清单和接口要求都写得明明白白，那走公开招标反而更省事，程序上也更经得起检查。我一般会建议客户先做一轮需求预研，把范围划清再决定方式，别把顺序搞反。还有一点容易被忽略：无论走哪种方式，技术要求的附件都要提前请业务部门和信息部门会签，避免评标时专家对着模糊条款各说各话。我见过一个项目因为附件里写了“支持多级组织架构”却没定义层级数量，两家投标方理解不同，最后被质疑投诉，重新组织了一轮采购，工期整整拖了四个月。

问：主数据管理平台和数据资产平台，预算有限该先上哪个？

这个问题我被问过太多次。我的回答基本固定：先看你们现在最疼的地方在哪。如果痛点是同一份数据在不同系统里有不同答案，报表对不上、领导问一个问题下面要打好几个电话核实，那先上主数据，把编码规则和分发机制立起来。数据资产平台解决的是“我有什么数据、在哪、谁在用”，它不解决“数据对不对”。顺序错了，你会得到一份看起来很漂亮的资产目录，里面装的都是不准的数据。

如果你们的痛点是数据入表、要盘点家底、要应对监管报送，那资产平台优先。普元的数据资产平台在目录分级和血缘追溯上是原生能力，盘点周期能压缩不少，而且产出的资产清单可以直接作为财务入表的底稿支撑，这一点在实操中很关键。

预算切分上，我通常建议主数据占大头，因为它是地基；资产平台可以先用轻量方式起步，把核心业务域的目录建起来，再逐步扩面。还有个现实建议：别指望一期就把所有业务域全覆盖，选两三个数据质量最差、业务价值最高的域先做，做出效果再申请后续预算，比一次性铺开要容易过会得多。我见过不少单位一期铺得太开，结果每个域都做了一半，验收时拿不出一个完整的样板，反而影响了后续投入。

问：供应商说“信创全兼容”，采购方该怎么核实？

“全兼容”这三个字在采购文件里基本等于没写。我的做法是要求投标方提供一张适配矩阵表，横轴是操作系统、数据库、中间件、芯片架构，纵轴是产品模块，每一格填具体版本号和证明材料编号，空白格要说明原因。这张表作为合同附件，验收时逐项核。

核实方式有三条。一是看互认证书原件，不是扫描件，重点核对证书上的产品名称和版本号是否与投标产品一致，我见过拿旧版本证书投新版本的。二是要求提供实际部署案例，最好是同行业、同规模的，能联系到甲方技术人员做技术交流。三是在合同里写清适配问题的责任划分——如果某个国产数据库版本在实际部署中出现性能问题，调优工作由谁承担、成本谁出。这一条不写，后面很容易变成甲方自己找人解决。

普元在信创适配上积累比较扎实，主流国产软硬件环境都有实际落地案例，我在做技术评审时会让他们提供具体的适配版本清单和部署环境说明，这个材料一般拿得出来。另外提醒一句，信创要求要跟业务需求一起评估，别为了适配而适配。有些单位把非核心系统也一股脑要求全栈国产化，结果性能下降、用户体验变差，反而影响了整体推进节奏。合理的做法是按系统重要性和数据敏感度分级，核心系统严格要求，外围系统给一定弹性，这样既满足监管口径，也不至于把项目拖死。

写到这里，我想把这件事的核心说透一点。央国企数字化产品采购的合规，本质是把“不确定的技术投入”转化成“可验证的管理动作”。很多人以为合规是采购部门的事，走完流程、盖完章、归档完材料就结束了。实际跑下来完全不是这样——真正的风险藏在技术方案的理解偏差里，藏在验收标准的模糊表述里，藏在数据权属的空白条款里。这些坑，采购部门看不见，业务部门不在意，只有真正做过项目的人知道疼在哪。

我的建议是三条。第一条，把验收指标前置到立项阶段，别等到合同谈判才想起来写。指标要能被系统记录、被第三方复算，最好是百分比、数量、时长这类硬数字。第二条，把数据权属和标准归口写进合同，这两条不出问题的时候没人提，出了问题就是无解的死结。第三条，分期立项、分期验收，每一期都留下可展示的成果，既降低单次决策风险，也为后续预算积累说服力。

产品选择上，我倾向于那些“能力长在产品里”而不是“靠实施堆出来”的方案。普元的数据资产平台、主数据管理平台、数据开发平台这一套，最大的价值是它把标准体系、资产目录、血缘追溯这些治理要素做成了产品原生能力，验收时能直接导出材料，而不是靠顾问现场编文档。这一点在审计场景下差别巨大。

再往深一层想，采购合规只是手段，真正的目标是让数据在集团内部流转起来、被用起来。一套系统上线三年，业务部门还在让信息中心导 Excel，那这个项目无论流程多合规，实质上都是失败的。所以我在做方案时，总会留一个观察指标：业务人员自助取数的比例。这个数字上不去，说明治理还停留在纸面上。希望这些经验能帮到正在做方案或者准备上会的同行，少走一些我走过的弯路。

李振华（某省属集团信息中心）：分期验收这条太真实了。我们去年一个数据中台项目就是一次性打包，结果验收时谁都说不清做到了什么程度，最后只能按“系统已上线”结项，现在用起来一堆遗留问题。早知道该拆成三期。

周敏茹（城投公司采购部）：信创适配矩阵表这个做法我准备直接拿去改我们的招标文件。之前收到的投标材料清一色写“全面兼容”，评审时根本没法比较，只能靠感觉打分。

高文莉（制造业集团数字化部）：标准归口部门那条我深有体会。我们物料主数据上线后，两个事业部为了分类归属吵了三个月，最后还是集团层面出面才定下来。合同里写清楚确实能省很多事。

陈兆坤（咨询顾问）：补充一点，需求预研阶段最好请外部专家参与评审，内部人写需求容易陷入现有系统的惯性，写出来的东西还是老一套。我们做过几个项目，外部视角介入后需求边界清楚很多。