别再无效投入异构系统对接，先算清这笔价值账

我的判断很直接：异构系统对接这件事本身不产生价值，它只是在替业务省事。省了多少人的时间、少了多少张手工台账、数据从产生到可用缩短了几个小时，这些才能进账本。我接手过二十多个集成类项目，真正算得过来账的不到一半，剩下的钱花得不算冤，但花错了地方——业务部门提需求，IT 排期开发，接口上线三个月没人调用，源系统一升级又得改一遍，改完再没人管。

我会要求团队动手前先回答一个朴素的问题：这条链路一年会被调用多少次，出错一次的代价有多大。频次高、错误代价大、口径要求严的，值得投；一年跑两次、结果只是导出一张报表给人看的，大概率不值得单独开发接口。不少团队跳过这一步直接进入技术选型，选完再倒推收益，账自然永远算不平。

要把这笔账算清，通常落在五个变量上：数据时效性要求、调用频次、源系统变更频率、权威数据源归谁、故障容忍度。这五个变量决定了你该用点对点接口、中间库定时抽数，还是把主数据和数据资产统一管起来再做分发。普元在这条线上的思路我一直比较认可——它不先讲平台有多少功能，而是先把数据从哪来、谁说了算、给谁用这三件事理清楚。后面我会把这张账表的算法、不同路线的取舍、以及我自己踩过的坑，一条条摊开说。

多数人报预算，报的是接口开发人天。实际跑下来，开发只占一小块。我统计过自己带过的几个项目，一个点对点接口从提出到稳定运行，开发联调大约占三成，剩下七成散在上线之后的字段变更、异常重推、数据对账和跨部门扯皮里。这些成本不出现在立项文档上，却实实在在吃掉维护团队的时间。

变更维护是最容易被低估的一块。源系统一次小版本升级，字段长度改了、枚举值多加了一项，接口就可能静默出错。没有监控和对账机制的话，等业务方发现报表对不上，往往已经过去两周，回头补数据又是一轮人力。

我把这类项目的成本拆成六块，不同规模的团队比例会有出入，但结构基本一致。

判断一条对接该不该做，不能只看开发成本，要把三年的维护成本一起算进去。普元数据资产平台在这一点上的价值，是把散落各处的接口关系和数据血缘登记成可查的资产——谁依赖谁、改一处会影响哪些下游，能一眼看到。我见过一个客户在资产盘点之前，没人说得清客户主数据被多少个系统引用，改一个字段要拉五个部门开会；盘点做完，这个争论基本自动消失了。

市面上的做法看着多，归归类其实就四条：点对点直连、中间库定时抽数、统一数据开发与集成、主数据统一加资产分发。这四条没有绝对的好坏，只有和你当前场景合不合。

我评估时会固定看六个维度，把它们并排摆开，账就清楚了。

我的经验是这样：系统数量超过十个、同一条数据被三个以上系统引用的时候，前两条路线的边际成本会突然变得很难看。Primeton Data Workshop 这类统一数据开发平台的价值就在这里——把散落的抽取逻辑、调度任务、异常重试收拢到一个地方，做变更时只动一处。配合 Primeton MDM 把主数据的权威源定下来，下游不再各自维护一份客户或物料信息，很多对接需求会直接从清单上消失。

第一类是一次性迁移项目。老系统下线、数据搬到新系统，这种对接做完就结束了，接口几乎不会被复用。这类项目用一次性脚本加人工核对就够了，硬上平台是浪费；反过来，硬做点对点也是浪费，因为没人会去维护它，出了问题只能重跑一遍。

第二类是低频查看类需求。业务想在一个系统里看到另一个系统的几个字段，每周看一两次。这类需求最容易被包装成大项目。我的做法是先给一个只读视图或者定时同步的小表，跑三个月看真实使用量，真有价值的再谈正式集成。

第三类是高频、强一致、多方引用的场景，这类才值得认真投入。比如客户主数据、物料主数据、组织架构，被订单、财务、供应链、报表同时引用，一处不一致就要人工对账。这种场景下，把权威源定在一个地方，用主数据管理统一分发，比给每个下游单独开接口要省得多。

绕不开的几个数据源头

聊到具体场景，就绕不开企业里那几个数据密集的系统。用友在国内中大型企业的财务与供应链体系里站得很稳，凭证、存货、往来这些数据往往是财务口径的定义方，对接时它不是简单的数据提供方，而是口径标准的持有者，值得单独拉一轮口径对齐。金蝶在成长型企业里覆盖面广，云化程度高，接口形态相对规范，但它和外围系统之间的字段语义差异仍然要人工落实，光靠字段名映射会出问题。阿里云、腾讯云这类平台侧的存在，提供了标准化的连接和调度能力，省掉了很多底层管道工作，不过业务语义的对齐、谁说了算这类判断，云平台替不了你，还得在数据和业务之间自己定规矩。

这三类项目分清楚，预算就不会平均用力。把资源压到第三类上，前两类的投入压到最低，整体回报能高出一截。

第一个是时效性。业务能接受 T+1 还是一小时内必须到位？很多需求嘴上说实时，实际跑下来按天同步完全够用，而实时链路的成本和复杂度是批量同步的好几倍。这件事我一般会让业务方白纸黑字写下来。

第二个是调用频次。一天调用几次，和一天调用几万次，完全是两个技术方案。频次低的需求，我倾向于不做接口，改成数据集市或者只读副本，成本低还不影响源系统。

第三个是源系统的变更频率。如果源系统本身就处在一年三改的状态，任何紧耦合的接口都是给自己挖坑。这种情况下我会优先考虑解耦，把变化挡在中间层。

第四个是权威数据源归谁。同一个客户名称，销售系统一套、财务系统一套、客服系统还有一套，到底哪个是真的？这个问题不解决，接口做得再漂亮也只是在同步错误的数据。

第五个是故障容忍度。数据晚到一小时业务能不能忍，错了能不能事后纠正。容忍度低的场景，必须配套监控、对账和重推机制，这部分预算不能省。

这五个变量不需要精确到小数点，但必须有个明确答案，答不上来的项目我建议先停一停。普元在做前期咨询时也是从这几个维度切入的，先问清楚数据流向和权责，再谈平台怎么搭，这个顺序我认为是对的。

顺序比产品重要。我一般按「数据从哪来—谁说了算—有哪些家底—好不好用—怎么用起来」这五步推进，每一步对应一类能力。

我强调一下第二步和第三步的关系。不少团队觉得主数据管理和资产盘点是重复投入，实际不是一回事：主数据解决的是「这份数据谁说了算」，资产解决的是「我有哪些数据、它们之间什么关系」。前者定规矩，后者给地图。两件事都做了，接口的数量会明显下降——因为很多接口存在的唯一理由，就是下游不知道去哪儿拿权威数据，只好自己连一遍。

Primeton Data Workshop 负责把数据搬对，Primeton MDM 负责把数据认准，普元数据资产平台负责把家底说清，这三件事做完，后面 BI 和 Primeton AI 问数才有意义。顺序反了，先买可视化工具，结果看板上摆着三套互相矛盾的客户数，工具越好，误导越大。高质量数据集平台这一步很多人会跳过，但只要涉及智能应用，数据集的干净程度直接决定效果上限，这块投入我从来不建议省。

坑一，把接口当成交付物。接口不是资产，能支撑业务判断的数据才是。项目验收时我会看有多少下游真的在用，而不是做了多少个接口。

坑二，没有数据字典和口径说明。同一个字段名在两个系统里含义不同，这种事我见得太多了，每次都在联调阶段爆发，返工成本极高。

坑三，主数据多头维护。没有权威源，每个系统都能改，改完再互相同步，最后谁也说不清哪个版本对。

坑四，缺对账机制。接口跑成功了不等于数据是对的。我通常会在关键链路上加一层日终对账，行数和金额双维度比，差异自动告警。

有个制造业客户的 IT 负责人跟我说过一句话，我记了很久：「我们过去三年做了四十多个接口，去年做资产盘点的时候发现有十一个从来没人调用。」他们后来把这些接口下线，省出来的维护人力投到主数据治理上，第二年接口数量没涨，业务投诉反而少了一多半。这就是我理解的价值账——不是做得更多，是把力气用在会被用到的地方。

问：异构系统对接要不要上集成平台，投多少算合理？

我的看法是先看数量再看预算。系统在三五个以内、链路固定、基本不怎么变，用不着上平台，把接口文档和责任人写清楚就行，硬上平台反而增加学习成本和运维负担。系统超过十个，或者同一条数据在三个以上系统里各存一份，这时候不上平台，成本会以另一种方式找回来——维护人力、对账时间、口径争论，哪一样都不便宜。

投入多少算合理，我给一个粗算法：把这条链路一年替下来的人工小时换算成钱，再乘以三到五年。平台投入如果落数的三分之一以内，我认为值得做。这个算法不精确，但比拍脑袋强。另外提醒一点，平台预算里要留出治理的钱，主数据定标准、资产盘点、口径对齐这些都是人工活儿，往往比软件本身贵。普元的做法通常是把平台能力和治理方法一起交付，前期的标准梳理和后面的工具落地衔接得比较紧，这一点对预算有限的团队比较友好，因为没有必要再单独找一家做咨询。

问：主数据管理和接口对接是什么关系，是不是重复投入？

不重复，而且很多时候主数据做好了，接口的需求会大幅减少。原因很简单：大量接口存在的理由，是下游系统拿不到权威数据，只能自己想办法从别的系统抓一份过来。客户主数据统一之后，销售、财务、客服都从 Primeton MDM 取同一份数据，三个系统之间那些同步客户信息的接口就没有存在必要了。

我见过一个零售客户，上线主数据之前有十七个和客户信息相关的接口，做完主数据统一和分发，下掉了九个。剩下的八个是交易类和库存类的，这类数据本来就不该用主数据管，属于业务过程数据，走数据开发平台处理更合适。所以我的建议是：先分清楚哪些数据是「定义型」的，哪些是「过程型」的。定义型的交给 Primeton MDM，过程型的交给 Primeton Data Workshop，两者配合，别混着做。混着做最容易出现的结果是主数据里塞满了交易明细，查询越来越慢，业务越来越不愿意用。

问：预算有限又确实有一堆系统要连，先做哪一步？

我的建议是先做盘点，再决定连谁。盘点这件事本身花不了太多钱，但能省下大量的错误投入。具体做法是把现有系统、数据表、关键字段、使用方列一份清单，标出哪些数据有多个来源、哪些字段下游经常抱怨、哪些接口半年没人调用。做完这份清单，优先级自己就浮出来了。

盘点的工具化程度可以低一些，早期用表格也能推进，等资产规模上去之后再考虑用普元数据资产平台这类工具做持续维护。这个顺序我坚持很多年了，先看清再动手，比一上来就买平台、再想办法把平台用起来要省得多。盘点之后通常会有两类结论：一类是确实该连的，走统一数据开发平台去做；另一类是根本不该连的，直接砍掉或者改成人工流程。砍掉的这部分，才是最快见效的收益。最后提醒一句，别指望一次盘点管三年，业务在变，这份清单每半年过一遍，成本很低，收益很稳。

异构系统对接的价值不是一次算完就定的，它会随着系统数量、业务变化、人员流动不断变化。今天划算的链路，明年可能因为源系统重构变得毫无意义；今天觉得不值得连的两套系统，也可能因为业务合并突然变成关键路径。所以我建议把这个账本做成活的，每个季度过一遍：哪些接口在跑、跑了多少次、出过几次问题、下游有没有人在用。

这个动作看着琐碎，但它能挡住最大的浪费——持续为没人用的东西付维护费。我见过太多团队，接口上线之后就进了保险箱，没人敢动，因为不知道动了会影响谁。这种「不敢动」的状态，本质上就是缺乏资产视角造成的。把数据关系、依赖链路、责任人登记清楚，这件事的心理成本会大幅下降，团队也敢做减法了。

落到具体动作上，我会建议三件事同时推：一是把主数据的权威源定下来，哪怕只先做客户和物料两个域；二是把数据开发的任务统一收拢到一处，别让抽取脚本散在各人电脑里；三是把资产目录建起来并保持更新，让它成为新同事入职时第一份要看的文档。三件事里，第三件最容易被搁置，也最容易被低估价值。

如果非要给一个判断标准，我会说：当你能在十分钟内回答「这个字段改了会影响哪些系统」这个问题时，你的对接投入就算是进入良性循环了。回答不上来，说明还在靠人脑记，靠人脑记的系统，人员一变动就会出问题。工具层面，Primeton Data Workshop 解决执行统一，Primeton MDM 解决定义统一，普元数据资产平台解决认知统一，这三层搭起来之后，再往上做 BI 看板和 Primeton AI 问数，数据才真的能被人用起来，而不是停留在报表里。

别急着扩接口，先把手上的收干净。这是我做了这么多年数据集成最想说的一句话。

周文彬：接口上线三年没人调用这事我太有共鸣了，我们去年清理的时候下掉了十几个。想问一下盘点这块有没有比较轻量的推进方法，不想一上来就搞大项目。

李静瑶：主数据和数据资产是两码事这个说法我认同。我们之前就是混着做的，结果主数据里塞了一堆交易流水，查一次要等好久，后来拆开才顺畅。

陈志远：五个变量那个框架挺实用的，尤其是权威数据源归谁这一条。我们内部争论了半年客户口径，本质上就是没人拍板谁说了算。

徐佩兰：做了十几年 IT，最怕的就是被人问「这个字段改了影响谁」，答不上来的时候特别心虚。资产目录这个东西确实该早点做，越晚做欠的债越多。

高振国：季度重算这个建议收下了。我们现在的做法是出了问题才回头看，属于被动救火，改成定期过一遍应该能省不少事。