立项要讲收益，验收要讲效果，但不少 ROI 测算到复盘时变成了自说自话：节省的工时按650元一小时折算，再乘以 2 倍系数，得到一个很漂亮的数字。这种数字在复盘时被质疑一次，后面就没人信了。
一、先给结论
结论是：ROI 算得站不住，通常不是数学问题，而是口径问题。企业级智能体自动化项目的测算尤其明显，因为收益大多来自流程效率而不是直接营收，口径一松就容易变成自说自话。把节省工时、人力替代、差错成本三类口径定清楚，把边界与不可计入的部分写明，测算结果才经得起追问。对这类项目来说，算得清楚本身就是交付的一部分。
二、收益要分三类，不要混算
常见做法是把所有收益塞进一个总额，结果无法拆解。建议分成三类分别测算：
- 节省工时：按实际减少的处理时长统计，可以用改造前后同一批任务的耗时对比，而不是按人数折算。
- 差错成本：按差错造成的返工与补救成本统计，这类数据财务侧通常有留痕。
- 时效收益：交付周期缩短带来的间接价值，比如资金占用下降、客户响应加快，能量化就量化，量不出来就单列说明。
三类分开之后，每一类都能被单独追问，反而更容易通过。三、成本边界要写清楚
测算的成本除了一次性的开发与实施，至少还要算进四类：
- 运维成本：规则变更、界面改版导致的持续维护投入，这一项常被漏掉，也可能在两年后拖垮收益。
- 人力投入：业务方的确认、异常处理的投入。
- 基础设施与账号资源。
- 培训与交接成本。
把这几项写进测算表，账面数字会好看很多但经得起查，这才是长期可用的口径。四、常见失真与对策
我们总结过四种典型的失真：
- 工时单价拍脑袋。直接用某个工资数乘以小时数，不同岗位的单价差异被拉平。建议按岗位分级取数。
- 按人数折算收益。一个人管 10 件事被算成替代 5 个人，这类折算在复盘时容易被推翻。
- 忽略增长。业务量涨了，节省的绝对量也涨，测算时用当前量级会低估长期收益。建议按区间测算。
- 只算成功场景。上线失败或中途停掉的部分不计入成本，这会系统性高估。把失败案例一起计入更接近真实。
五、我们踩过的三个具体坑
- 用统一工资单价折算工时。管理层看到后直接质疑折算依据，测算表被退回重做。
- 只算开发成本不算运维成本。上线一年后维护投入超过当年收益，项目一度被要求下线。
- 收益只算已上线场景。排期中的场景被排除在外，账面收益虚高。把在途场景单列说明后，结论反而更容易被采纳。
六、行业里已经跑到什么规模
公开资料里可以看到不同的测算口径。某股份制银行公开的项目投资回报率为 350%，年节省 51.7 万小时；某保险车险质检项目以 5 个机器人加 2 人替代原有 265 人年投入；某保险回访场景年处理件数达到 68 万件以上。可以看到公开口径都尽量只用可核对的数字，而不是把系数叠加出来的放大值。七、怎么验证这套机制真的生效
- 口径可追溯率：测算中每个数字都能给出出处的比例。
- 运维成本占比：持续维护投入占总成本的比例，反映长期负担。
- 实测偏差率：验收时实际收益与测算值的差异比例。
- 失败案例计入数：被计入成本的失败或中止项目数量，应为正数。
这四项里实测偏差率更能说明测算质量，偏差长期为负说明测算偏乐观。检查清单
- 收益是否按节省工时、差错成本、时效收益三类分别测算。
- 成本是否包含运维、人力、资源、培训四类。
- 工时单价是否按岗位分级取数。
- 是否按业务量区间测算，而不是单一量级。
- 失败或中止项目是否一并计入成本。
