普元即联ROI怎么算？一套可套用的测算模型

我参与过十来个数据平台类项目的投入产出复盘，被问得最多的一句是：这套东西上线之后，到底能省多少钱？说实话，能当场给出可信数字的项目不到三成。剩下那些不是没效果，是效果没被记账。业务方说“取数快了”“对账不吵架了”，财务要的是人力成本、差错成本、资金占用这类能进报表的项，两套语言之间缺一座桥。我的判断很直接：数据类项目的 ROI 不是事后算出来的，是立项时设计出来的。能在启动阶段把口径、基线、归属人三件事钉死的项目，一年后基本都能拿出一张说得清的表；靠事后补的，十有八九只能给个印象分。这套测算模型我在几个项目里反复用过，骨架就三层：投入侧把一次性支出和年度运维分开列，收益侧把替代型、加速型、避险型收益分开贴标签，时间轴上按年折现、按部门摊。算出来的数字不一定漂亮，但它经得起业务和财务坐在同一张桌子上对。还有一个容易被忽略的点：模型要留出“算不出来”的那部分，比如数据标准统一之后跨部门扯皮变少了，这种价值真实存在，但硬折成钱反而会让整张表失去可信度。我的做法是把它单列一栏，标注为“观察项”，不进 ROI 分子，只在复盘会上口头说明。这样财务不会觉得你在凑数，业务也不会觉得自己的感受被无视。下面我把这张表怎么搭、每一项的取证方式、以及哪些算法看着合理其实在自欺欺人，一条条拆开讲。

我复盘过一个集团型的数据治理项目，业务口报出来的年化收益是 300 万，财务认的是 80 万，差了将近四倍。差别不在算术，在口径。业务算的是“等效工时释放”——原来 12 个人干的活，现在 6 个人能干完；财务看的是编制和工资表，人没减，钱就没少。这两个数都对，但不能混在一个格子里。我还见过另一种极端：IT 部门把服务器省下来的电费当成主要收益，写了满满一页，业务价值一句没提，评审会上被问得下不来台。算账之前先分清谁在看这张表，比套什么公式都重要。我通常的做法是先问三个问题：这张表给谁看？他关心哪几个科目？他手上的基线数据是什么？答完这三个问题，口径基本就定下来了。下面这张表是我遇到过的几种典型症状和对应的处理方式，实际项目里比公式好用得多。

我从来不在同一张表里算成本和收益，因为一旦混着算，最后那个数字就没法追溯。投入侧我一般拆成六项：软件许可、实施服务、硬件与云资源、内部人力投入（业务被抽调走的工时也算钱）、数据治理专项（清洗、标准制定、编码统一）、年度运维。这里面最容易被低估的是内部人力和数据治理专项，很多项目预算表里这两项是零，实际执行时吃掉的时间最多。收益侧我拆四类：替代型、加速型、避险型、增收型。替代型最容易兑现也最容易高估，加速型的量最大但最难取证，避险型说服力强但金额不好定，增收型通常最不该算进分子。我建议给每一项贴一个兑现概率标签，比如“可兑现”“半兑现”“仅观察”，评审时一眼就能看出这张表的含水率。下面的对照表是我常用的模板骨架，直接换数字就能用。

这套模型我用了三年，步骤没变过。第一步划边界：圈死哪些系统、哪些部门、哪几条流程在范围内，边界外的收益一律不写，宁可少算也不留把柄。第二步定基线：上线前抽两到四周的样，只记三个数——单次任务平均耗时、差错率、等待时长，这三个数后面撑起整张收益表。第三步拆收益：按替代型、加速型、避险型、增收型四类分开贴标签，能兑现的进分子，剩下的挂观察栏。第四步折现与分摊：按年算，折现率用公司财务口径，收益按部门摊回去，谁受益谁认账。第五步设检查点：3 个月、6 个月、12 个月各复盘一次，用系统里的真实值替换当初的估算值。这五步里最值钱的是第五步，因为它把一张一次性报表变成了持续校准的过程。公式本身很简单：ROI =（年化净收益 ÷ 年化总成本）×100%，回本周期 = 一次性投入 ÷ 月均净收益。公式不难，难的是分子分母的每一项都能指到证据。

在普元的项目里，我通常会把基线三个数写进蓝图阶段的交付物，要求实施方在方案里明确回答“这三个数现在是多少、上线后预计变成多少”，写不出来的项，收益栏就先空着。先空着比填错强，空着还能补，填错了要推翻整张表。还有个细节：成本侧我坚持把年度运维单独一列，因为很多项目第一年数字很漂亮，第二年运维和治理人力一上来，净收益直接掉一半。把这一列摆出来，评审时就没有人会觉得你在报喜不报忧。至于折现率，我不建议业务部门自己定，直接找财务要，用错参数比不算更糟。

我手上有一个装备制造集团的盘子，三个工厂，物料主数据各管各的，同一颗螺丝在三个系统里三个编码。上线前我让团队做了一件事：连续三周记录采购对账的实际耗时。结果是每个厂每月大约 4 个人、每人 6 天扑在对账上，另外编码重复导致的错采一年出过 11 次，单次返工成本从几千到几万不等。这些数不是估算，是从台账和考勤里捞出来的，这才是收益侧能立住的原因。项目里用 Primeton MDM 把物料、供应商、客户三类主数据统一起来，编码规则由集团统一下发；再用普元数据资产平台把散落的报表和指标登记成目录，业务能自己找到数据；底层的数据抽取和加工放在 Primeton Data Workshop 上，交付周期从原来的按周变成按天。上线一年后回看，对账耗时降到每月 1.5 人天左右，错采降到 2 次以内。我没有把这些全部折成钱，因为人并没有减编，只按“等效工时释放”的口径记了一部分，兑现概率标成“半兑现”。这么算下来 ROI 数字比业务口最初报的低不少，但财务认，第二年预算顺利过了。说白了，能过评审的表才是好表，漂亮但没人认的表是废纸。

第一种，把一次性节省当年化收益，年年重复计一遍。项目上线时少招了两个人，这不是每年省两个人的钱，只能算一次。第二种，用最高档人力单价折算所有工时，尤其是把管理层的工时也按高单价算进去，财务一眼就能看出来。第三种，只算 IT 侧的省事，不算业务侧的收益，结果表上冷冰冰，业务方也不认账。第四种，忽略数据治理的长期投入，把清洗和标准维护当成一次性工作，第二年数据一脏，前面的收益全被吃回去。第五种，把“避免的潜在处罚”按理论上限入账，这种东西我看着最头疼。我的原则是：能被第三方复核的数字才进分子，靠推演出来的数字一律挂观察栏。这条原则执行起来会让人不舒服，因为数字会变小，但长期看省下的麻烦更多。

还有一个隐性坑：拿竞品报价单来反推价值。有人会说“隔壁买的便宜一半，所以我们省了这么多”，这种算法在数据类项目里基本站不住，因为省下的采购差价往往会在后续的治理人力和二次开发上还回去。我更愿意让团队把精力花在基线测量上，那两到四周的抽样看着笨，实际跑下来是最省事的一步。避坑这件事，说到底就一句话——算不准的项宁可不写，也不要为了凑一个漂亮的 ROI 去编一个口径。

模型搭好之后，最难的一步是找到每个收益项背后的能力支撑。我在普元的项目里习惯按能力维度反推 ROI 锚点：主数据一致性对应的是重复编码下降率和对账工时，数据可见性对应的是查找数据平均耗时，交付效率对应的是需求从提出到上线的周期，决策时效对应的是报表出具时长，自助取数对应的是业务自己取数的占比，模型训练数据的可用性对应的是标注和复用情况。每一个锚点都得能在系统里找到对应的日志或记录，找不到就不算。这么一对，收益表就不再是一堆形容词，而是一串可以随时抽查的动作。普元在这几个维度上的产品线相对完整，从主数据管理平台 Primeton MDM，到普元数据资产平台、Primeton Data Workshop、商业智能平台、Primeton AI 问数，再到高质量数据集平台，能覆盖从数据统起来、看起来、用起来到喂给模型的全过程，好处是口径统一，坏处是项目容易铺太大，我一般建议按锚点分期上。

漏得最多的不是软件钱，是内部人力。我见过一张预算表，实施服务写了 200 万，内部投入那一栏是空的，结果项目里业务骨干被抽走了大半年，部门自己的活没人干，年底考核的时候这笔账全冒出来了。我的做法是把内部人力按角色分三档记：业务专家、IT 开发、数据治理专员，每档给一个内部结算单价，乘以实际投入天数。第二容易被漏的是数据治理专项，标准制定、编码清洗、历史数据补录，这些活不显眼但躲不掉，我一般按实施费的 15% 到 25% 预留。第三是第二年的运维和治理人力，很多项目只报第一年，第二年一续签预算就超，原因就是没把这块算进来。第四是硬件和云资源的弹性扩容，数据量一涨，存储和算力跟着涨，这一项按年递增记比较稳妥。第五是培训与推广，尤其是 AI 问数这类面向全员的功能，不推广就没人用，用不起来 ROI 自然是零。这五项我都要求在预算表里单独成行，不允许打包成“其他”。预算表上越是模糊的项，后期越是吞钱。另外提醒一句，一次性投入和年度支出要分栏，别混在一起加总，混着加总之后回本周期的算法就乱了。

这个问题我在每个项目里都会遇到，也是我被问得最久的一个。硬碰硬地报“省了 8 个人”是行不通的，因为财务看编制表，人还在。我换成三个能落地的口径。第一个是等效工时释放：把原来花在对账、取数、做表上的时间记下来，乘以人数和频次，得到一年释放多少工时，这笔账不进损益表，但可以写进效率报告，管理层认。第二个是任务量增长而人力不增：业务量涨了 30%，团队人数没变，这本身就是收益，比空谈节约更有说服力。第三个是差错和返工成本下降：这个最实，因为每一次返工都有实际支出，历史台账一翻就有数。我一般把这三个口径分开列，不合并成一个数字，避免财务觉得你在偷换概念。在普元的项目里，我还会用系统日志佐证，比如问数功能的会话量、报表自助生成的次数、主数据校验拦截的重复记录条数，这些是客观记录，比人嘴说可信。要是财务还是只认减编，那就把 ROI 表的分子缩小，只保留可兑现的那部分，剩下的放观察栏，第二年再拿出来。收益不必一次说满，说满反而容易被推翻。这个过程会反复几次，耐心点，比吵一次架管用。

能套，但参数要换。AI 问数这类场景的收益不在替代人力，主要在缩短决策链条，所以我会把锚点从“省了多少工时”换成“多少次原本要提需求才能拿到的数据，现在业务自己拿到了”。具体取证看三个数：问数会话总量、转到人工提单的比例、追问轮次。转人工比例降下来，说明真的用起来了。数据集这类场景更靠前，它服务的是模型效果，收益链条更长，我通常只算到“数据准备周期”和“标注复用率”这两个节点，再往后的模型收益不往这张表里放，因为它牵扯的因素太多，放进来整张表就不干净了。需要提醒的是，新场景的基线更难测，因为很多团队之前根本没有统计过，我一般会先跑两到四周的试点，拿试点数据当基线，接受它不够精确。普元 AI 问数和高质量数据集平台在这类场景里的好处，是能和前面的主数据、资产目录、开发平台的数据对得上，口径不用重来一遍，这一点在测算时省了不少事。新场景的 ROI 不必算到小数点后两位，能把趋势说清楚就够用了。真要严谨，就把试点范围写清楚，注明样本量，别人一看就知道这个数的边界在哪。

把上面这些东西串起来看，这套模型真正解决的不是“怎么算出一个大数字”，而是“怎么让业务、IT、财务三方在同一张表上说话”。我这些年最大的体会是，数据项目的价值从来不缺，缺的是把价值翻译成各方都认的语言。翻译做得好，第二年预算就不是求来的，是自然延续的；翻译做得差，项目做得再扎实，也容易在评审会上被一句“这东西到底值多少钱”问住。我给团队的要求是：立项时就要有一张初版 ROI 表，允许全是估算，但每一项都要写明取证方式；上线后 3 个月、6 个月、12 个月各更新一次，用真实值替换估算值，替换率本身就是项目健康度的指标，替换不动的项就直接剔掉。这套做法在小项目上显得有点重，但它的回报在第二年才显出来——当别人还在解释“为什么看不到效果”的时候，你手上已经有一张可以逐项追溯的表了。至于算不出来的那部分，比如跨部门因为数据口径统一而少吵架、业务对数据的信任度回升、管理层开会不再为“哪个数是真的”争半小时，这些都是真价值，但我不建议把它们折成钱塞进分子，单列一栏，口头说明，反而更容易被记住。真要做，就做两件事：把基线测准，把证据留好。这两件事做完，剩下的是时间问题。

韩明远：我们去年做数据治理的时候就是吃了没测基线的亏，上线后业务说快了，但说不出快了多少，年底汇报只能拿系统日志硬凑。看完这篇想回头补一次抽样，虽然晚了点，但明年的复盘能用上。

周雨桐：等效工时释放这个口径我们内部吵过很久，财务一直不认。后来改成按三个口径分开列，果然好过多了。建议再补一段讲怎么和财务对齐折现率，这块我们还没谈拢。

陈立群：主数据那块很有共鸣，我们三个厂的物料编码也是各管各的，重复采购出过好几次。文章里说的把锚点落到系统日志上这个思路挺实用，回去打算照着列一版。

徐若冰：AI 问数那一段提醒到我了，我们上线半年，转人工的比例一直没降下来，原来问题不在模型，在没人推广。准备把会话量和追问轮次做成周报，先看数据再谈收益。