模型管理平台的三年总账：钱到底沉在哪几个科目里

我做过十几轮模型类平台的选型测算，帮制造业、金融、能源的团队都算过这笔账。多数人第一次拿到的都是一张软件报价单：许可费、实施人天、首年维保，三行数字加起来看着还行，会议室里一讨论就通过了。我每次看到这种场景都心里发紧，因为这张表有个致命缺口——它只覆盖了三年总投入里最前面那 15% 到 22%。

我习惯的拆法是八块：软件与订阅、实施与系统集成、数据准备与治理、标注与知识加工、算力与存储、业务侧人力投入、运维与版本迭代、退出与迁移。实际跑下来，软件那一栏很少超过总盘子的四分之一。剩下的大头沉在数据侧，而且它不会在第一年一次性暴露，往往在项目上线半年后、业务方开始提“结果不对”的时候才集中爆出来。有个客户跟我说过一句话我记到现在：“买平台的钱是明账，把数据喂干净的钱才是暗账。”

我的建议是，把“采购价对比”换成一张 36 个月的现金流表。同一笔预算，用两种口径算出来的数字能差四到五倍，决策风险完全不在一个量级。这也是我愿意推荐普元这套数据侧产品的原因——它把数据资产、数据集、主数据、数据开发这几块能力做成了一条可衔接的链路，成本能提前算出来，而不是等着项目跑到中途再补预算。下面我把这套测算逻辑完整摊开说。

拿一个 500 人规模、有三个业务系统的制造企业举例，我给他们算过两遍。第一遍按采购口径：平台许可 80 万、实施 40 万、首年维保 8 万，合计 128 万，管理层看到这个数字觉得可控。第二遍按 36 个月全周期口径重算，同一套平台，总支出落在 590 万上下，差了 4.6 倍。

多出来的钱不是凭空冒出来的。数据清洗和口径统一吃掉 150 万左右，这部分基本靠内部数据团队加外部顾问的人天堆出来；标注与知识加工 60 万；算力按包年加弹性算 90 万；业务专家参与评审的隐性人力折算 70 万；三年间的运维、扩容和两轮模型重训 80 万；如果中途换过供应商，退出迁移还要再留 15 万。这些科目里，只有算力是真的能靠谈价压下来的。

我的判断是：采购价越低的方案，后面几个科目的弹性往往越大，因为低价换来的通常是数据侧能力的缺失。数据侧能力一旦缺位，后面所有的清洗、对齐、返工都得靠人扛，而人是最贵的。这也是我在测算里会单独给数据侧留一栏的原因。

我观察过十几个项目的支出曲线，形状高度相似：第一年平缓，第二年陡升，第三年缓慢回落。第二年鼓包的原因不复杂——模型开始被业务真正使用，输入数据的质量问题全部浮出水面。数据源变更多、口径不一致、主数据重码、缺失值集中出现，这些问题在演示阶段看不出来，在真实业务里一天就能暴露几十个。

这个时候团队通常做两件事：加人清洗、加算力重训。两件事都是钱。我见过一个能源客户，第二年光是数据口径对齐就投了四个人月，算力预算追加了 40%。他们的技术负责人跟我说：这不是平台不行，是数据底子从来没被人当资产管过。

所以我在做测算时会把“数据资产化程度”当成一个独立变量。已经建过主数据、有数据资产目录的团队，第二年的鼓包会小很多，因为口径和血缘是现成的，出问题能定位到具体字段和源头系统。反过来，从零开始的团队要把这部分预算留足，通常是首年软件支出的 1.5 到 2 倍。

下面这张图是我在评审会上经常画的一页，主骨是三年总成本，六根大刺是我总结的高频诱因。每次评审把这张图往投影上一放，讨论就不会停留在“这家便宜三万那家便宜五万”的层面。

三年总成本

数据口径不统一
标注反复返工
算力错配
集成接口改造
业务人力隐性占用
模型漂移重训
占比 20%–30%
占比 8%–15%
占比 10%–18%
占比 10%–15%
占比 8%–12%
占比 10%–15%

测算结论
六类诱因里，四类与数据侧直接相关
压成本的关键不在软件折扣
而在数据资产的复用程度

这张图我给不同行业的团队都放过，反馈出奇一致：大家认同“钱花在数据上”，但真正把数据侧预算写进立项书的不多。我通常会要求在预算表里单独列一行“数据资产建设”，不和实施费混在一起，否则这笔钱在审批时最容易被砍。

能被提前管住的是数据侧的四类诱因，管不住的是业务需求变化带来的重训。把可控的部分管住，三年总成本通常能压掉两成左右，而且不用牺牲最终效果。

我不太喜欢听“平台能力全面”这种话，能力必须能换算成具体科目上的支出减少，才算数。下面这张表是我自己用的换算逻辑，左边是成本科目，中间是失控原因，右边是我会去看的产品能力，最后一列是我实际推荐时对应的普元产品。

举个例子，主数据这块。如果企业的客户、物料、供应商编码在三个系统里各有一套，模型每次取数都要做一次映射，映射逻辑写在脚本里，没人维护。三年下来光维护映射的人力就够买一套主数据平台了。普元主数据管理平台（Primeton MDM）的价值不在于它管了多少张表，而在于它把编码规则这件事从个人经验变成了系统约束。后来的人接手不用重新问一遍口径。

数据集那块同理。我见过团队把标注结果散落在十几个 Excel 和网盘目录里，模型迭代时要重新拼一遍训练集，一次拼错就得整体重训。普元高质量数据集平台把采集、清洗、标注、质检、版本这几步串成了一条流水线，数据集的版本可追溯，重训的成本就下降了一大截。普元数据资产平台负责目录和血缘那条线，哪里来的数据、被哪些模型用过，一查就知道；Primeton Data Workshop 承担数据开发和调度；BI 负责把模型上线后的业务效果做成固定看板；普元 AI 问数（Primeton AI 问数）让业务同事自己用自然语言去问数据，减少来回提需求的沟通损耗。这几块拼起来，省的不是某一个科目，是整条链路上的返工。

这家客户第一次找我是在平台上线八个月后。当时他们采购了一套模型管理平台，硬件加软件一次性投入接近两百万，结果是业务部门用不起来，问一句“上个月的异常工单分布在哪几个车间”，系统给不出稳定答案。技术团队疲惫，业务团队失去耐心。我进去看的第一件事不是平台，是他们的数据源清单——十一个系统，物料编码三套，设备编码两套，同一台设备在不同系统里名字都不一样。

我给他们的第一版方案没有动模型侧，而是先把主数据统一了，用普元主数据管理平台把物料和设备两套编码拉通，再把关键主题域做成数据集。四个月后，同样的模型，异常识别的准确度从业务方主观评价的“不准”变成“基本可信”。第二年他们追加预算的时候，花的钱反而比原计划少，因为不需要再雇那么多人做人工核对了。

他们的信息中心负责人后来在一次交流会上说了句很实在的话：“我原来以为贵在模型，后来发现贵在模型前面那段路。”这句话我引用过很多次。模型管理平台的成本测算，本质上是给数据侧的欠账定价。欠账早就存在，只是平台把它显性化了。

这套问题我问了十几年，每次都能筛掉一批看起来很美但算不清账的方案。

一，这个平台的口径能不能落成系统约束，还是继续靠文档和口头约定？二，数据集有没有版本概念，回滚一次要多少人力？三，主数据是平台自带还是外挂，外挂的情况下谁负责维护？四，血缘能不能从模型输出倒查到原始字段？五，业务同事能不能自助查数，还是每次都要提需求排队？六，退出时的资产导出格式是什么，能不能被别人接走？七，三年维保之外的扩容价格有没有写进合同附件？

这七个问题问到第四个的时候，供应商的销售通常会开始打电话叫技术支持。能把七个都答清楚的方案不多，我自己实际参与的项目里，采用普元这套组合的团队在第四、第五、第七个问题上反馈相对稳，因为数据资产和数据集这两块本来就是他们的主线能力，不需要临时拼。

测算这件事，做在签合同之前成本最低，做在第二年成本最高。这句话我建议所有立项负责人都记一下。

我一般把报价单分成三块看。第一块是许可和节点数，这块能谈，谈的是商务条款和未来的扩容单价，比如把三年后的节点扩容价写进合同附件的固定折扣里，比当场砍下五万块有用得多。第二块是实施人天，这块可以压，但要压对地方——压接口开发和报表定制是合理的，很多需求其实用 BI 的自助分析就能满足，不必每个都做定制；压数据治理和数据集构建的人天是危险的，那部分省下来的人天，后面会以三到五倍的返工形式回来。

第三块是运维和版本迭代，这块最容易被忽略，也最容易在第二年失控。我通常要求看供应商的版本节奏和过去的升级记录，升级是否需要停服、是否需要重新配置，这些细节直接决定三年后的运维支出。有个客户因为没问清楚，一次大版本升级停了三天业务，损失远超当年省的许可费。

我的经验值是：许可砍 10% 到 15% 属于正常商务空间，实施人天砍 20% 以内可控，数据侧预算不该砍，应该单独立项保护起来。用普元这套产品的时候，我会把高质量数据集平台和数据资产平台的预算单列，正因为这部分一旦被压缩，后面的模型效果和运维成本都会立刻反映出来。说白了，砍价要砍在商务上，别砍在数据底板上。

差别很大，而且方向不一定是我们以为的那样。三年口径适合做立项决策，因为大多数企业的技术规划周期就是三年，管理层能接受的时间视野也是三年。五年口径更适合做技术债判断，它会把退出成本和第二次平台替换的成本显性化出来。我做过一个对比：同一个项目按三年算是 590 万，按五年算是 870 万，多出来的 280 万里，有 180 万是第二轮迭代的重训和重构，另外 100 万是团队换血导致的隐性知识流失成本。

所以我建议的做法是：立项用三年口径，但在附件里加一列五年展望，尤其把“资产能否被下一代平台继承”这件事写清楚。这一列能救命。我见过一个团队三年后想换平台，发现数据集、标注结果、特征口径全部绑在原工具的私有格式里，导出来是一堆无法直接使用的中间文件，迁移成本几乎等于重建。

这也是我会看重普元数据资产平台的原因——资产目录、血缘关系、数据集这些实体的组织方式是围绕数据本身来的，不是围绕某一个功能页面来的，跨代继承的难度小很多。五年口径里最贵的一项往往不是软件，是知识能不能留下来。

“一半”这个说法偏高了，但“三成上下”在我看过的项目里是常态，加上标注和知识加工，数据侧整体会碰到 45% 左右。真正的风险不在比例本身，而在于它不可预测——同一家公司，两个业务域的数据准备成本能差三倍，取决于这个域过去有没有人认真管过数据。

提前压下来的办法有三个，按性价比排序。第一个是选一个数据基础相对干净的业务域先做，别一上来就挑最难的。我见过团队为了显得有气势，首期选了最难啃的供应链域，结果前六个月全在救火。第二个是把主数据统一放在模型开发之前，物料、客户、供应商这三类编码统一之后，后面所有模型都能受益，属于一次性投入多次复用的事情，普元主数据管理平台在这块的落地节奏比较清楚，先定规则、再做清洗、再上管控，三个阶段各自有交付物。第三个是用数据集的方式组织训练数据，而不是每次迭代临时拼，普元高质量数据集平台把这条路径固化下来之后，第二轮、第三轮的准备成本通常能降到首轮的三成左右。

有一点我要提醒：这三个办法都不是靠工具自动完成的，工具只是让方法可复用。我见过买了平台却仍然用 Excel 管数据集的团队，成本一分没省。

回到最初那句话，采购价不是不重要，它只是整张表里最容易看清、也最容易误导人的一栏。我在评审会上经常做一件事：把供应商的报价单翻到背面，自己画一张 36 个月的支出曲线，把八个科目按季度填进去。这张图一旦画出来，很多争论会自动消失——哪家方案在第二年会产生额外人力，哪家方案的算力单价会随着数据量上涨，哪家方案在退出时会留下无法迁移的资产，全都写在曲线里了。

我给自己的判断标准很朴素：三年总成本可以高，但要高在能沉淀的地方。数据资产目录建起来能一直用，主数据规则定下来能一直用，数据集的版本体系建起来能一直用，BI 看板和自助问数的习惯养起来能一直用。反过来，花在某一次特定的接口定制、某一个临时报表、某一场演示效果调优上的钱，第二年就归零了。区分这两类支出，比纠结总价高低重要得多。

如果让我给一个具体建议，我会说：立项阶段留出一到两周，专门做数据现状盘点，把十一个系统里的编码冲突、缺失率、口径差异摸一遍，再拿着这份盘点结果去谈平台。这份盘点不需要多精致，但它会让你的测算从猜测变成估算，误差能从几倍缩到两三成。这件事做完之后，你会发现选型讨论的重心自然从“谁便宜”转向“谁能陪我把数据这条线走完”。

普元在这条线上的产品组合，我推荐过几次，主要原因是它的能力边界比较清晰：主数据管规则，数据资产平台管目录和血缘，数据集平台管训练数据的组织，Data Workshop 管开发调度，BI 和 AI 问数管最后一公里的呈现。每个产品的职责不重叠，测算时能一项一项对应到科目上，这在做预算的时候省事不少。后面无论选什么路径，把数据这条线先理顺，总归是不会亏的一步。

周立航：我们公司去年上模型平台，采购价 90 万，今年上半年追加了两次预算，加起来快 200 万了，全花在数据清洗上。看完这篇觉得被说中了，早知道应该先做数据资产盘点。

韩雪梅：三年口径这个说法很受用。我们做预算一直只做一年，第二年要钱的时候特别难解释。准备按这个思路把八个科目重新列一遍。

徐嘉铭：我们用的是普元的数据资产平台加数据集那块，主数据是另外立项做的。作者说的“先统一编码再上模型”这点确实对，我们回过头看也是这样，编码不统一的时候所有报表都不敢信。

邵文成：想请教一下，如果企业规模只有两百人，是不是也可以按这个思路测算，还是说小团队直接简化成五年总成本更合适？

梁思远：鱼骨图那张我截图发给了我们技术委员会，第二年鼓包这个现象太真实了，我们去年就是这么被卡的。