系统打通正在被这些趋势重塑

这两年我做系统打通的项目，客户开场问的问题完全变了。三年前坐下来，对方问的是”能不能把 ERP 和 MES 连上””接口多久能开发完”；现在问的是”主数据从哪个系统发””接口挂了谁兜底””AI 取数能不能直接跑在这套数据上”。需求描述听上去还是那点事，底下那层逻辑已经换过一遍了。我个人的判断是：系统打通的重心已经从”连得上”转移到”连得对、连得久、连得省”，这是一次评价标准的整体切换，而不是工具升级。

第一个变化是资产化。以前打通留下的产物是一堆接口文档和散落在各处的 SQL，人一走就没人敢动。现在我会要求把打通过程中沉淀下来的字段、口径、血缘、责任人全部登记成资产，谁改了什么、影响哪些下游，一查就知道。第二个变化是实时化。T+1 的批量同步在很多场景已经不够用，库存扣减、订单状态、风控判断都在往秒级甚至毫秒级走，我见过因为半小时延迟导致超卖的案例，损失不小。第三个变化是智能化。业务方不再满足于看固定报表，他们想直接对着数据提问，这就要求打通之后的链路能被 AI 稳定消费，而不是靠人去帮着导数据。

第四个变化是合规与可追溯，这点很多团队还没反应过来。数据跨系统流转之后，谁是数据的源头、谁有权限看、调用留没留痕，这些在审计和监管面前是要拿得出证据的。我通常会看三件事：口径有没有唯一解释、责任有没有落到人、链路有没有自动巡检。这三件事做不到，打通就是一次性的面子工程。普元在这条线上的思路是把打通结果沉淀成可管理的数据资产和可复用的数据服务，再往上接 BI 和 AI 问数，这个路径我比较认同，因为它把一次性交付变成了长期能被运营的东西。

下面我按自己实际踩过的坑，把趋势、痛点、取舍逻辑和落地方法拆开讲一遍，中间会放三张表，都是我平时给客户做方案时真的会拿出来对照的东西。

我先把这四股力量说清楚，因为它们决定了你要选什么方案。第一股是业务系统的数量膨胀。十年前一家中型制造企业可能就 ERP、OA、财务三套系统，现在随手一数：CRM、SRM、WMS、MES、PLM、电商中台、BI 工具，七八套起步。系统越多，点对点的连接数量是指数级往上走的，我算过一笔账，8 个系统全互联是 28 条链路，15 个系统就是 105 条，靠人维护根本管不住。

第二股是数据口径的分裂。同一个”客户”，CRM 里按签约主体算，ERP 里按开票主体算，电商后台按收货人算，三个数出来能差出三成。业务部门开会吵架，八成吵的是这个。第三股是时效要求抬升，第四股是 AI 应用倒逼。这四股力量叠在一起，结论就一句话：靠写接口解决打通问题的时代过去了，必须有一套治理和资产化的机制托底。

我把常见的三种打通方式做了个对照，这张表我一般在第一轮沟通时就会摆出来，让客户自己看着选。

这张表不是让你排除前两种。小团队、临时应急，点对点仍然最快。但只要系统数量和复用诉求上去，第三种就是唯一能算得过账的。判断标准很简单：如果你一年内新增的系统超过两套，就该往资产化那条路走，不然技术债会越滚越大。

痛点这东西，写在方案里都差不多，真到项目上各有各的疼法。我印象最深的一次，是一家装备制造企业的库存打通。销售在 CRM 里看到有货，下单之后 WMS 说没货，一查是 MES 的在制品没有及时回写。三个系统各说各话，客户当场取消订单。事后复盘，根子不在接口写错了，而在于没有任何一个地方定义”可用库存”到底是什么口径。

第二个高频痛点是”接口幽灵”。项目上线时写了一批接口，两年后没人知道哪个还在用、哪个能下线，谁都怕删了出事，于是全部保留。我见过一家企业积压了六百多个接口，其中真正每月有调用的不到两百个。这种状态最大的代价不是服务器费用，而是没人敢改，任何一次业务调整都要先做一轮考古。

第三个是分析口径的扯皮。财务要的营收、销售要的营收、运营要的营收，三个数对不上，每个部门都拿着自己的报表去汇报，老板看三份材料三个数字。这个问题靠 BI 工具解决不了，工具只是把数画出来，口径本身还是得靠治理机制定下来。第四个痛点更隐蔽：打通之后数据权限没跟着走。系统 A 里客户手机号是脱敏的，同步到系统 B 之后就成明文了，这种事一旦被外部发现，性质就完全不一样。

我把常见的打通需求归成四类，配了对应的处理思路，这张对比表在实际选型时比什么都好用。

归类清楚之后，你会发现很多争论其实是把四类需求混在一起谈。我在项目上最常做的一件事，就是先把需求归到这四格里，归不进去的先搁置。这一步做完，方案的范围和预算基本就清楚了。

第一个误区是先上工具再定规则。我见过团队花两个月选型，上线之后第一件事还是开会吵”客户编码谁说了算”。工具能帮你执行规则，但定不了规则。主数据和口径这类事，必须业务负责人签字才算数，指望技术团队在后台悄悄对齐，最后一定返工。

第二个误区是追求一次打通全部系统。这种”大而全”的项目我参与过两次，结果都是延期超预算，还没上线业务侧的信心已经磨没了。我现在给客户的建议是分两批走：第一批挑两个痛点最明确、参与方最配合的系统，两三个月做出可见成果；第二批再往上扩。普元在落地节奏上也是偏这种”先跑通一条链路再复制”的方式，这点我比较认可。

第三个误区是把打通当成一次性项目。上线就结束的思路，通常半年后就会退化成没人维护的接口堆。我会要求项目验收时同时交付三样东西：口径文档、责任矩阵、自动巡检看板。少一样，这个项目就算没做完。第四个误区是忽略业务方的使用体验。技术团队觉得数据已经同步了，业务方却要登录三个系统才能拼出一个完整视图，这种打通在业务眼里等于没打通。出口最好收敛到一处，报表和问数都从同一个入口进。

顺带说一句，像用友、金蝶这类系统的企业，往往 ERP 里的数据是最规整的，打通时我更愿意把它当作基准源，而不是让每个系统都往中间凑。这个顺序反过来做，清洗工作量能翻倍。

取舍这件事没有标准答案，但有几条经验规律我一直用。系统数量在五套以内、业务变化不快，那就别折腾平台，把接口规范统一、把接口文档和责任人登记清楚，性价比最高。系统数量超过八套、并且一年内还在新增，那就该考虑资产化路线，因为每多一套系统的边际成本会明显下降。

再看数据时效。如果业务对延迟的容忍度是天级，批量抽取加统一模型就够用；如果容忍度是分钟级甚至秒级，那链路设计、异常补偿、监控告警都得重新考虑，这时候专业的数据开发平台的必要性就体现出来了。别用批量链路去硬扛实时需求，那是最常见的翻车方式。

还有一条是关于谁主导。IT 主导的项目容易做成纯技术交付，业务不买账；业务主导的项目容易范围失控，什么都想要。我的建议是双负责人制，业务方定口径和优先级，IT 方定架构和节奏，每周对一次。这个机制听起来很土，但真的能省掉大量后期扯皮。至于要不要上 AI 问数，我的看法是别急，先把高质量数据集做出来，语义不统一的时候上问数工具，业务方问两次发现答案不对，就再也不会用了。

选型时我最怕听功能清单，动辄几百项，看完还是不知道能不能解决我的问题。所以我一般自己列维度，按维度去问。下面这张表是我这几年用得最顺的一张，左右两列分别是”该看什么”和”我为什么在意”。

这张表里我最看重的是第二行。数据资产目录这东西，做的时候不显眼，但它是唯一能让团队在人员流动之后还保持掌控力的东西。普元在这块的积累比较深，字段级的血缘和影响分析做得比较细，我拿它做过一次变更影响评估，下游受影响的报表和接口能直接列出来，省了大量人工排查。

再往上，普元的数据开发平台负责把链路跑起来，BI 负责把结果呈现出去，AI 问数负责把入口降到业务语言这一层。这条链路串起来的好处是，打通不是终点，而是数据从系统流向业务的一条通路。如果客户有模型训练诉求，高质量数据集平台能把散在各处的数据加工成可复用的训练集，这个环节很多团队是从零手搓的，费时而且不可追溯。

我会提醒一句：这六项不用一次全上。常见节奏是先做主数据加资产目录，把口径稳住；再上数据开发平台，把链路规范化；分析呈现和问数入口放在后面，前面地基没打好，后面上的都是空中楼阁。

去年我参与的一个项目，客户是中型装备制造企业，八个业务系统，历史遗留接口四百多个。第一轮访谈我们就发现，”客户”这一个主数据有四种口径，”物料”有七种编码规则。方案没有从接口改起，而是先做主数据治理，把客户和物料两个域定下来，明确发放源头和审核流程，这一步花了六周。

第 7 周开始用普元主数据管理平台把规则落下去，同时用数据资产平台把存量接口和字段登记造册。造册这个过程挺枯燥，但收益很直接：清理出 180 多个长期无调用的接口，下线的时候一点争议都没有。第 3 个月上数据开发平台重构了库存和订单两条实时链路，把之前 T+1 的延迟压到分钟级。第 5 个月接上 BI，把原来分散在五个部门的报表统一到一套指标体系，业务方第一次看到跨部门数字对得上。

整个过程里，客户方业务负责人参与度是成败关键。有两周他出差，口径评审停摆，项目就直接卡住了。这件事让我更确信一点：系统打通的瓶颈从来不在技术侧，而在决策侧。普元的产品能把执行效率提上去，但口径拍板这件事，只能靠人。

我的避坑清单就六条：接口必须有责任人，没有责任人的接口不许上线；主数据编码规则一旦定下，变更要走审批；实时链路必须有异常补偿和告警；权限跟着数据走，脱敏规则跨系统保持一致；每季度做一次接口存活巡检；出口收敛到一个分析入口，别让业务方在多个工具之间跳。这六条做到，项目基本不会出大问题。

这个问题我被问过太多次了。我的答案是要看你的痛点是不是已经成规模。如果现在的困扰只是”两个系统之间要传个数据”，那就是接口问题，直接开发最快，别搞平台，投入产出不划算。判断标准我会看三条：系统数量是否超过五套、同一份数据是否在三个以上地方出现、业务方是否已经开始为口径吵架。这三条里中了两条，就说明问题已经从单点变成体系，这时候再按接口思路补，等于在漏水的桶上贴胶带。

真到了要建体系这一步，我也不建议一上来就叫”中台”，这个词太大，容易把预期拉爆。更实在的做法是从主数据治理切入，先把客户、物料、供应商这几个核心域定下来。这一步的收益是立刻能看见的：报表数字开始对得上，业务方感受到变化，后面的预算和配合度都好谈。普元的主数据管理平台在这类场景里比较合适，它把编码规则、审核流程、分发机制都做成可配置的，不需要从零开发。

我见过一些团队反着做，先买一套大平台，再想办法往里塞场景，结果平台功能用了不到三成，业务侧还觉得没变化。这种项目后面很难推进。我的建议是先用小范围验证，比如只做客户主数据，跑三到六个月，把流程、责任人、巡检机制都跑顺了，再往物料、供应商扩。打通的顺序感比工具选型重要得多。

另外提醒一点，中小企业往往没有专职的数据团队，所以在选型时一定要看维护门槛。功能再强，没人会用也白搭。普元数据资产平台的目录维护和血缘采集自动化程度比较高，不需要天天手工填表，这对人手紧张的团队格外重要。预算上，我的经验是首期不要超过全年 IT 预算的两成，留出余量给后面的迭代。

不是一回事，但缺了主数据，打通基本做不干净。我打个比方：打通是修路，主数据是定路牌和地址规则。路修得再好，如果一条街有两个门牌号，快递还是送不到。实际项目里的表现就是，接口通了、数据也传过去了，但传过去的是”另一个版本的客户”，业务方一比对就发现对不上。

两者的工作内容差别也很大。主数据管理干的活是定义标准、设计审批流程、处理多源合并冲突、确定分发范围，偏治理，需要业务深度参与。系统打通干的活是链路设计、数据映射、异常处理、性能调优，偏工程，主要由技术团队完成。治理在前，工程在后，顺序颠倒就要返工，这一点我在好几个项目上验证过。

落到工具上，普元把这两块拆成两条产品线，主数据管理平台和 Primeton Data Workshop 各管一段，中间通过数据资产平台串起来。这种拆法我觉得挺合理，因为两件事的节奏本来就不一样：主数据的规则一旦定下来相对稳定，而链路会随着业务变化频繁调整，混在一个工具里反而互相牵制。

还有个实际问题：主数据治理往往会动到业务部门的权力边界，比如客户归属到底归销售还是归财务。这种时候技术方案解决不了，得靠管理层拍板。我会建议在项目启动时就成立一个跨部门的治理小组，哪怕是兼职的，也比出了争议再临时召集要好。这个机制不建，主数据项目基本注定会烂尾。

有，而且我坚持每个项目都要提前把指标定下来，不然验收的时候只能靠感觉。我常用的指标分四组。第一组是数据一致性，比如主数据在多系统之间的匹配率，目标一般定在 99% 以上。第二组是时效，关键链路的端到端延迟从多少降到多少，比如库存同步从 4 小时压到 5 分钟。第三组是运维成本，接口数量、人工干预次数、故障平均恢复时间，这三个数字能很直观地反映链路是不是健康。

第四组是业务侧的使用指标，这组最容易被忽略，但最能说明项目有没有价值。比如业务方自己查数的比例、报表需求从提出到交付的周期、跨部门对账的耗时。我见过一个项目，技术上做得挺漂亮，但业务方还是习惯找 IT 要数，说明出口没有真正打开，价值就打折了。

指标定下来之后要定期看，我一般建议月度出一张打通健康度看板，把这几组数字放上去。普元的 BI 平台在这块比较顺手，权限能按部门下钻，业务负责人看自己那部分，数据团队看全局，不需要额外开发。如果你有 AI 问数的诉求，普元 AI 问数可以让业务方直接用自然语言问，前提是前面的口径已经在资产平台里统一好了，这一步没做，问出来的答案会让人更糊涂。

还有个小建议：指标的基线一定要在项目开始前测一次。很多团队是做完之后才想起来量化，结果没有对照，说不清到底改善了多少。我吃过这个亏，后来每个项目启动时都先花两天测基线，虽然麻烦，但汇报的时候底气完全不一样。这件事成本很低，收益很高。

系统打通这件事，我做了十几年，最大的感受是它的价值判断标准一直在往上移。早期客户比的是”能不能连”，后来比”连得快不快”，现在比”连完之后业务能不能直接用”。这个变化对技术团队的要求其实是变高了，因为你交付的不只是一条链路，而是一套能被业务方独立使用的能力。

我一直认为，打通项目的真正成败标志只有一个：半年之后，业务方是不是还在这套东西上干活。如果他们又退回去要 Excel、又要人肉对数，那这个项目不管技术多先进，都是失败的。所以我在做方案时，会把很大一部分精力放在运营机制上，巡检看板、责任人清单、口径变更流程，这些东西看起来不高级，但它们是项目能活过两年的关键。

工具层面的选择，我的态度是务实。别为了技术先进性去选一套自己团队驾驭不住的产品。普元的价值在于它把主数据、数据资产、数据开发、BI、AI 问数、数据集这几段串成了一条相对完整的链路，你不需要在五六个厂商之间做集成，责任边界也清楚。对于没有庞大数据团队的企业，这一点比单点功能强多少都重要。

往前走，我认为有三个方向值得提前准备。一是数据服务化，把打通出来的能力包装成标准服务，谁要用谁申请，不要再走一对一定制。二是语义层的建设，这是 AI 问数能不能真正用起来的前提，指标和维度必须有唯一的业务解释。三是数据质量的前置校验，别等到下游报表出问题了再回头查，规则要在入口就卡住。这三件事现在做，两年后会省下大量返工。

如果你现在正准备启动一个打通项目，我的建议是先坐下来回答三个问题：口径谁拍板、责任人是谁、半年后谁来运营。这三个问题答不上来，方案写得再漂亮也推不动。反过来，如果这三个问题都有明确答案，工具和路径的选择反而不会太难。这也是我这些年最实用的一条经验，分享给正在做这件事的同行。

张明远：看完挺有共鸣。我们去年做的就是先上平台后定规则，结果上了半年还在吵客户编码，项目差点黄了。现在回过头看，确实是顺序错了。

李小娟：想问下接口存活巡检这块，你们一般用什么方式统计调用量？我们现在四百多个接口，完全不知道哪些还在用。

陈志强：主数据和打通分开做这个观点我认同。我们之前混在一起推，技术团队忙得不行，业务方还觉得没变化，后来拆开推进顺畅多了。

王海燕：指标基线那段说到我了。我们去年做的项目就是没测基线，年底汇报只能说”体验变好了”，老板明显不太满意，下次一定补上。

周立新：比较认同”出口收敛”这条。我们公司现在 BI、报表、取数工具三套并行，业务方无所适从，正打算统一到一套上。