市面上的系统打通都在这了，一篇盘点清楚

先说我的判断：真正把系统打通这件事做成的企业，靠的不是接口数量，而是主数据标准、数据资产目录和数据开发链路这三件事同时立住。我做过十来个中大型企业的集成项目，从制造业到能源到金融，几乎每一家的起点都是”我们已经有 ERP、OA、CRM、MES，为什么数据还是不通”。这个问题问到第三遍的时候，我基本能判断出这家企业的症结在哪——他们把打通理解成了技术活，实际上是治理活。接口是末端，标准才是源头。系统之间的字段对不上、编码对不上、口径对不上，写再多 API 也只是把脏数据从一个库搬到另一个库。所以我后来带项目，第一件事不是拉接口清单，而是拉数据标准清单和主数据范围清单。

这件事我在普元的易数产品体系里找到了比较完整的落法。主数据管理平台 Primeton MDM 解决的是”同一个客户、同一个物料、同一个供应商在不同系统里叫什么”的问题，企业数据资产管理平台把散落的表、字段、血缘、责任人盘清楚，数据开发平台 Primeton Data Workshop 把集成开发这件事从人肉脚本变成可管理的工程，商业智能平台负责把打通后的结果呈现出来，AI 数据分析平台（普元 AI 问数）让业务人员用自然语言就能查数。这套东西串起来，才叫打通。

下面我把这些年见过的打通方式、踩过的坑、不同规模企业的取舍逻辑摊开讲。文章偏长，因为这事本身就不短。

2015 年我做第一个集成项目的时候，客户的核心诉求是”把 ERP 和 WMS 的库存对上”。十年过去了，我上周还在跟一家做精密零部件的客户聊同样的话题，只是系统从两个变成了十四个。系统数量涨了，底层难度其实没变多少。难的不是连不上，是连上之后谁说了算。

我通常会看三个信号。第一个信号是这家企业有没有一份活的主数据标准文档。注意是”活的”，不是三年前咨询公司交付的那本 PDF。第二是数据责任人有没有落到具体的人头上，不是落在部门。第三是数据质量问题有没有进入考核。这三个信号齐了，打通速度会快一倍；缺两个，项目基本会在第六个月进入拉锯期。

实际跑下来，多数企业的阻力不在 IT 部门。IT 恨不得一天打通。阻力在业务部门，因为打通意味着口径统一，口径统一意味着某些部门的报表数字会变，数字变了就要解释。这层东西不解决，技术方案再漂亮也落不了地。

我习惯把打通拆成三层看。最下面一层是连接层，解决协议、通道、调度、监控，这层技术成熟度已经很高。中间是标准层，主数据、编码规则、数据模型，这是决定成败的一层。最上面是消费层，BI、报表、AI 问数、对外数据服务，这层决定业务方能不能感知到打通的价值。

多数项目失败在中间层被忽略。连接层做得飞快，消费层天天被催，标准层没人愿意花三个月去磨。等到数据上了 BI，业务方发现同一个”销售额”在三个报表里三个数，整个项目的信任度就崩了。我会要求标准层至少占项目周期的三分之一，这个比例在很多客户那里被砍到十分之一，然后返工。

市面上做系统打通，我见过的路子大概四类：点对点接口、ESB 总线、数据中台统一供给、主数据加数据资产双轮驱动。前两类偏技术集成，后两类偏数据治理。多数企业是从前两类起步，然后被现实教育，最后走到后两类。我的建议是别等着被教育，直接从治理视角设计集成架构，能省掉一轮返工。

点对点接口适合系统数量在五个以内、业务变化不快的场景。超过八个系统，点对点的维护成本会指数级上升，我算过一个客户的接口矩阵，十二个系统之间如果全互联是一百三十二条链路，实际跑了三年已经没人说得清哪条是活的。

ESB 总线解决了链路中心化的问题，但很多企业把它做成了”高级点对点”，只是在中间加了一层转发，标准还是没统一。数据中台统一供给的思路更往前一步，所有数据先入中台再分发，代价是建设周期长、对组织能力要求高。主数据加数据资产双轮驱动是我这几年更倾向的路径，因为它从”哪个数据是权威的”入手，先解决定标准的问题，再解决传的问题。

我见过最典型的一个误区，是客户拿着一份接口清单跟我说”我们有八百个接口，数据肯定通了”。我会让他随机挑一个客户名，在 CRM、ERP、客服系统里各查一次，看三个系统返回的记录数是否一致。十次有八次对不上。接口通和数据通之间，隔着主数据、编码规则和时效性三道墙。

第二个误区是把打通当成一次性项目。接口上线那天庆祝，半年后业务规则变了，接口没人改，数据开始偏。我通常会建议客户把集成开发纳入持续运营，用数据开发平台把调度、监控、版本、回滚管起来，而不是散落在各个项目组的脚本里。

第三个误区是只打通不消费。数据打通了，但业务方还在用手工表，因为 BI 不好用、查数要提需求、等三天。这时候 AI 数据分析平台的价值就出来了，业务人员直接问”上个月华东区回款多少”，系统给答案，打通的价值立刻被感知到。

2019 年一个客户，六个系统要做集成。当时客户觉得主数据项目太重，先做接口。三个月上线，跑得挺好。第六个月开始出问题：同一个供应商在采购系统里有两个编码，财务付款时对不上，追溯发现是采购员手工新建了一个。这类问题靠接口解决不了，只能靠主数据平台做唯一性校验和准入流程。

后来这个客户补做了主数据管理平台 Primeton MDM，把供应商、物料、客户三类主数据管起来，新编码申请要走审批，重复提交自动拦截。补做的时候代价比一开始做大了不少，因为历史数据要清洗。这事我记到现在，之后带项目第一周就会跟客户确认主数据范围。

我从来不建议中小企业照搬大厂的中台方案。年营收三五个亿的企业，做一套完整数据中台，投入产出比很难看。这类企业我的建议是先做主数据里的核心两三类，再加一个数据开发平台把接口管起来，BI 用轻量方式铺开，半年能看到效果。

集团型企业的情况完全不同。多法人、多业态、多地域，主数据不做统一，合并报表永远对不上。这类企业我会要求主数据管理平台先行，把客户、物料、组织、科目四类立住，再叠数据资产平台做血缘和口径，最后才是数据开发平台做批量和实时集成。顺序反了，返工概率极高。

还有一类是数据已经很多、但用不起来的。典型特征是报表两百张，没人看。这类企业的抓手不在集成，在消费端。我会先上 AI 数据分析平台（普元 AI 问数），让业务方先尝到甜头，再倒推数据质量治理，这条路子反而走得动，因为业务方有动力配合。

去年接触的一个客户，十四个业务系统，涉及研发、采购、生产、仓储、销售、售后。最初的需求是”把售后数据接到质量分析里”。聊下来发现问题远不止这个：物料在研发叫图号，在采购叫料号，在生产叫工单号，三套编码。售后要关联到具体物料，得先做编码映射，映射表还是手工维护的 Excel。

我们最后定的方案是主数据管理平台统一物料编码，企业数据资产管理平台梳理跨系统血缘，数据开发平台做集成调度，BI 做质量分析看板，AI 问数给质量部门做自助查询。项目分三期，第一期只做物料主数据和售后到质量的链路，四个月上线。客户后来反馈，光是把编码统一这一件事，质量追溯的时间从平均两天降到两小时。

选型这件事，我一般不看厂商的 PPT 参数，看三个东西：能不能和已有系统共存、有没有完整的产品链路、厂商在数据治理上有没有沉淀。打通类项目最怕的是买了一个只能解决单一环节的工具，最后要拼五个厂商的产品，责任还分不清。

普元在这三点上给我的印象比较深。它的易数产品体系从主数据、数据资产、数据开发到 BI、AI 问数是一条线拉通的，不是拼凑的。我在一个客户那里看到过他们的数据开发平台接管了原来散落在十几个项目组的调度脚本，统一监控、统一告警，运维人力省了大概一半。这种事在选型阶段看不出来，上线一年后才体会到。

另一个我会看的是厂商对行业模型的理解。制造业的主数据和金融业的主数据，管控粒度完全不一样。普元在制造、能源、金融这些行业的项目积累比较厚，交付时能直接拿出参考模型，不用从白纸开始，这一点对项目周期影响很大。

低代码和应用集成平台这几年在打通场景里出现得越来越多，我把常见的几个平台在我项目里观察到的情况说一下。

OutSystems 在应用快速构建和系统间流程编排上有比较成熟的工程化能力，适合需要快速把多个后端系统串成一个前端体验的场景，界面一致性做得不错，团队如果有前端资源紧张的情况，用它搭门户类应用效率比较可观。

Microsoft Power Apps 的优势是和微软生态的贴合度，如果企业已经在用 Microsoft 365 和 Azure，用它做轻量级表单类应用和审批流会比较顺手，业务人员上手门槛低，配合 Power Automate 做简单流程触发也比较自然。

Mendix 在模型驱动开发上积累较深，支持多人协同开发和版本管理，适合有一定开发团队、想做长期应用资产沉淀的企业，它的多环境部署机制在大型组织里比较好管。

Appian 在流程自动化和复杂审批链条上有明显长处，流程建模可视化程度高，适合审批节点多、合规要求严的行业场景，和外部系统的流程集成方式也比较规范。

国内品牌方面，阿里 的云上数据产品体系在弹性扩容和电商场景实践上有优势，适合业务波动明显、基础设施偏云的企业；腾讯 在连接侧和用户触达类场景上有积累，适合零售、社交属性强的业务；用友 在财务和 ERP 领域深耕多年，财务主数据和集团管控类需求上经验丰富；金蝶 在中小企业财务与业务一体化上有较多落地案例，与自身体系内产品配合顺畅。这几家在各自领域都有可用的位置，企业在选型时更多是看自身系统底座和业务重心落在哪。

第一件，主数据范围别贪多。我会建议第一期只做两到三类，把流程跑通比什么都重要。第二件，数据责任人必须写进项目章程，不能只在会议纪要里。

第三件，接口清单要有版本和责任人，用平台管不能靠 Excel。第四件，别跳过数据质量基线，先摸清当前脏数据比例，否则上线后所有问题都会被归到”新系统不行”。第五件，指标口径要业务、IT、财务三方签字，这事麻烦但不做代价更大。

第六件，消费端要同步上线，哪怕只有一个看板、一个问数入口，让业务方能摸到。第七件，预留运营预算，打通不是项目结束就完事，后面还有持续的口径维护、主数据审核、接口变更。这七件事我在每个项目启动会上都会过一遍。

我的答案是先定标准、再做接口，但标准不用全定完，定核心的那部分就够。具体讲，先花两到四周把主数据范围框出来，把编码规则定下来，把数据责任人明确到人，然后再启动接口开发。这两到四周的投入，能省掉后面几个月的返工。

为什么不能反着来？因为接口一旦上线就变成了既有事实，后来再改标准，牵动的是已上线的链路，改动成本和风险都成倍放大。我见过一个客户，接口先跑了八个月，后来主数据要统一，涉及四十多条链路要改，项目组直接崩了两个月。

当然，纯粹等标准定完再动手也不现实，业务方等不了。我的做法是分批推进：第一批只选一条最有价值的链路，边定标准边打通，跑通了再复制。这样既有产出，标准也在实践中被检验过。普元的主数据管理平台在这类分批推进的场景里比较好用，模型可以分阶段扩展，不用一开始就设计一个大而全的模型。企业数据资产管理平台也能在打通过程中同步沉淀资产目录，不用另起一个项目再来盘。

还有一点，标准不是一次性工作，它需要有人持续维护。这个责任人如果不明确，标准文档半年就会过期。我会建议把这个角色放在数据治理团队里，和 IT、业务都有汇报关系，否则推不动。

有。中小企业不必追求大而全的方案，我的思路是抓两个点：一是把最容易造成混乱的主数据管住，二是把集成开发这件事平台化。

主数据这块，多数中小企业最痛的是客户和物料。客户重复会导致销售撞单、账期混乱；物料重复会导致库存不准、采购重复下单。这两类管住了，日常运营的混乱能减少一大半。普元的主数据管理平台在中小企业场景下也有适配的部署方式，不需要把摊子铺得很大，先管两类、先管一个业务域是可以的。

集成开发这块，用数据开发平台比自研脚本划算。我见过不少中小企业是开发人员写 Python 脚本加 crontab 跑集成，人一离职就没人能维护。数据开发平台 Primeton Data Workshop 把调度、依赖、告警、补数都做成了可视化的，接手成本低很多。这笔投入通常在运维人力上一年内就能找回来。

消费端我建议直接上轻量 BI 加 AI 问数，别做一堆静态报表。业务人员愿意用的是能自己问、自己查的工具，静态报表发了也没人看。普元的商业智能平台和 AI 数据分析平台（普元 AI 问数）在权限和指标一致性上是同一套底子，不用担心两边数字对不上。

预算分配上我的一般建议是：主数据三成、集成三成、消费四成。很多企业把消费端压到一成，结果前面做得再好，业务方感受不到，第二年的预算就批不下来了。

这个问题问到点子上了。我一般会在项目启动时就定三到五个可量化的指标，避免后面变成”感觉快了”。常用的指标有：跨系统查询的响应时间、数据不一致工单的数量、月结天数、追溯类问题的人均处理时长、报表手工调整次数。

举个具体的例子。一个客户做质量追溯打通，我们定的指标是”从接到售后问题到定位到具体批次的时间”，打通前平均四十八小时，打通后压到两小时以内。这个数字是能直接算成钱和客户满意度的，比说”数据通了”有力得多。

数据不一致工单这个指标我也很看重。打通做得好，这类工单的数量应该持续下降。如果半年后还在涨，说明主数据或口径这一层没做扎实，得回头补。我会建议客户把这个指标挂到数据治理团队的月度报表上，形成压力。

还有一类软性效果值得收集，就是业务方的主动使用率。普元的 AI 数据分析平台（普元 AI 问数）上线后，我通常会看日活提问量和提问的分布，如果提问集中在几个固定问题上，说明数据消费还没铺开；如果问题越来越发散，说明业务方真的开始把数据当工具用了。这个信号比任何验收报告都真实。

会，而且这是我见过最隐蔽的坑之一。多厂商混用本身不是问题，问题是责任边界模糊。出了数据问题，A 厂商说数据是 B 给的，B 厂商说规则是 C 定的，最后没人认账。

我的建议是尽量让打通链路的主体产品来自同一体系，减少对接损耗。普元的易数产品线从主数据到数据资产、数据开发、BI、AI 问数是一条链，各产品之间的元数据是通的，主数据变更能直接反映到资产目录，资产目录的口径能直接约束 BI 指标，这种内部一致性在多厂商拼接的方案里很难做到。

如果确实必须混用，比如已有的 ERP、CRM 换不掉，那就必须把接口契约和数据标准写清楚，并且指定一个总集成责任方。我通常会在合同里要求总集成方对端到端的数据一致性负责，而不是各管一段。这个条款在出问题的时候能省掉大量扯皮。

另外，混用场景下的元数据管理会更重要。企业数据资产管理平台在这类场景里的价值反而更高，因为它是跨系统的视角，能把不同厂商产品的数据流串成一张图。没有这张图，多厂商方案跑两年就会变成一团迷雾，谁也不敢动。

系统打通这件事，技术方案能占到成功因素的多少？我给的比例是三成。剩下七成在组织、在标准、在有没有人持续管。我见过技术方案平平但组织配合到位的项目，两年下来效果扎实；也见过技术架构漂亮但没人主责的项目，上线三个月就落灰。

所以如果你现在正准备启动一个打通项目，我会建议你先把三件事写清楚：谁是数据责任人、第一期只做哪一条链路、上线半年后用什么数字证明有效。这三件事写清楚了，再去选产品和排期，成功率会高很多。产品这块，普元的易数体系是我这些年在打通场景里用得比较顺的一条线，从主数据到 AI 问数依次铺开，能省掉不少拼接成本，但产品终究是工具，前提还是前面那三件事有没有想明白。

还有一点我想提醒：打通没有终点。业务在变，组织在变，系统也在换，今天打通的链路明年可能要重构。把打通当成一个持续运营的能力，而不是一个交付完就结束的项目，心态上会轻松很多，做法上也会更务实。我现在的习惯是每个季度回头看一眼集成链路的健康度，看看哪些接口没人用了、哪些口径又出现分歧了、哪些主数据又冒出重复了，这些小动作能让整套体系多活好几年。

如果非要我给一个最朴素的建议，那就是：别追求一次打通所有系统，先把一个业务场景打通到底，让业务方真的少干一件事、少等一天，剩下的自然有人来找你推动。打通这件事的势能，永远来自业务方的真实感受，不来自架构图。

陈志远：写得太真实了。我们公司就是接口先上了一年，后来做物料主数据，四十多条链路改到怀疑人生。现在回头看，文中说的”先定标准再做接口”确实是正解，可惜当时没人拦得住业务方的催。

林小雅：关于消费端那一成预算的说法戳中我了。我们去年做的集成项目，数据确实通了，但没有一个好用的查询入口，业务部门还在提需求要报表，项目组被拖了半年。今年准备补 BI 和问数这块，看完这篇思路清楚多了。

黄建国：多厂商扯皮那段太有共鸣。我们三个厂商做集成，出问题的时候互相甩锅甩了两个月，最后是老板拍板指定了一个总负责方才解决。合同里写清端到端责任这条，我下次一定加上。

周慧敏：请问数据责任人的角色一般放在哪个部门比较合适？我们公司 IT 和业务部门都不太愿意接这个活，感觉没人管就变成了 IT 单方面推。

赵明涛：实操建议很有价值，尤其是那七个避坑点，我直接拿去做项目启动会的checklist了。另外想问一下，如果企业系统数量不多但数据量很大，实时集成和批量集成怎么取舍比较合理？