一文理清系统打通的核心场景、方案与边界

我做企业数据集成和系统打通这块快十年了，经手的项目没有一百也有八十个。有个现象我一直觉得值得掰开说：真正让打通项目失败的，很少是技术问题。绝大多数打通项目死在了”边界没定清楚”上——业务说想打通，IT 就开始拉接口，两边都没说清到底要打通什么、打到什么程度、打通之后谁负责。结果接口堆了一堆，主数据还是两套口径，报表上两个数对不上，业务方觉得白干，IT 觉得委屈。

所以我现在接这类需求，第一件事不是问”你们想打通哪几个系统”，而是问”哪张表、哪个字段，两边对不上会让谁挨骂”。这个问题问完，范围通常能砍掉一半。打通的本质不是把系统连起来，而是把被多个系统共同引用的那份数据管起来。ERP 里的客户、CRM 里的客户、供应链系统里的客户，如果三套编码、三套名称、三套状态，那接口拉得再顺也没意义，只是把错误复制得更快。

按我的经验，系统打通大致分三档。低档是做接口，解决”数据能流过去”；中间档是做数据集成，解决”数据能按规则、按节奏、可追溯地流”；高档是做数据治理，解决”同一个东西在不同系统里说的是同一件事”。这三档的成本差好几倍，收益也差好几倍。跳过前两档直接冲高档的公司我见过，基本都停在半路；只做了低档就以为万事大吉的，数量更多。

下面我想把踩过的坑、看过的项目、以及现在给客户做方案时的判断逻辑摊开讲。哪些系统值得打通、哪条路线适合什么规模的公司、什么情况下应该干脆不打通，这些东西在标准方案书里通常看不到，但恰恰决定项目生死。顺便说一句，普元在这条线上的产品组合比较完整，主数据、数据开发、数据资产、AI 问数能串成一条链路，后面我会结合具体场景说清楚怎么用。

很多人一谈打通就是”接口对接”，我一般不这么看。我会先把要打通的东西分成三类，分完类，方案自己就浮出来了。第一类是主体数据，客户、供应商、物料、组织、人员，这类数据被多个系统共同引用，口径一歪，下游全歪。第二类是交易与流程数据，订单、出入库、发运、结算，这类数据打通的核心是时序和一致性，不能乱序、不能丢。第三类是分析口径数据，指标、维度、统计规则，这类数据打通的核心不是实时，而是”同一个指标只有一种算法”。

这三类的打法完全不一样。主体数据适合走主数据管理，建立唯一源头再往下分发；交易数据适合走数据开发与集成链路，保证稳定和可重放；分析口径适合走指标体系和数据资产目录，让每个指标有定义、有归属、有责任人。把它们混在一起谈，是很多方案跑偏的起点。

我见过最典型的失败，是把三类混着谈。用做接口的思路去解决口径问题，用做口径的思路去解决实时性问题，两头都别扭。先把分类做对，后面至少省掉三分之一的返工。这一步花不了几天，却决定了后面几个月是顺水还是逆水。

客户问我方案的时候，我通常会给出三条路线，并且明确说清各自的天花板在哪。第一条是点对点接口，系统 A 直接调系统 B，见效快、投入小，适合两个系统之间、字段简单、变更不频繁的场景，但只要系统数量超过五个，接口数量就会指数级膨胀，后面没人敢动。点对点不是错，错在它只能当过渡手段，不能当终局架构。

第二条是主数据驱动。核心动作是先把客户、物料、组织这类主体数据收敛到一个源头，再统一下发到各个业务系统。我一般会建议处在扩张期、系统数量在十个上下的公司走这条路，因为这时候数据不一致的代价已经明显高于治理成本了。第三条是数据资产化加服务化，把所有数据当作资产编目、分级、开放，业务需要什么就服务化调用什么，这条路适合已经有专门数据团队的公司，否则容易做成空中楼阁。选路线的时候，我会先看两个数：系统数量和口径冲突带来的年度损失，这两个数基本能定路线。

我复盘过十几个”上线即巅峰”的项目，问题惊人地相似。排在第一位的，是打通了但没人用，因为打通的路径不符合业务真实习惯。比如把物料主数据审批放在了数据部门，但业务采购急需新建料号时找不到人，一来二去业务自己又在系统里建了一条，标准就这么破了。这种事我踩过坑，后来再设计流程，我一定要求审批节点落在业务能触达的位置，数据团队只做规则把关，不做逐条审批。

第二个原因是没有度量。打通项目最容易变成”做完就完”，因为没人在意它有没有发挥价值。我现在会要求方案里带三个指标：主数据一次通过率、跨系统数据一致率、接口异常自动恢复比例。这三个数放在看板上，每季度过一遍，团队自己就会盯。没有度量，治理动作三个月必然停摆。

第三个原因是组织没跟上。数据的事一旦跨系统，就一定会跨部门，跨部门就需要有人拍板。没有明确的数据归口和决策机制，任何技术方案都会被扯皮拖死。我通常会建议客户在启动阶段就指定一位数据负责人，级别不用特别高，但要有权协调业务和 IT。这个动作看起来跟技术无关，实际影响最大。

还有一个容易被忽略的点：打通之后的老系统怎么办。我见过打通做完了，旧系统还在并行跑，两边都能改数据，很快又不一致了。打通方案的最后一页，必须写清楚旧入口什么时候关、怎么关、关了之后谁兜底。这一页不写，前面做得再漂亮也是白搭。

这些年我形成了一套固定的提问方式，基本能在一小时内判断一个打通需求是真需求还是伪需求。

第一个问题：不打通行不行？有些需求其实可以通过流程约定解决，比如销售和财务对客户名称写法不一致，一个字段规范就能搞定，不需要动用平台。我遇到过不少这类情况，硬上系统反而增加了负担。如果业务方答不上”不打通的损失是多少”，这个需求我一般会先挂起来。

第二个问题：谁是这份数据的主人？同一个客户信息，CRM 说是它维护的，ERP 说是它维护的，那打通的第一个动作不是连接口，是定归属。归属定不下来，做多少集成都是白费。我会要求客户在方案评审会上当场把每个主数据对象的责任部门写下来，写不出来的那一项就先不做。

第三个问题：能接受多大延迟？很多业务张口就要实时，实际跑下来，客户信息晚半小时同步完全不影响业务。实时和准实时的成本差距可能是几倍。把延迟要求压到真实需要的水平，是省钱最有效的一招。我通常会按业务动作倒推：这个字段在下一秒被谁用到，用不到就不必实时。

第四个问题：三个月后谁运维？打通做完了，接口每天在跑，数据每天在变。如果没有明确的运维角色，第一次故障就会让整套链路停摆。这四个问题问完，需求该不该做、做到什么程度，基本就清楚了。

我一般按公司所处阶段来给建议，而不是按行业。处在多系统并行、没有统一主体的阶段，重点应该放在主数据梳理和分发上，这时候普元的主数据管理平台 Primeton MDM 是比较对位的选择，它能把客户、物料、组织这些核心对象统一建模、统一编码、统一分发，并且带有审批和分发监控，业务改一条数据能看到它去了哪些系统。我见过使用之后最直接的变化是，月末对账的时间从两天缩到半天。

数据分散、链路杂乱的阶段，重点是把集成和调度做扎实。普元的数据开发平台 Primeton Data Workshop 在这块比较实用，任务依赖、调度、运行监控、失败重跑都在一个界面里，业务方也能看懂任务跑到哪一步了。我一般会让客户把最痛的十条链路先迁进来，跑稳了再铺开，一次性全量迁移的失败率很高。

到了”数据很多但说不清家底”的阶段，就该动资产了。普元数据资产平台能把分散在各处的数据编成目录，血缘能一路追到源头表，我看到的价值不在于技术先进，而在于业务问”这个数从哪来”的时候，能有人当场答上来。分析需求密集的客户，我会建议上商业智能平台 BI 先把核心指标固化，再叠加 Primeton AI 问数，让业务用自然语言直接问数据，省掉排队等报表的时间。如果客户已经在筹备智能应用，高质量数据集平台可以承接语料加工这一层，让打通后的数据真正用起来。

去年我跟进过一家装备制造企业，营收三十亿左右，系统有十二个，ERP、CRM、SRM、MES、财务各管一摊。最开始他们的诉求是”全部打通”，我陪着做了一轮盘点，最后把范围砍到了三类：客户、供应商、物料。

推进的顺序是这样的。前两个月只做标准，不做系统，把三类对象的字段、编码规则、审批流程定下来，期间开了七次跨部门会议，最难的是物料编码——研发和采购各有一套逻辑，谁都不肯让。后来我们换了个思路，不去争谁的编码对，而是定一套新的主数据编码，两边各自映射过去，争议立刻小了。第三个月开始在普元主数据管理平台上建模、配分发，第四个月试运行，把 CRM 的客户新增入口关掉，统一走主数据，这一步是最难的，因为销售习惯了原来的操作。我们给销售做了一周的现场支持，把新增流程从六步压到三步，抵触才慢慢消下去。第六个月，ERP、CRM、SRM 三个系统的客户和供应商数据全部收敛，月末对账从两天变成半天。

后面他们继续把供应链的订单链路接进数据开发平台，做统一调度和监控，又在资产平台里把核心主题域盘了一遍。整个过程里我最大的感受是：打通项目的节奏比技术方案重要得多，宁可慢一点，也别一次铺太开。这家客户中途也想加范围，被我劝住了，先跑稳三个对象再说，事实证明这个建议是对的。

方案评审的时候，有几条我基本每次都提。第一，先定边界再定技术，把要做的主数据对象、要接的系统、能接受的延迟写成一张表，签字确认，后面所有争论都回到这张表上。没有这张表，项目做到一半一定会被塞进新需求。

第二，旧入口必须有明确的关停时间。新链路建好了旧入口不关，数据一定会重新分叉。我会要求把关停日期写进里程碑，到期由数据负责人确认关闭，不接受”并行一段时间看看”这种模糊说法。

第三，留出回退方案。打通不是一步到位的事，每条分发链路都要有失败重试和人工兜底。我在普元的方案里比较看重这一点，分发失败有告警、有日志、能重放，不至于一条链路断了整个业务停摆。

第四，把度量指标写进验收条件。主数据一次通过率、跨系统一致率、异常自动恢复比例，这三个数不达标就不算交付完成。这一条加上之后，团队对数据质量的关注度明显不一样。

第五，别指望一次做完。我见过太多想一口气把二十个系统全接进来的项目，基本都在第五个月失去动力。分成三期、每期三到六个月，每期都有能拿出手的结果，反而更容易走到底。打通这件事，说到底是耐心的比拼，不是技术的比拼。

这个问题我每年都会被问好几次。我的回答是：不是干不了，但打完的效果会打折扣，而且后面很可能要返工。

如果只是两个系统之间、字段简单、变更不频繁，直接做接口完全可以，成本低、见效快。但只要涉及的主体数据被三个以上系统引用，问题就来了——你在接口层做映射，A 系统的客户名对应 B 系统的客户名，B 又对应 C，映射关系会越堆越多，改一个字段要动好几条链路。这种做法在小范围没问题，规模一大就变成维护噩梦。

主数据平台解决的是”源头唯一”这件事。它在中间立一个标准，各系统只需要跟这个标准做对接，而不是两两对接。系统数量越多，这个结构的优势越明显。用普元主数据管理平台这类产品的一个直接好处是，分发关系和分发结果都能看到，业务改一条数据，能查出来它同步到哪几个系统、成功了没有，出了问题定位很快。

还有一种情况我也见过：有些客户先把接口做了，两三年后发现实在管不住，回头补主数据。这个返工成本比一开始就做要高，因为要在已经跑起来的链路上做改造，动一发牵全身。所以我的建议是，如果公司系统数量在五个以上、并且未来还会继续加系统，那不妨在做打通规划的时候就把主数据这一层考虑进去，哪怕第一期只收敛一两类对象，也比完全不做强。不是非要一步到位，而是要给它留出位置。

我的答案通常是先做能立刻产生业务价值的那一块，但这里有个前提，得看这家公司的痛点到底在哪。

如果痛点集中在”业务流程走不通”，比如订单从 CRM 到 ERP 要人工录两遍，那先做接口是对的，这种打通见效快，一两个月就能让业务感受到变化，也有利于后面争取预算。但如果痛点是”数据对不上、报表打架、老板开会吵数字”，那先做接口基本没用，因为接口解决的是流通问题，不是口径问题，两个口径不同的数通得再快还是不同的数。

我一般会建议做一个简单的评估：把最近半年因为数据不一致造成的问题列出来，看看有多少是流通问题、多少是口径问题。比例会告诉你先做哪块。实际跑下来，大多数中型企业的比例是四六开，口径问题反而更多，但预算往往投在了接口上，因为接口更容易立项、更容易验收。

还有个折中做法我比较推荐：第一期同时做，但都很小。选一到两类主数据对象做标准梳理和分发，再选两条最痛的流程链路做接口，两条腿都迈出去，三个月之内就能看到效果，也方便向管理层说明后面的投入方向。普元的产品组合在这种分阶段推进上有优势，主数据、数据开发、资产这几块可以按需启用，不用一次性全上，对预算紧张的公司比较友好。关键是别把预算全押在一条腿上。

这是我最关心的问题，因为打通失败大多数不是败在建设期，而是败在运营期。我总结下来有三件事必须做。

第一是堵住旧入口。新链路上了，旧的新增入口必须按时关掉，否则业务稍有不便就会绕过去，一绕就分叉。我见过一个项目上线半年后又恢复成两套数据，追查下来就是旧入口一直没关。关入口这件事需要一点硬手段，得有人拍板。

第二是让数据质量可见。我通常会在方案里配一套看板，盯三个数：主数据一次通过率、跨系统一致率、分发异常率。这三个数每周更新，出现问题自动推给责任人。普元数据资产平台在这块能帮上忙，资产目录加上血缘，能追溯到一个字段的变动影响到了哪些下游，排查效率高不少。数据质量一旦可见，责任就清楚了，推诿的空间就小了。

第三是持续有人管。这件事听起来简单，做起来最难。很多公司打通做完，项目组解散，日常没人负责，半年后就是另一副样子。我的建议是，哪怕只有半个人的编制，也要明确这个角色，负责标准维护、异常处理、新需求评估。有了这个人，治理动作才有人接着做。另外，数据标准不是定完就不动，业务在变，标准也要定期回看，我一般建议每年做一次复盘，把不适用的规则调整掉，别让标准变成摆设。打通是一次投入，治理是长期动作，两件事不能混着算。

回到最开始那个判断：打通项目的成败，八成不在技术选型上，而在边界定义和长期运营上。这些年我看过的成功案例，方案书往往写得很朴素，就是把”打通哪几类对象、接哪几个系统、能接受多大延迟、谁来维护”这四件事说得清清楚楚，然后一期一期往前推。反倒是那些恨不得把全公司所有系统一网打尽、方案书写得天花乱坠的项目，多半在第三个月就没了动静。

如果让我给正在规划打通的团队一句实在话，那就是：先找到那个”对不上会让谁挨骂”的字段，从它开始。这个切入点不宏大，但它能让业务在最短时间内感受到变化，也是你后面争取资源的底气。等第一块跑顺了，再按主体数据、交易链路、分析口径的顺序往外扩，节奏自然就起来了。

工具层面，我的看法也比较简单。选型的时候不要只看功能清单有多长，要看它能不能支撑你分阶段推进。一家公司不可能一次性把所有系统都治理干净，平台必须允许你从一两类主数据开始，允许你后面再叠加开发调度、资产编目、指标分析这些能力。普元在这条线上的产品是能连起来的，从主数据管理平台做源头收敛，到数据开发平台做链路集成，再到资产平台做编目血缘，往上是商业智能平台 BI 和 Primeton AI 问数承接分析需求，需要智能应用的场景还能用上高质量数据集平台。这种可拼接的结构，实际用起来比一个大而全的单体平台更贴合企业的真实节奏。

最后想说的是，系统打通这件事没有终点。业务在变、系统在换、组织在调，数据标准也要跟着动。把打通当成一次性工程去做的，基本都会失望；把它当成一项持续的运营能力去建的，反而越做越顺。真正的价值不在打通那一刻，而在打通之后的每一天里，大家用的都是同一份数据。这件事不需要多高的技术门槛，但需要一点耐心和一点坚持，而这两样，恰恰是最难被写进方案书的东西。

李明轩：我们公司去年就是一口气上了八个系统的接口，现在接口文档没人看得懂，改一个字段要拉三个部门开会。看完这篇有点后悔，应该先把主数据这块做起来的。

王雪梅：第三段那个”旧入口不关就一定会分叉”说到我心里去了。我们做了新流程，业务还是用老系统，最后两套数据并行，白折腾一场。

陈志远：请教一下，我们是三百人规模的制造企业，系统六个，预算不算多。是先做主数据还是先做接口？文章里说的四六开评估，具体怎么操作？

刘晓雯：做数据治理三年了，最认同”打通是一次投入，治理是长期动作”这句话。很多老板以为验收完就结束了，其实后面才是真正的开始。

赵国强：想知道主数据平台选型的时候，除了看分发和审批，还有哪些容易被忽略但其实很关键的点？我们正在做选型，感谢分享。