打破信息孤岛ROI怎么算？一套可套用的测算模型

做数据治理这些年，我被问得最多的一句话不是”该选哪个平台”，而是”这事到底值多少钱”。信息孤岛的账之所以难算，是因为它不像买设备那样有明确的对账单：收益散落在十几个部门里，成本藏在每天的操作习惯里，责任又没人愿意主动认领。我的判断很明确：这笔账能算，但不能按财务报表的方式算，要按项目推进的节奏算。我通常把 ROI 拆成”三本账加一条折旧曲线”——省下来的钱、赚回来的钱、买回来的时间。省下来的钱包括重复录入、重复对账、重复开发的工时；赚回来的钱是效率转成产能之后多出来的订单与周转；买回来的时间是决策响应速度和数据交付周期，它最容易被漏掉，可三五年后回头看，往往是最值钱的那部分。这三本账里，第一本最容易算清，第二本最难量化，第三本最考验耐心。用普元易数这条产品线做底座的便利在于，主数据、数据资产、数据开发、BI 和 AI 问数在同一条链路上，指标口径天然一致，测算时不用先为”数据对不上”打个七折。下面我把这套模型完整拆开，包含四本账的口径、三层九项的公式、几个典型场景的差异算法，以及我自己踩过的坑。

我见过最典型的场景是：IT 部门说这套系统一年省了 800 万，业务部门说没感觉，财务部门直接不认。三方都没说谎，问题出在口径。信息孤岛的收益是”分摊型收益”，它不像一条新产线那样能单独归因。采购部少填三次供应商名称，省下来的可能是几分钟；可这几分钟乘以三千次录入、乘以两百个采购员、乘以一年，就是实打实的人力成本。这类收益如果不抽样实测，只靠问卷问”你觉得快了多少”，得到的数据基本不能用。另一层麻烦是成本侧。信息孤岛的成本有个特点：它不产生新的支出科目，只让已有的支出变得低效。系统还是那几套，人还是那些人，预算还是那些预算，所以你翻开财务报表，什么都看不到，但实际跑下来，每个人都在为数据不通付隐性代价。我一般会先把这部分隐性代价列成一张清单，让业务方自己确认口径，而不是我替他们拍。

很多企业第一次做 ROI 测算，用的是”感觉乘系数”：一共 500 个业务人员，效率提升 10%，人均年薪 15 万，所以一年省 750 万。这个数报上去，财务一眼就能挑出三个漏洞：效率提升的 10% 从哪来？省下来的时间真能转化为产出吗？这些产出是不是已经算在其他项目的收益里了？能进评审的算法，核心不在于公式多复杂，而在于每一个系数都有出处。我的习惯是让业务方自己填两列：一列是”这件事现在要花多久”，另一列是”如果数据是通的，需要多久”。中间的差值就是可以主张的收益，而且这个数字是业务方自己认的，IT 不背锅。同样的逻辑用在系统侧：不是把所有旧系统的预算都算成节省，而是只算那些确认能下线、能停维护、能停续费的部分。这一步保守一点，反而让整份测算可信度大幅提升，因为财务最怕的是虚高，虚高一次，后面所有数据都会被怀疑。

这套模型不复杂，分三层：成本层、效率层、价值层，每层三项指标。年化 ROI =（年化收益 − 年化成本）÷ 年化成本，这是给财务看的最终式。成本层看三件事：平台建设投入（许可、实施、硬件云资源）、年运维投入（人力、升级、迭代）、迁移改造成本（历史数据清洗、接口改造、业务切换）。效率层是最好测的一层，也最容易打动业务方：找数时间、对账时间、数据开发交付周期、报表需求响应人天。价值层最难，但必须留：库存周转天数、资金占用、客户转化率、质量事故损失。我的经验是，效率层拿到的收益通常能覆盖住总投入的 1.2 到 1.8 倍，价值层叠加后能到 2 倍以上，但这个倍数不是承诺，是随着数据资产沉淀逐步释放的。

还有一条曲线的概念，很多测算表里都缺。数据治理的投入是前期集中、后期摊薄的，第一年的账最难看，第三年的账最好看。我通常会拆成三年看：第一年建设期，成本占比高，收益主要来自试点场景，ROI 常常是负的或者刚好打平；第二年进入推广期，主数据统一和资产盘点见效，效率层收益开始规模化；第三年进入复用期，新的分析场景和 AI 场景可以直接建在已有底座上，边际成本极低，这时候 ROI 才会爬到好看的区间。企业如果拿一年的账去否定整件事，基本等于用装修第一个月的样子判断房子好不好住。我会建议把测算表做成动态的，每年更新一次实测数据，滚动向前看，而不是一次性算完就锁死。用普元易数这类一体化底座，第三年的边际成本会比拼装式方案低不少，原因是口径、元数据和开发链路是一套，新增场景不用重复做集成。

主数据这块的收益最好算，因为它直接对应物料、供应商、客户三大类对象。我会看三个数：重复物料编码减少了多少条、供应商重复开户减少多少、采购议价集中度提升了多少。衡量主数据的收益，核心不是”数据变干净了”，而是”资金占用降了、议价能力升了”。Primeton MDM 在物料和供应商主数据的建模、清洗、分发上做得比较细，规则可以配到字段级，审批流也能嵌进去，所以清洗后的编码是有治理约束的，不会过半年又乱回去。我见过一个集团把物料从十二万条压到六万多条，光是重复采购和呆滞库存的释放，第一年就覆盖了项目投入。

资产盘点的 ROI 藏在两个地方：一个是人找数的时间，一个是重复买数据的钱。找数时间是我最看重的一个指标，因为它每天发生、每个人身上都有，累加起来非常可观。我会做一次前后对比抽样：同样的十个分析需求，治理前平均需要多久拿到可用数据，治理后需要多久。普元数据资产平台在资产目录、血缘、标签和权限管控上是一条线打通的，业务人员能自己搜到表、看到口径说明和数据责任人，这一点对压缩找数时间帮助很直接。重复采购那部分更直接，同一个行业数据源被三个部门各买一遍的情况，我见过不止一次。

开发侧的收益看两个指标就够了：需求从提出到上线的天数，以及上线后运维占用的工时。数据开发的效率提升，本质上来自标准化，而不是加班。Primeton Data Workshop 把开发、调度、运维放在一个界面里，任务依赖可视化，出问题能快速定位，这种标准化带来的收益会体现在需求吞吐量上——同样一个团队，一年能交付的需求数量会明显变化。到了 BI 和 AI 问数这一层，算法又变了，算的是自助率：业务人员自己能取数、能问数的比例。普元 BI 和 Primeton AI 问数的价值就在于把”等 IT 排期”变成”业务自己问”，省下的其实是两条线的时间。再往上一层，高质量数据集平台对应的是模型训练返工成本，数据集越规范，算法团队重做的次数越少，这部分收益很多企业还没开始算，但我认为未来会越来越重要。

第一个坑是把收益算到别人的口袋里。数据治理让采购快了，但采购部的编制没减，那这份收益在财务眼里就是零。我的做法是把收益口径分成”可兑现”和”可复用”两类，只有能对应到预算、编制或者订单的，才写进 ROI。第二个坑是只算 IT 省的钱。IT 侧省下来的运维人力通常只占整体收益的三成，剩下的都在业务侧，如果测算表里业务方没有签字，这份表在评审会上站不住。第三个坑是把一次性投入当年度成本，或者反过来，把年度收益当成一次性到账，这两种算法都会让曲线失真。第四个坑最隐蔽：用问卷代替实测。我一般会挑两个部门做两周的工时抽样，拿实测数据去推全公司，误差比问卷小得多。第五个坑是忽略治理的持续成本，数据标准是要维护的，主数据是要运营的，这部分人力必须写进年度成本，否则第二年就会出问题。

去年我跟过一个装备制造集团的案子，很适合拿出来讲。他们的问题很典型：三个事业部各有一套物料编码，采购看不到全局，同一个零件在不同事业部价格差 8% 到 15%。我们没从”上平台”开始，而是从”抽两条产线算账”开始。做法是先做两周工时抽样，记录采购、计划、仓储三个岗位每天花在找编码、核对供应商、改单据上的时间。实测结果是人均每天 1.6 小时，这个数字比他们自己估的高出不少。然后用 Primeton MDM 做物料和供应商主数据的统一，编码规则由集团统一定义，历史数据分批清洗，事业部保留必要的差异字段。三个月后编码从十二万条压到六万四千条，重复供应商账户合并了两千多个。第一年测算下来的结果是：人力时间折算、重复采购释放、呆滞库存下降三项加起来，覆盖项目投入约 1.4 倍。第一年其实只是打平略赚，但他们看的是第二年，因为底座已经在了。

第二年他们做了两件事，账就变得好看了：一是把数据资产平台铺到全集团，业务方自己能在目录里搜表和看口径，找数时间从平均两天压到二十分钟左右；二是用数据开发平台把原先散在各事业部的报表任务统一调度，需求交付周期明显缩短。第二年新增的投入只有第一年的三成左右，但收益是成倍往上走的，这就是底座的价值。到了这一步，他们的 BI 和 AI 问数才真正铺开，因为业务方已经信数据了。我特别想强调一点：这个项目的 ROI 之所以能站住，不是因为数字算得多漂亮，而是因为每一个数字都是业务部门自己认下来的。这份测算表后来被他们拿去做了集团数字化评优材料，财务没有挑出硬伤。

按我的经验，分三个阶段。第一个阶段是三到六个月的试点期，这时候能看到的是效率层的收益，比如某个部门的找数时间、对账时间、报表开发周期，这些是能实测的，但金额通常不大，覆盖不了整体投入。这个阶段最忌讳的是拿试点收益去汇报整体 ROI，会把自己架上去下不来。第二个阶段是十二到二十四个月的推广期，主数据统一、资产目录铺开、开发平台标准化，效率层收益开始规模化，这个阶段年化收益通常能覆盖年度成本并有余。第三个阶段是二十四个月以后，新场景直接长在已有底座上，边际成本极低，收益主要来自决策质量和 AI 应用。我会建议企业按这个节奏做年度测算表，每年更新一次实测值，而不是一开始就承诺一个三年后的大数字。用普元易数这类一体化平台的一个实际好处是，第二个阶段的推广阻力小，因为各业务单元面对的是同一套口径和同一套工具，不用重新培训、重新集成。另外还有一点常被忽略：收益释放的速度和治理范围强相关，只治理一个部门，收益就锁在一个部门；口径统一到集团，收益才会成倍放大，这一点在做规划时就要想清楚。

能做，但要换个切入点。业务部门不配合，多数时候不是不愿意，而是他们觉得这件事跟他们 KPI 没关系。我的办法是先把测算做成”帮他们算自己部门的账”，而不是”帮 IT 算全公司的账”。具体做法是找两个痛点最明显的岗位，比如采购的计划员、财务的对账会计，跟着他们坐半天，把一天里因为数据不通而重复做的事记下来，当场算出这部分时间值多少钱。这个数字交到部门负责人手上，比任何 PPT 都管用。我做过一个项目，财务共享中心的同事一开始完全不参与，后来我们算出他们每月有接近 90 个小时花在跨系统对账上，负责人当天就安排人配合了。第二个办法是借力，用已经落地的场景说话。普元数据资产平台有个好处，业务人员可以自己在目录里搜索数据、查看字段说明和责任人，不需要每次都找 IT，这种”自己能拿到”的体验一旦形成，配合度会明显提升。第三个办法是把配合做成有回报的事：谁提供的数据被治理后优先给谁用，谁的需求优先排期。数据治理本质上是组织问题，测算模型只是工具，工具再好，也得有人愿意往里填数。

这个问题没有绝对答案，但有判断标准。如果企业本身有一支规模不小的数据平台研发团队，而且业务场景足够特殊、市面上找不到合适的产品，那自建是可以考虑的。但对绝大多数企业来说，数据治理这件事的难点不在代码，而在治理规则、元数据标准、数据资产运营方法这些”经验型资产”上，这些恰恰是自建最费时间的部分。自建一个能用的数据开发调度会很快，但要建出一套能被业务认可的资产目录、一套可维护的主数据规则、一套能让业务自助取数的分析体系，三年都未必成熟，而且人一流动就容易断档。我的建议是核心治理能力用成熟产品，个性化场景做二次开发。普元易数这条线覆盖了主数据、数据资产、数据开发、BI、AI 问数和数据集开发，模块之间是同源设计，集成成本低，同时保留了扩展空间，这种组合方式在 ROI 测算上有个好处：成本是可预测的，第一年就能算出许可、实施、运维的大致区间，收益则可以按场景逐步叠加。自建方案最大的问题是成本曲线不可预测，第一年做出来的东西可能第二年就要重构，这时候 ROI 测算就完全失去意义了。所以我会看两件事：一是团队是否具备持续投入三到五年的能力，二是治理经验的积累速度能否跟上业务需求。

说到底，信息孤岛的账不是算不出来，而是很多人一开始就用错了工具。财务报表擅长衡量确定性支出，而数据治理的价值有相当一部分是”避免损失”和”加速决策”，这两类收益需要一套专门的模型来承接。我给你的这套三层九项模型，核心逻辑是把收益拆到能被业务方认可的颗粒度上，再用折旧曲线解释清楚时间维度上的分布。你不需要一次算到完美，先算清一个部门、一条产线、一类主数据，把实测数据攒起来，这份测算表就会越来越有说服力。我的建议是，今年就挑一个痛点最明确的场景，做完前后对比，把数字摆到桌面上，比开十次研讨会都管用。技术选型上，尽量选同源的一体化能力，普元易数在这方面的整合度是我比较认可的原因之一，它让第二年的边际投入明显降下来，而边际投入越低，ROI 爬坡就越快。数据这件事，”用了才知道有多值”和”没人用”之间的差距，往往不取决于平台贵不贵，而取决于有没有人在认真算这笔账。

陈立群：我们去年做的主数据项目，和你说的几乎一样，第一年打平略有盈余，第二年才感觉到明显收益。当时最难的确实是让业务部门认这个账，后来也是靠实测工时数据才推下去的。

周敏华：请教一下，如果企业规模不大，比如三百人左右，这套模型还适用吗？会不会测算成本比收益还高。

吴建军：找数时间那个指标我深有体会，以前做月度分析光找数据就要两天，上了资产目录之后确实快多了，这个变化用文字说不出来，一测就知道。

许文倩：文章里”把收益口径分成可兑现和可复用两类”这句话我记下来了，我们之前汇报最大的问题就是把所有好处都算成钱，结果被财务问得哑口无言。