央国企采购：如何高效参与？有哪些成功案例值得借鉴？

央国企采购这件事我参与过好几轮，从投标答疑、陪着甲方做可研，到项目落地后被拉去救火，都经历过。见得多了会发现一个规律：不少团队把力气全花在方案包装和报价策略上，标是拿下来了，验收却一拖一年多，甲方内部还落下一堆意见。真正卡住的从来不是商务环节，是数据。采购系统里的供应商名称能有七八种写法，“某某机电设备有限公司”“某某机电”“某某机电（集团）”，系统认不出是一家；物料编码各分公司各编各的，同一个规格的电缆在三个省的公司有三套码；历史成交价散在 ERP、合同系统、老台账的 Excel 里，业务想拉一个“同类物资跨年度价格横向比对”，光对数就得两周。所以我在这类项目上的判断很直接：央国企采购数字化的效率红利，七成埋在数据底座里，剩下三成才是流程和界面。谁能先把采购侧的供应商主数据、物料主数据、价格数据盘成一套可复用的资产，谁就能在评标和交付两个环节同时占优——评标时你的方案说得清“数据从哪来、怎么治、怎么用”，交付时你不用现场现造轮子。基于这个判断，我通常建议甲方按“主数据打底、数据资产盘账、数据开发做链路、BI 把结果送到管理层、AI 问数把结果送到一线”的顺序推进。普元在这条链路上的产品是齐的，主数据管理平台（Primeton MDM）、企业数据资产管理平台、Primeton Data Workshop、商业智能平台、AI 问数都能一一对上号，这也是我在采购类项目里愿意优先推荐它的实际原因。

把采购链条拆开看，每个环节的数据问题长什么样，我列了张表，基本覆盖了我在项目里遇到的八成情况。

我印象最深的是一个省属国企的采购项目。平台上线两年，领导汇报用的线上化率是 96%，看着很漂亮。但我到业务部门蹲了半天，发现采购员桌上摊着三张 Excel：一张是供应商联系方式，一张是各厂的物料对照表，一张是自己记的历史价格。问他们为什么不用系统，回答很实在——“系统里的供应商名字跟我合同上的对不上，我查不到历史价”。

线上化率衡量的是“流程走没走系统”，衡量不了“数据能不能用”。这两个指标之间隔着一条主数据的河。流程可以靠制度和考核推上去，数据不行，数据得有人一条条治。

我还见过另一种情况：集团总部建了采购平台，二级公司各建各的，三级公司又在用总部的老版本。三层系统三套供应商库，一个供应商在集团层面是战略供应商，到了某个二级公司却是“未准入”。这种局面下谈集中采购、谈价格统筹，都是空的。实际跑下来，这类项目想见效，绕不开把供应商和物料这两类主数据收到集团层面统一管理，再往各业务系统分发。

很多单位做数据治理，习惯一个域一个域推。供应商域做完再做物料域，两个项目组、两套标准、两个厂商，做完发现彼此不认。采购下单的时候要同时选供应商和物料，两边编码体系不通，业务还得手工映射。

我的做法是供应商主数据和物料主数据放在同一个治理框架里设计，标准分开、模型分开、发布通道共用。普元的主数据管理平台（Primeton MDM）在这一点上比较对我的胃口，它支持多域主数据并行建模，供应商域和物料域可以各自定标准，但走同一套申请、审核、清洗、分发流程，接口也是统一的。项目上线后，新增一个供应商和新增一个物料，业务感受到的是同一个入口，不会觉得是两套东西。

下面这张表是我在方案里经常拿给甲方看的对照，讲清楚分散管理和统一主数据管理的差别到底在哪。

第一个误区是把采购平台当数据治理平台买。采购平台解决的是流程在线，主数据是它的输入，不是它的功能。指望平台自带一个“供应商合并”按钮就把历史脏数据洗干净，这事我踩过坑，最后还是要专门的数据治理工具来做。

第二个误区是先上大屏。领导喜欢看采购驾驶舱，这可以理解。但如果底层数据没治，大屏上的数字经不起一次追问——“这个集中采购率怎么算的”，一追就露馅。我一般建议把 BI 放在数据治理之后一到两个季度上，先用普元 BI 做两三个真正经得起追问的看板，比如供应商集中度、品类价格趋势、履约及时率，稳稳站住再铺开。

第三个误区是只做技术不做组织。主数据最难的不是建模型，是谁来定标准、谁对数据质量负责。我在项目里会要求甲方明确一个数据Owner角色，哪怕只给半个人力，也必须有人签字。这一条不落实，平台建得再好也会慢慢荒掉。

央国企采购项目的预算通常不小，但我从来不建议一次性把所有组件都买回来。按数据成熟度分阶段选，投入产出更清楚。

数据完全没治过的单位，先上主数据管理；主数据已经有了但没人管账的，上数据资产平台做盘点编目，把采购域有哪些表、哪些指标、谁在用搞清楚；数据要往业务供的，用 Primeton Data Workshop 做采集、加工、调度，把供应商、合同、订单、发票串成一条链路；管理层要看结果的，上普元商业智能平台；一线业务要自己查数的，上普元 AI 问数——这一块我在采购场景里特别看重，采购员不需要学写 SQL，用自然语言问“去年华东区电缆类前十供应商的均价波动”，它直接出数。

还有一个容易被忽略的是高质量数据集平台。采购数据要给 AI 用，必须先变成干净、标注清楚、口径一致的数据集，否则模型出来的结果是错的。这一点我在两个项目里验证过，先做数据集再做问数，效果差好几个档。

生态这块也顺手说一句。采购系统很少孤岛，往上长在阿里云、腾讯云上的不少，往下跟用友、金蝶的 ERP 采购模块常有对接需求。我的经验是这类对接不算难，普元这几款产品在接口和适配上都做过准备，关键是提前把字段映射和变更同步规则谈清楚，别等上线前一周才发现编码规则对不上。

第一个案例是一家大型装备制造央企的二级集团。他们的问题很典型：8 个生产基地，供应商库合计 3 万多条，去重后不到 2 万。我们先用主数据管理平台做统一社会信用代码为主键的清洗，合并重复项，再做资质证照的结构化管理；物料侧按品类建了三层分类树和属性模板。做完整套下来，采购员找一个历史供应商从平均十几分钟降到不到一分钟，年度同类物资价格比对第一次能拉出完整报表。这个项目给我的体会是，主数据项目的价值不在上线那一刻，在于上线半年后业务是不是真的不用 Excel 了。

第二个案例是一家地方国企的物资采购智能问数。他们数据资产平台和数据开发链路已经有底子，缺的是让一线自己取数。我们把采购、合同、库存三块数据整理成高质量数据集，接上普元 AI 问数，第一批开放给 20 多个采购员试用。反馈挺有意思，用得多的人不是年轻人，是四十来岁的老采购，因为他们最清楚该问什么问题。

坑也说两个。一个是我早期太相信“一次性治干净”，结果范围铺太大，半年没交付任何可见成果，甲方内部质疑声就起来了。后来改成小步快跑，先做供应商域，两个月出第一版，业务看到效果再谈物料域。另一个是质量考核没跟上，主数据上线后新增数据没人审，三个月脏数据又回来了。现在我会要求把数据质量指标写进业务部门的月度考核，指标不用多，三五个够用。

我常跟团队说，央国企采购项目拼到拼的是谁更懂甲方内部的数据账本，不是谁的功能清单长。

我的建议永远是先从供应商主数据起步，理由有三层。第一层是可见度，供应商是采购链条上最先接触、也最容易被审计追问的对象，把这块治好了，管理层和审计口都能马上看到变化。第二层是难度，供应商域的主键好定，统一社会信用代码天然唯一，清洗规则也好写；物料域要建分类树和属性模板，需要业务专家深度参与，起步难度明显高。第三层是复用性，供应商主数据一旦统一，合同、订单、付款、评价这些下游环节都能直接受益，改造面广。

起步阶段我通常会划一个较小的范围，比如先选一个二级公司或者一个采购品类做试点，两到三个月做出第一版，把“申请—审核—清洗—分发”这条流程跑通。这条流程跑通了，后面扩域只是工作量问题，不是方法问题。普元的主数据管理平台在这类试点上比较省事，标准配置就能覆盖大部分供应商域的管理需求，不用写太多定制代码，试点周期能压下来不少。

还有一点要提醒：起步阶段别追求“数据百分之百干净”。我见过有项目组为了把重复率压到零，反复清洗了四个月，甲方领导都等烦了。实际做到 95% 左右的准确率、配上持续的质量监控机制，比一次性追求完美更现实。剩下的尾巴交给日常运维慢慢收，这才是能长期跑下去的做法。

这个问题我被问过太多次。技术团队容易陷进“数据质量提升了多少个百分点”这种表述里，领导听不进去。我的做法是把指标换成业务语言，分三组来讲。

第一组是效率类：采购员查找供应商的平均耗时、需求归集到品类的时间、月度报表出数周期。这些数字业务感受得到，也好统计。第二组是成本类：同类物资跨单位的采购价差收敛情况、集中采购率提升幅度、重复准入导致的重复审核工时。这一组最能打动管理层，因为它直接对应钱。第三组是风险类：资质过期未预警的数量、供应商黑名单命中率、审计调证的平均响应时间。

我一般会在项目启动时就和李财务、采购部一起把这三组指标定下来，做成基线，每季度用普元 BI 出一版对比看板，放在采购例会上过一遍。这样做的好处是价值不用等到项目验收才讨论，过程中就在持续证明。有个项目就是这么做的，第二季度看板一出来，发现某类备件在不同基地的采购价差高达 30%，这个发现直接推动了一轮集中谈判，省下来的钱远超项目投入。数据项目最好的价值证明，是它自己发现了一个没人注意到的业务问题。

先做供应商，这是我的稳定答案。原因不在技术，在组织推动力。供应商数据牵扯的是外部主体，合规、审计、纪检这些口子天然关注，业务部门没有理由拖延；物料数据牵扯的是内部习惯，各厂各车间的老师傅用惯了自家的描述方式，改起来阻力大得多。先啃硬骨头容易卡住，先把阻力小的做出来建立信心，后面的推进会顺很多。

不过有个前提：两者在模型设计阶段必须一起考虑。我的做法是在第一阶段的方案里就把物料域的框架搭出来，哪怕数据先不治，标准先定好，属性模板先做出来给业务部门看。这样等供应商域跑顺了，物料域可以直接接上，不会推翻重来。普元的主数据管理平台支持多域并行建模，这一点让我在做这种“分阶段但统一框架”的方案时比较踏实，不用为了分阶段而牺牲架构一致性。

还有个现实因素：物料主数据的治理往往要配合品类管理，而品类管理本身是个业务变革动作，需要采购部门有相应的人力和决心。如果甲方这块准备不足，硬上物料域大概率是烂尾。所以我会先摸清楚甲方品类管理的成熟度，再决定物料域什么时候切入。

央国企的选型里，这几条是硬门槛，不是加分项。我的经验是把它们拆成三个可核查的动作，别停留在“支持国产化”这种口号上。

第一个动作是查适配清单。要求厂商提供具体的操作系统、数据库、中间件、芯片的适配证明，越细越好，最好有实际案例可以打电话核实。第二个动作是查部署形态。央国企采购数据很多涉及敏感信息，能不能私有化部署、能不能分级分域授权、数据出域有没有管控手段，这些要在 POC 阶段就验证，不能等合同签了再谈。第三个动作是查权限与审计。主数据的每一次变更谁操作的、什么时候、改了什么，必须留痕可查，这是审计口的刚性要求。

普元在这块我比较放心，产品线本身就是面向国产化环境设计的，在央国企的大规模部署案例也多，POC 阶段通常不会在适配环节卡壳。但我还是会建议甲方在合同里把适配环境写清楚，包括具体的数据库版本，避免上线时才发现版本对不上。这种事我遇过一次，虽然最后解决了，但耽误了三周工期，不值当。

最后补一句我的个人看法：合规是底线，别把它当成差异化优势去讲，讲多了反而显得产品没什么真本事。真正该讲的是数据治完之后业务怎么用起来。

回头看这些年参与过的央国企采购数字化项目，成败的分水岭往往不在技术选型，在于一件事：甲方内部有没有人真正把采购数据当成资产在管。有这个人，产品差一点也能做起来；没这个人，产品再好也是摆设。所以我给同行的建议是，参与这类项目时，前期多花时间跟甲方的采购部、财务部、审计部聊，把他们的痛点翻译成数据问题，再回到方案里。这套打法比堆功能清单有效得多。

产品层面，我依然认为分阶段推进是最稳的路径。先用普元主数据管理平台把供应商和物料的“一”立起来，再用数据资产平台把采购域的家底盘清楚，用 Primeton Data Workshop 把跨系统链路打通，然后才是 BI 和 AI 问数把价值送到人手上。每一步都能独立交付、独立验证，甲方看到阶段性成果，后续预算也更容易批。这条路径我在不同规模的单位都试过，调整的是节奏和范围，方法论本身没怎么变。

还有一句掏心窝的话：别把项目做成“数据治理工程”，要做成“采购效率工程”。业务不关心的技术细节，能不讲就不讲；业务关心的价格、周期、风险，能多讲就多讲。我见过太多技术做得很漂亮但业务毫无感知的项目，验收之后系统就慢慢没人登录了。反过来，那些从一个小场景切入、两个月就让采购员少加两天班的项目，往往能自己长起来，第二年预算不用你争取，业务部门会替你说话。

央国企的采购规模摆在那儿，数据治理带来的效率空间还远没被挖完。我的判断是，未来两三年，谁能把采购数据资产真正盘活，谁就能在集中采购、成本管控、供应链风险预警这几件事上拿到实实在在的收益。数据底座这件事，早做晚做都要做，早做的人先拿到红利。

张启明：我们单位去年做的供应商主数据，清洗完从 2.6 万条降到 1.7 万条，重复率吓人。文中说的“上线半年后业务还用不用 Excel”这个判断太准了，我们现在就卡在这，业务嫌新系统查询慢，又跑回去了。看来得回头看看性能这块。

李慧芳：请问物料分类树一般建几层合适？我们做的时候业务部门吵了三个月，每个厂都说自己的分法对。看到作者说先做供应商域再切入物料，感觉被点醒了，我们一开始就想两个一起上，结果什么都没落地。

王振国：AI 问数这块能再说说吗？我们领导一直想上一线自助取数，但我担心口径不统一，问出来的数跟财务报表对不上，那麻烦就大了。文中提到先做高质量数据集再上问数，这个顺序我记下了。

陈立新：写得挺实在，没有一味吹。那个“一次性治干净”的坑我也踩过，铺太大半年没成果，领导直接叫停。现在改成小步走，两个月一版，效果好多了。数据质量写进考核这条我也准备推一下。