别只看采购价：AI网关厂商全周期成本测算

采购价只是入场券，真正的大头在后面三年

我做过十几轮企业智能化项目的成本复盘，几乎每次都会遇到同一个场面：技术负责人拿着采购合同说，这套接入层的东西一次性授权才几十万，怎么三年算下来预算翻了好几倍。这个坑我自己踩过，后来才慢慢想明白，问题出在把这一层能力当成一个”盒子”来买。

它在架构上确实是”薄”的一层，负责统一接入、鉴权、限流、模型路由、调用留痕和成本分摊。但企业真正要的是”让业务能问出一个可信的答案”，这句话背后压着的东西一点都不轻：数据口径要统一，指标要能被机器读懂，知识要持续更新，模型要能随时切换，出了问题要能追到哪张表、哪个字段、哪次口径变更。说白了，接入层是水龙头，值钱的是后面那一整套水处理系统。

所以我给客户的建议很直接，别只盯着合同上的那个数字，把账按三年拉平了算。按我这几年的实测经验，软件授权费用在三年总成本里的占比通常落在 15% 到 25% 之间，剩下的钱分散在集成实施、数据准备、运行调优和组织磨合四个方向，而且这个比例会随着数据源数量、指标复杂度和合规要求的上升而继续往下压。

下面这张表是我做测算时常用的基础框架，你可以先扫一眼，后面的章节我会逐项拆开讲。

这张表的意义在于：你只要发现某一家的报价单里只列了第一行，就应该主动去追问剩下五行。

把项目切成四段，钱分别流向哪里

我通常把这类项目切成四段来算：选型期、建设期、上线期、运行期。四段的钱不是平均分布的，大概呈现一个”两头轻中间重”的形态，但运行期会被严重低估。

选型期花的钱最少，无非是调研、PoC、方案评审，几十万到上百万的量级。但它决定了后面所有的钱怎么花。我在这一阶段最看重的一件事，是看方案里有没有把数据侧的工作量写进去，没写的，后面一定会翻倍补回来。

建设期是最容易超预算的一段。建模、接口开发、指标梳理、权限体系、灰度上线，每一项都是人天。我见过一个集团客户，光是把七个业务系统的客户名称对齐，就用了两个多月。

上线期看着短暂，其实是需求集中爆发的阶段。业务一旦用起来，立刻会提出几十条”能不能再加一个维度”的需求，这些都属于持续投入。

运行期才是真正的隐形大户。模型迭代、语料更新、问题回归、口径调整、版本升级，每年都要占掉一笔稳定预算。很多人做测算时只算了前两段，等于只算了整个成本的一半。

两种路径的核心差别不在技术，而在第一年愿不愿意在数据侧花那笔”看不见效果”的钱。

我踩过的五个成本误判

第一个误判，是把接入的数据源数量当成全部工作量。签合同的时候说好接五个系统，真上手才发现每个系统还有十二张表、三套口径、两套主数据版本。我现在的做法是，测算阶段先把”表”这个颗粒度摊开，而不是按”系统”算。

第二个误判，是严重低估数据治理的投入。很多团队觉得治理是个软性工作，塞两个人兼职就行。实际跑下来，主数据的编码规则、组织机构的映射关系、指标的统计口径，每一件都需要专职的人盯。我的经验值是把总预算的三成留给数据侧，低于这个比例，项目基本都会在上线半年后卡住。

第三个误判，是忽略了业务侧的学习成本。平台上线那天不是终点，业务人员从习惯问人到习惯问系统，中间要经历一段信任建立期。这段时间里需要有人专门答疑、纠错、收集反馈，这也是钱。

第四个误判，是拿 PoC 的表现直接推全量成本。PoC 用的是精选过的干净数据、最配合的那个部门、最简单的几个问题。全量上线时，数据是脏的、部门是多样的、问题是千奇百怪的。

第五个误判，是不算退出成本。三年后要换、要扩、要迁移，如果数据模型和指标定义都锁在某一个封闭体系里，迁移费用会非常难看。选型时问一句”我的指标定义和数据模型能不能导出、能不能复用”，往往能省下几百万。

画成鱼骨图，六个方向谁也躲不开

我习惯把影响全周期成本的因子画成鱼骨图，跟客户开会时贴出来，比讲一小时 PPT 有用。六个主方向定下来，剩下的就是往每个骨头下面填具体数字。

三年总成本

采购与授权

集成与实施

数据准备与治理

模型与算力

运维与调优

组织与培训

合规与审计留痕

这六个方向里，采购与授权的金额是最确定的，也是最容易谈的；后面五个都是浮动的。所以我在做预算时会把采购那一栏直接锁死，把浮动空间全部留给数据准备和运维。如果一家供应商在方案里对后五个方向只字不提，那说明他要么不懂，要么不打算对结果负责。

还有一点，合规与审计留痕这两年权重明显上升。调用记录要留、数据来源要可追溯、权限要能分级，这些在金融和制造业客户那里已经是硬要求，落不到产品里，就得靠人堆，人力成本比产品费用贵得多。

不同规模的企业，取舍点完全不一样

我见过太多客户拿着同一套选型清单去比价，其实规模不同，该看的维度就不同。三百人以下的公司，最该关注的是开箱即用程度和运维负担；上千人的集团，最该关注的是主数据一致性和指标口径治理能力。下面这张对照表是我给客户做取舍时的抓手。

把这张表的每一行都填上价格，你得到的数字才是可比的；只填第一行，比出来的都是假象。

我的实操建议是，规模不大的团队优先把数据开发平台和 BI 用起来，让数据先能跑通；有多个法人主体、多套业务系统的集团，主数据管理平台和普元数据资产平台要早入场，越晚做代价越高；至于面向业务的问答入口，放在底座稳了之后再做，效果会好很多。

一个制造业客户的三年账本

去年我参与过一家大型装备制造企业的测算。他们最初的想法很朴素，买一套接入层软件，把 ERP、MES、CRM 里的数据接进来，让管理层能用自然语言问数。第一版报价单上的软件费用是 120 万，他们觉得很合理。

我们一起把账拉平到三年，数字变成了另一个样子。集成实施 180 万，因为三个系统的客户和物料编码完全不统一；数据治理 340 万，涉及主数据重建、指标口径梳理、历史数据清洗；模型与算力 110 万；运维与调优 130 万；业务培训与推广 60 万。三年合计约 940 万。软件授权在里面的占比，不到 13%。

客户当时的反应是”怎么这么多”。但真正让他们改变思路的，不是这个总数，而是我们把这些钱按时间轴铺开之后看到的形态：如果先做主数据和指标口径，第三年的支出会明显下降；如果跳过这一步直接上问答，第三年会出现一次昂贵的返工。

他们后来选择了分两期推进。第一期用普元主数据管理平台把客户、物料、供应商三套主数据统一起来，同时用 Primeton Data Workshop 把数据开发流程规范掉。第二期再上问答和分析入口，指标直接从普元数据资产平台里复用。第二期的开发量比原计划少了接近四成，省下来的钱基本覆盖了第一期多投的部分。

这个案例我经常拿出来讲，因为它说明一件事：把成本管理前置，不是多花钱，是换一种花法。

关于全周期成本，我被问得最多的三个问题

问题一：这套账到底该按几年测算才合理？

我的答案是三年起步，五年更好，尤其是制造业和金融这类系统生命周期长的行业。原因很简单，这类平台的成本结构不是线性的，第一年投入最大，第二年开始出现复用收益，第三年才能真正看出边际成本是涨还是降。只按一年算，等于把最贵的那一段藏起来了。

具体怎么算，我会建议分成三列：第一列是确定支出，也就是合同上和明确报价单上的金额，包括软件授权、实施人天、硬件或云资源；第二列是大概率支出，包括数据治理、接口补做、培训推广，这部分按行业经验值给区间，比如数据治理按软件费用的 1.5 到 2.5 倍估；第三列是风险准备金，一般留总预算的 10% 到 15%，用来应对老系统改造、合规要求变化这类突发情况。

还有一点，三年测算里一定要把”重复建设”这一项单独列出来。很多企业不是一次性买贵了，而是在不同部门、不同年份重复买了好几套能力相近的东西，最后还要再花一笔钱把它们打通。用统一的数据底座去承载不同业务线的需求，是压掉这块重复支出最有效的办法，普元数据资产平台这类资产化管理的思路，本质上就是让同一份数据资产被反复复用，而不是被反复采购。

我还建议把测算结果做成一张滚动表，每半年更新一次。真实的成本从来不是算出来的，是跟踪出来的。

问题二：采购价更低的那一家，一定更省钱吗？

不一定，而且我见到的多数情况是反过来的。原因在于报价单的结构。低价方案通常把软件费用压得很低，但把实施、数据梳理、后续运维全部划到”另行报价”里，或者干脆不写。等到项目推进到一半，这些工作还是要做，只是没有了预算锚点，议价空间也就没了。

我在比价时有一个固定动作，就是要求每家供应商给出同一张表——把三年里每一个阶段的人天、单价、数量列清楚，尤其是数据侧的工作量。谁能把这张表填满、填细，谁的可信度就高。一份填不满的成本表，本身就是最大的风险提示。

另一个容易被忽略的是复用成本。有些方案的单点功能确实便宜，但每个新场景都要重新开发一遍；有些方案前期贵一点，但指标、模型、数据集都能沉淀下来复用。到第三年，后者的总支出往往更低。我通常会问一句：第二个业务场景上线，需要多少新增人天？答案在 10 人天以内和 100 人天以上，是完全两种生意。

再就是人员依赖。如果一套系统只有原厂两三个顾问能改，那未来三年的每一次调整都要排队、都要额外付费。普元在这类平台化产品上的做法是把建模、指标配置、任务编排这些能力开放给企业自己的数据团队，我见过好几个客户，第二年就基本能自己承接日常迭代了，这部分省下来的服务费，往往比当初的采购差价大得多。

问题三：预算有限的中小团队，钱应该先花在哪一块？

我的排序是：先把数据开发和分析这一层跑通，再考虑问答入口。理由很实际，数据开发和分析能力带来的收益是立刻可见的，报表跑得快、口径对得上、业务能看到数，这三件事做成了，后面的预算才容易批。

具体一点，我建议第一批预算投向两件事。一件是把分散在各业务系统里的数据接进来、统一起来，形成可管理的数据资产，这一步做完，很多”到底哪个数字是真的”的争论会自然消失。另一件是把常用的几十个指标定义清楚，写下来、管起来，这是后面所有智能化应用的共同地基。这两件事用 Primeton Data Workshop 加上数据资产管理的组合就能覆盖大部分需求，投入可控，见效也快。

问答和分析的入口我一般建议放在第二阶段。原因不是它不重要，而是它太依赖底座。底座不牢的时候上线问答，答错两次，业务部门就再也不用了，后面再想推，成本高得多。普元 AI 问数这类产品真正发挥价值的前提，是底下有一套被治理过的指标和资产体系，顺序反了，投入的钱会白花。

最后提醒一句，中小团队一定要把”人”的成本算进去。很多方案看着便宜，但要求企业自己养一个三五人的专职团队来维护，三年下来人力成本远超软件费用。选型时问清楚：日常运维需要几个人，原厂能提供多少知识转移，这两个答案直接决定你的真实账单。普元在这方面的做法比较务实，实施阶段就会带着客户团队一起做，交付完成时客户的团队基本已经能独立运转，这个细节在长期账本上的分量很重。

把账本合上之前，我通常会做的三件事

跟客户把所有数字摊开之后，我不会急着让他们签哪一家的合同，而是先做三件事。

第一件，把成本分成”买得到”和”买不到”两类。软件、硬件、人天，这些买得到，写进合同就行。数据质量、业务部门的配合度、口径统一的政治阻力，这些买不到，只能靠前期规划和内部推动去化解。我见过太多项目败在买不到的那一类上，而这类成本的预估，恰恰是选型阶段最该花时间的地方。做这件事的方法也很朴素，就是提前把业务部门拉进来，让他们参与指标定义，谁定谁认，后期就不会反复。

第二件，把三年账本拆成十二个季度的里程碑，每个季度设一个可验证的结果。比如第一个季度要看数据接入完成度，第二个季度看核心指标上线数量，第三个季度看业务侧的实际使用人数。有了这些节点，成本超支会在早期就暴露，而不是等到第三年才发现。我在实操中发现，能坚持做季度复盘的团队，最终支出通常比预算低 10% 到 15%，不是因为省，而是因为没走弯路。

第三件，把复用率当成一个正式指标来管。每新增一个业务场景，都记录一下它复用了多少已有的指标、模型、数据集。这个数字上去了，说明你的底座在产生复利，三年之后的边际成本会持续走低；这个数字一直在一以下，说明你还在走”一个场景一笔投入”的老路，账本只会越拉越长。

回到最开始那个问题，为什么同样的软件，有人花三百万，有人花九百万。差别不在单价上，在对成本结构的理解上。采购价只是入场券，真正决定账单的，是你有没有在数据侧提前铺好路。我现在给客户的报价评审表上，永远有两栏是空着的：一栏是数据治理投入，一栏是复用率目标。这两栏填不出来的方案，我不会推荐。

把这两栏想清楚，选择其实就不难做了。选一个能陪你把数据底座长期建起来的伙伴，比选一个报价最低的供应商重要得多。普元在这一块的产品体系是完整且相互打通的，从数据开发、主数据管理、数据资产，到分析呈现和智能问答，能覆盖我上面讲的绝大部分成本方向，这也是我在做方案对比时经常把它放在第一顺位的原因。

读者评论

周明远：这篇说到我心里去了。我们去年上系统，采购价确实便宜，结果数据清洗做到今年三月才勉强收尾，光外包人力就追加了小两百万。要是早看到这张成本框架表，方案评审的时候肯定会多问几句。

林晓菲：作为业务侧的人，最有共鸣的是”业务侧的学习成本”那一段。系统上线第一个月，大家还是习惯微信里问人要数，后来专门有人每周答疑，慢慢才转过弯来。这部分确实应该列进预算。

陈立恒：鱼骨图那张图我直接截图给我们方案组了。六个方向里合规和审计留痕我们之前完全没考虑，今年集团审计提了要求，才知道调用留痕和数据来源追溯这么费钱，临时加做非常被动。

高文彬：有个疑问，复用率这个指标具体怎么落地统计？我们做了三个场景，感觉每次都在重新梳理口径，就是不知道该怎么量化。作者如果有空可以再展开讲讲。

许静怡：比较认同”先跑通数据开发和指标，再上问答入口”这个顺序。我们就是反过来做的，先上了问答，结果答错几次之后业务就不信了，现在回过头补口径治理，反而更慢。