立项评审会上最容易被放过的一句话是“效率肯定会提升”。它听起来成立，却不可验证，也无法在事后归因——同期可能还有组织调整、市场变化或其他系统改造。组织变革的成本收益之所以难算，问题常不在缺少公式，而在测算框架只覆盖了采购清单，把组织适配留在了模型之外。
成本侧：把内部消化的人力显性化
报价单上的软件许可、实施人天、服务器资源容易进预算；流程梳理占用的业务骨干时间、数据清洗人力、关键用户培训、上线初期的效率下降、变革沟通，则多以“大家配合一下”被内部消化。可行的做法是把流程梳理、培训、数据治理折算成工时，按内部人力成本计入预算，哪怕这笔钱不实际支付；把上线后的效率下降作为过渡成本单列；把试点与变革沟通写进计划，而不是临时安排。代价是项目看起来更贵，好处是决策者能看到真实投入规模，避免追加预算时反复拉扯。
口径可以分为四层：软件与基础设施、实施与集成、组织与变革、持续运营。接口数量与历史数据质量常在立项后才被重新发现，运维人力、版本升级、订阅续费则被默认为“以后再说”，后两层最易被系统性低估。
归因侧：先有基线，再谈收益
收益按可验证程度分三类。可直接计量的有系统记录、口径稳定，如工时节约、对账人力下降、库存占用降低，前提是上线前锁定基线。可推算的需业务逻辑换算，例如审批周期缩短带来的回款提前，必须写明假设与换算系数来源。风险控制、合规满足、客户体验这类战略性收益不宜强行折现，单列判断依据作为定性权重，而不是塞进净现值凑数。
归因设计要在启动前完成：保留上线前3至6个月的同一口径基线；选未上线的事业部或区域作对照；分模块、分区域上线形成自然的前后对比；同时记录同期其他变化，复核时逐项排除。行业研究只能作参考——有基于国家示范区1950家企业2015至2019年追踪数据的研究显示，数字化变革中资本产出弹性明显高于劳动产出弹性——但具体到一家企业，仍要用自己的基线做测算。
模型不必复杂。保守、中性、进取三层情景并列，比给出一个精确数字更能支撑讨论；再做敏感性排序，若某个假设小幅变动就让结论翻转，说明它需要在立项前补充验证。复核节点应嵌入项目节奏：立项确认基线与责任分工，上线验收核对实际成本与范围变更，稳定运行3至6个月做首次收益复核，年度复盘更新假设。假设清单由业务、财务、IT三方共同签署，复核才有约束力。
这套方法有前提。业务目标尚不清楚、基线数据完全缺失，或组织对变革方向尚未形成共识时，精细测算的意义有限，更合适的动作是先做诊断或小范围试点，把基线补起来再进模型。