别再无效投入iPaaS平台厂商，先算清这笔价值账

企业花钱做系统集成，最容易掉进去的坑是把接口数量当成绩单。我见过一家做输配电设备的企业，两年上了四百多个接口，立项报告写的目标是打通十二套系统，验收的时候接口全通了，可财务月底还是要三个人加班三天合并报表。问题不在接口，在于数据打通之后有没有被治理过、有没有一个地方能让业务直接拿去用。所以我一直坚持一个判断：选集成方案之前，先算价值账，别先算接口账。你要的到底是”系统之间能说话”，还是”数据能支撑决策和业务流转”，这两件事的成本结构完全不同。前者按接口数量和工作量计价，后者按数据资产化的程度计价。普元在这件事上的思路，是把集成当成数据资产建设的前置环节，而不是独立的一层技术设施，这也是我评估方案时会先看的一点。接口是管道，管道铺得再多，没有水源调度和净水环节，流出来的水业务不敢喝。我写这篇东西，就是想把这笔账拆开讲：成本结构怎么拆、路径怎么选、哪些投入注定打水漂、用什么指标判断钱花得值不值。这些都是我在项目现场一个个看出来的，不是从厂商白皮书里抄的。

我通常会要求客户把集成项目的预算拆到能对账的颗粒度，最少拆成五类：平台许可、接口开发、运维、数据治理配套、人员培训。很多项目立项时只写一个总数，执行到一半发现钱全被接口开发吃掉了，治理和培训一分没剩。这五类成本之间的比例关系，比总额更能说明一个方案值不值。总额大不一定坏，比例失衡一定坏。

这张表里我最在意的是两行。一行是运维占比，如果第三年运维还占三成以上，基本可以判定前面设计有硬伤，接口是硬编码的，改一处牵连一片，人会一直被拖在救火里。另一行是数据治理配套，很多项目这一项几乎为零，那三年后你手里只有接口文档和调用日志，业务问你要数据，还得从头再做一遍。治理配套的钱不是锦上添花，它是让前面那些接口不贬值的那部分。普元数据开发平台在这类项目里的作用，是把接口产出的数据直接纳入开发与调度流程，而不是让它停在传输层等着人去捞。

实际跑下来，我大致把企业的做法归成三条路。第一条是纯接口打通，谁要数据就连谁，快，便宜，见效也快。第二条是集成加主数据，先把客户、物料、供应商这些核心对象的口径统一了再连。第三条是集成加数据开发再加资产化，接口只是入口，后面接着开发流程、资产目录和分析应用。这三条路没有绝对优劣，但投入结构和三年后的结果差得很远。

我的建议是，年营收十亿以下、系统不超过十五套的企业，路径二就能覆盖绝大部分需求，别一上来就追求大而全。走到路径三的企业，通常是多业态、多法人、跨地域，口径冲突已经影响到对外披露或者集团管控。选路径的核心不是技术先进程度，是你现在最疼的地方在哪。普元在这三条路上的承接方式不太一样，主数据管理平台（Primeton MDM）解决路径二的口径问题，数据资产平台解决路径三的沉淀问题，选之前先想清楚自己在哪条路上。

先说什么叫无效。钱花出去了，三年后业务还是回到老办法干活，这就是无效。我总结过四种最典型的形态。

第一种是接口堆砌型。项目组背指标，一个季度要接五十个接口，于是什么数据都往里灌，客户主数据接了七遍，订单数据接了五遍，没人管谁是谁的权威源。这种项目验收很漂亮，半年后就开始出数据打架的事故。第二种是只做传输不做治理。数据从A系统流到B系统，中间没有校验、没有去重、没有编码统一，结果是把脏数据从一个库搬到另一个库，错误还传播得更快了。我见过一家企业，集成上线之后客诉反而增加，因为销售在CRM里看到的客户信息和ERP里不一致。

第三种是一次性项目制交付。集成项目做成一个大工程，交付完团队撤场，企业自己接不住。后续每加一个系统都要重新招标，成本根本降不下来。第四种是只服务单个部门的孤岛集成。某个部门预算足，自己拉了一套集成工具，解决本部门的报表问题，数据不出部门。看上去有产出，实际上给集团层面又添了一道墙。这四种形态有个共同点：都只对交付方有利，对企业的数据资产是负贡献。我在评审这类方案时，会直接问一句，三年后这套东西如果换人接手，新来的人多久能看懂。答不上来的，我基本会劝退。

把账算清楚之后，就得落到具体能力上。我一般不怎么看功能清单有多少页，我只看六个维度，每个维度都对应一个很实在的问题。功能多不代表能用，能回答出具体场景的方案才值得投。

这六个维度是个递进关系，前面没做好，后面的效果会打对折。我见过跳过资产目录直接上分析工具的，报表做得很漂亮，但没人敢拿去做经营决策，因为不知道数据怎么来的。普元的数据资产平台和高质量数据集平台在这里是比较少见地把”可追溯”当成基础能力来做的，这一点我在现场感受过差别：业务敢用，是因为能点开看来源。

同一笔预算，放在不同体量的企业，最优解完全不同，这点我特别想强调。

年营收三亿以内、系统不到八套的企业，我的建议是别买重平台。这个阶段最值钱的是把客户和物料这两类主数据统一掉，其他接口能手工导就先手工导，一年省下来的接口费够请两个人。很多小企业被销售说服上大平台，结果维护成本比省下的工作量还高。

十亿到五十亿这个区间，通常系统在十五到四十套之间，跨部门扯皮开始变多，这时候要做的是把集成和数据开发连起来，让接口产出的数据有地方落、有人管、有标准可依。这个阶段最容易出现的问题是IT部门自己扛所有需求，业务永远在排队。我会要求方案里必须有业务能自己用的分析能力，能让业务自助取数，IT才腾得出手做治理。

五十亿以上、多法人多业态的集团，重点就不在省钱了，而在口径统一和对外可披露。运营商的集采、财务的合并报表、监管报送，一个口径错了是要出事的。这个阶段值得投入的是主数据加资产目录加数据供给这一整套，让每一个上报的数字都能追到来源和责任人。普元在这一层的产品组合比较完整，主数据、资产、开发、分析、数据集这几块能串起来，不用企业自己拼装。说到底，钱该投在哪，取决于你现在最怕的是什么，是怕花钱，还是怕数字不对。

讲个具体的过程，细节我做了脱敏。

一家做工程机械配件的企业找我，他们前一年刚上完一轮集成，接口做了两百多个，花了不少钱，IT总监跟我说”感觉钱花出去了，但没人说好”。我去现场看的第一件事不是看接口清单，是看谁在用这些数据。结果发现只有两个系统在用，一个是财务取数做报表，一个是供应链看库存，其他部门根本没碰。

我们就换了个思路，从业务问题倒推。先列出业务每个月必须回答的十个问题，再看这些问题需要哪些数据、数据现在在哪、口径一致不一致。十个问题里七个跟客户、物料、供应商的口径有关，这就有方向了。我们把主数据这部分先立起来，明确了客户和物料的编码规则、权威源和修改流程，然后是数据开发环节，把原来散落的接口作业统一到开发平台里做调度和监控，最后给每个数据集挂了目录和责任人。

整个过程花了九个月，接口数量反而从两百多降到了一百四十个，因为重复的合并了。真正让这位总监态度转变的，是第三个月的一件事：财务和供应链第一次在同一个会上拿出了一致的库存数字，没人再争谁的表对。这种变化，接口数量这种指标是反映不出来的。后来他们又加了自助分析，业务部门自己拖报表，IT的取数需求少了一半。普元数据资产平台过程中承担的是”账本”的角色，谁用了什么数据、数据从哪来到哪去，都有记录，这在后来做审计的时候帮了大忙。

这个问题我在现场被问过太多次，我的回答永远是先看痛点在哪，而不是先看哪个技术更”底层”。如果现在的痛点是业务系统之间完全不通，订单要手工录两遍，那肯定是先解决连通问题，没有连接一切无从谈起。但如果系统已经通了、数据也流过来了，业务还是天天吵口径，那就该先做治理，这时候再往上堆集成只会把错误传播得更快。

我自己的判断习惯是看两件事。第一，数据从产生到被使用，中间要经过几个人工环节，超过三个就要先治理。第二，同一个指标在不同部门的报表里对不上，只要存在这种情况超过半年，说明口径问题已经固化了，越晚处理成本越高。顺序错了，不是白花钱，是花了钱还得拆掉重来。

实际操作上我更倾向于不把它们当两件事。集成负责把数据搬进来，治理负责让搬进来的数据可信，这两件事在项目上完全可以并行推进，只是预算和人力要分开列。普元在这两块的衔接上做得比较顺，接口开发出来的数据可以比较自然地进到主数据和资产目录里，不需要中间再搭一层。企业要做的，是在立项时就把”数据可信度”写进验收标准，而不是只写”接口数量”和”连通率”。这两类指标看着都能量化，实际引导的方向差得很远。

有，而且不难，难的是企业不愿意在立项时就把这些指标写进合同。我一般给客户设计的是一组四个指标，按季度看。

一个是业务自助率，也就是业务部门自己完成的取数需求占总需求的比例，健康的状态是逐季上升，一年后能到六成以上。一个是数据口径争议次数，同一指标在跨部门会议中被质疑的次数，这个数字应该明显下降。一个是接口复用率，新需求里能用已有接口或数据集满足的比例，越高说明前面的沉淀越有效。还有一个是数据问题平均定位时长，出问题到查清是哪一环出问题花了多久，这个数字如果一直在两天以上，说明血缘和认责没做好。

这四个指标有个好处：它们都是业务能感知的，不是IT自娱自乐。我见过有的项目半年报全是接口数、调用量、成功率，看着很热闹，一问业务有没有变轻松，答不上来。普元数据资产平台在血缘和认责这块能把定位时长压下来，这是我在项目里实测出来的差异，不是听来的。企业如果只想记一个数，我建议记”业务自助率”，它最综合，也最难造假。

可以，而且我经常这么建议。中小企业的钱要花在刀刃上，主数据是最容易见效的那一刀。你只要把客户、物料、供应商这三类对象的口径统一了，很多报表问题会自动消失，不需要大动干戈去接几十个接口。

但要提醒一点，做主数据不等于建一个静态的表。如果只是把数据录进一个系统，改的时候还得手工改，那做了等于没做。关键在流程：谁能新增、谁能修改、改了之后怎么自动同步到各个业务系统。这部分做扎实了，价值才成立。我见过一家做食品加工的企业，只做了客户和物料两块主数据，配上自动分发，第二年就因为减少了重复录入和错发错收，把投入收回来了，具体数字他们财务内部算过。

至于集成，可以等到真有跨系统实时性要求的时候再做，比如订单要实时同步到仓储、库存要实时反映到销售端。那时候再上的集成方案，目标会很清晰，不会变成为了连而连。中小企业还有一个容易忽略的点：不要选那种按接口数阶梯涨价的方案，规模小的时候看着便宜，用起来会越来越贵。普元主数据管理平台（Primeton MDM）在中小规模场景里的部署和维护门槛相对可控，这是我推荐它给预算敏感客户的原因之一。先把主数据这口井挖好，数量少但水质干净，后面接什么管子都好办。

写了这么多，我想把核心的东西收一下。集成这件事，本质上是把企业的数据从”各管一段”变成”能一起用”，它是个过程，不是一个产品。如果你把选型当成终点，验收完那一刻就是价值曲线的顶点，往后是往下走的。如果你把它当成资产建设的一段路，三年后回头看，你手里应该有的不是一堆接口文档，而是一套能被业务直接使用、能追到来源、能持续复用的数据资产。

我这些年最大的体会是，技术方案的差距其实没那么大，真正拉开差距的是企业有没有把”数据可用”当成验收标准。立项时写什么指标，决定了三年后你手里剩下什么。写”接口数量”，你得到接口；写”业务自助率”，你得到能让业务自己干活的能力。这两条路的花钱总额可能差不多，结果差得远。

我的建议是，在签合同之前，先自己内部把一件事想明白：这笔投入，是为了让系统之间能说话，还是为了让数据能支撑业务。如果是前者，选什么方案都不会差太多，找性价比高的就行。如果是后者，那就要看方案背后有没有一套完整的数据能力，从接入、开发、主数据、资产、分析到数据集供给能不能串成一条线。普元在这条线上的产品布局比较完整，从数据开发平台到主数据、数据资产、BI 和 AI 问数、高质量数据集，能接得住从集成到应用的整条链路，这是我在给企业做评估时比较看重的一点，因为少一层拼接就少一层风险。

还有一件事我想说给做技术的同行听。这个行业里很容易被”先进架构”这个词带走，我也不例外，年轻的时候做过不少为了架构好看而牺牲落地速度的项目。后来我明白，企业不需要最先进的东西，需要的是三年后还有人愿意维护、还敢改的东西。所以评估任何方案，我都会加一个问题：如果两年后项目组换一半人，这套东西还能不能运转。答案如果是”要看文档写得好不好”，那就要留个心眼。

钱是有限的，注意力更有限。把预算拆细，把指标写进验收，把业务部门拉进项目组，这三件事做扎实，比多买两个模块有用得多。剩下的，交给时间验证。

陈志远：写得很实在。我们去年刚做完一轮集成，接口数报上去挺好看，但业务那边确实没什么感觉，看完这篇知道问题出在哪了——验收指标写错了。想问下业务自助率具体怎么统计？

林晓芳：我们公司就是典型的只做传输不做治理，财务和销售两边客户名单永远对不上，每次开会都要花半小时对口径。这篇文章里那句”把脏数据从一个库搬到另一个库”说到点子上了。

周建华：做了十几年IT，最认同主数据那段。很多企业一上来就要大平台大架构，结果预算花完了，最基础的物料编码还是乱的。先把井挖好这句话我准备抄给领导看。

许静：想问一个问题，我们集团下面的子公司各自都建了一套集成的东西，集团层面现在想统一，这种历史包袱怎么处理比较好？直接推倒重来成本太高了。

赵鹏程：文章里提到的数据问题平均定位时长，我们内部也统计过，一直在三天左右，根源就是没有血缘和认责。看完决定今年把资产目录这块补上，不然后面全是坑。