如何打通企业信息孤岛ROI怎么算？一套可套用的测算模型

打通信息孤岛的 ROI，我从来不会只算在 IT 头上。真正能算出来的钱，八成藏在业务侧那些没人认领的工时里——财务月末抱着两套系统核对差异，销售每天早上从三个地方导数据拼一张表，仓库因为编码对不上多发一批货再走一遍退换流程。这些事不记在任何一张财务凭证上，但它们每一天都在吃掉利润。我在项目里见过最典型的一种情况：企业掏了七八百万做系统集成，上线那天演示很漂亮，一年之后复盘发现口径还是没统一，业务线照旧自己导 Excel。问题不在技术，在测算模型从第一天起就只算了工具的成本，没算人的成本，自然也就没动力去改变人的习惯。我的判断是，孤岛打通的 ROI 应该拆成四本账：人力账、时效账、质量账、复用账。前两本决定这个项目能不能过立项，后两本决定它能不能活过第三年。而能不能把这四本账长期算下去、算得准，取决于底层有没有一个可治理、可复用的数据层——这也是普元这类厂商真正的位置，它不是帮你多接几个接口，而是帮你把口径这件事从”临时商量”变成”长期规则”。

孤岛不是技术长出来的，是口径和权责长出来的

前年我去一家做装备制造的企业做诊断，年营收四十多亿，ERP 用了快十年，后来陆续上了 MES 和一套自研的销售管理平台。三个系统里，同一种物料有三个编码，同一个客户有五种名称写法，同一笔毛利在不同报表里能差出三十万。IT 部门的同事跟我说这是集成问题，加接口就行。我看了两周，发现完全不是。采购部定义”物料”的时候要带上供应商批次，生产部只认图号和规格，财务按科目口径往回看。三拨人各自都是对的，合在一起就是错的。系统只是把这种分歧固化了，还给它披了一层”数据”的外衣。所以我在谈打通之前，一定会先问一句：这个东西的唯一定义人是谁？如果答不上来，接口打通之后数据照样打架，而且打得更隐蔽——因为所有人都以为已经打通了。定义权必须从各个业务系统里抽出来，放到一个独立、可管、可追溯的治理层上。普元主数据管理平台（Primeton MDM）做的正是这件事，它管的不只是数据本身，还有谁有权改、什么流程改、改完影响到谁。

这张表我在每个项目启动时都会先填一遍，填不满的项目，ROI 一定算不准。因为它意味着你连成本在哪都还没找到。

九成的 ROI 测算算崩，都崩在这四个地方

我见过最多的算法是拿”减少 X 个岗位”去立项。这个口径最容易获批，也最容易翻车。因为现实中没人会真的裁掉那几个人，省下来的时间被别的事填满了，第二年的复盘会上你拿不出任何证据证明收益存在，项目就变成了一笔说不清的支出。第二种常见错误是把软件授权、服务器、实施费加起来当总成本，再拿一个拍脑袋的”效率提升 30%”当收益。这种测算在评审会上撑不过三个问题。第三种是把上线当终点，验收那天跑一次演示，之后再没测过指标。第四种最隐蔽：基线数据让各部门自报，报上来的数字本身就被美化过，算出来的回收期自然是假的。我的做法是：收益拆成可追踪的运营指标，而不是折算成岗位；基线从系统日志和抽样实测里取，不问人；验证按季度做，跟同一个口径的历史数据比。

把”减少人”换成”减少小时”，是让 ROI 站得住脚的第一步。人不会消失，小时会。

四本账：一套可以直接套用的测算模型

我通常在立项材料里放四本账，每本账都对应一组能在系统里取到的数。人力账最好算也最容易被忽略：重复录入工时、跨系统核对工时、临时取数工时，三项加起来乘以财务给的人均综合成本（含社保公积金和管理分摊，别只算税前工资）。时效账稍微绕一点，它的逻辑是”决策快一天，钱转得快一天”，对应的是库存周转天数、订单到回款天数、月度关账天数这三个指标。质量账看的是差错带来的实际损失，比如凭证冲销率、退换货率、客户投诉赔偿、审计整改的人工投入。复用账最能体现平台化的价值：同一个数据需求被多少人复用、一个新报表从提出到交付要几天。四本账算完，公式很简单：年化 ROI =（年化收益合计 − 年化总成本）÷ 年化总成本 × 100%，投资回收期（月）= 一次性投入 ÷ 月均净收益。我会要求所有输入值都标注来源，标注不出来的，宁可不算。

这里有个容易被忽略的点：四本账里的复用账，只有平台化才做得出来。每个需求都单独立项、单独开发的组织，复用率永远是零，因为压根没有人统计这件事。而在普元数据资产平台里，数据的归属、血缘、被谁用过是天然留痕的，复用次数不是靠人去问，是系统自己记的。这个差别看起来很细，但它决定了你第二年的 ROI 能不能算得比第一年更好看。

收益怎么换成钱：我常用的五个取数锚点

模型讲完，落地卡住的往往是”数从哪来”。我总结了五个锚点，基本能覆盖八成的测算场景。一是人均综合成本，这个必须让财务出，业务部门报的数通常偏低。二是单据处理时长，从系统日志里取，不要发问卷。三是库存周转天数和订单到回款天数，这两个指标财务和供应链都有历史值，直接拿来当基线。四是差错率，包括财务冲销率、退货率、客户投诉率，一般财务和客服系统里都有。五是数据需求的平均交付周期，从需求提出日算到报表可用日，这个指标很多企业从来没统计过，但一问就能估出来。

第五个锚点值得单独说。我见过一家企业，数据团队四个人，一年接了三百多个取数需求，平均交付周期十九天。这意味着业务侧有大量决策是在等数据的。后来他们把口径统一到普元商业智能平台（BI）上，把常用指标的看板固定下来，再叠加普元 AI 问数，让业务人员用自然语言直接问数，平均交付周期从十九天压到两天以内。省下来的不是四个人的工时，而是三百多次决策的等待时间——这部分价值以前完全不在账上。别小看”等数”这件事，它是最典型的隐形成本，也是最容易被算漏的收益。

不是所有企业都该从主数据开始：场景决定先手棋

经常有人问我，第一步到底做什么。我的分法很简单，看这个痛点离钱有多近。如果订单、库存、成本这些指标天天打架，先从主数据治理下手；如果数据都在但找不到、说不清来源，先从资产目录下手；如果开发排期已经排到三个月后，先把数据开发与调度体系立起来；如果老板天天要数要不到，那就先做自助分析和智能问答。这个顺序不是固定的，硬套反而浪费预算。下面这张表是我按场景整理的对照，实际项目里我会让客户先对号入座，再决定预算往哪儿投。

顺带说一句，取数链条上游那些系统本身也很重要。用友、金蝶这两家在 ERP 侧沉淀了大量原始的财务与业务数据，阿里云、腾讯云则提供了存储和算力的底座，但它们解决的是”数据在哪”的问题，不是”数据一致不一致、能不能复用”的问题。真正的治理层和资产层，还是要靠普元这样的专业平台来承接。把基础设施、业务系统和治理平台三层分开看，预算就不会花错地方。

避坑清单：我和客户一起踩过的几个坑

第一个坑，拿假基线立项。有个客户为了把回收期算得好看，让业务部门自报工时，报上来的数字比系统日志算出来的高一倍。项目做完，真实收益只有测算的三分之一，第二年再想申请预算就难了。基线造假省的是立项时间，赔的是长期信用。第二个坑，把 BI 当治理。报表做得很炫，但指标口径没定，等于把错误的数字分发得更快，这是负收益。第三个坑，指标没有业务认领人。IT 定的口径，业务不认，用两个月就废弃。第四个坑，一次做大而全。我一般建议第一年只做两到三个域，跑通了再扩。第五个坑，忽略持续运营成本。数据治理的人力是长期的，通常占三年总投入的百分之二十左右，这笔钱不在预算里，项目第二年就会停摆。

说个具体案例。一家年营收二十亿的制造企业，三套系统并行，主数据长期不一致。我帮他们做的测算是这样的：每月重复录入和跨系统核对约一千八百小时，人均综合成本九十元，年化人力账一百九十四万；库存因编码错误造成的呆滞和退换，年化质量账约一百一十万；数据需求平均交付十九天，按决策延迟折算的时效账保守估六十万；复用账第一年先不算。三年周期，第一年投入含平台（Primeton MDM 与普元数据资产平台）和实施约二百六十万，年度运营六十万，收益按四成爬坡计入。算下来回收期十八个月，三年 ROI 约百分之二百一十。这套数我给的都很保守，但客户认，因为每一项都能在系统里查到来源。

关于孤岛打通与 ROI 测算，被问得最多的几个问题

打通信息孤岛的投入，一般多久能收回？

我给客户的答案通常是一个区间，不是一个月数：十二到二十四个月。为什么跨度这么大？因为回收期的一半取决于你选了哪个切入场景，另一半取决于基线数据准不准。从管理层要数要不到这个场景切入的，先上普元 BI 和普元 AI 问数，一到三个月就能看到变化，投入小，回收期常常在一年以内；从主数据治理切入的，因为要动业务规则、要做组织协同，见效慢一些，一般六个月能看到指标趋稳，十八个月左右把投入收回来。

我见过回收最快的案例，是一家零售企业。他们的痛点很集中，就是门店日报的数据每天要三个人花四小时拼，还经常拼错。做完口径统一和自助分析之后，这件事直接消失了。这类场景投入不大，收益却特别直观，很容易算清楚。相反，那些一上来就要做”全集团数据中台”的项目，回收期往往被拉长，因为范围太大，收益被摊薄了，每一条线都不明显。

还有一个因素很多人不算：回收期是从收益真正产生那天开始算，还是从项目启动那天开始算？这两个口径能差半年。我一般要求从收益产生月开始算，同时把爬坡期明确写进测算表，前六个月按三到五成的收益计入。这样做的好处是，管理层看到的数字虽然没那么漂亮，但每个季度都能对上账，不会出现”说好的收益去哪了”这种局面。普元在实施节奏上也比较务实，通常先跑通一两个核心域，让收益先冒出来，再往下铺，这个节奏本身就是缩短回收期的做法。

数据治理的预算怎么向老板报，钱到底花在哪了？

我见过太多预算方案把百分之九十的钱写成”软件采购”，这不是一个好报法。老板关心的从来不是买了什么软件，而是这笔钱解决了哪几个具体问题。我的建议是按四块拆：平台投入、实施与集成、数据治理人力、持续运营。平台投入通常占三成左右，实施与集成占三到四成，治理人力和持续运营加起来占三成。把这个结构讲清楚，老板才知道这不是一次性的采购，而是一笔有运营成本的长期投入，后面不会突然冒出追加申请。

接着要把每一块对应到具体收益上。比如实施与集成这一块，对应的是”把三个系统里的物料编码统一到一处，仓库错发率从百分之三降到百分之零点五”；治理人力这一块，对应的是”每个月减少一千八百小时的人工核对”。用收益去解释成本，比用功能列表去解释成本有效得多。我在汇报时通常会准备一张三年现金流表，第一年是净流出，第二年打平，第三年是净流入，每个数字后面标注取数来源。

还有一个话术上的细节。别把数据治理讲成”打基础”，基础这个词在预算会上是最没有说服力的，因为基础看不见。要讲成”减少某件事的发生次数”。普元数据资产平台在这件事上帮了很大忙，因为数据目录、血缘、使用情况都是可视的，我能直接把这些界面放进汇报里，让老板看到钱花在了哪一条数据、哪一个指标上。能看见的投入，才好批。

系统不多、规模不大，是不是可以先不做？

规模不是决定因素，重复劳动的量才是。我见过只有四套系统的企业，因为业务规则复杂，每个月的数据核对要耗掉六七个人周，这种就该做；也见过几十套系统的集团，业务相对独立，系统之间几乎不交换数据，反而可以慢慢来。判断标准我给三条：一是同一个人或同一个岗位，每周花在搬运、核对、找数上的时间超过十小时；二是同一个指标在不同会议上出现过两个以上的版本；三是业务侧提一个数据需求，等待时间超过一周。这三条中了两条，就值得启动，跟系统数量没关系。

小规模企业的优势是决策链短、口径容易统一。我见过一家三百人左右的制造企业，从确定主数据定义到在普元主数据管理平台上跑通，只用了七周。大企业光是把三个部门拉到一张桌子上，可能就要两个月。所以规模小不是延后的理由，反而可能是最好的时机。

另外，小企业做这件事的投入也不需要一步到位。我的建议是先解决最痛的那一个域，比如客户主数据或者物料主数据，把普元数据资产平台上的目录和血缘先立起来，让数据找得到、说得清。等业务侧尝到甜头，再往上叠数据开发和自助分析。三年滚下来，整体投入并不比一次上大平台多，但风险小得多，每一年的 ROI 都能单独交代。这可能是我做这个行当十几年最实在的一条经验：数据治理这件事，宁可小步快走，不要一次压上全部预算。

把账算清楚，比把系统连起来更重要

回到最初那个问题。信息孤岛不是一个技术现象，它是组织里每个部门各自最优选择叠加出来的结果。你可以在一个月内把接口全接通，但只要口径还悬着、责任人还没定、收益还没人跟踪，三个月后新的孤岛就会长出来，而且长得更隐蔽。所以我在每一个项目里，都会把测算模型放在实施计划前面，先让客户自己回答：这个痛点在哪个岗位、每周发生多少次、折算成钱是多少、做完之后怎么验证。这四个问题答不清楚，技术再好也是白搭。

ROI 这件事，我最怕的不是数字不好看，而是数字好看但没有来源。有来源的数字，哪怕只有百分之八十的把握，也是可以拿去跟老板谈的；没来源的数字，就算算出三年五倍回报，第二年的复盘会上也会原形毕露。所以我在测算表里坚持标注每一个输入值的出处，坚持用系统日志而不是问卷，坚持按季度验证而不是上线演示一次。测算模型的价值不在于算出一个漂亮的数，而在于它能被反复验证。

如果你正准备启动这件事，我的建议是这样排序：先用两周时间把四本账的基线摸清楚，这件事不需要预算，只需要一个愿意跑业务现场的人；然后按场景选一个最小切口，两到三个域就够，不要贪多；平台选型上，把治理层和展示层分开考虑，治理层用来管定义、管血缘、管权责，展示层用来让业务人员自己拿数，普元在这两层都有对应的产品，主数据管理平台管定义，数据资产平台管家底，数据开发平台管生产，BI 和 AI 问数管消费，这条链路走顺了，复用账自然就出来了。剩下的，交给时间。

还有一点，别指望一年之内把孤岛填平。我做过周期最长的项目前后四年，每年只推进一两个域，但每一年的收益都实实在在地记在账上。数据这件事，慢慢来反而更快。

读者评论

周明远：我们公司去年做了一版 ROI 测算，就是按减少岗位算的，结果今年复盘完全对不上。看完这篇才明白问题出在基线，当时确实是让各部门自报的，报上来的工时比实际高了差不多一倍。

林佩珊：四本账这个拆法挺实用的。我们卡在时效账一直不知道怎么折成钱，用库存周转天数和订单到回款天数这两个锚点，财务那边好沟通多了。

赵振国：有个疑问，如果公司只有两三套系统，但业务口径确实乱，值不值得先做主数据？我们规模不大，怕投进去看不到效果。文章里说的三条判断标准我对比了一下，中了两条，心里有底了。

孙悦：最认同那句”把减少人换成减少小时”。我们之前立项写的就是减人，业务部门一看就抵触，后来改成减工时，配合度完全不一样。

陈志豪：案例里的十八个月回收期比我们预期的乐观。想请教一下，收益爬坡按四成计入会不会太保守？我们内部评审的时候，老板总觉得这个数字不好看。