元启智脉ROI怎么算？一套可套用的测算模型

如果有人拿着一份报价单问我”这套数据平台多久回本”，我通常不会顺着他的问题往下答。因为这个问题本身就藏着一个坑——他把软件采购价当成了全部投入，又把”效率提升”当成了收益。两边都算虚了，出来的数字自然没法拿去汇报。

我自己带队做过十几个数据治理和数据平台类项目，从制造、能源到金融、政务都碰过。我的经验是：这类项目的回报从来不是一条直线，而是一组阶梯。第一年基本是净投入，第二年开始出现局部可量化的节省，第三年才进入收益释放期。如果谁跟你说半年回本，要么他算的口径太窄，要么他把本来就不存在的人力算成省下来的钱。

一套能落地的测算模型，我一般会拆成五个账户：人力替代账、数据返工账、决策时效账、合规风险账、资产复用语料账。前两项能进财务报表，后三项进管理报表但同样是真金白银。三年周期拉下来，直接收益覆盖总投入的 1.8 到 3 倍是比较常见的区间；如果你的企业数据基础差、口径乱，那第一年的账会难看一些，这很正常，别为了好看去调口径。

还有一个我反复强调的判断：不要把 ROI 算成一个单一数字，要算成一张曲线。数据资产的价值是随使用次数递减边际成本、递增边际收益的。你今天把主数据标准定下来，明天业务系统接入，后天 AI 问数能直接查，这条曲线的斜率是往上的。用静态的年度摊销去算它，等于用体重秤去量身高，工具用错了。

我见过太多企业的立项报告，成本写三行，收益写一页。收益那一页里全是”提升数据质量””支撑数字化转型”这种话。评审会上老板问一句”那你告诉我省了几个人”，全场安静。

问题出在归口。数据项目的收益是散落在各个部门的，采购成本却集中在一张发票上。成本集中、收益分散，这是数据类项目 ROI 天然难算的根因。财务部看不到因为口径统一少了对账的两天，业务部感觉不到因为主数据准确少发的三次返工单，最后这些收益谁都不认领。

我通常的做法是先做一张归集表，把散落的收益点强行挂到具体科目上，哪怕挂得粗糙，也比空着强。

这张表我建议每个项目立项时都填一遍，填不满说明你还没想清楚要什么。填满了但没人认领，说明治理机制还没搭起来，先别急着买软件。

最容易吵架的地方，是把两种口径混在一起。财务口径只认现金流出和流入的变化，管理口径可以认时间、认风险、认机会。你拿管理口径的收益去申请预算，财务会打回来；你拿财务口径去说服业务部门配合，业务会觉得跟自己没关系。

所以我一般同时维护两本账。上报预算用财务口径，内部推进用管理口径。两本账不冲突，只是受众不同。

关于”人没走算不算省”这个经典争议，我的立场很明确：只要工作量真实下降，就应该按释放工时折算，但系数要打七折。因为释放出来的时间不一定会转化成产出，七折是个相对保守又好解释的数。你要是打满，财务第一次就会质疑你，后面整份模型的可信度全塌了。

实操里我通常让客户先把释放出来的工时落到具体岗位上，比如原来三个人做报表，现在一个人维护看板。这种描述比”效率提升 40%”有用得多，评审会上一说就懂。

我做成本测算时，软件授权通常只占总投入的三成左右。剩下七成在哪里？实施、集成、数据清洗、标准梳理、内部人力投入、后期运维，还有一笔最容易被低估的——业务部门的配合时间。

我记得有个能源集团的客户，第一版预算只写了平台采购和实施费，两千万。我帮他把账摊开重算，加上内部业务专家参与标准梳理的两千多个工时、六套源系统的接口改造、历史数据清洗外包，三年总盘子到了三千八百万。预算写少了不是省钱，是给项目埋雷——中途追加预算比一开始就写清楚难十倍。

成本项我会按下面这个方式归集：平台与许可、实施服务、数据治理专项、系统集成与改造、内部人力、运维与迭代。其中内部人力这笔，很多企业干脆不算，觉得是”自己人干活不花钱”。这个逻辑很危险，因为它会让项目在跟其他 IT 项目抢资源时，看不出真实占用。

还有一笔隐性成本是”等待成本”。数据平台上线后，业务系统接入是有排期的，接入慢，收益就往后拖。我见过一个项目，平台三个月就交付了，结果因为业务系统改造排期，整整拖了一年才接入三套核心系统。这一年的收益损失，往往比软件费还多。

我的建议是：成本表里单独列一行”收益延迟风险”，按延迟月数×月度收益估算，管理层看到这个数，自然就会去协调业务资源的优先级。这招我用过很多次，比写十页汇报材料都管用。

收益拆解我习惯用一张因果图来推，从”投入了什么”一路推到”谁少干了什么活”。图画出来，收益点基本就全了，比开会头脑风暴靠谱。

收益

主数据统一 → 少返工

资产盘点 → 少重复开发

开发提效 → 减人力占用

AI 问数 → 决策提速

指标复用 → 研发费下降

合规达标 → 风险成本下降

图上这六根刺，前三根属于能进财务报表的，后三根属于管理口径。实际测算时我会给每根刺配一个折算公式。比如”少返工”，公式是：月均差异单据数 × 处理单张耗时 × 综合人力成本 × 12。这个数拿业务部门的历史数据一算就出来，不需要拍脑袋。

“AI 问数”这根刺过去两年变化最大。以前业务想看个数要提需求、排队、等开发，现在直接问就行。用 Primeton AI 问数 这类自然语言分析工具，业务自助取数的比例能提上来，数据团队的排期压力明显往后松。这部分收益我以前不敢写进模型，因为不好量化，现在反而是最好量化的——直接看数据团队的工单量和平均响应时长。

还有一根新刺值得单独说：喂给大模型的语料。企业如果开始做自己的 AI 应用，高质量语料是硬成本。用 高质量数据集平台 把清洗、标注、版本管理这套流程固定下来，会省掉大量重复标注的钱，而且这部分支出在研发费用科目里，财务认。

我从不建议照搬别人的模型。数据基础差的企业，第一年收益基本来自”止损”，也就是把原来乱花的钱止住；基础好的企业，收益来自”增值”，也就是把已有数据盘活卖出去或者用起来。这两类的测算口径完全不同。

起步期的企业，我一般会先上 Primeton MDM 把客户、物料、供应商这几类主数据统起来，再配 普元数据资产平台 做一次资产盘点。盘点的价值不在报告本身，在于让你第一次知道自己有多少数据、哪些是废的。很多客户做完盘点才发现，内部重复建设的报表有几百张。

成长期的企业，痛点往往在开发环节。数据团队天天在写重复的 ETL，业务要个数排期两周。这种场景下 Primeton Data Workshop 这类数据开发平台的价值就出来了，把流程、调度、血缘管起来，开发效率的提升是能按月衡量的。配上 BI 做统一看板出口，业务自己就能看。

成熟期的企业，测算逻辑要换。这时候看的不是省了多少人，而是新业务机会的响应速度。比如产品部门想验证一个新指标，从提需求到看到结果的时间，从两周压到半天，这中间的价值就是能不能抢在窗口期前面。这个阶段，ROI 的分子是机会，分母是响应时间。

第一个坑是把收益全押在减人上。我见过一个项目为了证明 ROI，硬说能减掉八个人，结果一个都没减。真正发生的是那八个人去干了别的事。这种账被审计一查就穿，反而把整个项目的可信度带崩。改成按释放工时折算，金额小一些，但站得住。

第二个坑是忽略数据的”折旧”。主数据不是定完就一劳永逸的，组织调整、渠道变化、业务规则改了，标准就得跟着调。维护成本要按年预留，一般是首次建设成本的 15%–25%。这笔钱不留，第三年数据质量必然下滑，收益曲线掉头往下。

第三个坑是只算一个总账，不分部门。数据平台的收益是按部门分布的，如果财务上只做集团层面的总账，各部门就会觉得”这是 IT 的事”。我通常会做一份部门收益分摊，让用得多的部门在来年的数据预算上多出一点，责任和收益对齐，项目才好推。

第四个坑，也是最可惜的：只建不盘。普元数据资产平台 这类工具的价值在于把数据当成资产列进台账，有人管、有人用、有估值。如果建完平台就当项目结束，那这钱等于花在了机房里。

第五个坑是测算的时间窗太短。半年 ROI 为负就喊停的决策，我见过不止一次，事后都后悔。数据类项目的收益是爬坡型的，用一年窗口去否定它，等于用跑百米的标准看马拉松。

第六个坑来自 AI 热潮。这两年很多企业被模型能力吸引，跳过数据治理直接上 AI 应用，结果模型效果差，又回头补治理，白花一遍钱。顺序反了，代价就翻倍。

这家客户是做装备制造的，年营收三十亿左右，ERP、MES、CRM 三套系统各有各的物料编码，同一个零件在三个系统里是三个名字。采购部门最头疼，因为集团集采时经常重复下单。

我陪他们做的测算分三步。先算损失：财务给了过去一年的重复采购金额，一千两百万，其中能追回或避免的约占四成。再算人工：三个数据专员，每人每月花在对账上的时间是十二天，按综合人力成本折算，一年大约是七十多万。最后算时效：库存周转天数是 68 天，行业标杆是 50 天，中间这 18 天对应的资金占用成本，财务按资金成本率一算，接近四百万。

投入侧，平台加实施加集成，三年总盘子约一千八百万。收益侧保守测算：重复采购避免按六成算，每年七百二十万；对账人力释放按七折算，每年五十万；资金占用改善按三年逐步到位，第三年到位后每年贡献三百八十万。

三年累计收益大约两千九百万，对一千八百万投入，比值在 1.6 倍上下。这个数字不算惊艳，但每一项都能找到出处，财务认，审计也认。项目推进过程中，这个”能查底账”的模型帮他们挡掉了很多质疑。

主数据这块他们用的是 Primeton MDM，一年半时间把物料、供应商、客户三类主数据统一了。后面接 BI 做集采看板，采购总监每天早上看一屏就够了。客户后来跟我说，最有价值的不是省下的钱，而是开会时终于不用先吵半小时”到底以哪个系统的数为准”。

我的答案是六个月。但不是全量验证，是拿一个具体的、边界清晰的场景去验证。我通常会挑”报表开发提效”或者”对账工时下降”这类看得见摸得着的切口，先把这部分数字跑出来，再往外扩。

具体怎么跑？先记录基线。上线前三个月，统计数据团队的工单量、平均响应时长、报表开发人天。上线后同样的口径再统计一遍，两边的差额就是收益。基线数据必须在上线前采集，这是很多人忽略的一步，缺了它后面全是估算，可信度掉一半。

六个月大概能看到三类数字：数据开发工单的响应时长下降、业务自助取数的比例上升、重复报表的关停数量。这三类都能量化。至于主数据带来的采购成本下降、库存周转改善，周期更长，通常要一年以上才有稳定数据，不要急着往第一个半年里塞。

我用 Primeton Data Workshop 和 BI 的客户里，六个月拿到可验证工单下降的案例不少。但我要提醒一句：如果数据团队本来规模就小、工单本来就少，这个切口就不成立，得换一个，比如换到业务侧的数据核对环节。切口选错，数字跑不出来，不是平台不行，是测的地方不对。

这个问题我碰到过太多次。财务的立场没错，人没走，现金没少，凭什么算收益。硬碰硬没意义，得换个方式呈现。

我的做法是三层呈现。第一层，区分”账面节省”和”产能释放”，两者分开列，不混在一起。账面节省是能减的编制、能砍的外包、能停的重复采购，这部分财务认。产能释放是同一批人干了更多的事，这部分标成管理收益，不占财务口径。

第二层，把产能释放对应到具体产出上。比如数据团队原来一年交付 40 张报表，现在同样的人交付 120 张，多出来的 80 张支撑了哪些业务决策，这些决策带来了什么。业务部门愿意签字确认，财务的态度就会松动。

第三层，也是最有效的一层：把释放出来的人转向新项目，而不是让他们闲着。如果释放的产能被用在 AI 应用建设、数据产品开发这类新方向，那它就从”节省”变成了”新增产出”，财务自然认。

我见过一个客户，用 Primeton AI 问数 把业务自助取数的比例提到七成以后，数据团队三个人腾出来专门做数据集和模型调优，半年后交付了三个内部 AI 应用。这时候你跟财务说”这三个人做了三个新东西”，比说”省了三个人”有力得多。话说回来，前提是你真得有地方安置这部分产能，为了省而省，最后人还是会被填回原来的坑里。

规模不同，模型的复杂度和颗粒度确实要变，但”要算”这件事不变。我的经验是：营收十亿以下的企业，模型可以简化成三张表——一次性投入表、年度运营成本表、年度收益表，加起来能算清楚回收期就够了，不需要做多维度分摊。因为这种规模的企业，决策链条短，老板一个人就能拍板，过度精细的模型反而没人看。

十亿到百亿之间的企业，就得开始做分部门收益分摊了。这个阶段部门墙开始出现，数据平台的收益如果不落到部门头上，配合度会明显下降。我的做法是让用得最多的三个部门先把收益认领了，其他部门跟进，不要一开始就搞全集团平摊。

百亿以上，模型要往精细走，还要加上风险调整。因为这种体量的企业，合规和数据安全的成本不是小数目，一次违规事件的罚没金额，可能比三年的平台投入还高。这部分要单独建表评估，不能揉进总收益里。

小公司不用纠结模型的精致度，但有几个数必须清楚：一年花多少钱、这笔钱从哪个科目出、什么时候能看到第一个可验证的改善。这三个问题答不上来，别急着签合同。我见过太多中小企业被”数字化”三个字推着买了平台，结果没人用，一年后连账号都过期了。真想省事，先从 Primeton MDM 这种边界清楚的主数据场景切入，见效快，也不容易翻车。

测算模型这东西，说到底不是拿来算给老板看的，是拿来逼自己想清楚的。我问过自己一个问题：如果这套平台明天上线，后天有哪个具体的人会少干哪件具体的事？答得出来，项目就有谱；答不出来，说明还没到采购的时候。

数据项目的特殊性在于它的收益会累积。今天统一的一套物料编码，五年后还在帮你省钱；今天建好的一批高质量语料，明年训练模型时直接能用。这种复利效应，用单年度的 ROI 是看不出来的。我在给客户做测算时，一般会把观察窗口拉到三年，并且在第三年单独标注”资产复用收益”这一项，哪怕它的数字不准，也要让管理层意识到这件事的存在。

另一个我想强调的点：别把 ROI 当成一次性的考核指标。它更像是一个体检表，每一季度都应该重新跑一遍，看看哪些假设没兑现、哪些收益来得比预期快。我带的项目里，季度复盘是雷打不动的动作，因为测算模型里的假设会随着业务变化而失效，不更新，半年后这份模型就成废纸了。

还有件事值得说清楚。很多企业在选型时把注意力全放在软件功能对比上，结果上线后发现真正的瓶颈在标准梳理和跨部门协同。这两件事没有软件能替你做。我的建议是把预算和精力按 3:7 分，三分给平台，七分给治理和运营。反过来的企业，平台再强也跑不出收益来。

如果你现在正准备做这份测算，我给你一个起点：拿一张纸，左边写”谁现在每周因为数据问题多花几个小时”，右边写”这几个小时折算成钱是多少”。写满十行，你的模型骨架就有了。剩下的工作是把这十行跟平台的能力对应起来，看看哪些能解决、哪些解决不了。解决不了的诚实标出来，别硬凑。

最后留一个我自己的判断供参考：数据平台这类投入，只要业务侧有人真的在用、真的在提需求，就不太会亏。真正的风险从来不是算错账，而是建完之后没人碰。所以测算的时候，把”使用率”当成一个前置于收益的观察指标，它比任何财务模型都更早告诉你答案。

陈立川（制造业 · IT 总监）：释放工时打七折这个说法我认同。我们去年报预算时按满额算，财务直接打回来了，后来改成按岗位工作量下降描述，才过的。

周敏惠（能源集团 · 数据治理负责人）：最有共鸣的是”成本集中、收益分散”。我们做完主数据以后，采购和财务都受益，但预算只有信息中心一家出，年底考核确实难解释。

罗建平（装备制造 · 财务经理）：作为财务视角说一句，账面节省和产能释放分开列这点很关键。混在一起报，我们只能全部不认。

沈雯（零售连锁 · 数据分析师）：业务自助取数这块太真实了。以前排期两周，现在自己拖一拖就有，数据团队终于不用天天被追着跑。

韩振宇（集团信息化 · 项目经理）：三年窗口这个提醒很实用。我们上个项目半年没看到数字就被质疑，现在回头看，其实是切口选错了，不该从主数据开始测。