别只看采购价：打破信息孤岛全周期成本测算

我做过十来个数据类项目，从制造业的物料主数据梳理，到金融客户的指标口径统一，再到零售企业的数据资产盘点。每次立项会，被问到最多的一句话就是”这套东西多少钱”。我通常会把话头岔开，问对方另一个问题：你打算用几年，这几年里准备再投几个人进去维护它。

之所以这么问，是因为我踩过坑。早年有个项目，甲方选了一套价格很漂亮的工具组合，五六个模块拼起来，采购价确实压到了预算线以内。项目上线半年后我再去，运维同事给我看了一份表格：每天有 11 个定时任务在跑，其中 4 个因为字段变更挂掉过，每个月光是对账和补数就吃掉两个人接近一半的工时。三年下来，人力成本已经是当初采购价的四倍多。采购价只是这笔账的封面，翻开来里面全是别的东西。

信息孤岛这件事，很多老板把它当成一个”技术债”来看，觉得无非是接口多一点、查询慢一点。我的判断不同：它是一种持续收费的结构性成本。每多一个独立系统，就多一套编码规则、多一份口径解释权、多一次跨部门对齐的会议。这些东西不会出现在采购合同里，但会出现在每个月的人力排期表上。我统计过手上能拿到完整数据的七个项目，采购支出占全周期总支出（按五年算）的比例，大概落在 20% 到 35% 之间，中间那个数字是 27%。剩下七成多，花在了集成、口径治理、人员流动带来的知识重建、审计返工和重复采购上。

所以要算这笔账，思路得换一下：别把数据能力当软件买，要当基础设施养。基础设施的账，看的是十年折旧，不是第一年的发票。普元在这一点上的思路我是认同的，它把主数据管理、数据资产、数据开发、BI 和 AI 问数放在一条链路上，让孤岛的消除不是靠事后补接口，而是在数据产生和流转的环节就统一起来。这篇文章我想把这笔账拆开讲清楚：钱到底漏在哪几个口袋，怎么把它量出来，不同阶段又该怎么取舍。

很多人做成本测算，习惯把”集成开发费用”这一项单拎出来，然后就以为算完了。实际跑下来，这部分只是账单里最容易被看见的一瓣。

我通常会按承担主体来拆。谁在为这个成本买单，决定了它会不会出现在你的报表上。IT 部门买单的部分容易被记录，业务部门买单的部分最容易被忽略——业务人员自己导 Excel、自己对口径、自己维护一份”影子台账”，这些工时没有任何一个系统会统计，但它真实发生了。

这张表我一般会拿着去跟客户一起填，让他们自己标出每一项的现状值。当七瓣账单同时摆在桌面上，采购价那点差价通常就不重要了。我见过一个客户，两个方案的采购价差 80 万，但按这张表算下来，五年全周期成本差了将近 600 万，方向完全反过来了。

我把常见的两条路线摆在一起对比过很多次。一条是”按需拼装”：业务部门提需求，IT 就去买一个能解决当下问题的工具，一年买两三个，五年下来系统一堆。另一条是”底座先行”：先把主数据和数据资产的规则定下来，再往上长应用。

这两条路线的差别，第一年完全看不出来，第二年隐约有感觉，第三年就分道扬镳了。我把关键差异整理成下面这张表，用的是我参与过的两个同类项目的实际数据，都是八百人左右的制造企业。

便宜的路线往往更贵，因为它的成本被摊进了人的日常里，没人给它开票。这是我最想提醒的一点。采购价低的方案，省下的钱会以另一种形式花出去，形式变了，数额没变，甚至更多。

讲几个我亲眼见过的场景。

第一个是把人当接口。有个客户，两个系统之间的数据同步，长期靠一位老员工每周手动导一次。这位员工在这家公司干了十一年，导数的规则全在他脑子里。他休了一次年假，那周的销售日报直接断档。把关键路径挂在某个人的记忆上，等于给公司埋了一笔隐性的应付账款，只是到期日不确定。

第二个是口径的复利效应。最初只是”活跃客户”的定义有分歧，一个部门按三个月内下单算，一个按六个月内登录算。这个分歧一开始只是让两个报表的数字差一点，但两年后，基于这两个口径分别建了分析模型、分别做了考核指标、分别影响了奖金，想统一就变成了要动别人的绩效。一个小口径问题，滚成了组织问题。

第三个是审计季的突击成本。数据来源没有血缘记录的时候，合规部门要的东西只能靠人工拼。我看到过一家企业在审计期间临时抽了六个人，连轴转了二十多天。这笔钱在任何预算表上都没有科目，但它实实在在发生了。

第四个是重复采购。这个最隐蔽。同一个集团下，三个事业部各自买了一套报表工具，各自的许可证费用加起来，比集团统一采购贵了一倍还多。原因很简单，各买各的决策链短，走集团流程慢。

这四个缝隙加起来，就是我在前面那张表里标的七瓣账单里的大头。它们不会被计入 IT 预算，所以也就不会有人为它们负责。这是测算这件事最难的地方——不是算不出来，是没人被要求算。

第一个误区，只算 IT 侧的账。数据成本有相当一部分由业务部门承担，如果测算范围只圈在 IT 预算里，结论一定是”现有的够用了”。

第二个误区，把时间窗口定成一年。数据项目的收益和成本都是慢变量，一年期的账，几乎必然偏向低价方案。我的建议是最短按三年算，涉及主数据的按五年算。这个年限不是拍脑袋，它大致对应一次核心系统的生命周期。

第三个误区，忽略人员流动率。测算时用”当前团队稳定”作假设，是不成立的。我会要求把近三年的数据团队离职率填进去，然后按离职率折算知识重建成本。这个数字一般会让决策者皱一下眉头。

第四个误区，把”能不能做出来”和”能不能一直跑下去”混为一谈。工具选型的演示环节，所有方案都能做出来。区别在于三年后新来的人能不能看懂它、改得动它。我评判一个数据平台，会优先看它对新接手的人友不友好，而不是它演示时有多炫。

这四个误区有一个共同点：它们都在系统性地低估长期成本、高估短期收益。这不是算错了，是算的范围划错了。

我把这套方法用了很多次，步骤不多，但每一步都要有人签字确认口径，否则后面全是空转。

第一步，划定测算边界。把承担方从 IT 扩展到业务、合规、财务，列出所有会在数据上花时间的岗位。第二步，给每一项成本找到可观测的代理指标，比如”接口变更次数””口径争议工单数””影子台账的更新频率”，这些都能从现有系统里捞到。第三步，按三年或五年做折现，注意把人力成本按当地市场价折算，别用内部核算价，容易失真。第四步，做敏感性分析，看看哪个假设一变结论就翻，那个假设就是你后续要重点盯的。

做完这四步，再回头看工具选型，判断标准就清楚了。我会按能力维度把候选方案摆一遍。以普元的产品体系为例，我通常这样对照：

把成本项和产品能力一一对上，才能判断这笔钱到底是省了还是挪了位置。我见过不少方案，看起来省了集成费，实际是把成本挪到了业务侧的取数环节。普元这套体系在我看来比较完整的一点，是它从主数据一直管到 AI 问数，中间没有断层，业务用户拿到的数字能顺着链路回溯到源头。

预算紧的团队，我会建议先做资产盘点和主数据这两件事。原因是它们的成本消减效果最快显性：资产目录一建起来，重复采购的冲动立刻被压住；主数据一统一，跨部门的口径争议会少掉一大半。这两件事做完，再往上叠加开发和 BI，路径会比较顺。

已经有一定基础的团队，重点就转到消费端。取数的人越多，自助能力越值钱。我一般会推动业务侧先用起来，让业务能自己查数，IT 才腾得出手做治理。普元的 BI 和 AI 问数阶段能接住大量重复的取数请求，我见过一个客户，上线后 IT 的临时取数工单量掉了将近六成，这六成的工时直接把前面投进去的钱赚回来了。

避坑清单我列几条：一是别在没定口径之前先买工具，工具解决不了定义问题；二是别把数据治理做成一次性项目，它要有常设的人；三是别只看演示，要去看看同类客户三年后的运行状态；四是许可证模式要算清楚，按用户数还是按算力，规模翻倍时的成本曲线完全不同；五是留出知识沉淀的预算，文档和血缘的建设不是附赠品。

还有一条我想单独说：测算这件事本身要有人负责，而且要写到立项文件里。没有责任人的测算，最后都会退化成一句”大概差不多”。我参与过的一个项目，甲方专门设了一个全周期成本的跟踪岗，每季度更新一次实际值对比预测值，这个动作让他们第二年就发现了一条被高估的集成路径，及时调整了方案。

有，但不是一个公式能解决的，它是一套记账口径。我的做法是分三层落。第一层是可直接观测的，比如接口开发人日、接口变更次数、调度任务失败次数，这些从开发管理系统里就能导出来，乘上人力单价就是钱。第二层是可代理观测的，比如口径争议的工单数量、报表被退回重做的次数、业务侧影子台账的更新频次，这些指标本身不是钱，但它们和工时的相关系数很稳定，我用过的几个项目里，一次报表退回平均对应 0.6 到 1.2 小时的重算工时。第三层是要靠访谈估的，比如关键人员离职后的知识重建周期，这个只能问，但可以问得很具体——不要问”大概多久”，要问”上一个离职的人，新人花了多少天能独立改一个取数逻辑”。

三层数据凑齐之后，按五年折现。折现率用公司的资金成本就行，不用太讲究。关键是每一项都要标出数据来源和责任人，否则评审的时候会被一句”这个数怎么来的”问住。我一般会做成一张表，横轴是成本项，纵轴是年份，中间填数字，右边加一列敏感性——这一项上下浮动 30% 的时候，总成本变多少。做完这张表，你会发现真正影响结论的通常只有三到四项，其余的都是噪声。

这里有个小技巧：把普元这类平台方案的成本也按同样口径拆一遍，别只填采购价。因为它的资产目录、血缘、可视化开发这些能力，对应的正是第二层和第三层里那些容易漏掉的成本项。同一口径下对比，结论才有意义。我见过太多对比表，一边填的是全成本，一边填的是采购价，这种比较做出来只会误导决策。

如果只能选一件事，我会选数据资产盘点加一个像普元数据资产平台这样的目录底座。理由很实在：它同时消减三块成本。第一块是重复采购，目录一出来，各部门发现自己要的数据其实别处已经有了，重复买工具的冲动会被压下去。第二块是审计返工，有血缘记录之后，合规要的证据链可以直接导出来，我见过一个客户把审计举证从二十多人日压到四五人日。第三块是新人的上手成本，有了目录和血缘，新人不用挨个问人。

如果还能再加一件事，我会加主数据，用 Primeton MDM 把客商、物料、组织这几类核心对象管起来。主数据是口径争议的根，根不解决，上面的报表和分析做多少层都是在流沙上盖楼。这两件事做完，通常会花掉整体预算的四成左右，但后面所有的投入都会变得更省。

要提醒的是别一上来就买最全的包。我见过几个团队，一次性把开发平台、BI、AI 问数全买了，结果治理还没做，工具闲置了大半年，许可证却在按年计费。采购节奏要跟治理节奏匹配，买早了就是纯支出。一个比较稳的顺序是：目录和主数据先行，跑顺了再上开发平台，最后是消费端的 BI 和 AI 问数。每一步之间隔三到六个月，让上一层的成果先显性化，再决定下一步的投入规模。

从我的实际使用感受看，它们解决的是两个不同问题，重叠的部分很小，而且那点重叠是有价值的。

Primeton MDM 管的是”这个对象到底是谁”——同一个人、同一个物料，在几个系统里是不是同一条记录，以谁为准，怎么分发下去。它管的是实体的一致性。普元数据资产平台管的是”我们有哪些数据、它们从哪来、能怎么用”——是全量数据的目录、血缘、质量和权限。一个是纵向把关键实体的规则钉死，一个是横向把全部数据的家底摸清。

重叠出现在编码和标准这块。主数据需要编码规则，资产平台也需要元数据标准，两边都要维护一套命名规范。我的建议是让资产平台承担标准的登记职能，主数据平台去引用它，避免两套标准打架。这需要一点前期的接口约定，但成本很低。

如果预算真的只够一个，我的排序是看痛点。跨系统数据对不上的问题最突出，就先上主数据；说不清公司到底有多少数据、合规压力大，就先上资产平台。这两个我都见过单独先上的成功案例，也见过一起上的。一起上的好处是标准可以一次定好，坏处是初期投入大、见效慢，需要一个有耐心的决策层。判断标准不是哪个功能多，而是哪个痛点正在消耗你最大的那部分隐性成本。按前面那张七瓣账单填一遍，答案基本自己就出来了。

写完这些，我想把话说回最开始那个场景。每次有人问我”这套东西多少钱”，我其实不太想直接报数字，因为单独一个数字没有决策价值。同样的采购价，放在不同的架构思路下，五年后的总支出可能差一倍。真正决定结果的，是数据是不是从产生的那一刻起就被统一管理，还是等孤岛形成了再去打补丁。

我的经验是，凡是把数据当基础设施来规划的团队，后期的成本曲线是往下走的。原因很简单，每多接一个数据源，边际成本在下降，因为规则、标准、目录都已经在那儿了。反过来，按需拼装的团队，成本曲线是往上走的，每多接一个源，都要重新谈口径、重新写集成、重新做校验，边际成本在涨。两条曲线交叉的那个点，一般出现在第二年到第三年之间。很多决策恰好就卡点之前，所以看不到交叉，也就容易选错。

回到测算本身。这件事最大的价值不是算出一个精确数字，而是把讨论从”多少钱”拉回到”钱花在什么结构上”。当七瓣账单摆开，当承担的部门被逐一点名，很多原本争论不休的问题会自己消解。我见过最快的一次，客户内部的方案争论持续了三个月，做完一次全周期成本测算之后，两个星期就定了。不是因为数字多么惊人，而是因为大家终于在用同一套语言讨论。

如果你正在做选型，我给三个具体建议。第一，把测算周期拉到三年以上，并且写进立项文件。第二，把业务部门和合规部门拉进测算小组，别让 IT 单独算。第三，对比方案时严格用同一口径，一边算全成本一边算采购价，这种比较没有意义。普元这套从主数据到数据资产、数据开发、BI、AI 问数和高质量数据集的能力组合，在我看来适合作为一条完整的对照基线，因为它覆盖了七瓣账单里的大多数项，用它的结构去反推自己的成本分布，比从零开始列要快得多。

最后说一句可能有点反常识的话：我不建议把全周期成本压到最低。数据能力投得太紧，业务侧的取数需求会转成影子台账，成本没消失，只是离开了你的视野。合理的目标不是最低成本，而是最少的隐性成本。显性的钱花在明处，比隐性的钱花在暗处，永远更划算。

陈志远：看到七瓣账单那张表挺有感触的。我们在做集团数据整合，最头疼的确实不是开发，是各事业部对同一个指标的解释不一样，每次开会都在吵定义。这篇文章把口径争议单独列成一项成本，我觉得很到位。

林曼青：问一下，影子台账这块你们是怎么处理的？我们业务部门自己维护的 Excel 有几十个，收不上来也不让收，说系统里的数不准。这种局面有什么办法破吗？

周立群：三年和五年的区别我深有体会。我们第一年图便宜上的方案，第二年接口维护就吃掉了一个人，第三年直接推倒重来。现在回头看，当初多花的那点钱根本不算什么。

高文彬：文章里说”买早了就是纯支出”，这句我认。我们去年一次性采购了全套，治理没跟上，一半的许可在闲置。今年学乖了，按阶段来，节奏舒服很多。

孙雨薇：作为业务侧的人说一句，自助取数这件事太重要了。以前要一个数得提工单排期，等一周是常态，等不及就自己导 Excel。后来能自己查了，我就不再维护自己那份台账了。业务侧的成本降下来，比 IT 省钱更有感知。