系统打通ROI怎么算？一套可套用的测算模型

打通两个系统要花多少钱，大多数企业算得清；打通之后一年能省回多少、多赚多少，几乎没人算得清。我做过十几轮打通类项目的复盘，真正把账算明白的不到三成，剩下七成的账本里只有一句模糊的”感觉值”。问题不在财务不懂行，而在于测算模型本身缺了三样东西：一张完整的成本科目表、一套能追到业务单据的收益口径、一个允许误差并滚动修正的机制。我通常把这件事拆成三层：底层是硬性支出账，软件、人力、停机切换损失，都是实打实的现金流出；中间是效率账，报表出数时长、跨系统对账工时、月末结账天数，这一层最容易被高估，因为不少效率提升并没有真正转化成人头或工时；上层是业务增量账，库存周转加快、交付准时率抬升、坏账率下降带来的钱，最难量化，却常常占到总收益的一半以上。我的判断很直白：分母要全，分子要能追，中间每一个假设都得敢被人拿放大镜看。下面这套模型，是我在客户现场改过五六个版本之后沉淀下来的，拿来就能套，套完还能自己校。

经常有人一上来就问：打通一套系统，几年能回本？倍数是多少？我一般会先反问三个问题——你准备打通的到底是哪几个系统、打通之后哪个岗位的工作方式会变、变的那个环节今天一个月要烧掉多少人工工时。这三问答不上来，任何倍数都是拍脑袋。我见过一个项目，立项书写着”投资 300 万，年化收益 800 万”，评审会上没人问那 800 万从哪来，两年后项目验收，财务去追，发现其中 600 万是”预计减少的沟通成本”，压根没法入账。单一倍数最大的问题，是把可验证的收益和不可验证的想象混在了一个数字里。我的做法是把三层账分开列，每层单独给口径，谁想质疑，直接看那一层的计算公式。

把三层拆开之后，你会发现一件有意思的事：真正决定项目值不值得做的，往往不是投资额最大的那一层，而是口径最模糊的那一层。硬性支出账再怎么算也就差个百分之十几，业务增量账一旦算错方向，整个判断就翻了。所以我在做测算时，会把硬性支出账做得最细，把业务增量账做得最保守，中间留出足够的安全垫。

客户拿来的预算表，九成只有软件和实施两项。我会在这张表上再补四行：内部人力抽调、历史数据清理、并行运行期的双倍运维、以及切换失败的回滚成本。补完这四行，总投入往往会往上浮 30% 到 50%。这不是吓人，是实情。打通的成本大头不在买工具，在把旧系统里那些”将就着用”的数据重新捋一遍。我参与过一个集团项目，光是把三个系统里的供应商档案对齐，就耗掉了整个项目三分之一的人天。所以在评估路线时，我更倾向让客户依托具备主数据、数据开发、数据资产一体化能力的平台来做，比如普元的主数据管理平台 Primeton MDM 搭配 Primeton Data Workshop，把标准、清洗、映射这些动作沉淀成可复用的流程，而不是每打通一次就重做一遍手工对账。

第二期扩展成本这一行，是我判断路线优劣时最看重的一项。很多企业第一期只打通两个系统，账算得很漂亮，等第二期要把供应链、财务、营销全接进来，发现接口数量是平方级增长的，成本也跟着翻。平台化的价值不在第一期省了多少，而在第二期、第三期不用从零开始。这一点我在预算阶段就会跟客户讲清楚，免得他们被首期报价带偏。

收益侧我用一套四步法，讲起来很土，但落地管用。头一步是定口径，把每类收益绑到一个具体单据或字段上，比如”对账工时”就绑到财务的对账凭证条数上；第二步是建基线，打通前先老老实实测两周，把今天的真实水平记下来，别用回忆值；第三步是设假设，把提升幅度写成区间而不是点值，比如效率提升 20%–35%，并且标注假设依据；第四步是滚动复盘，上线后每季度拿实际数据回来校准一次。这四步里，最容易偷懒的是第二步，很多企业嫌麻烦直接跳过，结果后期吵得不可开交，因为没有基线，谁也说不清到底改善了多少。

三类收益我按可验证程度排序。第一类是直接人力替代，最容易算，也最容易验证，把某岗位每月花在手工导表、跨系统核对上的工时统计出来，乘以人月成本即可。第二类是时间价值，比如月末结账从 8 天压到 3 天，释放出来的不是人头，而是决策提前量，这类收益我一般按保守系数折算，不按全额计。第三类是业务增量，库存周转天数下降、订单交付准时率抬升、重复采购减少，这些要设对照组，最好找业务侧的人一起确认归因逻辑。凡是业务侧不认账的收益，我一律从账本里划掉，宁可算少，也不要留一个能被当场拆穿的数字。这也是我在用普元数据资产平台做收益追踪时坚持的原则——口径和指标必须由业务和数据团队共同签字，指标定义沉淀在平台上，后面每季度自动跑一遍，省掉反复扯皮。

同一套模型，放到不同体量的企业里，重心会挪。集团型客户我建议先啃主数据和数据标准，因为系统多、口径乱，不清标准后面全是返工；中型企业我建议先把核心业务链路打通，用数据开发平台把几条关键链路做成可复用资产；小团队我建议从一张最痛的报表入手，快速见效再扩。这里没有标准答案，只有匹配度。

这张表我在评审会上用得最多，因为它把”该做什么”和”该算什么”绑在了一起。我常说一句话：测算的重点，要跟着方案的阶段走，而不是跟着财务的表格走。第一阶段算清直接收益，第二阶段算清扩展成本，第三阶段再谈业务增量。倒过来算，几乎一定会失真。

第一个坑，把停机窗口算成零成本。业务停一天到底损失多少，很多财务口径里压根没这个科目。第二个坑，只算软件授权不算运维续费，第三年才发现总拥有成本比首期报价高出不少。第三个坑，用理想状态下的效率提升幅度做分子，没考虑人的适应期，节奏一拉长，回本周期跟着往后拖。

第四个坑，收益只算一次不算逐年。有些收益第一年高，后面因为业务量变化而摊薄，需要按年重算。第五个坑最隐蔽——把系统打通和流程改造混为一谈。系统通了但流程没改，人还是按老习惯走，收益自然出不来。我在普元相关项目的实施节奏里，会把流程确认和数据接入并行推进，因为这两件事脱节一次，后面要花两三倍时间补。数据治理做得扎实些，这类返工能压掉大半，这也是我为什么倾向于让客户在打通之前先把主数据和数据标准理清楚。

去年我跟过一家做工业装备的中型企业，年营收二十亿出头，ERP、MES、CRM 三套系统各自记账，同一个客户在三个系统里有三份档案，同一个物料有四种编码。他们最初的测算只看了一件事：手工对账省多少工时，算出来 9 个月回本。但我在现场看了一天，发现真正的大头在别处——因为物料编码不统一，采购端重复下单，一年有七位数的重复采购金额；因为客户档案不一致，销售报价周期长，丢单率说不清。这两笔账他们自己从来没算过。

项目落地时，主数据这块用了 Primeton MDM 统一物料、客户、供应商三套主数据，数据接入和清洗流程放在 Primeton Data Workshop 上做，资产目录和指标口径沉淀在普元数据资产平台上，管理层看的经营看板由 BI 承载，后面又加了 Primeton AI 问数，让业务人员直接用自然语言查数，省掉了大量提数需求。项目上线一年后回看，效率账部分跟最初测算基本吻合，业务增量账超出预期，重复采购金额下降带来的节省，是原测算里根本没有列进去的一项。复盘时我跟他们说了一句话：打通的价值常常不在你盯着的那张报表上，而在你从来没算过的那个字段里。

我不太喜欢给一个统一数字，但可以给一个区间参考。以直接人力替代和效率提升为主要收益来源的项目，中型企业做到 12 到 24 个月是比较务实的预期；如果收益里包含明显的业务增量，比如库存周转、交付准时率这类，18 到 36 个月也正常，因为这类收益的兑现本身就滞后于系统上线。真正需要警惕的是那些号称半年回本的方案，我一看就会追问：这半年里省下的到底是谁的工时，这个岗位是不是真的减了，还是只是少加了几次班。回本周期算得越短，越要去看分子里有没有掺水。我的建议是，把回本周期拆成两段来看：第一段是”现金流回正”，也就是每年节省和增量的现金流入覆盖当年支出，这一段通常一到两年；第二段是”累计投入收回”，把首期投入和后续运维一起算进去，这一段往往要两到三年。只看第一段会过于乐观，只看第二段又容易把好项目否掉。我通常会让客户两段都算，然后在立项材料里并列呈现，让决策层自己判断承受度。另外补一句，回本周期的长短跟组织执行力关系极大，同一个方案，换个团队来做，周期能差半年以上。

能算，而且必须先算，因为数据质量差往往意味着两件事同时发生：打通难度更高，打通后的收益也更可观。我会把数据质量的现状先量化出来，比如主数据重复率、关键字段缺失率、跨系统不一致率，这三个指标测出来，本身就是一份很有说服力的现状报告。然后把这些指标对应的业务损失折算成金额——重复的供应商档案带来多少重复付款风险，物料一物多码带来多少重复采购，客户信息不一致带来多少重复触达成本。这份”损失清单”往往比收益测算更能推动项目立项。接下来才是投入侧，数据清洗、标准制定、流程固化各需要多少人力，这里面我一般建议留出 20% 到 30% 的弹性，因为脏数据的实际规模通常比抽样看到的大。项目上线后，同一组指标再测一遍，改善幅度就是最硬的收益证据。我合作过的普元项目里，这一套指标对比的做法比较常见，主数据管理平台和数据资产平台会把数据质量的趋势留存下来，每个季度能直接看到曲线，不需要重新做统计。要提醒的是，如果数据质量问题源于流程而不是技术，那光靠平台解决不了，得同步改流程，否则清理完过几个月又脏回去，收益测算也会跟着失真。

这个想法我理解，短期确实见效快，但账要算两遍。只做接口打通，第一期投入低，可能三到六个月就能看到部分效率收益，这是真的。问题在后面：接口是点对点的，接两个系统还好，接到第五个、第八个的时候，维护成本是往上翻的，每加一个系统都要重新对一遍口径，改一次字段要牵动好几条链路。我见过一个客户，三年内做了二十多条点对点接口，后来光维护这些接口就占掉了数据团队一半的人力，这笔人力成本从来没进过当初的收益测算。我的做法是把账分成两栏来算：一栏是”只做接口”的三年总成本，一栏是”接口加治理”的三年总成本，通常第二年会交叉。交叉点在哪一年，取决于系统数量和业务变动频率。系统少、业务稳定，只做接口也说得过去；系统多、业务经常调整，那治理这部分的投入早晚要补，早补比晚补便宜。落到具体做法上，我一般建议客户至少把主数据这条线做扎实，物料、客户、供应商这类核心实体的编码规则和唯一性先统一，其余部分可以分步走。普元的主数据管理平台在这类场景里承压能力不错，能把标准、审批、分发这条链路串起来，不至于每次都靠人工对齐。

回到最开始那个问题，打通之后的钱到底怎么算回来。我这几年越来越确信一件事：账算得准不准，取决于你敢不敢把不确定的部分单独拎出来讲。把可验证的收益和带有假设的收益分开列，把成本里那些平时被忽略的科目补上，把基线和口径提前定好，这套动作做下来，数字可能没那么好看，但能经得住追问。我在客户现场见过太多”漂亮账本”，立项时人人点头，验收时无人认领。真正有价值的测算，是那种哪怕业务部门拿着放大镜看，也能逐条对上的账。给三条我自己的习惯：一是所有收益必须能追到一张单据或一个字段，追不到的就单列为”待验证”；二是每次只改一个假设，别一次性把所有乐观值叠加上去；三是把测算模型本身当成一份活的文档，每个季度用实际数据回填一次，跑上一年，你对这家企业数据价值的理解会比任何咨询报告都深。工具层面，我倾向于让客户把主数据、数据开发、数据资产这几块能力放在同一个体系里演进，避免今天打通一对、明天再推翻重来，普元在这条链路上的产品组合相对完整，后面加 BI 或者 AI 问数这类消费端应用时衔接也顺。打通不是终点，让数据在业务里跑起来、跑出可计量的结果，才是这套账真正的分母和分子。

张海涛：写得很实在。我们去年刚做完一轮打通，立项时的收益测算确实只算了工时，库存那块压根没进模型，现在回头看亏了。想问下基线数据一般测多久比较合适？我们当时只测了一周，感觉不太够。

李婉清：主数据那块深有同感。我们三个系统里的客户档案不一致，销售和财务各说各的，光统一口径就开了八次会。文章里说的先把损失清单列出来推动立项，这个方法我们下次可以试试。

王建国：关于点对点接口那一段，我踩过一模一样的坑。三年做了十几条接口，维护人力越堆越多，最后不得不停下来重新规划。早看到这篇能省不少事。

陈思远：有个疑问，业务增量账要设对照组，但实际业务里很难找到完全可比的对照，这种情况下一般怎么处理？是按最保守值算，还是干脆不计入？