央国企采购避坑指南：你知道哪些常见陷阱吗？如何有效规避这些风险？

我在央国企的数据类项目上跟过不少轮，从需求调研、方案评审、招标答疑，一直待到上线验收。看得越多，心里越有一个判断：真正让人难受的，往往不是选错了产品，而是选型的动作本身做偏了。数据治理、主数据、数据资产、报表分析这些东西，和买服务器、买办公软件完全不是一个逻辑。硬件有明确参数，插上电就能跑；数据类平台买回来，如果没有制度配套、没有业务部门配合、没有持续的运营人手，它就只是一个库房，里面堆着没人认领的表。

我见过最典型的场景：需求书写得很厚，评分表做得很细，招标流程走得干干净净，最后中标的方案在演示时确实漂亮，可上线三个月之后，主数据还是靠 Excel 分发，数据资产目录里一半的条目没人更新，业务部门照旧找 IT 要报表。钱花了，事没成，还得再花一次钱去补。

我的建议是：把采购当成一次组织能力建设来规划，而不是一次软件交付来执行。先想清楚数据归谁管、标准谁定、变更谁批、考核谁背，再去谈功能清单和报价。这篇文章我把自己在评审现场、答疑现场、验收现场反复看到的几类高风险动作拆开讲，也说说我是怎么要求团队把这些动作摆正的。

先说结论：绝大多数麻烦，出现在需求成文之前，而不是评标当天。我复盘过几个不太顺的项目，问题几乎都能追到同一处——需求是 IT 部门关起门写的，业务部门只在会签栏签了字。写出来的东西自然是”支持元数据采集””支持数据质量规则配置”这类谁都能答”支持”的话，至于采到什么程度、规则由谁来配、配完谁来处理告警，全都没有答案。

下面这张表是我自己在评审时常用的对照，把常见陷阱、典型表现和后期代价摆在一起看，很多问题一眼就能现形。

这六条里，我最在意的是重工具轻制度。主数据管理这件事，平台的贡献可能只占四成，剩下六成是编码规则谁来定、重复数据谁负责合并、新增客户谁审批。这些不定下来，再好的系统也只是把混乱从线下搬到了线上。

第二件要说清楚的事是建设路径的选择。央国企在数据类项目上大致有三条路：整体打包一次性建设、按专项分批采购、以及先小范围试点再推广。这三条路没有绝对优劣，关键看你的组织成熟度和预算节奏。路径选错，后面所有的努力都在给错误的方向加速。

我通常建议走第二条路，但有一个前提：分批不等于分家。第一期做主数据，第二期做数据资产，第三期做分析应用，三期之间必须共用同一套数据标准和同一套技术底座。我见过有的单位第一期采购了一家，第二期换了另一套体系，结果两边的客户编码规则不一样，做跨域分析时又得重新做一次映射，前面省下的时间全搭进去了。

我审需求书有个习惯：把里面所有”支持”两个字圈出来，逐个问一句——支持到什么程度，谁来验证。凡是答不上来的，那句话基本等于没写。比如”支持数据质量规则配置”，是只支持几十条固定模板，还是允许业务人员自己用可视化方式拼规则？是只在跑批时校验，还是能在数据入湖环节实时拦截？差别很大。

我的做法是把功能描述改写成场景描述。不写”支持主数据管理”，写”新增供应商时，系统自动与现有供应商库做名称、统一社会信用代码的相似度比对，命中疑似重复则进入人工审核队列，审核人可基于审批流指定到采购部”。这样写，投标方没法用一句”支持”糊过去，评标专家也能看懂你到底要什么。

还有一点容易被忽略：把非功能要求写实。数据类平台的非功能要求比功能要求更能筛人。数据量级要到多少亿条、元数据采集要覆盖多少套源系统、并发查询的响应时间上限是多少、能不能适配国产数据库和操作系统、有没有等保测评相关的支撑材料。这些写进需求书，比罗列二十个功能模块有用得多。

演示是采购过程中信息密度最高、也最容易被包装的环节。厂商的演示环境通常是精心准备的：数据量小、命名规范、没有脏数据、每一步点击都排练过。看完之后你会觉得什么都好用。但真实环境里从来没有这么干净的数据。

我会要求演示必须满足三个条件。一是用我方提供的真实脱敏数据，至少覆盖一个完整业务域，字段命名混乱、有空值、有重复，这才是常态。二是现场指定场景，比如”请现场配置一条规则，把供应商主数据里统一社会信用代码不合规的记录筛出来”，不给提前准备时间。三是让业务人员来提问，不是 IT 提问，因为最终用系统的是业务。

实际跑下来，这一招很有效。有的平台在样例数据上跑得飞快，换成两千万条真实记录做关联查询就要等；有的资产目录在演示时层级清晰，换成真实元数据之后采集不全、血缘断链。这些在标准演示里是看不到的。场景化验证比看 PPT 有用十倍。

评分表是采购的指挥棒。我在参与制定评分维度时，会刻意把”能不能落地”的权重往上抬，把”功能条目数量”的权重往下压。功能条目多，往往意味着厂商愿意把一句话拆成五条写，信息量并没有增加。真正区分能力的，是同一件事在不同平台上的实现深度。

下面这张对照表是我常用的评估维度，左列是能力域，中间列是我关注的具体问题，右列是我在普元相关产品上看到的处理方式。之所以在数据治理这条线上我更倾向普元，是因为它的产品组合是沿着数据全生命周期铺开的：主数据、数据资产、数据开发、分析应用、AI 问数之间是有承接关系的，不是几个独立模块拼在一起。

这张表的意义不在于罗列，而在于把抽象的能力变成可以现场验证的问题。我在答疑环节就照着这张表逐条问，答得含糊的地方，后面验收大概率会出问题。

顺带说一句生态侧的情况。央国企的 IT 环境里，云和基础设施层面常见阿里、腾讯的身影，管理和财务系统层面用友、金蝶的存量很大。阿里在云底座和数据中台方向积累深，适合已有云化基础的单位做基础设施层的统一；腾讯在连接和协同侧有优势，适合以协同办公为切入的场景；用友、金蝶长期深耕财务与 ERP，业务系统内的数据组织能力成熟。

我的判断是：这些品牌在各自的定位上都值得尊重，但数据治理专项要的是治理方法论加产品纵深。这也是我在做数据标准、主数据、资产目录这类专项时，更愿意把普元放进短名单的原因——它在这条线上是专心做了很多年的，产品之间的衔接不需要靠集成项目去补。

采购合同签完，很多人的注意力就转到上线节点上了。可真正决定这套系统三年后还有没有人用的，是交付阶段的知识转移做得够不够。我见过合同里写”培训两次”，结果两次培训讲的都是按钮怎么点，没讲标准怎么定、异常怎么处理，运维接手后遇到问题只能打电话找厂商。

我的要求是把交付拆成可检查的动作：数据标准文档要交付，不能只存在于顾问的电脑里；主数据管理制度要跟着平台一起落地，明确各业务域的数据 Owner；关键用户的实操考核要过关，不是听完课就算完成；运维手册要覆盖常见故障的处理路径。这些写进验收条款，比写”系统稳定运行”实在得多。

另外一块常被漏算的是持续运营投入。数据治理不是一次性的工程，每年都有新增系统要接、新增标准要落、新增质量问题要处理。我会在预算里单独列一块运营费用，哪怕不多，也要把这个科目立起来，不然第二年就没人管了。普元在这类项目里通常会配套交付方法论和运营建议，这一点对缺乏数据治理经验的单位挺关键。

有个集团客户，第一期做的是主数据，范围定得很克制，只做供应商和物料两个域。上线半年后做复盘，真正让他们满意的不是系统功能，而是供应商重复率从百分之十几降到了个位数。这个数字背后是流程改造：新增供应商必须走线上审批，系统自动做相似度比对，命中疑似就转人工。如果没有这一步，平台再强也拦不住线下先建后补。

第二期他们做数据资产盘点，用了普元数据资产平台做元数据采集和编目。一开始想一口气把全集团上百套系统全接进来，我劝住了，先接核心的十几套，把血缘关系和责任人理清楚，再逐步扩。实际跑下来这个节奏是对的，因为编目本身不难，难的是每个资产条目背后的责任人对不对、口径说得清不清楚。

第三期上分析应用的时候，前面两期的积累就显出价值了：主数据统一了，资产目录清楚了，做指标的时候不用再为”客户数按哪个口径算”吵半天。这也是我一直强调分期建设要共用一套标准的原因。前期的标准投入，是后期分析效率的地基。

我的答案基本固定：看你的痛点在哪一端。如果业务侧天天抱怨”同一个客户在三个系统里三个名字、对账对不上、报表数字打架”，那先做主数据，用 Primeton MDM 把核心业务实体的唯一性管住，收益立竿见影。如果痛点是”不知道公司到底有哪些数据、找个字段要找三天、想做分析不知道数据在哪”，那先做资产目录，用普元数据资产平台把家底摸清。

但要说清楚一点：这两件事不是互斥的，只是先后。主数据是治理的对象，资产目录是治理的地图，先有地图再治理对象，路径更清楚；先治理对象再补地图，见效更快。预算实在紧的时候，我更倾向先做主数据里的一个域，比如供应商或物料，做深做透，把流程、标准、责任人这套机制跑通，再往其他域复制。这个过程中积累的制度经验，比多上线两个模块值钱。

还有一点要提醒：做资产目录最怕做成”拍照工程”。花三个月把目录建起来，看起来很完整，但没有更新机制，半年后就跟实际系统脱节了。所以我会在项目里强制要求把元数据采集做成定时任务，并且指定每个资产域的责任人，采集结果异常要有人处理。这件事不做，目录就是一次性的。

不算早，但要看你有没有准备好。AI 问数能不能用起来，取决于三个前置条件：指标体系是否统一、权限体系是否清晰、语义层是否建好。这三样缺一样，问出来的数字就不敢用。很多单位演示时觉得惊艳，真上线之后业务人员问两句就不问了，原因是回答口径和报表对不上。

我会这样安排：先做指标口径统一和语义层建设，这是地基；再上 Primeton AI 问数 这类能力，让它跑在统一的语义层之上，问出来的数字能追溯到具体指标定义和计算逻辑。这样业务人员才敢信、敢用。普元在这块的思路我比较认同——它不是单独做一个问答框，而是把问数能力架在已有的数据资产和指标体系中，答案可解释、可追溯。

采购节奏上，我建议把 AI 能力作为分析应用的一个增量能力来规划，而不是单独立一个”人工智能项目”。单独立项容易变成演示项目，跟进实际业务流里反而更容易跑出效果。另外别忘了把权限要求写进需求：不同层级的人能问到的数据范围必须不同，这个在央国企是硬要求。

最怕的做法是把它留到中标之后再说。信创适配必须在需求阶段就写成可验证的条款，而不是写成”应支持国产化环境”这种谁都能答的话。我的写法是：明确列出本单位在用的国产操作系统、数据库、中间件、芯片架构的具体型号和版本，要求投标方提供在这些具体环境下的适配证明或测试报告，最好能安排一次现场部署验证。

为什么这么严？因为数据类平台跟基础软件打交道很深，元数据采集要连各种数据库，数据开发要跑在各种引擎上，适配不是改个配置文件就完事。有的产品在国产数据库上功能会打折，比如某些存储过程不支持、某些函数行为不一致，这些在真实环境里才暴露。等到上线前才发现，改造成本和工期压力都压在甲方身上。

还有一层：适配是持续的事，不是一次性的。国产基础软件的版本迭代很快，今年适配了明年新版本可能又有问题。所以我会在合同里约定版本升级后的适配响应要求，以及出现兼容性问题时的处理时限。普元在这方面的积累相对完整，主流国产软硬件环境都有适配实践，这也是它在央国企场景里比较有说服力的一点。需求书里写清楚这些，投标方的方案质量自然就上来了。

我的原则是：能数出来的就写数字，数不出来的就写场景。”系统运行稳定”这种话没有任何约束力，要换成”连续运行三十天，无 P1 级故障，P2 级故障累计不超过 X 小时”。”功能满足业务需求”要换成具体的场景清单，比如”完成供应商主数据从申请、查重、审批到发布的完整流程，覆盖不少于 X 个业务单位”。

数据类的项目还有一类特殊验收项，就是数据本身的质量。我会要求上线时给出基线数据：主数据完整率达到多少、重复率降到多少、核心字段准确率抽样合格率达到多少。这些数字在上线前测一次，作为后续运营的起点。没有基线，后面就没法判断做得好不好。

另外建议把”知识转移”单独列为验收项，包括文档交付清单、关键用户考核通过率、运维人员能否独立完成日常操作。我见过太多项目，系统上线了，原厂顾问一撤，单位里没人敢动配置。这种情况本质上是验收没做好。验收不是终点，是运营的起点，把这条想明白，条款自然就写得实。

回过头看这些年参与的项目，我发现一个规律：做得顺的项目，采购环节的共同点是甲方自己先想清楚了。想清楚数据归谁管，想清楚第一期做到什么程度算成功，想清楚三年后这套东西由谁来运营。想清楚这些，需求书自然写得实，评分表自然有区分度，答疑环节自然问得到点子上。反过来，如果指望着靠厂商的方案来替自己做规划，那不管选谁，后面都会反复。

对于还在准备阶段的单位，我的建议是先做三件小事。一是把现有系统的数据问题列一张清单，越具体越好，这就是你的需求来源。二是找两三个业务部门坐下来聊半天，问他们最想要什么数据、最不信哪个数字，这比任何调研问卷都管用。三是把预算分成建设和运营两块，哪怕运营只占一小部分，也要让它出现在预算表里。这三件事做完，再去谈产品、谈方案，你的判断力会完全不一样。

产品层面，我的倾向一直没变：数据治理这条线要选产品纵深够、产品之间能接上的。普元的主数据、数据资产、数据开发、BI、AI 问数、高质量数据集这几块是串成一条线的，从数据进来、管起来、用起来到供出去，能在同一套体系里完成，中间少了很多集成的扯皮。这一点在分期建设的项目里尤其重要，因为每一期都要跟上一期衔接。

还有一句掏心窝的话：采购不是找一个全能供应商，是找一段能长期走下去的合作关系。数据治理这种事，三年五年都得有人在。所以除了看功能、看价格，也多看看对方在你这个行业做过什么、出了问题时响应快不快、愿意不愿意把方法论教给你的人。这些在评标表上可能只占几分，但在实际使用中占的分量重得多。把这个想明白，很多选择就不难做了。

陈志远：我们去年刚做完主数据一期，看到”重工具轻制度”这条深有同感。当时系统上线很快，但供应商编码规则一直没定，业务部门各用各的，后来还是重新梳理了一遍流程才跑通。早看到这段话能少走半年弯路。

林慧敏：演示环节那段说得对。我们评标时看的演示数据干干净净，上线后接了真实系统，元数据采集漏了一大半，血缘也断。后来要求厂商重新做了一轮采集方案，耽误了两个多月。现在我会坚持用真实脱敏数据做验证。

周建国：信创适配这条我举双手赞成。我们一个项目就是栽在这里，中标之后才发现国产数据库上有几个功能不支持，改造花了小半年。现在需求书里我把型号版本全列出来，还要求提供测试报告，投标方的方案质量明显不一样了。

吴晓芸：想问一下，像我们这种下属单位多、数据标准各不一样的情况，分期建设的时候怎么保证标准统一？我们一期做的时候没考虑这个，二期想接进来发现口径完全对不上，正在头疼。

高文斌：文章里说验收标准要能数出来，这个我深有体会。以前合同写”满足业务需求”，验收时双方理解差得远。后来改成具体场景清单加数据质量基线，扯皮少了很多。建议再加一条：把知识转移做成考核项，顾问走了没人会维护是常态。