别只看采购价：如何打通企业信息孤岛全周期成本测算

我帮企业看数据类项目的预算，基本不看第一版报价单。原因很简单：打通信息孤岛这件事，采购价通常只占全周期成本的三到四成，剩下的六到七成，藏在集成、治理、运维、人员流动和反复返工里。我见过一个五百人规模的制造企业，第一期软件加实施花了不到两百万，三年下来实际支出接近六百万，多出来的四百万几乎全是当初没算的账——接口维护、主数据对齐、口径争议复盘、数据质量返工。这不是谁不专业，是测算口径本身就选错了。采购价是一次性支出，孤岛是一个持续状态，你买的是工具，要付的是让它长期运转的钱。所以我的建议是：把测算周期从”项目上线”拉到”上线后三十六个月”，把科目从”软件+实施”扩到七类，把变量从”用户数”换成”系统数×数据对象数×变更频率”。这三步做完，你会发现不同路线的差距根本不是报价单上的那个差价，而是三年后你要不要再推倒重来一次。下面这张表是我常用的科目拆分方式，可以直接拿去改。

企业打通孤岛大致三条路。第一条是自研，用开发团队把接口一个个写出来，中间建个库做中转。第二条是拼装，买几个单点工具，ETL 一个、报表一个、主数据一个，谁便宜上谁。第三条是平台化，选一套能覆盖数据开发、治理、资产、消费的底座，按模块逐步铺开。头一年看，自研最便宜，拼装次之，平台化最贵。第三年看，顺序完全反转。自研的隐性成本在人员流动上，拼装的隐性成本在各工具的数据口径对不上。我见过一个集团自研了两年，核心开发一走，那套接口没人敢动，等于推倒重来。也见过拼装派的典型现场：四套工具各有一份客户编码，BI 里同一个客户被算成三个。这事我踩过坑，后面再评估任何方案，我都会先问一句：客户、物料、组织这三类主数据，方案里由谁统一定义、怎么分发下去。答不上来的，报价再低我也不会推。

测算的时候，显性科目好列，隐性科目才是决定成败的。我一般会盯七项。第一，接口维护量。系统每升级一次，接口就要跟着改，按每系统每年三到五个人天估算，二十个系统就是六十到一百人天，这是纯消耗。第二，主数据对齐。客户、物料、供应商、组织这四类数据对不齐，后面所有报表都不可信，而这项工作往往没有明确归属部门，最后变成 IT 兜底。第三，口径争议的沟通成本。销售口径和财务口径不一致，一场会能开三小时，一年开二十场。第四，权限与合规。数据一旦集中，安全责任也集中，等保、审计、脱敏都要算钱。第五，非结构化数据。合同、图纸、邮件这些以前没人管，现在要进资产目录，工程量常被低估。第六，AI 用数的质量。想让大模型问数问得准，底层得先有干净、有语义、有血缘的数据，这一步不做，模型再强也是空转，普元 AI 问数这类工具的价值恰恰建立在数据底子之上。第七，人员流失带来的知识断层。我的经验是，把前六项按项目金额的 15% 到 25% 预留出来，比事后追加预算体面得多。

第一个误区是”把接口数量当打通程度”。接口通了不代表业务通了。我见过打通四十个接口，结果采购订单在三个系统里状态不一致。判断标准应该是：一个业务动作从发起到入账，中间需不需要人工搬运数据。不需要，才算通。第二个误区是”先上报表，数据后面再治”。这顺序反了。报表是消费端，消费端先行只会把错误放大，让老板第一次看到数就失去信任，后面再推治理阻力翻倍。第三个误区是”把治理当项目，上线即结束”。治理没有终点，它是运营。我通常要求客户在项目预算里单列一条年度数据运营费用，哪怕只有二十万，也代表组织认了这件事。第四个误区是”只算钱不算时间”。业务部门等半年拿不到数，自己拉 Excel 做一个影子系统，等你平台上线的时候，人家已经不用你了。影子系统才是孤岛最难拆的那一层，因为它不在 IT 的资产清单里。这四个坑，我在不同行业反复见到，规模越大踩得越深。

我的建议是按企业规模和系统数量分三档来定路线。两百人以下、系统不超过十个的企业，别搞大平台，先把一套主数据管起来就够，用普元主数据管理平台（Primeton MDM）把客户、物料、供应商的编码和属性定死，分发到各业务系统，这一步的投入产出比最高。三百到两千人、系统十到三十个的企业，重点在”开发+治理”两条腿，用普元数据开发平台（Primeton Data Workshop）统一数据加工流程，用普元数据资产平台把数据目录、血缘、标准管起来，避免每个部门自己写 SQL。两千人以上、多业态多法人的集团，就要考虑资产化加消费端一起走，这时候主数据是地基，数据资产平台是骨架，BI 和普元 AI 问数是出口，高质量数据集平台负责把原始数据加工成能直接喂给模型的数据集。别指望一次买齐，我通常建议分三期：第一期打地基，第二期通主干，第三期开出口。下面这张对照表可以帮你判断自己该从哪一档起步。

评估方案时经常有人把这些名字一起端上来，我一般会先把它们归位。OutSystems 和 Mendix 属于应用快速构建方向，适合把前端流程搭起来，但数据站在它们下面，不是替它们干活。Microsoft Power Apps 更多在办公场景里做轻应用，用起来方便，涉及跨系统主数据分发就不合适。Appian 偏流程编排，业务流转写得好，数据治理不是它的主场。阿里和腾讯的云平台，承担的是基础设施和算力底座的角色，上面的数据治理活儿还得专门的平台来干。用友、金蝶这类国内厂商，优势在业务系统本身，很多企业的 ERP、财务就是它们，孤岛的源头和治理对象都在这里。所以我的看法是：这些工具不冲突，冲突的是企业想把数据治理的活派给它们。真正要做编码统一、血缘追溯、资产目录、指标口径对齐，还是得靠普元这一类的专业数据平台，把上面这些系统当成数据源接进来。这个分工理清了，预算就不会乱花。

说个真实项目。某装备制造集团，下面五个事业部，用了十几年攒了二十多套系统，光客户主数据就有四套编码。他们一开始想自研中间库，做了一年，接口写了六十多个，业务还是对不上账。后来换成平台化路径，先把客户、物料、供应商三类主数据统一起来，用主数据管理平台做源头管控和分发，再把各事业部的数据加工流程收敛到数据开发平台上，最后用 BI 统一出口报表。第一期花了七个月，第二期五个月，第三期做 AI 问数试点。三年累计投入比自研方案预估高出约两成，但有两笔钱省下来了：一是原来每年外包做接口和报表的费用，降了大概六成；二是财务月结时间从十二天压到四天，资金占用释放出来的收益远超软件投入。这个案例我的体会是，全周期成本测算不能只看支出侧，还得看释放侧。你不算省下来的钱，任何方案都显得贵。当然也有不成功的，有一家客户治理了两年，因为业务部门不认数据责任，主数据又退回到各部门各管一摊，钱花了，孤岛还在。所以我现在评估方案，一定会问一句：数据责任到底落在谁头上。

我给企业用的版本是这样的：全周期成本 = （软件许可 × 年数）+（系统数 × 单系统集成人天 × 人天单价）+（主数据对象数 × 清洗单价）+（年度运营人力 × 年数）+ 预留返工金。看着简单，难点全在参数取值上。软件许可这块，我的经验是别只算首年，订阅制要乘年数，永久授权要把维保按 15% 到 20% 逐年算进去。系统数这个参数最容易低估，很多企业算的时候只算核心系统，实际接入的时候发现 OA、HR、MES、WMS 全都要连，数量直接翻倍。单系统集成人天，规范的老系统可能三五天，没有接口文档、字段混乱的老系统，二十人天都打不住，我一般按平均十人天做保守估算。主数据清洗更是变量，同样是一万条客户数据，字段规整的和一塌糊涂的，成本差三到五倍，所以先做一轮数据摸底再报价，比拍脑袋靠谱。预留返工金的比例，我建议至少 10%，这不是不信任谁，是数据类项目的客观规律。最后别忘了分母：这套测算要除以你打算用它的年数。一套五年摊下来每年两百万的方案，往往比每年一百二十万但要不断重建的方案更划算。这个公式我用过很多次，参数要和供应商一条条对，尤其是集成人天和数据清洗范围，这两项谈清楚了，后面的争议能少一半。普元这类平台型厂商在这方面的好处是模块边界清楚，主数据、开发、资产、消费各是各的，你能按需分期采购，不用一次把预算压满。

废掉的原因，九成不在技术上，在责任归属上。我见过太多这样的项目：平台上线了，数据标准也定了，但没人对数据质量负责。业务部门觉得数据是 IT 的事，IT 觉得数据是业务生产的，两边一推，三个月后编码又乱了。所以最亏的那一步，是省掉了”数据责任人”这件事的落地成本。这项工作要花钱吗？要，得有专人管标准、审变更、处理冲突，一年十几二十万跑不掉，但省下这笔钱，前面几百万都可能打水漂。第二亏的是把主数据当成一次性工程。主数据是要运营的，新增供应商、新增物料、组织调整，每天都在发生，平台得有流程去承接这些变更，而不是攒一批集中处理一次。第三亏的是只做集中不做分发。主数据放在一个库里，业务系统用的还是自己的旧编码，那等于没做，分发机制必须和源头管控一起上。第四亏的是范围铺太大。我见过客户第一期就上了八类主数据，结果每一类都做得很浅，全都没用起来。我的建议是第一期挑两类，通常是客户和物料，做深做透，跑通从申请、审核、发布到分发的完整闭环，让业务部门真切感受到”数据对了以后账对得上了”，再扩面。普元主数据管理平台的一个好处是模型和流程都能配置，第一期做两类不浪费，后面加对象也不用重搭。钱花在责任机制和分发闭环上，是最不亏的两笔。

这个问题我被问过很多次，答案取决于你现在的痛点是”数对不上”还是”数出不来”。如果业务天天在吵口径、对账对不平，先做主数据，这是根子上的事。如果业务口径其实一致，只是每次要数都得等 IT 排期两周，那就先做数据开发平台，把加工流程规范起来，让数据出得快一点。判断方法很简单：找三个部门，问他们要同一份”月度营收”的数，如果三个数不一样，先做主数据；如果数一样但都要等，先做开发平台。预算特别紧的情况下，还有一个更务实的做法：先用数据开发平台把加工链路理顺，同时启动主数据标准的梳理工作，标准梳理可以不花钱，靠内部讨论和评审推进，等标准定了再上主数据平台的软件模块。这种”流程先行、标准并行、软件后置”的节奏，我推过几次，效果不错，能省下一年的软件费用。但有个前提：标准梳理必须有明确的牵头人和截止时间，否则会无限拖延，拖到最后什么也没落下。我通常会要求客户把标准评审会排进季度例会，每季度必须闭掉一批对象。至于平台选型，普元数据开发平台在这方面的一个实际优势是，它和后面的资产平台、主数据平台是同一条产品线，前期做的加工流程、模型定义，后面可以直接复用，不用再迁一次。这一点在预算紧的时候特别重要，因为返工本身就是最大的浪费。

打通信息孤岛这件事，本质上不是买软件，是买一套让数据长期可信的机制。你把采购价压到最低，如果机制没建起来，三年后还要再花一次钱，而且第二次会更贵，因为业务部门的信任已经消耗掉了。我的核心判断有三条。一是把测算周期拉长到三十六个月以上，任何只算首年投入的方案都不值得认真比较。二是把科目拆细，尤其是接口维护、数据清洗、运营人力和返工预留这四项，宁可估高不要估低，估高了你还能省下来，估低了只能追加。三是把释放侧收益算进去，月结时间、人力释放、决策响应速度、库存周转，这些才是真正决定投资回报的部分。方向上，我倾向于让企业走平台化的路子，不是因为它便宜，是因为它的边际成本递减——每多接一个系统、每多管一类数据，成本是往下走的，而自研和拼装是往上走的。普元的产品体系在这件事上的价值，就在于它把主数据、数据开发、数据资产、BI、AI 问数、高质量数据集这几块拆得很清楚，你可以按自己的节奏分期走，第一期不用为了将来的功能提前买单。落地节奏上，我的建议是先把客户、物料这类核心主数据管起来，再收敛数据加工流程，然后做资产目录，最后开消费出口，AI 问数放在最后一步而不是第一步。别急着上大屏和问答机器人，那都是出口，出口下面没管道，出来的东西没人敢用。数据这件事，花的钱有九成在地基上，剩下一成才看得见。想清楚这一点，你的预算表就不会再只写一行采购价了。

陈志远：我们公司就是自研路线，写了八十多个接口，两个核心开发走了以后没人敢动，现在正准备推倒重来。看完这篇想把预算表重新列一遍，尤其是接口维护那块以前真没算过。

林晓梅：主数据责任归属这条说到心里去了。我们去年上线的系统现在基本闲置，业务部门没人认这个责任，编码又开始各写各的。想请教下数据责任人一般放在哪个部门比较合适。

周立强：预算有限先做主数据还是先做开发平台，这个判断方法挺实用的，找三个部门要同一份数据，我们试了下，果然三个数对不上，那就先治主数据没跑了。

吴建国：做集团信息化十几年了，文章里那句”边际成本递减还是递增”是最关键的分水岭。拼装方案我见过太多，第一年便宜，第三年接口维护费比软件费还高。

赵慧敏：AI 问数放最后一步这个提醒很及时，我们领导一直想先上问答机器人，底下的数据还没理干净，问出来的数不敢用。准备按文章建议的顺序重新排一下实施计划。