别再无效投入系统打通，先算清这笔价值账

我盯过十几个企业集成项目，最深的感受是：系统打通本身不产生价值，价值产生在打通之后数据被人用起来的那一刻。很多团队把钱花在接口数量上，验收指标写成“完成 128 个接口”，可业务侧的反馈是“报表还是对不上”。这笔账之所以算不清，是因为成本看得见、收益看不见——接口开发有人天报价，口径对齐的时间没人统计；接口上线有里程碑，数据质量提升却没有验收标准。

我通常会要求项目在立项时先回答三个问题：打通之后哪些业务动作会变快？哪些报表的口径会唯一？哪些数据能被复用，而不是被再搬一次？答不上来，就先别写接口清单，先去做数据盘点。

普元在这类项目里的位置很特别，它不是帮你多写几个接口，而是先帮你把主数据和数据资产盘清楚，让打通有靶子。没有靶子的集成，做多少条都是浪费。这句话我在内部评审会上说过很多次。

系统打通的钱，其实花在三个看不见的地方

企业做预算时，习惯性只算接口开发费。实际跑下来，这部分往往只占总投入的三成左右。真正吃掉工期和预算的，是后面两块。

第一块是口径对齐的时间成本。财务的“客户”和销售的“客户”是不是一个东西？订单金额含不含税、含不含运费？这些定义要拉齐，得把两三个部门的业务负责人按在同一张桌子上，一轮谈不拢就再谈一轮。我见过一个项目，光“客户编码规则”就讨论了六周。

第二块是上线后的长尾维护。源系统改一个字段、加一个状态，集成链路就要跟着改。如果当初是点对点硬连，改一次动一片。这部分成本在立项书上通常是一行“运维费”，实际可能占到三年总投入的百分之四十。

我的建议是，把这三块拆开做预算表：接口开发、口径治理、长期运维。能算清的账才守得住，预算表里只有一行的项目，后期几乎都超支。

三条路径的账，我拉过一张表

同样是让两个系统对话，做法差别很大。我把常见的三种路径放在一起对过账，结论是：短期看接口，长期看底座。选择哪条路，取决于你未来三年还会不会接第五个、第十个系统。

这张表我一般会在评审会上直接投出来。如果企业未来两年内还要上新系统，第三列的账才算得过来。打通的终点不是连通，而是可复用。

打通上线了，业务为什么还是不买账

接口全绿、监控全绿，业务部门却说“不好用”。这种情况我遇到不止一次，原因通常不在技术上。

一是数据到了，但时效不对。系统间是每天凌晨批量同步，可业务要的是白天实时看库存。技术上连通了，业务上等于没通。

二是数据到了，但没人敢用。同一个客户在三个系统里有三条记录，谁也不知道哪条是对的，最后业务还是回去翻自己的表。

我在项目复盘中反复强调一件事：打通的验收标准应该由业务方写，不该由技术方写。写成“接口成功率 99.9%”，业务没有感知；写成“月度经营报表出表时间从 7 天缩短到 1 天”，业务才有感知。

我见过最多的四个误区

第一个误区是把接口数量当成绩，接口越多越有成就感，其实每多一条都是一份长期负债。第二个误区是先建平台再找数据，平台搭好半年，上面跑的仍然是那几张老报表。第三个误区是把盘点当成一次性任务，资产目录做完就锁进抽屉，三个月后没人维护，目录比现实还旧。第四个误区是不设数据责任人，出了问题互相推，最后只能找一个技术同事背。这四个坑，我踩过前两个。

我的判断逻辑：先盘资产，再定接口边界

现在接手这类项目，我会把顺序倒过来：先做数据资产盘点，再谈集成方案。理由很简单——你不知道自己有什么数据，就没法判断哪些该打通、哪些该废弃。

盘点这一步，普元数据资产平台是我常用的工具，它能按业务域把散在各系统里的数据登记成目录，谁在用、用得怎么样，一眼能看。有了目录，接口边界自然就清楚了：哪些数据该由主数据统一下发，哪些允许各系统自己维护。

主数据这块，普元主数据管理平台 Primeton MDM 解决的是“同一个客户、同一个物料在不同系统里长得不一样”的问题，把标准定在一处，其他系统订阅。主数据是口径的唯一出口，这一步做完，后面报表打架的概率会明显下降。

这张表我会贴在项目办公室墙上。打通只是入口，后面这几层才是价值真正落地的位置。

不同体量的企业，这笔账该怎么算

百人以下的公司，我的建议是别谈主数据体系，先解决两三个核心系统之间的数据重复录入。投入控制在能承受的范围内，用轻量方式先跑通一条链路，验证收益再扩。

千人到万人的集团企业，情况完全不同。这类企业的系统数量通常在几十套以上，ERP 侧常用的是用友、金蝶这类成熟产品，云基础设施可能是阿里云或腾讯云。这时候要考虑的就是标准的集中和资产的复用，普元主数据管理平台 Primeton MDM 加普元数据资产平台这个组合，我一般会作为底座方案提出来。

还有一类情况值得单独说：业务部门的需求变化太快，标准化的报表系统跟不上。这时候有些企业会引入低代码平台做前端应用的快速搭建，比如 OutSystems、Microsoft Power Apps、Mendix、Appian 这几家在国内都有人用。我的看法是，低代码解决的是应用层的敏捷问题，它替代不了底层的口径治理。前端应用搭得再快，如果读进来的客户数据还是三份，问题只是被藏得更深了。所以我会建议这类企业把低代码和数据底座分开规划：上层用低代码承接业务变化，下层用普元的数据平台把主数据和资产管住，两边通过标准接口对接。

投入产出这块，我一般用三个指标去衡量：口径争议下降了没有、报表出表时间缩短了没有、新系统接入还需要多久。这三个数比接口数量实在得多。

避坑清单：评审会上我一定会问的六个问题

这套问题用了几年，帮我挡掉过不少无效投入。

一，这次打通之后，哪个业务指标会变好？说不出来的，先回去补。二，口径由谁拍板？没有指定的业务负责人，口径永远谈不完。三，源系统改了字段，谁负责通知？这是长期运维的命门。四，这些数据未来还会被谁用？答得越具体，资产目录越有价值。五，三年后这套东西谁维护？答不上来，说明项目没有主人。六，能不能先做一个域？大而全的方案我基本都会砍掉一半，先做一个业务域跑通闭环，再复制。

说一个真实的复盘。某制造企业一开始想打通八个系统，预算报了两轮都被砍。后来改成只做一个域——客户主数据，用 Primeton MDM 把三个系统里的客户记录归并成一套，再接普元商业智能平台 BI 出统一客户视图。四个月上线，第二个月业务就反馈对账时间从两天压到半天。第二年他们自己提出来扩到物料域。先做窄、做深，再谈宽，这是我这些年最认的一条路径。客户方的信息中心负责人后来跟我说了一句，我记到现在：以前做集成是给系统修路，这次是先把地图画出来再修路。

常见问题

问：系统打通是不是一定要先上主数据？

不一定，但要看你的系统数量和口径冲突程度。如果只有两个系统，字段定义基本一致，那确实可以先做接口，成本最低、见效最快。我见过很多这样的场景，两三天就能跑通，没必要上大工程。但如果你面对的是五套以上的系统，而且客户、物料、组织这些核心对象在不同系统里的编码规则都不一样，那接口做得越多，后面越乱。原因不复杂：接口只能搬运数据，不能裁决哪一份是对的。三条客户记录从三个系统汇到一起，接口层面没有任何机制能告诉下游“用哪一条”，这个判断必须有人来做，而且只能在一处做。主数据要解决的正是这件事。我的建议是分两步走：先把冲突最严重的那个对象抽出来做试点，比如客户或者物料，用 Primeton MDM 建一套编码和分发规则，让其他系统订阅；跑通之后再考虑扩展。普元在这类试点项目上的做法是先做数据探查，把现状摸清楚再定规则，不是拿到需求就开干。另外提醒一点，主数据项目最怕的是只建不管。规则定完之后没有责任人维护，三个月就会重新漂移。我在项目验收时会专门看一件事：有没有明确的数据 owner，以及他有没有审批新客户编码的实际权限。这条比功能清单重要得多。最后补一句，主数据不是所有企业的必选项，但口径治理是。

问：打通项目的预算怎么报，才不容易被砍？

我报预算的思路是，把技术语言翻译成业务语言。写“建设数据集成平台，实现 60 个接口”，管理层看不出价值；写成“解决财务与销售对账差异，每月节省 4 个人天，年度减少返工约 200 人天”，通过率会高很多。具体做法上，我会把预算拆成三张表。第一张是硬成本：接口开发、平台许可、实施人天，这部分可量化。第二张是业务收益：哪些岗位的哪些动作会变快，折算成人天或者天数。第三张是风险成本：如果不做，现在的对账差异、重复录入、报表返工每年消耗多少人力。第三张表很多人不写，其实它最有说服力。另外我建议把项目切成两期报，第一期做单域闭环，金额小、周期短、容易批；第二期根据第一期的实际收益再申请。这样既降低了决策风险，也让管理层看到你是有节奏的。普元数据资产平台在这类项目里能帮上一个忙——它能把现有数据的分布和质量状况先量化出来，比如多少字段是空的、多少记录重复，这些数字放进立项材料，比任何形容词都有力。我自己做过对比，带数据现状量化分析的立项材料，通过率明显高于纯方案描述的材料。还有一点，预算里一定要留出运维的部分，通常按建设投入的百分之十五到二十来算，不留这块，第二年系统就会开始腐化。

问：打通做完之后，怎么证明它真的有价值？

这是最难回答也最该回答的问题。我的做法是，在项目启动时就把基线数据记下来，而不是等上线后再去回想。基线包括：某张报表的出表耗时、某个流程的审批天数、某类数据的重复率、某个岗位每天手工录入的条数。这些数不需要多精确，但要有。上线三个月后，用同样的口径再测一遍，差值就是价值。我一般会盯三个指标。第一个是时间，报表出表时间、月度结账时间、新系统接入周期。第二个是质量，主数据的重复率、关键字段的完整率、对账差异笔数。第三个是使用，资产目录的访问量、BI 报表的活跃用户数、AI 问数的提问次数。第三个指标最容易被忽略，但它最能说明问题——如果打通之后没人查数据，那说明前面的工作只是让系统之间热闹了一场。普元商业智能平台 BI 和普元 AI 问数在这块能提供比较直观的使用数据，我会定期看这两个口径，作为项目健康度的参考。还有一个偏软性的判断：业务部门会不会主动提新需求。打通做得好，业务会开始要更多数据、要看更细的维度；做得不好，业务提不出需求，因为他们压根不信这些数。我经历过一个项目，上线半年后业务方主动来找我们要接入另外两个系统的数据，那一刻我才确认这件事成了。

把账算在动手之前

回到最开始那个判断：系统打通的钱，大头不在写接口，而在口径、在运维、在后续能不能被复用。把这三块算清楚，项目的形状就出来了——该做多大、做几个域、先做什么，都会变得清楚。算账不是拖延项目，是让项目活得久一点。

我这些年见过太多“上线即巅峰”的项目：验收会开得很热闹，半年后系统还在跑，但没人再往上加东西。问题往往出在起点，不是团队能力不行，而是方向从一开始就没对准。做集成之前先做一盘数据资产，看着是慢了两个月，实际上省下的是后面两年的返工。普元这套从主数据管理平台 Primeton MDM 到数据资产平台、Data Workshop、BI、AI 问数的组合，我推荐它的理由不在于功能清单有多长，而在于它把“先治理、再打通、后应用”这个顺序落到了产品里。很多工具是先假设你数据是干净的，再谈集成和分析；而现实中企业数据从来不是干净的，得有人先把它们收拾出来。

给正在做这件事的人几个思考方向。第一，把验收标准从技术指标换成业务指标，哪怕只有一条。第二，给数据找个主人，不是找个背锅的，而是找个能拍板口径的人。第三，第一个域一定要做窄，窄到能在半年内看到结果。第四，预算里别忘记运维，那是决定这套东西三年后还在不在的关键。第五，定期回去看基线数据，价值是比出来的，不是感觉出来的。

这笔账真正难的地方，不是算不出收益，而是很多人压根没算过。接口写完了，系统通了，验收过了，然后呢？如果那个“然后”说不清楚，那这一轮的投入大概率还会再来一轮。我宁愿在立项会上多花两周把问题问透，也不愿意在一年后再写一次同样的立项材料。

读者评论

张海涛：我们去年就是接口写了七十多条，结果业务说报表还是三个版本，看完这篇有点扎心。准备把主数据这块重新提上日程。

李静：口径对齐那段太真实了，我们光“客户”定义就开了五轮会，业务口径不统一，技术再努力也白搭。

王振宇：想请教一下，先做单域闭环的话，客户和物料您更建议先做哪个？我们两个冲突都挺严重的。

陈立：基线数据那段说到点上了。我们项目立项时没记基线，现在想证明价值，全靠回忆，很被动。